我正在Android P beta 4版上测试我的应用程序。我的应用程序的 targetSdkVersion为27
已观察到警报管理器通知未按预期运行。我正在使用以下代码设置通知-
if (android.os.Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT) {
alarmManager.set(AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmIntentBuilder.buildPendingIntent(context, uri));
} else if (android.os.Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT && Build.VERSION.SDK_INT < Build.VERSION_CODES.M) {
alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmIntentBuilder.buildPendingIntent(context, uri));
} else {
alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerAtMillis, AlarmIntentBuilder.buildPendingIntent(context, uri));
}
我在Android 8.0上测试了相同的逻辑,但工作正常。在Android 9.0中,通知有效,但有时根本不起作用。另外,如果它们能正常工作,则它们并不精确,并且会花费大量时间,即使应用程序位于前台,也会发生这种情况。
逻辑是,我有在特定时间设置的重复提醒,这些提醒应该每天在指定时间自行重复。另外,这些都是高优先级提醒,应该在确切的时间降落,因此我正在使用setExact,一旦收到通知,它就会显示出来,并设置同一天下周的新警报。
我已经检查了Android P API文档,但是找不到任何对 AlarmManager 和通知的工作有影响的链接。我认为引起问题的唯一原因是 Android P中的电源管理和优先级存储桶。但是,即使应用程序位于前台,通知也无法正常工作。
我在这里什么都不见了。非常感谢您的帮助。
答案 0 :(得分:4)
正如您自己提到的那样,电源管理的新App Standby Buckets功能很可能是原因。新文档指出:
如果某个应用位于频繁出现的存储桶[或以下]中,则系统会对其运行作业和触发警报的能力施加更严格的限制
和
尤其是,存储桶确定应用程序的作业运行频率,应用程序触发警报的频率
此外,如果您查看Power Details,则可以大致了解延迟时间。
值得注意的是,您的存储桶似乎基于平均使用情况(和机器学习)而不是基于当前使用情况-这意味着,即使您的应用程序刚刚出现在前台,存储桶也会播放一些内容角色
答案 1 :(得分:2)
之所以发生这种情况,是因为Android Pie中引入了Power management功能。
在android P中,对在后台运行的应用程序引入了严格的限制。这些限制的说明here
正如我们在上面的链接中看到的那样,如果我们将设备连接至充电状态,则设备不受任何限制,并且通知运行正常。但是,如果我们删除设备,则Android系统会对在后台运行的应用添加某些限制。
我们可以通过从设备设置中关闭应用程序的电池优化来关闭此限制。在设置中搜索电池优化并为我们的应用程序将其关闭。
此外,通过更改设备日期和时间来测试通知是迄今为止一直可以正常使用的黑客手段,但是在Android P中,我们要么实时测试它们,要么关闭电池优化我们的应用程序以测试它们。
我希望这将消除我们的疑虑。