adb屏幕旋转270度后无法恢复正常显示？

Question

使用ADB命令将设备屏幕旋转270度后，部分设备无法通过常规方式恢复默认显示方向，屏幕仍保持异常朝向。此问题多因系统未正确重置`persist.display.rotation`或`window.orientation`参数所致，尤其在定制ROM或低层显示服务未正常响应重置指令时更为常见。即使执行`adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:0`也无法立即生效，重启后方可修复。该现象影响自动化测试与调试效率，亟需排查显示服务状态及系统旋转策略。

Answer 1

1. 问题现象与背景分析

在Android设备调试过程中，通过ADB命令实现屏幕旋转是一项常见操作。典型命令如：

adb shell settings put system user_rotation 3

该命令将屏幕设置为270度旋转（即逆时针旋转90度）。然而，在部分设备上，尤其是搭载定制ROM或使用非标准显示服务的设备中，执行恢复默认方向命令：

adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:0

后屏幕方向并未立即恢复正常，仍保持270度朝向。此问题并非普遍存在于所有设备，但在自动化测试场景下影响显著，导致UI元素错位、触控坐标偏移等问题。

2. 系统级参数与显示服务机制

Android系统中控制屏幕旋转的核心参数包括：

• user_rotation：用户设定的旋转角度（0-3）
• persist.display.rotation：持久化显示旋转状态，部分厂商自定义属性
• window.orientation：当前窗口的逻辑方向，由AMS（Activity Manager Service）管理

当调用settings put system user_rotation时，仅修改系统设置数据库，但底层SurfaceFlinger或DisplayManagerService可能未实时响应变更，尤其在以下情况：

1. 厂商重写了DisplayPolicy或禁用了自动旋转监听器
2. 低层HAL模块缓存了旋转状态
3. 系统处于冻结状态（如息屏或后台运行）

3. 排查流程与诊断方法

为定位根本原因，建议按如下流程进行排查：

步骤	命令/操作	预期输出	异常表现
1	adb shell settings get system user_rotation	返回0	返回3
2	adb shell getprop persist.display.rotation	无输出或0	返回3
3	adb shell dumpsys window	Window Manager状态中orientation=ROTATION_0	仍为ROTATION_270
4	adb shell dumpsys display	Display Power state: ON, Rotation: 0	Rotation: 3
5	adb logcat -b events | grep rotation	观察是否有USER_ROTATION_CHANGED事件	无事件或被拦截
6	adb shell service call activity 42 s16 user_rotation i32 0	强制AMS广播旋转事件	部分设备需root权限
7	adb shell wm rotation	显示当前WM旋转值	不支持该命令旧版本
8	adb shell dumpsys input	检查InputReader配置是否同步旋转	触摸坐标系未更新
9	adb shell setprop persist.display.rotation 0	尝试写入持久化属性	属性只读或无效
10	adb reboot	重启后验证是否恢复	仅重启生效

4. 深层机制解析与厂商差异

不同Android设备对旋转策略的实现存在显著差异：

# 高通平台设备可能存在专有节点
echo 0 > /sys/class/graphics/fb0/rotate

# 联发科设备常使用persist.sys.orientation控制
setprop persist.sys.orientation 0

# 华为EMUI曾使用displayengine服务拦截旋转指令
stop displayengine; sleep 2; start displayengine

此外，某些定制ROM会通过SystemUI中的RotationButton或DevicePolicyReceiver主动锁定方向，导致ADB设置被覆盖。此时需结合dumpsys device_policy查看是否启用Kiosk模式或方向锁定策略。

5. 可行解决方案汇总

针对上述问题，可采取以下多层级应对策略：

1. 优先使用标准ADB命令组合：

2. adb shell settings put system accelerometer_rotation 1
   adb shell settings put system user_rotation 0

3. 若无效，尝试触发AMS重新计算方向：

4. adb shell am broadcast -a android.intent.action.CONFIGURATION_CHANGED

5. 对于支持wm命令的设备：

6. adb shell wm rotation 0

7. 强制重置SurfaceFlinger状态（需root）：

8. adb shell stop surfaceflinger; adb shell start surfaceflinger

9. 清除显示服务缓存（适用于AOSP类设备）：

10. adb shell pm clear com.android.systemui

11. 修改持久化属性（若可写）：

12. adb shell setprop persist.display.rotation 0

13. 使用反射调用DisplayManager内部API（需shell权限）：

14. adb shell dpm set-device-owner（配合定向广播）

15. 自动化脚本中加入“软重启”机制：

16. adb shell svc power reboot normal

17. 开发专用调试APK注入WINDOW_MANAGER_ROCKET权限执行reset
18. 建立设备兼容性矩阵，记录各型号旋转行为特征

6. 自动化测试环境优化建议

为提升测试稳定性，建议构建如下流程图作为标准恢复逻辑：

graph TD
    A[开始恢复屏幕方向] --> B{设备是否支持wm rotation?}
    B -- 是 --> C[执行adb shell wm rotation 0]
    B -- 否 --> D[执行settings put user_rotation 0]
    C --> E[等待2秒]
    D --> E
    E --> F{屏幕是否已恢复?}
    F -- 否 --> G[尝试setprop persist.display.rotation 0]
    G --> H[发送CONFIGURATION_CHANGED广播]
    H --> I{是否恢复?}
    I -- 否 --> J[执行surfaceflinger重启]
    J --> K[最终判断]
    I -- 是 --> L[结束]
    F -- 是 --> L
    K --> M{仍失败?}
    M -- 是 --> N[标记设备异常并重启]
    N --> O[记录日志供后续分析]
    

该流程可集成至CI/CD流水线，结合设备指纹识别动态调整恢复策略。