问题描述
在使用Galaxy S8手机时遇到一个关于后台应用程序的问题：下载了一个FTP服务器应用，并希望其在后台稳定运行，包括保持Wi-Fi连接。然而当屏幕关闭后5分钟后Wi-Fi连接会断开，导致无法继续连接到设备。虽然启用了Wi-Fi一直在线的设置并且程序具备PARTIAL_WAKE_LOCK和WifiLock权限，但“未监测应用”列表中的添加并没有解决问题。通过adb命令查看发现服务持有的WAKE_LOCK并未出现在mDeviceIdleWhitelist中，而后使用dumpsys deviceidle whitelist 添加了包名到白名单后，问题得到了解决。
用户的问题是这两个设置之间有何区别？它们之间的差异是否会导致不同的行为结果？如果没有差别，这是否意味着手机软件存在问题？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
“未监测应用”与mDeviceIdleWhitelist的区别：
- “未监测应用”：在一些安卓设备上，用户可以在电池优化设置中将某些应用设为未监测。这样可以保持这些应用更长时间运行或保持其唤醒状态，然而这并没有被系统正式记录到设备闲置白名单机制内。
- mDeviceIdleWhitelist：这是一个内核级别的参数列表，在
dumpsys deviceidle输出的“WAKEUP_WHITELIST”和“DEVICE_IDLE_STATES”中。这个列表用于管理哪种应用程序和服务可以在设备进入空闲模式时依然被允许保持唤醒状态，从而保持Wi-Fi连接、系统时间同步等。
解决方案
要确保应用在屏幕关闭后还能保持唤醒并使用Wi-Fi，需要将应用的服务添加到mDeviceIdleWhitelist中。可以通过以下步骤操作：
1. 启用开发者选项：进入“设置” > “关于手机”，连续点击版本号7次来开启开发者选项。
2. 使用adb命令查询当前白名单状态:
shell
adb shell dumpsys deviceidle whitelist
3. 将应用包名加入wakeup白名单中：
shell
adb shell dumpsys deviceidle whitelist +PACKAGE_NAME
4. 验证配置是否有效：
– 重新运行上述dump命令，确认服务已添加至白名单。
– 尝试触发设备进入空闲模式或屏幕关闭，观察Wi-Fi连接状态。
注意事项
- 修改和操作
mDeviceIdleWhitelist需要具备一定的权限，并且在非官方环境下可能对部分应用产生冲突。 - 使用“未监测应用”列表仅限用户自行选择性地保持某些应用的唤醒状态，但并不改变系统层面设备是否可以进入空闲模式的行为。因此它不能替代正式的白名单设置。
方案2
通过代码管理 WAKE_LOCK
如果需要更精确地控制WAKE_LOCK的应用程序行为，可以通过编写自定义初始化代码来确保特定组件在进入空闲阶段仍保持唤醒状态：
public class MyService extends Service {
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
// 请求PARTIAL_WAKE_LOCK权限
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,
"myapp");
// 持有唤醒锁不释放，模拟进入白名单效果
wl.acquire();
return START_STICKY;
}
@Override
public void onDestroy() {
super.onDestroy();
WakeLock wl = (WakeLock) getApplicationContext().getSystemService(WAKE_LOCK_SERVICE);
if (wl.isHeld())
wl.release();
}
}
此段代码片段展示了如何编程性地持有唤醒锁，模拟处于白名单中的效果。需要注意的是，实际操作中需确保服务被正确启停管理，以避免不必要的系统资源消耗。
以上两个方案分别为在安卓手机上实现并维护WAKE_LOCK机制提供了不同的方法。如果用户设备支持mDeviceIdleWhitelist功能（通常较新Android版本），那么通过adb命令动态调整可能是更好的选择；反之亦然。但不论何时进行上述操作，请慎重行事保证不造成潜在的系统兼容性问题。
结论
“未监测应用”和mDeviceIdleWhitelist尽管都能影响应用在设备空闲时的唤醒行为，但是它们针对不同层面的控制机制并应用于不同的场景。前者用于用户自定义忽略某部分优化策略的应用，后者则属于底层内核级别的管理工具。
如果两者效果差异不明显或者没有达到预期，在排查过程中应考虑是否存在与厂商定制或非标准配置相关的兼容性问题。对于普通开发者来说，理解这两个概念及其实际应用有助于更精准地进行开发和调试工作。同时，任何尝试直接修改系统参数的操作皆需小心谨慎以保证系统的稳定性和兼容性。