在 Android 9 中，电池优化得到了进一步推动，应用程序根据用户最近与应用程序的交互量被分类为备用存储桶（请参阅Android 文档）。系统会根据应用所在的桶来限制每个应用可用的设备资源。
即使用户不与之交互，如何将我的应用程序保留在“工作集”存储桶中？（我没有找到任何允许覆盖此电源管理功能的权限或类似权限。）
更具体地说，我PeriodicWorkRequest必须每 30 分钟运行一次，灵活性为 10 分钟。但是，如果我了解强加的电源限制表，如果我的应用程序被放入“稀有”存储桶，则此类工作请求可能会被推迟至 24 小时。（在后台，工作库使用作业调度程序。）
情景的更多细节
该应用程序对安全至关重要，不打算供公众使用，但仅对有限的一组用户有意义。但是，如果其他人使用此应用程序，则不会发生任何不好的事情，但该应用程序对他/她没有任何用途。
更准确地说，该应用程序连接到特定建筑物的中央火灾报警站。所有员工都被要求在他们的智能手机上安装该应用程序。如果该建筑物的中央火灾报警站检测到事件，它会向所有注册的智能手机发送推送通知（通过 FCM），并且应用程序会播放警报声。这意味着（希望）很长一段时间内什么都没有发生，并且用户无意以任何方式与应用程序交互。应用程序本身不提供任何交互，它仅说明当前状态（绿色“OK”标志或红色“ALERT”标志）并在后台等待其余时间。
由于应用程序对安全至关重要，因此必须检测应用程序失去与服务器的连接的故障情况。为此，服务器实际上是在后台周期性地发送消息，即一个序列idle, idle, idle, idle, alarm, alarm, alarm, alarm, idle, idle, idle, ... 通常情况下，每 5 分钟以低 FCM 优先级广播消息。如果状态发生变化，则会立即发送一条具有高 FCM 优先级的附加消息（cp.粗体字母）。
PeriodicWorkRequest该应用程序使用上述问题中提到的方法实现了看门狗。这个看门狗有双重作用：唤醒设备并让设备接收所有（低优先级）已被推迟的 FCM 消息，然后检查最新消息是否不超过 1.5*5 分钟。如果失败，应用程序会尝试向服务器重新注册，并等待状态消息再次开始进入。如果这也失败了，应用程序会向用户显示警告。
到目前为止一切正常。唯一的问题是新型电池优化会在某个时间点减慢看门狗的速度。当然，我可以发布一个常规规定，强制所有员工偶尔打开应用程序并简单地查看它，但这有点愚蠢。
我可以重新表述上面的问题：我完全理解为什么 Android 将电池优化推向了边缘。有很多（疯狂的）应用程序滥用周期性任务来达到本应以不同方式解决的目的。而且网络上仍然充满了“白痴”的编程建议，比如每 5 秒检查一次特定网页的修改。但是，如果电池优化越来越成为一个障碍，我怎么能写出需要看门狗来实现合法目的的安全关键应用程序。谷歌的“如果用户不使用你的应用程序，这对他/她显然不重要”的规则在这里不适用。