问题标签 [android-doze]

如果我每 120 秒发送一次 GPS（纬度/经度），我必须实施一项服务。到我的 REST 后端。

我的问题是屏幕关闭时服务似乎停止工作。

1. 尝试使用 StartedService 和 BroadcastReceiver
2. 尝试使用 IntentService 和 WakefulBroadcastReceiver

1. Attempt 例如适用于 SAMSUNG Galaxy X COVER，但不适用于 HUAWEI P9 Lite。尽管我关闭了华为手机中的省电模式（Power Apps）。所以当屏幕关闭时我的应用程序会继续运行。例如 10 分钟后，我在华为手机上打开屏幕并在运行服务中看到服务正在运行（经过的秒数），因此我可以验证服务没有关闭。

2. 屏幕关闭时尝试在没有手机的情况下工作。

当屏幕打开（无睡眠）时，这两种尝试都正常工作。

注意：为简洁起见，我删除了不相关方法的代码（获取/传输 gps 数据）。

这是1的代码。尝试：

服务

广播接收器

在 MainActivity.OnCreate 中注册 Broadcastreceiver

2.尝试

服务

唤醒接收器

AndroidManifest.xml

添加了 WAKE_LOCK 权限

我现在真的很绝望。希望可以有人帮帮我。谢谢

埃里克

我有一个使用地理围栏的 android 应用程序，我很难克服打瞌睡模式。我的清单具有 WAKE_LOCK 权限，并且每个区域的七个 setNotificationResponsiveness 为 0。我什至将 PendingIntent 更改为 BroadcastReceiver，但应用程序在删除智能手机屏幕后确实会休眠或死机。我已经尝试过使用 LocationRequest

即便如此，我也没有成功。有没有人设法让应用程序与 Doze 一起运行？

TL;博士

Android 7.1.2 的“2017 年 6 月 5 日”安全更新是否导致 Android 开始忽略电池优化白名单（即旨在让应用禁用打盹模式的东西）？

如果是这样，如果应用程序有一个需要 CPU 和 wifi 保持持续活动的用例，它现在如何以编程方式禁用打盹模式？

语境

我有一个 Android 应用程序，它支持将本地音频文件投射到联网的 Chromecast 接收器（使用嵌入式 HTTP 服务器将文件内容流式传输到接收器）。

为了让它在 Android M 上运行（在设备正在投射音频但处于空闲状态时不会丢失 Chromecast 会话），我不得不使用这个答案中的方法来禁用打盹模式。

具体来说，在我的AndroidManifest.xml我有：

...并且只要建立 Chromecast 会话，就会执行以下代码：

...而且我还以标准方式获取唤醒/wifi 锁定，同时 Chromecast 播放处于活动状态：

该应用程序出现在电池白名单中，就在几周前，这一切都运行良好。但是，该应用程序现在被打盹模式捕获。

测试设备没有变化；这是运行 Android 7.1.2 的 Google Pixel。唯一的软件更改是我安装了 2017 年 6 月 5 日的安全补丁。

Android 系统日志报告以下内容（在主动投射时）：

此时（延迟几秒钟后）我的 ChromecastonConnectionSuspended()方法被调用，值为CAUSE_NETWORK_LOST. 这当然是因为打盹模式已经关闭了 wifi。

Android 7.1.2 的“2017 年 6 月 5 日”安全更新是否导致 Android 开始忽略电池优化白名单（即旨在让应用禁用打盹模式的东西）？

如果是这样，如果应用程序有一个需要 CPU 和 wifi 保持持续活动的用例，它现在如何以编程方式禁用打盹模式？

编辑

这是一个演示该问题的最小示例项目（至少在我的 Google Pixel 上）：

https://github.com/adam-roth/droid-doze-test

这是我得到的结果，在我的 Pixel 上运行测试：

我有一个需要获取单个位置更新的前台服务。

它由一个特定的广播启动，启动后它只是在我们的后端发出一个请求。当它接收到另一个广播时，它会请求位置更新（一次），执行另一个后端请求，然后自行停止。

