Android13 待机唤醒后Wi-Fi异常关闭的日志追踪与PowerManagerService关联分析

1. 问题现象与初步排查

最近在调试Android13 TV设备时遇到一个奇怪现象：当设备进入待机状态（通过input keyevent 26触发）后重新唤醒，Wi-Fi总会自动关闭。这个问题在Amlogic方案的设备上必现，严重影响用户体验。作为开发者，我们需要从系统底层找出Wi-Fi被异常关闭的根本原因。

首先想到的是检查系统休眠策略。通过adb命令查询wifi_sleep_policy属性：

adb shell settings get global wifi_sleep_policy

结果显示默认值为2（WIFI_SLEEP_POLICY_NEVER），理论上Wi-Fi不应该被关闭。但查看Android13源码发现这个属性已被标记为@Deprecated，说明平台不再使用该策略控制Wi-Fi休眠。

进一步检查stay_on_while_plugged_in属性：

adb shell settings get system stay_on_while_plugged_in

尝试将其设置为4（无线充电模式）后问题依旧。这说明我们需要更深入地分析系统服务间的交互逻辑。

2. 关键日志捕获与分析技巧

要定位这类系统级问题，日志分析是最有效的手段。建议使用以下命令捕获关键日志：

adb logcat -c && adb logcat -v threadtime | grep -iE "Wifi|Power"

在待机唤醒操作后，重点关注以下日志片段：

01-01 00:04:04.224 837 907 I PowerManagerService: Sleeping (uid 1000)... 01-01 00:04:04.272 1265 1265 D DroidLogicPowerService: action: android.intent.action.SCREEN_OFF 01-01 00:04:04.284 837 1761 I WifiService: setWifiEnabled package=com.droidlogic enable=false

这三条日志揭示了问题关键路径：

1. PowerManagerService通知系统进入睡眠状态
2. DroidLogicPowerService接收到屏幕关闭广播
3. WifiService执行了Wi-Fi关闭操作

3. PowerManagerService工作机制解析

在Android电源管理体系中，PowerManagerService是核心控制器。当设备进入待机时，它会经历以下状态转换：

// frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java case WAKEFULNESS_ASLEEP: Slog.i(TAG, "Sleeping (uid " + uid + ")..."); // 触发低功耗模式

但标准实现中并不直接操作Wi-Fi，这说明问题可能出在厂商定制层。通过日志回溯，我们发现DroidLogicPowerService这个厂商自定义服务才是真正的"罪魁祸首"。

4. 厂商定制层问题定位

在Amlogic方案的代码中，DroidLogicPowerService实现了特殊逻辑：

// vendor/amlogic/common/frameworks/core/res/src/com/droidlogic/DroidLogicPowerService.java private BroadcastReceiver mReceiver = new BroadcastReceiver() { public void onReceive(Context context, Intent intent) { if (Intent.ACTION_SCREEN_OFF.equals(action)) { setWifiState(context, false); // 关键问题点 } } };

进一步查看setWifiState方法实现：

private void setWifiState(Context context, boolean state) { if (!mSystemControlManager.getPropertyBoolean("ro.vendor.platform.wifi.suspend", false)) { return; // 属性控制开关 } WifiManager wm = (WifiManager) context.getSystemService(Context.WIFI_SERVICE); wm.setWifiEnabled(false); // 强制关闭Wi-Fi }

这里暴露出两个关键点：

1. 厂商硬编码了屏幕关闭时Wi-Fi的关闭逻辑
2. 可以通过系统属性ro.vendor.platform.wifi.suspend控制该行为

5. 解决方案与验证测试

根据分析结果，我们提供三种解决方案：

方案一：修改系统属性（临时解决）

adb shell setprop ro.vendor.platform.wifi.suspend false

方案二：代码层修改（永久解决）修改DroidLogicPowerService.java，注释掉setWifiEnabled(false)调用：

// wm.setWifiEnabled(false); // 禁用自动关闭逻辑

方案三：广播拦截（折中方案）在应用层注册广播接收器，拦截ACTION_SCREEN_OFF后重新启用Wi-Fi：

public class WifiKeeper extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { WifiManager wm = context.getSystemService(WifiManager.class); wm.setWifiEnabled(true); } }

验证方法：

adb shell settings get global wifi_on # 应返回1 adb shell dumpsys wifi | grep "Wi-Fi is" # 检查状态

6. 深度优化建议

对于需要深度定制的设备，建议：

1. 电源策略配置： 在frameworks/base/core/res/res/values/config.xml中调整：

<bool name="config_wifi_suspend_optimizations_enabled">false</bool>

2. Wi-Fi锁机制： 在应用层使用WifiLock保持连接：

WifiManager.WifiLock lock = wifiManager.createWifiLock( WifiManager.WIFI_MODE_FULL_HIGH_PERF, "MyWifiLock"); lock.acquire();

3. Doze模式适配： 检查PowerWhitelist配置，确保Wi-Fi服务在省电模式中保持活跃：

adb shell dumpsys deviceidle whitelist

7. 问题延伸与系统设计思考

这个案例暴露了Android定制化开发的典型问题：厂商在实现功能时，可能过度干预系统默认行为。我们在分析时需要注意：

1. 日志标记追踪：

   • 系统服务通常使用固定TAG（如PowerManagerService）
   • 厂商代码可能使用自定义TAG（如DroidLogic*）

2. 广播链路分析：

   • 使用adb shell dumpsys activity broadcasts查看广播注册情况
   • 特别注意ordered broadcast的优先级问题

3. 电源状态机： 通过adb shell dumpsys power可以查看当前电源状态：

Wake Locks: size=2 PARTIAL_WAKE_LOCK 'MyWakeLock' ON_AFTER_RELEASE...

在实际项目中，遇到类似问题时建议先理清标准Android实现逻辑，再对比厂商定制差异。这种分析方法不仅能解决当前问题，还能帮助理解整个系统的工作机制。