前阵子接了个定制终端项目Android 13系统屏幕物理横装需求就一句话所有界面必须横屏锁屏、通知栏、控制中心、第三方App谁都不许竖过去。一开始我觉得这活儿简单无非锁个方向真动起手来才发现Android 13想把一个设备做成“完全横屏”坑比老版本多了一倍。这篇把完整技术链路和踩坑记录写出来给做固定方向设备的系统开发者和方案商做个参考普通用户想靠App锁方向实现同样效果在Android 13上基本走不通看完你应该就明白为什么了。1. 为什么Android 13上想完全横屏这么难1.1 常见的锁方向办法怎么在13上一个一个失效先说设置里的“锁定屏幕旋转”。这个开关只是把自动旋转关掉对应Settings里的accelerometer_rotation0和user_rotation一个固定值。它拦得住重力感应但拦不住App的方向请求。你随便装一个写死了screenOrientationportrait的App系统照样会为了它切回竖屏。所以“旋转锁定”从来不是完全横屏的答案最多算个临时方案。第三方强制旋转工具比如早期常见的Rotation类App原理一般是前台控制加无障碍服务再通过反射去调WindowManager/ActivityManager的隐藏接口。在Android 12上部分还能用到了Android 13非SDK接口限制名单调整了一轮很多反射调用直接抛NoSuchMethodException。我测试的时候同一个App在12上还能把界面掰横刷到13上没几分钟就闪退或者失效工具作者更新也很吃力。自己写反射的话在userdebug构建上还能摸到部分接口一旦切到user构建反射路径基本被掐死。还有一类方案是在自己的App里反复setRequestedOrientation。这种对单个应用有效对系统UI、锁屏、输入法、通知面板这类系统级窗口完全无效而且会和系统方向决策打架。结论很直接在Android 13上想“完全横屏”老老实实走系统层定制要么改AOSP源码要么用平台级overlay没有第三条捷径。1.2 Android 12L/13对方向策略的收紧点Android 12L开始Google明显在往“大屏不强制方向”的方向走。原因也好理解平板上App横竖屏混用是常态如果所有App都能通过screenOrientation把系统硬掰到某个方向用户体验会很割裂。所以Google在框架里加了一套“忽略应用方向请求”的机制对应的资源就是framework-res里的config_overrideForceOrientationMethod。这套机制原本是为Pixel这类大屏设备准备的让系统可以直接无视App带过来的方向请求强行按设备方向显示。这套机制对做固定方向设备来说非常关键。但问题在于默认值是0也就是不生效。你要真用起来要么改framework-res的config.xml要么给你的设备加一个针对framework-res的overlay。改完之后第三方App写死的竖屏方向字段就不再能把系统拉走了。这是Android 13实现“完全横屏”和旧版本最大的不同以前是没人给你提供统一开关现在是有人提供了开关但藏在framework层不开就不生效。2. 把方向决策链路梳理清楚再决定改哪一层2.1 一次屏幕旋转从传感器到显示要过几道手续我建议动手前先花十分钟把方向决策链路过一遍不然改起来容易瞎猫碰死耗子。一次旋转大体经过这几层传感器上报数据WindowOrientationListener计算当前物理朝向。PhoneWindowManager按当前屏幕状态是否锁自动旋转、是否有特殊Policy给出建议方向也就是getProposedRotation()。DisplayRotation拿到建议方向后判断是否真的需要切换需要就调用setRotation()。DisplayContent.rotateDisplay()真正执行旋转更新DisplayInfo、Configuration通知SurfaceFlinger做画面重定向。SurfaceFlinger设置DisplayProjection把图层合成结果旋转到对应方向InputDispatcher同步调整触摸坐标映射。这个链路很像公司里的审批流程传感器是“发起人”PhoneWindowManager是“部门经理”DisplayRotation是“审批岗”DisplayContent是“执行岗”。你想强制横屏最省事的做法不是在“发起人”那边天天提交横屏申请而是直接给“审批岗”下一道死命令不管谁提什么全给我批成横屏。2.2 应用方向请求为什么能把系统拉回竖屏这里有个关键认知要修正系统方向从来不是一个全局“死值”它更像一个“取各方请求后的最终结果”。每个ActivityRecord都有自己的screenOrientationSystemUI里有Keyguard方向甚至对话框都有方向偏好。DisplayContent在计算最终方向时会把这些请求汇总起来谁在最顶层谁说了算。这也是为什么你明明把系统切成了横屏一打开某个强制竖屏的App整个系统就横屏转竖屏——因为那个App的请求优先级最高系统要满足它就得整体旋转。理解了这一点你就知道“完全横屏”不能只锁Display的rotation还必须把应用方向请求这个变量压掉否则任何一次Activity切换都可能触发反方向旋转。2.3 “完全横屏”拆成三个可控点把这些链路理清楚后“完全横屏”就变成三个明确的可控点可控点涉及模块主要手段不处理的风险系统显示方向固定为横屏DisplayRotation、DisplayContent源码锁rotation某个窗口或App把系统拉回竖屏应用方向请求失效framework-res configoverlay覆盖config_overrideForceOrientationMethod强制竖屏App打开后整体翻转SystemUI横屏编排SystemUI资源/代码overlay资源或源码适配锁屏、通知面板布局错乱后面几节按这三个点展开每个点我都写了实际改法和验证方法。3. 核心改造一把系统显示方向锁死在横屏3.1 DisplayRotation里直接定死结果先说明前提下面改动都需要在你自己的AOSP源码树上进行或者以overlay方式打进系统没有系统权限是做不到的。我用的第一个改动是DisplayRotation.updateRotationUnchecked()。Android 13里这个文件在frameworks/base/services/core/java/com/android/server/wm/DisplayRotation.java。核心逻辑就是直接返回横屏rotationOverride public void updateRotationUnchecked(boolean alwaysSendConfiguration, boolean forceUpdate) { setRotation(Surface.ROTATION_90, false); }Surface.ROTATION_90对应手机横屏往左转的方向如果你的设备装法相反需要改成ROTATION_270。至于ROTATION_0就是竖屏不会有程序员真的锁ROTATION_0还说做了横屏需求吧。这段改完之后不管传感器怎么上报不管App怎么请求DisplayRotation都不会再发起竖屏旋转DisplayContent的当前rotation会稳定在横屏值。注意我特意没保留原来的逻辑做fallback因为这类项目要的是“务必横屏”不是“尽量横屏”。如果希望保留自动旋转开关那是另一套需求不要用我这个改法。实际补丁里记得保留方法原有的日志开关和必要的前置判断上面示例只展示核心代码。3.2 开机不闪竖屏mInitialDisplayRotation也要动只改DisplayRotation会遇到一个很丑的问题开机动画和刚进SystemUI的第一帧还是竖屏然后突然横过来。这个闪变在交付验收时是会被客户盯着的。Android 13里系统初始方向由DisplayContent的mInitialDisplayRotation决定这个值来自DisplayDeviceInfo默认是自然方向0。我直接把DisplayContent构造逻辑里初始rotation的赋值改成ROTATION_90让整个系统从启动开始就以横屏为基准。mInitialDisplayRotation Surface.ROTATION_90;这样做的副作用是SurfaceFlinger的初始投影也要同步横屏。在多数高通、MTK平台上bootloader之后SurfaceFlinger会按DisplayInfo设置投影如果你发现开机动画仍然竖屏那就需要到平台侧看ro.sf.hwrotation这个属性。它和DisplayContent里的rotation不一样是给硬件合成层用的高通平台尤其喜欢用它来定物理面板方向。所以更彻底的做法是如果你的屏幕就是物理横装在lk/uefi、内核dts、SurfaceFlinger属性三层都按“面板自然方向横屏”去配Android层根本不用强制横屏所有东西天然就是横屏。我这次因为硬件已经开模没法改物理面板才选择在系统层锁横屏。这是我反复强调的经验能改硬件层的方向就别在软件层硬掰软件层强制旋转多多少少会带来时序、性能、抗锯齿上的代价。3.3 让第三方App的方向请求彻底失效锁死DisplayRotation只是让系统不主动转出去但如果某个Activity明确写了screenOrientationportraitDisplayContent在计算方向时仍然可能为了满足它而要求旋转。压掉这个变量才是Android 13上“完全横屏”的真正战场。最值得用的就是framework-res里的config_overrideForceOrientationMethod。我在自己树上加了这样一个overlay来验证!-- overlay/frameworks/base/core/res/res/values/config.xml -- resources integer nameconfig_overrideForceOrientationMethod1/integer /resources这个配置的作用是告诉DisplayContent应用发来的方向请求不用全盘照收按设备当前方向处理。AOSP 12L/13里DisplayContent会读取com.android.internal.R.integer.config_overrideForceOrientationMethod官方注释把取值定义成一组枚举0是默认不覆盖1是强制覆盖成设备方向还有一个取值是只在App没声明方向时才覆盖。具体你的分支上哪个值对应哪种行为编译前一定去源码里确认不同release之间有过调整。加了overlay以后我特意装了那种强制竖屏的App做测试系统纹丝不动通知栏也保持横屏。这一步建议和3.1联合使用双保险DisplayRotation保证系统不主动转config保证应用不能逼系统转。4. 核心改造二SystemUI在横屏下的编排适配4.1 SystemUI为什么经常是最后暴露问题的地方系统方向锁死后很多人以为大功告成结果一拉到通知栏发现布局还是竖屏逻辑。原因在于SystemUI并不是简单把View转个角度内部很多页面按“可用宽高”来编排而Configuration里的orientation是否更新到位直接影响布局。Android 13的SystemUI本身支持横屏但它是按“横竖屏都可用”去设计的不是说所有页面在纯横屏下都好看。比如快捷设置面板在横屏下会出现在屏幕上半部分横排展开这在平板上合理在窄条横屏终端上就可能挤得没法看。定位这种问题先确认Configuration有没有传到SystemUI进程。下拉通知栏后在logcat里搜SystemUI相关tag如果压根没有onConfigurationChanged的日志那就不是布局的问题而是direction change事件没有正常下发得往窗口类型、DisplayContent的通知链路查。4.2 通知栏和控制中心横屏布局验证我实际调试时最常在通知面板翻车。排查思路是先确认这个页面到底是跟随Display的rotation还是自己内部定义死。通知面板属于系统的窗口理论上会跟随Display方向但SystemUI内部有模块会缓存旧的DisplayMetrics缓存不刷新就会出现“系统已经横屏但通知栏还在按竖屏布局”的假象。真遇到布局需要调整的用SystemUI overlay覆盖资源尺寸比较干净。大致操作是给系统增加一个targetPackagecom.android.systemui的overlay包里面放尺寸、padding、layout等资源编译进vendor overlay目录。Overlay的标签写法可以参考overlay android:targetPackagecom.android.systemui android:requiredSystemPropertyNamero.build.type android:requiredSystemPropertyValueuserdebug /这样不会污染SystemUI源码也方便解耦维护。提醒一句给SystemUI做overlay时软件包必须和overlay的签名/权限模型匹配否则资源不会生效。4.3 TaskBar和锁屏在纯横屏下的表现Android 12L/13引进了TaskBar这是给大屏设备的任务栏。在横屏大屏上TaskBar默认可以常驻但对很多嵌入式终端来说这个东西不仅没用还会占一条屏幕空间。你要关掉它可以去SystemUI源码里搜taskbar_enabled这个namespace下的开关或者看平台是否有对应的feature flag。不同平台差异很大别拿网上的属性名通用化在自己树里确认最稳。锁屏的坑略有不同。锁屏方向不完全由Display决定Keyguard里有自己的方向策略。如果你的锁屏界面显示出来是竖屏先检查Keyguard相关的方向资源AOSP里有种情况是Keyguard布局会按资源里的方向偏好去显示即使Display已经横屏。多数情况下把框架资源里的方向偏好改成跟随系统就能解决具体key在你的分支源码里搜landscape就能找到。5. Android 13特有坑位实测中的排查记录5.1 第三方App强制竖屏日志里看到方向被App提走了这个坑我在验证时踩得最疼。第一版只改了DisplayRotation没有动config_overrideForceOrientationMethod测试时打开公司内部一个写死竖屏的办公App整个系统直接转成竖屏。我一度以为是DisplayRotation的代码没编译进去后来抓logcat在WindowManager的tag里清楚看到当前活跃Activity的requestedOrientation被DisplayContent读走用于计算最终方向这才反应过来问题不在“系统是否愿意横屏”而在“系统是否愿意听App的话”。如果遇到类似情况先用一条命令确认当前方向相关状态adb shell dumpsys window | grep -i -E rotation|orientation看到rotation在跳再配合logcat里DisplayRotation的日志基本能确认是哪一层把方向改了。这条排查链路在13上依然有效而且因为13引入了config_overrideForceOrientationMethod诊断起来比老版本更清晰。5.2 非SDK接口限制堵死了老式反射方案Android 13上非SDK接口名单在收紧直接影响了那些不做系统定制、只靠反射解决问题的旧方案。我前期做技术预研时试过用反射去调WindowManager的updateRotation一类隐藏API在userdebug包上还能成功切到user包直接就异常。如果你的项目要求user构建就不要把希望寄托在反射上。系统定制的核心价值就在这里直接改源码或overlay不受Runtime限制影响编译期就把行为定死。5.3 触摸坐标和显示方向对不上锁完屏幕方向后我发现触摸事件偶尔对不上。现象是UI已经横屏了但点击屏幕左侧区域响应在逻辑上却对应了竖屏时的位置。这个问题的根因多半不在WindowManager而在输入系统拿到触摸坐标后映射viewport和显示rotation不一致。可以先看当前位置adb shell dumpsys input | grep -B5 -A10 Viewport如果看到viewport里的rotation是0而显示已经是横屏的rotation那输入映射和显示就是不匹配的。常见解法是调整TP驱动里的坐标参考方向或者在高通平台检查SurfaceFlinger侧hwrotation和Android层的rotation是否一致。这块没有通用补丁不同平台差异很大但把命令跑出来对照方向基本不会判断错。6. 验证、日志与交付前检查6.1 一条龙验证命令方向改造完不能只看主界面必须把下面这套命令跑一遍# 查看窗口当前方向1ROTATION_90 adb shell dumpsys window | grep -i rotation # 查看显示设备方向 adb shell dumpsys display | grep -i rotation # 查看触摸输入viewport adb shell dumpsys input | grep -i orientation跑完命令再装几个强制竖屏的App、一个不声明方向的App、一个强制横屏的App逐个打开再退出盯着屏幕看系统是否一直保持横屏。每个App退出以后回桌面再看一眼很多方向问题不是切换瞬间暴露的而是App退栈回桌面时被某个ActivityRecord的历史方向残留影响。6.2 交付前要过的检查清单我一般会在交付前把这几项逐条过掉冷启动到桌面全程无竖屏闪变。锁屏横屏灭屏亮屏后方向不回跳。通知栏下拉、控制中心展开都是横屏布局。输入法弹出时横屏按键布局没有错位。安装第三方强制竖屏App打开后系统不被带走。拔插充电、低电量弹窗等特殊场景方向不跳。横竖切换后没有残留的半屏或错乱布局。这些看起来都是笨办法但固定方向设备这类项目用户验收时真的会拿着竖屏App一个接一个装少过一项就有翻车风险。6.3 日志排查的常见思路调试方向问题我比较依赖这几个关键tagDisplayRotation、WindowOrientationListener、WindowManager。遇到方向不按预期时先抓一段完整操作日志看DisplayRotation的updateRotationUnchecked是否被调用、入参是什么、最后setRotation带的是什么值。很多时候问题不是“能不能横屏”而是“有人把横屏改回了竖屏”日志会直接告诉你元凶是谁。最后说一句个人习惯这类系统层改动建议在源码里用一个独立的patch或者overlay目录维护不要把多个平台差异混在一起不然Android大版本升级时你都不知道要重打哪个补丁。每个release发布前把方向相关的改动单独列出来过一遍能省下大把调试时间。 
长河君 · 2026/9/9 14:54:42 · 阅读 1.2k Android 13完全横屏定制：锁方向、系统适配与踩坑指南
前阵子接了个定制终端项目Android 13系统屏幕物理横装需求就一句话所有界面必须横屏锁屏、通知栏、控制中心、第三方App谁都不许竖过去。一开始我觉得这活儿简单无非锁个方向真动起手来才发现Android 13想把一个设备做成“完全横屏”坑比老版本多了一倍。这篇把完整技术链路和踩坑记录写出来给做固定方向设备的系统开发者和方案商做个参考普通用户想靠App锁方向实现同样效果在Android 13上基本走不通看完你应该就明白为什么了。1. 为什么Android 13上想完全横屏这么难1.1 常见的锁方向办法怎么在13上一个一个失效先说设置里的“锁定屏幕旋转”。这个开关只是把自动旋转关掉对应Settings里的accelerometer_rotation0和user_rotation一个固定值。它拦得住重力感应但拦不住App的方向请求。你随便装一个写死了screenOrientationportrait的App系统照样会为了它切回竖屏。所以“旋转锁定”从来不是完全横屏的答案最多算个临时方案。第三方强制旋转工具比如早期常见的Rotation类App原理一般是前台控制加无障碍服务再通过反射去调WindowManager/ActivityManager的隐藏接口。在Android 12上部分还能用到了Android 13非SDK接口限制名单调整了一轮很多反射调用直接抛NoSuchMethodException。我测试的时候同一个App在12上还能把界面掰横刷到13上没几分钟就闪退或者失效工具作者更新也很吃力。自己写反射的话在userdebug构建上还能摸到部分接口一旦切到user构建反射路径基本被掐死。还有一类方案是在自己的App里反复setRequestedOrientation。这种对单个应用有效对系统UI、锁屏、输入法、通知面板这类系统级窗口完全无效而且会和系统方向决策打架。结论很直接在Android 13上想“完全横屏”老老实实走系统层定制要么改AOSP源码要么用平台级overlay没有第三条捷径。1.2 Android 12L/13对方向策略的收紧点Android 12L开始Google明显在往“大屏不强制方向”的方向走。原因也好理解平板上App横竖屏混用是常态如果所有App都能通过screenOrientation把系统硬掰到某个方向用户体验会很割裂。所以Google在框架里加了一套“忽略应用方向请求”的机制对应的资源就是framework-res里的config_overrideForceOrientationMethod。这套机制原本是为Pixel这类大屏设备准备的让系统可以直接无视App带过来的方向请求强行按设备方向显示。这套机制对做固定方向设备来说非常关键。但问题在于默认值是0也就是不生效。你要真用起来要么改framework-res的config.xml要么给你的设备加一个针对framework-res的overlay。改完之后第三方App写死的竖屏方向字段就不再能把系统拉走了。这是Android 13实现“完全横屏”和旧版本最大的不同以前是没人给你提供统一开关现在是有人提供了开关但藏在framework层不开就不生效。2. 把方向决策链路梳理清楚再决定改哪一层2.1 一次屏幕旋转从传感器到显示要过几道手续我建议动手前先花十分钟把方向决策链路过一遍不然改起来容易瞎猫碰死耗子。一次旋转大体经过这几层传感器上报数据WindowOrientationListener计算当前物理朝向。PhoneWindowManager按当前屏幕状态是否锁自动旋转、是否有特殊Policy给出建议方向也就是getProposedRotation()。DisplayRotation拿到建议方向后判断是否真的需要切换需要就调用setRotation()。DisplayContent.rotateDisplay()真正执行旋转更新DisplayInfo、Configuration通知SurfaceFlinger做画面重定向。SurfaceFlinger设置DisplayProjection把图层合成结果旋转到对应方向InputDispatcher同步调整触摸坐标映射。这个链路很像公司里的审批流程传感器是“发起人”PhoneWindowManager是“部门经理”DisplayRotation是“审批岗”DisplayContent是“执行岗”。你想强制横屏最省事的做法不是在“发起人”那边天天提交横屏申请而是直接给“审批岗”下一道死命令不管谁提什么全给我批成横屏。2.2 应用方向请求为什么能把系统拉回竖屏这里有个关键认知要修正系统方向从来不是一个全局“死值”它更像一个“取各方请求后的最终结果”。每个ActivityRecord都有自己的screenOrientationSystemUI里有Keyguard方向甚至对话框都有方向偏好。DisplayContent在计算最终方向时会把这些请求汇总起来谁在最顶层谁说了算。这也是为什么你明明把系统切成了横屏一打开某个强制竖屏的App整个系统就横屏转竖屏——因为那个App的请求优先级最高系统要满足它就得整体旋转。理解了这一点你就知道“完全横屏”不能只锁Display的rotation还必须把应用方向请求这个变量压掉否则任何一次Activity切换都可能触发反方向旋转。2.3 “完全横屏”拆成三个可控点把这些链路理清楚后“完全横屏”就变成三个明确的可控点可控点涉及模块主要手段不处理的风险系统显示方向固定为横屏DisplayRotation、DisplayContent源码锁rotation某个窗口或App把系统拉回竖屏应用方向请求失效framework-res configoverlay覆盖config_overrideForceOrientationMethod强制竖屏App打开后整体翻转SystemUI横屏编排SystemUI资源/代码overlay资源或源码适配锁屏、通知面板布局错乱后面几节按这三个点展开每个点我都写了实际改法和验证方法。3. 核心改造一把系统显示方向锁死在横屏3.1 DisplayRotation里直接定死结果先说明前提下面改动都需要在你自己的AOSP源码树上进行或者以overlay方式打进系统没有系统权限是做不到的。我用的第一个改动是DisplayRotation.updateRotationUnchecked()。Android 13里这个文件在frameworks/base/services/core/java/com/android/server/wm/DisplayRotation.java。核心逻辑就是直接返回横屏rotationOverride public void updateRotationUnchecked(boolean alwaysSendConfiguration, boolean forceUpdate) { setRotation(Surface.ROTATION_90, false); }Surface.ROTATION_90对应手机横屏往左转的方向如果你的设备装法相反需要改成ROTATION_270。至于ROTATION_0就是竖屏不会有程序员真的锁ROTATION_0还说做了横屏需求吧。这段改完之后不管传感器怎么上报不管App怎么请求DisplayRotation都不会再发起竖屏旋转DisplayContent的当前rotation会稳定在横屏值。注意我特意没保留原来的逻辑做fallback因为这类项目要的是“务必横屏”不是“尽量横屏”。如果希望保留自动旋转开关那是另一套需求不要用我这个改法。实际补丁里记得保留方法原有的日志开关和必要的前置判断上面示例只展示核心代码。3.2 开机不闪竖屏mInitialDisplayRotation也要动只改DisplayRotation会遇到一个很丑的问题开机动画和刚进SystemUI的第一帧还是竖屏然后突然横过来。这个闪变在交付验收时是会被客户盯着的。Android 13里系统初始方向由DisplayContent的mInitialDisplayRotation决定这个值来自DisplayDeviceInfo默认是自然方向0。我直接把DisplayContent构造逻辑里初始rotation的赋值改成ROTATION_90让整个系统从启动开始就以横屏为基准。mInitialDisplayRotation Surface.ROTATION_90;这样做的副作用是SurfaceFlinger的初始投影也要同步横屏。在多数高通、MTK平台上bootloader之后SurfaceFlinger会按DisplayInfo设置投影如果你发现开机动画仍然竖屏那就需要到平台侧看ro.sf.hwrotation这个属性。它和DisplayContent里的rotation不一样是给硬件合成层用的高通平台尤其喜欢用它来定物理面板方向。所以更彻底的做法是如果你的屏幕就是物理横装在lk/uefi、内核dts、SurfaceFlinger属性三层都按“面板自然方向横屏”去配Android层根本不用强制横屏所有东西天然就是横屏。我这次因为硬件已经开模没法改物理面板才选择在系统层锁横屏。这是我反复强调的经验能改硬件层的方向就别在软件层硬掰软件层强制旋转多多少少会带来时序、性能、抗锯齿上的代价。3.3 让第三方App的方向请求彻底失效锁死DisplayRotation只是让系统不主动转出去但如果某个Activity明确写了screenOrientationportraitDisplayContent在计算方向时仍然可能为了满足它而要求旋转。压掉这个变量才是Android 13上“完全横屏”的真正战场。最值得用的就是framework-res里的config_overrideForceOrientationMethod。我在自己树上加了这样一个overlay来验证!-- overlay/frameworks/base/core/res/res/values/config.xml -- resources integer nameconfig_overrideForceOrientationMethod1/integer /resources这个配置的作用是告诉DisplayContent应用发来的方向请求不用全盘照收按设备当前方向处理。AOSP 12L/13里DisplayContent会读取com.android.internal.R.integer.config_overrideForceOrientationMethod官方注释把取值定义成一组枚举0是默认不覆盖1是强制覆盖成设备方向还有一个取值是只在App没声明方向时才覆盖。具体你的分支上哪个值对应哪种行为编译前一定去源码里确认不同release之间有过调整。加了overlay以后我特意装了那种强制竖屏的App做测试系统纹丝不动通知栏也保持横屏。这一步建议和3.1联合使用双保险DisplayRotation保证系统不主动转config保证应用不能逼系统转。4. 核心改造二SystemUI在横屏下的编排适配4.1 SystemUI为什么经常是最后暴露问题的地方系统方向锁死后很多人以为大功告成结果一拉到通知栏发现布局还是竖屏逻辑。原因在于SystemUI并不是简单把View转个角度内部很多页面按“可用宽高”来编排而Configuration里的orientation是否更新到位直接影响布局。Android 13的SystemUI本身支持横屏但它是按“横竖屏都可用”去设计的不是说所有页面在纯横屏下都好看。比如快捷设置面板在横屏下会出现在屏幕上半部分横排展开这在平板上合理在窄条横屏终端上就可能挤得没法看。定位这种问题先确认Configuration有没有传到SystemUI进程。下拉通知栏后在logcat里搜SystemUI相关tag如果压根没有onConfigurationChanged的日志那就不是布局的问题而是direction change事件没有正常下发得往窗口类型、DisplayContent的通知链路查。4.2 通知栏和控制中心横屏布局验证我实际调试时最常在通知面板翻车。排查思路是先确认这个页面到底是跟随Display的rotation还是自己内部定义死。通知面板属于系统的窗口理论上会跟随Display方向但SystemUI内部有模块会缓存旧的DisplayMetrics缓存不刷新就会出现“系统已经横屏但通知栏还在按竖屏布局”的假象。真遇到布局需要调整的用SystemUI overlay覆盖资源尺寸比较干净。大致操作是给系统增加一个targetPackagecom.android.systemui的overlay包里面放尺寸、padding、layout等资源编译进vendor overlay目录。Overlay的标签写法可以参考overlay android:targetPackagecom.android.systemui android:requiredSystemPropertyNamero.build.type android:requiredSystemPropertyValueuserdebug /这样不会污染SystemUI源码也方便解耦维护。提醒一句给SystemUI做overlay时软件包必须和overlay的签名/权限模型匹配否则资源不会生效。4.3 TaskBar和锁屏在纯横屏下的表现Android 12L/13引进了TaskBar这是给大屏设备的任务栏。在横屏大屏上TaskBar默认可以常驻但对很多嵌入式终端来说这个东西不仅没用还会占一条屏幕空间。你要关掉它可以去SystemUI源码里搜taskbar_enabled这个namespace下的开关或者看平台是否有对应的feature flag。不同平台差异很大别拿网上的属性名通用化在自己树里确认最稳。锁屏的坑略有不同。锁屏方向不完全由Display决定Keyguard里有自己的方向策略。如果你的锁屏界面显示出来是竖屏先检查Keyguard相关的方向资源AOSP里有种情况是Keyguard布局会按资源里的方向偏好去显示即使Display已经横屏。多数情况下把框架资源里的方向偏好改成跟随系统就能解决具体key在你的分支源码里搜landscape就能找到。5. Android 13特有坑位实测中的排查记录5.1 第三方App强制竖屏日志里看到方向被App提走了这个坑我在验证时踩得最疼。第一版只改了DisplayRotation没有动config_overrideForceOrientationMethod测试时打开公司内部一个写死竖屏的办公App整个系统直接转成竖屏。我一度以为是DisplayRotation的代码没编译进去后来抓logcat在WindowManager的tag里清楚看到当前活跃Activity的requestedOrientation被DisplayContent读走用于计算最终方向这才反应过来问题不在“系统是否愿意横屏”而在“系统是否愿意听App的话”。如果遇到类似情况先用一条命令确认当前方向相关状态adb shell dumpsys window | grep -i -E rotation|orientation看到rotation在跳再配合logcat里DisplayRotation的日志基本能确认是哪一层把方向改了。这条排查链路在13上依然有效而且因为13引入了config_overrideForceOrientationMethod诊断起来比老版本更清晰。5.2 非SDK接口限制堵死了老式反射方案Android 13上非SDK接口名单在收紧直接影响了那些不做系统定制、只靠反射解决问题的旧方案。我前期做技术预研时试过用反射去调WindowManager的updateRotation一类隐藏API在userdebug包上还能成功切到user包直接就异常。如果你的项目要求user构建就不要把希望寄托在反射上。系统定制的核心价值就在这里直接改源码或overlay不受Runtime限制影响编译期就把行为定死。5.3 触摸坐标和显示方向对不上锁完屏幕方向后我发现触摸事件偶尔对不上。现象是UI已经横屏了但点击屏幕左侧区域响应在逻辑上却对应了竖屏时的位置。这个问题的根因多半不在WindowManager而在输入系统拿到触摸坐标后映射viewport和显示rotation不一致。可以先看当前位置adb shell dumpsys input | grep -B5 -A10 Viewport如果看到viewport里的rotation是0而显示已经是横屏的rotation那输入映射和显示就是不匹配的。常见解法是调整TP驱动里的坐标参考方向或者在高通平台检查SurfaceFlinger侧hwrotation和Android层的rotation是否一致。这块没有通用补丁不同平台差异很大但把命令跑出来对照方向基本不会判断错。6. 验证、日志与交付前检查6.1 一条龙验证命令方向改造完不能只看主界面必须把下面这套命令跑一遍# 查看窗口当前方向1ROTATION_90 adb shell dumpsys window | grep -i rotation # 查看显示设备方向 adb shell dumpsys display | grep -i rotation # 查看触摸输入viewport adb shell dumpsys input | grep -i orientation跑完命令再装几个强制竖屏的App、一个不声明方向的App、一个强制横屏的App逐个打开再退出盯着屏幕看系统是否一直保持横屏。每个App退出以后回桌面再看一眼很多方向问题不是切换瞬间暴露的而是App退栈回桌面时被某个ActivityRecord的历史方向残留影响。6.2 交付前要过的检查清单我一般会在交付前把这几项逐条过掉冷启动到桌面全程无竖屏闪变。锁屏横屏灭屏亮屏后方向不回跳。通知栏下拉、控制中心展开都是横屏布局。输入法弹出时横屏按键布局没有错位。安装第三方强制竖屏App打开后系统不被带走。拔插充电、低电量弹窗等特殊场景方向不跳。横竖切换后没有残留的半屏或错乱布局。这些看起来都是笨办法但固定方向设备这类项目用户验收时真的会拿着竖屏App一个接一个装少过一项就有翻车风险。6.3 日志排查的常见思路调试方向问题我比较依赖这几个关键tagDisplayRotation、WindowOrientationListener、WindowManager。遇到方向不按预期时先抓一段完整操作日志看DisplayRotation的updateRotationUnchecked是否被调用、入参是什么、最后setRotation带的是什么值。很多时候问题不是“能不能横屏”而是“有人把横屏改回了竖屏”日志会直接告诉你元凶是谁。最后说一句个人习惯这类系统层改动建议在源码里用一个独立的patch或者overlay目录维护不要把多个平台差异混在一起不然Android大版本升级时你都不知道要重打哪个补丁。每个release发布前把方向相关的改动单独列出来过一遍能省下大把调试时间。