编辑：澄清一下，服务本身会执行位置更新和后端请求。在这方面它独立于主应用程序。

这在 Lollipop 和 Marshmallow 上运行良好，无论是在手机处于唤醒状态还是处于打盹模式时。但出于某种原因，在 Android O 上，该服务在打盹模式下永远不会获取位置更新。网络工作正常，因为它的第一个请求在这两种情况下都通过。此外，如果我在位置请求运行时唤醒手机，它将获得更新。如果我把它放在维护窗口中也是一样的。

Android O 确实对后台位置引入了一些限制，但正如页面所述，前台应用程序行为（应用程序可见或前台服务正在运行）应保留并与以前的 Android 版本类似。

这是开发者预览中的问题还是我错过的限制？

我正在开发与 Voip 和 IM（聊天应用程序）相关的应用程序。直到 android OS 5.0 它运行良好，客户端也没有问题。但从 android OS 5.1.1 开始，我们面临着问题。

问题：

• 如果应用程序处于前台并且设备进入睡眠模式，则它运行良好。
• 如果应用程序处于后台并且设备在10 分钟后进入睡眠模式，所有服务都会自动停止。

测试：

• 为了测试，我创建了一个计时器任务，每 1 分钟打印一次日志。所以当我关闭应用程序时（意味着应用程序是否在后台）

• 直到android OS 5.0日志连续打印。

• 从android OS 5.1.1开始进入睡眠模式后，10 分钟后不会打印日志。定时器任务正在停止

我的应用程序也面临同样的问题。

在做了一些研发之后，我开始了解打盹模式和应用程序优化。无论如何与停止在后台自动运行的服务有关。

如果是，任何人都可以让我知道如何克服这个问题。

我正在设计一个应用程序，我需要在其中定期将位置发送到服务器。但是由于打瞌睡功能，设备会在一段时间后停止发送位置。是否有一种解决方法可以解决此问题。

提前致谢。

我正在尝试使用警报管理器每 30 分钟在我的应用程序中触发一次警报，setExactAndAllowWhileIdle但它不起作用！

每当我收到警报信号时，我都会通过发布推送通知来测试功能。

问题是：当设备闲置一段时间后进入打盹模式时，我不再收到警报。但是，只要我打开屏幕，我就会收到通知。我的应用需要准确的警报，需要每 30 分钟准确准时发送！由于设备处于打盹模式，因此无法接收延迟警报或丢失警报！

我在我的代码中使用了以下内容：

1. 当我打开我的应用程序时，我设置了闹钟。
2. 我使用 WakefulBroadcastReceiver 接收警报信号。在它的 onReceive()方法中，我设置了下一个闹钟。我还启动了一个 startWakefulService，它只发出推送通知，然后自行停止。
3. 我在 onReceive() 结束时调用了 completeWakefulIntent。
4. 我尝试同时测试：RTC_WAKEUP & ELAPSED_REALTIME_WAKEUP

笔记：

• wakefulbroadcastReceiver 类在 Manifest 中注册。
• 我添加了以下权限：android.permission.WAKE_LOCK
• 我尝试将我的应用程序列入白名单，但结果相同
• 我尝试使用setAlarmClock()which 即使在打瞌睡模式下也一直有效，每 50 个警报有一个丢弃/延迟警报。所以，它也不完美。而且我不希望用户一直在那里看到警报图标。
• setExactAndAllowWhileIdle() 不仅在打瞌睡时不起作用，而且在工作时精度也很差。
  我通常会在 1-3 分钟后或 1-3 分钟前收到很多警报信号。
• 我正在使用华为 Mate 8 和 android 7.0 Nougat 进行测试。

PS： 在回答之前，请确保您了解从 Android 6.0 M 和打盹模式开始施加的限制。

链接1：https ://developer.android.com/training/monitoring-device-state/doze-standby.html

总而言之，它说：

• 如果您需要设置在打瞌睡时触发的警报，请使用 setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle()。
• 使用 setAlarmClock() 设置的警报继续正常触发——系统在这些警报触发前不久退出打盹。

