在“无法从后台启动前台服务”限制的豁免之一中,文档提到:
您的应用程序调用精确的警报来完成用户指定的操作 请求。
这是否意味着下面的使用场景可以工作?
使用
AlarmManager.setAlarmClock
安排在时间 A 触发的确切警报。该警报带有针对已注册广播接收器的 pendingIntent
。
A 击中时,接收者获得意图。
在接收器
OnCreate
方法中,我们尝试startForegroundService
,其中涉及显示粘性通知并使用MediaPlayer
播放自定义音乐。
我已经实现并测试了它,它似乎有效,所以我认为这是一个有效的用例。
是的,您描述的场景应该有效并且符合 Android 12 引入的限制。
但是,请考虑是否可以直接使用待定意图而不是广播接收器来定位服务并从那里启动服务。在两者之间跳转是不必要的,甚至可能导致服务无法启动 - 请参阅 Android 官方闹钟应用程序 (DeskClock) 中的此评论:
// This intent is directed to AlarmService, though the actual handling of it occurs here
// in AlarmStateManager. The reason is that evidence exists showing the jump between the
// broadcast receiver (AlarmStateManager) and service (AlarmService) can be thwarted by
// the Out Of Memory killer. If clock is killed during that jump, firing an alarm can
// fail to occur. To be safer, the call begins in AlarmService, which has the power to
// display the firing alarm if needed, so no jump is needed.
val intent: Intent =
AlarmInstance.createIntent(context, AlarmService::class.java, instance.mId)