Android 15 的 DisplayRotation 改动比想象中更值得关注。屏幕旋转这件事从普通手机上的传感器横竖屏切换到大屏、折叠屏上“窗口要不要跟着转”、“状态栏要不要跟着转”、“系统要不要忽略你的朝向请求”整个逻辑在 Android 15 里被翻新了好几层。很多人把 DisplayRotation 理解成“获取一下角度”的 API实际上它在系统里的地位是窗口管理器里一个完整的决策模块。这篇文章不聊官方文档里抄得到的罗列而是从机制拆解、真机落地、疑难排查三条线展开讲清楚这版系统带来的变化以及开发者在适配时必须亲手验证的那些细节。1. 屏幕旋转机制的核心拆解DisplayRotation 到底在管什么1.1 先理解 rotation 值四个数字背后的坐标系Android 里的 DisplayRotation 并不直接读陀螺仪角度系统给外部暴露的是四个离散状态ROTATION_0、ROTATION_90、ROTATION_180、ROTATION_270。这四个值表示的是显示内容相对“物理屏幕自然方向”的顺时针旋转角度。自然方向通常是竖屏居左的状态即顶部在物理上方。之所以用离散状态而不是连续角度是因为 UI、输入分发、Surface 合成都需要固定角度的坐标系来对齐触摸方向和绘制方向连续角度没有意义。这里有一个常见的误区rotation 值是针对“显示内容”定义的不是针对传感器数据。也就是说哪怕用户拿着手机横过来如果系统当前认为应该保持竖屏Display 依然报告 ROTATION_0界面上不会旋转。这个决策是 WindowManagerService 根据朝向追踪、应用配置、设备类型等多重信息综合计算出来的DisplayRotation 就是这一决策链路的“最终执行器”。1.2 AOSP 里的 DisplayRotation策略判断与分发调度在 AOSP 源码里DisplayRotation 是一个藏在 WindowManager 服务中的策略类它负责监听来自 SensorManager 的方向事件结合当前窗口状态、用户锁定设置、游戏模式、车载 / 大屏设备的特殊策略决定整块 Display 最终的 rotation。这个过程不是瞬时切换的系统会评估旋转动画时长、Activity 重建成本、应用是否声明了固定朝向然后再触发全面更新。这就解释了为什么有时候转屏会“慢半拍”或者干脆不转。因为 DisplayRotation 的决策反馈是带权重的设备物理移动、传感器阈值、应用窗口的当前模式任何一个环节不满足条件旋转请求就会被缓存甚至丢弃。很多开发者在真机上测试时发现 Activity 重建不稳定大概率不是布局问题而是旋转请求根本没走到 onConfigurationChanged 那一层就被上层拦截了。1.3 rotation 如何影响 Surface 与触摸分发DisplayRotation 一旦改变除了影响 UI 绘制方向还直接影响触摸事件坐标映射和 SurfaceFlinger 的合成矩阵。Windows 的 bounds 会做一次坐标变换InputDispatcher 也会基于新的 DisplayInfo 重新计算坐标。这就是为什么某些自定义 SurfaceView 应用在旋转后会有一段时间的触摸偏移——如果只监听 Configuration 重绘界面没有重新绑定 InputChannel坐标对齐就会出现偏差。在 Android 15 上这个逻辑没有变但大屏多窗口场景下每个窗口可能位于不同的 display area如果开发者自己画的悬浮窗、弹层或小窗不处理 DisplayRotation 变化就会出现“UI 转了弹层还在原地”的割裂感。这块建议提前用 DisplayListener 做统一分发不要在 Activity 里各自监听。2. Android 15 在旋转调度上的关键变化2.1 大屏与折叠屏场景下的强制策略Android 15 最明显的变化就是进一步强化了大屏设备的旋转策略。过去针对手机的旋转逻辑是“传感器 应用声明”的简单组合。但到了平板、折叠屏和桌面模式系统开始强制区分“可调整大小应用”和“固定方向应用”。目标 SDK 为 35 的应用如果没声明 resizeableActivity在大屏设备上打开时会触发兼容模式系统甚至会忽略应用自带的 orientation 限制强行把窗口旋转成和设备方向一致。这对老应用的影响非常直接一个在手机上 locked 为 portrait 的应用到了大屏上可能不再老实竖屏反而会被拉伸成横屏窗口。Android 15 给开发者留了退路比如 targetSdk 保持 34 以下可以暂时回避强制行为但从长期兼容角度看这不是正道。官方给出的方向是新应用必须支持 resizable并且要自己处理好 orientation 与布局的关系。2.2 orientation request 与 ignore request 的角力系统里有一套“忽略朝向请求”的机制应用说我要竖屏但系统可以根据设备形态和应用窗口模式决定是否尊重这个请求。Android 15 上这套机制的触发条件更加明确比如在平板上如果 app targetSdk 是 35且窗口处于自由模式系统会倾向于忽略应用的 locked orientation。这对视频类、阅读类、工具类应用尤其值得注意。视频应用锁横屏在平板上体验尚可但在折叠屏内屏和外屏切换时如果系统忽略请求播放器方向的突然变化会直接导致播放画面短暂黑屏。实测中比较稳妥的方案是不要只依赖 AndroidManifest 里的 screenOrientation而是结合 WindowManager 的窗口属性动态设置方向给系统一个“可协商”的空间。2.3 多显示器与 display area 的独立旋转Android 15 还放大了多显示器场景的独立性。外接显示器、无线投屏、车内副屏每个 display 都有自己独立的 rotation 状态。传统的 Context.getDisplay() 拿到的是默认 display 的信息如果应用被拖动到了 secondary display 上再按默认 display 的 rotation 做适配就会出问题。这里建议开发者优先通过 Activity.getDisplay() 或者 WindowMetrics 去拿当前窗口所在 display 的信息。DisplayRotation 的变化监听也需要用对应 display 的 context 注册避免在主屏的 listener 里去处理副屏的旋转事件。3. 实操落地监听、判断与强制旋转 DisplayRotation3.1 获取当前 DisplayRotation 的正确姿势先给一段 Kotlin 示例入门场景下获取当前旋转状态val display context.display ?: return val rotation display.rotation when (rotation) { Surface.ROTATION_0 - 竖屏 Surface.ROTATION_90 - 横屏顺时针90度 Surface.ROTATION_180 - 倒竖屏 Surface.ROTATION_270 - 横屏顺时针270度 }注意这里不要用旧的 WindowManager.getDefaultDisplay()那套 API 在多窗口和折叠屏下返回的值不一定能代表当前窗口所在的屏幕。Android 15 推荐通过 WindowManager.getCurrentWindowMetrics() 结合 getDisplay() 来拿最新的 display 信息。3.2 监听旋转变更DisplayListener 的正确用法大多数应用只需要在 Activity 重建时读取一次 rotation 就够了。但涉及悬浮窗、播放器控制层、自定义渲染层的应用就需要实时监听。val displayManager context.getSystemService(DisplayManager::class.java) val listener object : DisplayManager.DisplayListener { override fun onDisplayAdded(displayId: Int) {} override fun onDisplayRemoved(displayId: Int) {} override fun onDisplayChanged(displayId: Int) { if (displayId context.displayId) { val rotation context.display?.rotation // 这里更新 UI 方向或渲染矩阵 } } } displayManager.registerDisplayListener(listener, null) // 别忘了在 onDestroy 里注销 override fun onDestroy() { super.onDestroy() displayManager.unregisterDisplayListener(listener) }实测中一个关键点onDisplayChanged 在旋转过程中会触发多次一次是物理旋转发生一次是动画开始一次是动画结束。不要在回调里直接做重量级操作尽量用标记位加上延迟处理或者直接从 Configuration 变化里获取最终值避免无谓的布局重建。3.3 强制旋转屏幕的若干方案强制旋转常用于游戏、视频、扫码类应用认为用户必须在某个固定方向下使用。最基础的方式是 AndroidManifest 里写 screenOrientation但如果想在运行时动态切换可以用requestedOrientation ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE不过需要特别提醒这个接口在 Android 15 大屏设备上可能不会立即生效。系统会先做一次窗口模式检查如果当前窗口不支持调整大小旋转请求会被延迟到下次 onResume。所以更可靠的做法是提前声明 resizeableActivity或者在应用内自行管理一个“业务旋转标志”用自定义 View 的变换来模拟方向切换减少对系统状态转换的依赖。3.4 旋转过程中如何保住渲染状态旋转触发的 Activity 默认行为是销毁重建。如果应用里有大型列表、相机预览、WebView、视频播放器重建成本非常高。Android 15 上仍然支持通过 configChanges 声明接管旋转而不重建android:configChangesorientation|screenSize|screenLayout|smallestScreenSize加了声明之后旋转只会回调 onConfigurationChanged不会重建。但有个隐患如果只写了 orientation 而不写 screenSize某些设备上依然会重建尤其是折叠屏展开状态变化时。所以做这种优化时configChanges 尽量写全上面四个属性否则测试时在大屏设备上会踩到“偶尔不触发 onConfigurationChanged”的坑。4. 常见问题与排查技巧实录4.1 旋转后黑屏或卡在动画中间这个问题在 Android 15 的低内存设备上更容易出现。根本原因是旋转过程中 SurfaceFlinger 同时处理了 layer 的释放与新 frame 的合成应用侧老窗口销毁慢新窗口又急着显示导致画面短暂停顿。排查建议先看 Logcat 里是否出现 Choreographer 掉帧再看 WindowManager 的 rotation 日志。如果应用里使用了多个 SurfaceView尽量把它们放进同一个窗口层级不要频繁 addView / removeView。若用到了大型 Bitmap 缓存旋转前主动释放一部分内存能有效减少黑屏时长。4.2 状态栏方向和应用方向不一致多见于某些“锁了横屏但状态栏还是竖着”或者反过来的场景。这通常是因为应用没有处理 display cutout 和 insets。Android 15 上窗口的 insets 是基于旋转后的坐标重新计算的如果开发者只固定了 Activity 方向却没有调用 WindowInsets 的同步更新系统栏就会短暂错位。处理方式在 onConfigurationChanged 里重新 requestLayout并强制刷新 systemUI visibility。另外检查是否设置了 fitsSystemWindows这个属性在旋转后会滞后计算建议用 androidx 的 WindowInsetsControllerCompat 统一管理。4.3 横屏输入法弹出时界面被挤压变形输入法旋转弹出的问题在 Android 15 上依旧存在但更容易出现在 freeform 窗口模式下。究其原因是 IME 的 insets 和 display rotation 的更新时序不同输入法先过来旋转后窗口 bounds 再更新UI 就短暂变形了。实测有效的方案在 manifest 对应 Activity 上声明 android:windowSoftInputModeadjustResize并配合 ViewCompat.setOnApplyWindowInsetsListener在 insets 变化时从最新 rotation 的坐标重新计算 padding。不要在 insets 监听里做耗时操作否则输入法会卡顿。4.4 大屏设备上 orientation 设置完全失效这是 targetSdk 35 应用最容易遇到的意外行为。系统为了大屏的一致性体验可能完全忽略你 manifest 里的 screenOrientation 设置。如果你遇到过“明明锁了竖屏却自动横过来”大概率就是被 ignoreOrientationRequest 处理了。解决方案不是去对抗系统而是做兼容用 setRequestedOrientation 动态请求方向。针对折叠屏监听 onConfigurationChanged 并以窗口大小判断使用哪种布局。对测试设备做覆盖测试内外屏、展开 / 折叠、桌面模式都跑一遍。4.5 旋转后自定义绘制出现坐标翻转自己写 SurfaceView / TextureView / Camera 预览时旋转后 Canvas 坐标和业务坐标会出现偏差。根因是从 DisplayRotation 到 View 坐标的矩阵没有更新。推荐的做法是重写 onLayout 后通过 display.rotation 重新计算 Matrix并在 onDraw 里乘上这个矩阵。不要尝试用 View 自身的 rotationX / rotationY 模拟那套组件在 90 / 270 度时会出现相机视角的透视形变跟系统旋转不是一回事。5. 调试与验证命令行和日志里的真相5.1 查看系统当前 rotation 状态实战调试时比起反复拿手机转来转去更快的是用 adb 直接查 display 状态adb shell dumpsys display | grep -i mCurrentRotation\|rotation adb shell dumpsys window | grep -i mRotation\|rotation前者能看到 Display 层当前报告的旋转状态后者能看到 WindowManager 层计算出的旋转状态。如果两者不一致说明有应用层或系统层的拦截策略可以顺着这个线索排查。5.2 模拟旋转事件Android 15 测试机上可以用命令强制旋转模拟器或投屏设备adb shell settings put system accelerometer_rotation 0 adb shell settings put system user_rotation 0 # 竖屏 adb shell settings put system user_rotation 1 # 90度 adb shell settings put system user_rotation 3 # 270度这种方式对 system app 和第三方 app 有效但注意它改的是系统级的 user_rotation不经过传感器融合算法跟真实转动手机的效果仍有区别。最终兼容性测试还是建议真机在手持状态下手动旋转覆盖 0/90/180/270 四个方向。5.3 验证应用是否被系统忽略方向请求被忽略时logcat 里通常会出现 WindowManager 相关的提示。想主动确认可以连续执行两次方向切换然后观察 onConfigurationChanged 是否被调用以及界面是否保持不变。如果 Activity 既不重建也不回调 onConfigurationChanged那大概率就是被系统的 ignoreOrientationRequest 机制拦截了。建议测试时同时覆盖 targetSdk 34 和 targetSdk 35 两个版本这样能直观看出 Android 15 的兼容性差异。6. 实操心得关于 Android 15 旋转适配的几点总结我在实际工作中接触到的项目真正在旋转上出大问题的往往不是代码逻辑难写而是开发者低估了“系统决策层”的影响。Android 15 这个版本对大屏、折叠屏、多显示器的策略比以往都激进一套代码只按手机形态适配已经不够用了。如果你手头有存量应用建议优先跑一遍大屏覆盖测试把“旋转 窗口缩放 展开折叠”三个维度组合起来打一遍。不要只测竖屏和横屏两个状态180 度和 270 度同样需要验证尤其是播放器、地图、相机这类依赖全屏渲染的场景。另外保留 configChanges 接管逻辑依然划算它能降低 Activity 重建带来的卡顿和内存波动配合动态调整布局能够让用户体验平滑很多。关于 DisplayRotation 在 Android 15 上的差异我自己的体会是不要跟系统策略对着干顺着窗口化、可调整大小的方向改造应用适配成本反而更低。与其在 manifest 里写死方向不如把 UI 拆成响应式布局让系统在各种形态下都有的用。实际踩过坑之后你会发现强制方向只是兜底方案真正的长期方案是让界面无论朝哪个方向都能自洽地工作。最后再分享一个小技巧在做旋转适配测试时打开开发者选项里的“显示布局边界”可以直观看到窗口每次旋转后 insets 的变化。这个开关在找状态栏错位、输入法挤压这类问题时非常高效比看代码快得多。