现在，为什么我不能每 30 分钟收到一次准确的警报信号setExactAndAllowWhileIdle()？！而且，为什么不是setAlarmClock()100% 可靠？！

语境

我正在开发适用于 Android 的屏幕过滤器应用程序（如 f.lux）。我目前正在使用该功能以在太阳落山时逐渐淡入滤镜。屏幕关闭时状态无关紧要，但当屏幕打开时，淡化进度正确（或立即更新）很重要。

技术要求

• 我想以半固定的时间间隔触发一系列意图。
• 当屏幕关闭时，它们可以被忽略/丢弃，除了：
  • 当屏幕打开时，必须立即触发最近的 Intent。
• 我不想不必要地耗尽电池。

明显的解决方案以及为什么它们不起作用

• 我可以使用AlarmManager.setInexactRepeating，这应该是最节能的警报，除了：

您的警报的第一次触发不会在请求的时间之前，但它可能不会在该时间之后的几乎整个间隔内发生。

我认为这意味着第一次触发必然会在第一个间隔内发生，这意味着设备将被唤醒，从而导致不必要的电池消耗。

• 我可以AlarmManager.set用来安排第一个警报。当它响起时，我可以更新屏幕，然后安排下一个闹钟。这会起作用，但会在每次警报时唤醒旧设备（没有打盹），而不是等到屏幕打开。它还使用 AlarmManger 作为计时器，文档明确建议不要这样做：

对于计时操作（滴答声、超时等），使用 Handler 更容易、更高效。

可以，然后呢，

• 我可以设置一个警报来启动一个Handler，它会定期更新 UI。但是等等：这依赖于postDelayed，它说（强调我的）：

在深度睡眠中花费的时间会增加执行的额外延迟。

我认为这意味着，当设备从睡眠中唤醒时，下一次更新可能不会在整个间隔内发生。我读对了吗？强迫用户在下一次更新之前等待一两分钟会破坏交易。

CountDownTimer和ValueAnimator在它们的实现中都使用了这个方法，所以如果我对 Handler 的解释是正确的，它们都出局了。

我可以使用基于处理程序的方法并在屏幕关闭时接收事件，此时我将取消现有动画，然后开始一个新动画。这看起来是最好的解决方案，但似乎应该有一种更简单的方法来做到这一点。

结论

关于这个主题还有很多其他的 SO 问题。每个人和他们的母亲都建议使用处理程序，但是除了上面的引用之外，绝对没有关于设备进入睡眠状态时它的行为方式的信息。（显然）没有其他人遇到这个问题真的很奇怪——我是在做一些非常不寻常的事情，还是缺少一些基本的东西？

任何人都可以提供有关Handler.postDelayed设备进入睡眠状态时的实际行为的见解，并推荐我在这种特定情况下应该做什么？

我正在使用 SIP 协议开发 IP 语音 (VoIP) 应用程序，该协议要求应用程序监听来电。这意味着应用程序不能休眠或死亡。

对于旧代码，似乎这样做的方法是获取PARTIAL_WAKE_LOCK。

现在从 Android 6.0 及更高版本开始，有了新的Doze。建议，如果您不希望您的应用程序进入待机状态，您应该通过请求REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限将其“列入白名单”。根据文档，这是专门针对 VoIP 应用程序的。

这两个不同的东西似乎是相关的。我不确定它们是如何相关的，它们是否相互干扰，我是否应该使用其中一个或两个，以及是否有其他考虑。请解释。

另外，我不允许在这个项目上使用推送通知。如果您有其他节省电池的建议，请告诉我。

我有一种方法可以定期运行以保持网络连接处于活动状态。在打盹模式下，我想禁用它定期运行并在维护窗口期间只运行一次。当设备退出 Doze 时，我希望再次定期调用该方法。我怎样才能做到这一点？

我已经注册了一个接收器来监听PowerManager.ACTION_DEVICE_IDLE_MODE_CHANGED广播，然后调用PowerManager.isDeviceIdleMode(). 但是，这两种情况都返回 false - 在维护窗口期间和设备退出打盹模式时。我怎样才能区分它们？