企业官网建设流程全解析

前阵子接了个定制终端项目，Android 13系统，屏幕物理横装，需求就一句话：所有界面必须横屏，锁屏、通知栏、控制中心、第三方App谁都不许竖过去。一开始我觉得这活儿简单，无非锁个方向，真动起手来才发现，Android 13想把一个设备做成“完全横屏”，坑比老版本多了一倍。这篇把完整技术链路和踩坑记录写出来，给做固定方向设备的系统开发者和方案商做个参考；普通用户想靠App锁方向实现同样效果，在Android 13上基本走不通，看完你应该就明白为什么了。

1. 为什么Android 13上想"完全横屏"这么难

1.1 常见的锁方向办法，怎么在13上一个一个失效

先说设置里的“锁定屏幕旋转”。这个开关只是把自动旋转关掉，对应Settings里的accelerometer_rotation=0和user_rotation=一个固定值。它拦得住重力感应，但拦不住App的方向请求。你随便装一个写死了screenOrientation="portrait"的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 一次屏幕旋转从传感器到显示要过几道手续

我建议动手前先花十分钟把方向决策链路过一遍，不然改起来容易瞎猫碰死耗子。一次旋转大体经过这几层：

1. 传感器上报数据，WindowOrientationListener计算当前物理朝向。
2. PhoneWindowManager按当前屏幕状态（是否锁自动旋转、是否有特殊Policy）给出建议方向，也就是getProposedRotation()。
3. DisplayRotation拿到建议方向后，判断是否真的需要切换，需要就调用setRotation()。
4. DisplayContent.rotateDisplay()真正执行旋转，更新DisplayInfo、Configuration，通知SurfaceFlinger做画面重定向。
5. SurfaceFlinger设置DisplayProjection，把图层合成结果旋转到对应方向；InputDispatcher同步调整触摸坐标映射。

这个链路很像公司里的审批流程：传感器是“发起人”，PhoneWindowManager是“部门经理”，DisplayRotation是“审批岗”，DisplayContent是“执行岗”。你想强制横屏，最省事的做法不是在“发起人”那边天天提交横屏申请，而是直接给“审批岗”下一道死命令：不管谁提什么，全给我批成横屏。

2.2 应用方向请求为什么能把系统拉回竖屏

这里有个关键认知要修正：系统方向从来不是一个全局“死值”，它更像一个“取各方请求后的最终结果”。每个ActivityRecord都有自己的screenOrientation，SystemUI里有Keyguard方向，甚至对话框都有方向偏好。DisplayContent在计算最终方向时，会把这些请求汇总起来，谁在最顶层谁说了算。这也是为什么你明明把系统切成了横屏，一打开某个强制竖屏的App，整个系统就横屏转竖屏——因为那个App的请求优先级最高，系统要满足它就得整体旋转。

理解了这一点，你就知道“完全横屏”不能只锁Display的rotation，还必须把应用方向请求这个变量压掉，否则任何一次Activity切换都可能触发反方向旋转。

2.3 “完全横屏”拆成三个可控点

把这些链路理清楚后，“完全横屏”就变成三个明确的可控点：

后面几节按这三个点展开，每个点我都写了实际改法和验证方法。

3. 核心改造一：把系统显示方向锁死在横屏

3.1 DisplayRotation里直接定死结果

先说明前提：下面改动都需要在你自己的AOSP源码树上进行，或者以overlay方式打进系统，没有系统权限是做不到的。

我用的第一个改动是DisplayRotation.updateRotationUnchecked()。Android 13里这个文件在frameworks/base/services/core/java/com/android/server/wm/DisplayRotation.java。核心逻辑就是直接返回横屏rotation：

@Override 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明确写了screenOrientation="portrait"，DisplayContent在计算方向时仍然可能为了满足它而要求旋转。压掉这个变量才是Android 13上“完全横屏”的真正战场。最值得用的就是framework-res里的config_overrideForceOrientationMethod。

我在自己树上加了这样一个overlay来验证：

<!-- overlay/frameworks/base/core/res/res/values/config.xml --> <resources> <integer name="config_overrideForceOrientationMethod">1</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覆盖资源尺寸比较干净。大致操作是给系统增加一个targetPackage="com.android.systemui"的overlay包，里面放尺寸、padding、layout等资源，编译进vendor overlay目录。Overlay的标签写法可以参考：

<overlay android:targetPackage="com.android.systemui" android:requiredSystemPropertyName="ro.build.type" android:requiredSystemPropertyValue="userdebug" />

这样不会污染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 一条龙验证命令

方向改造完，不能只看主界面，必须把下面这套命令跑一遍：

# 查看窗口当前方向，1=ROTATION_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 日志排查的常见思路

调试方向问题，我比较依赖这几个关键tag：DisplayRotation、WindowOrientationListener、WindowManager。遇到方向不按预期时，先抓一段完整操作日志，看DisplayRotation的updateRotationUnchecked是否被调用、入参是什么、最后setRotation带的是什么值。很多时候问题不是“能不能横屏”，而是“有人把横屏改回了竖屏”，日志会直接告诉你元凶是谁。

最后说一句个人习惯：这类系统层改动，建议在源码里用一个独立的patch或者overlay目录维护，不要把多个平台差异混在一起，不然Android大版本升级时你都不知道要重打哪个补丁。每个release发布前，把方向相关的改动单独列出来过一遍，能省下大把调试时间。