【发布时间】:2015-11-05 10:38:40
【问题描述】:
所以我有一个 BroadcastReceiver 和 AlarmManager。
假设我这样创建 Pending Intents:
Intent i;
i = new Intent(context, MyReceiver.class);
i.setAction(MyReceiver.ACTION_1);
i.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
pendingIntent1 = PendingIntent.getBroadcast(context, 1, i, PendingIntent.FLAG_UPDATE_CURRENT);
i = new Intent(context, MyReceiver.class);
i.setAction(MyReceiver.ACTION_2);
i.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
pendingIntent2 = PendingIntent.getBroadcast(context, 2, i, PendingIntent.FLAG_UPDATE_CURRENT);
并像这样安排警报:
now = SystemClock.elapsedRealtime();
long time1 = now + 10 * 1000;
long time2 = time1 + 60 * 1000;
am.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, time1, pendingIntent1);
am.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, time2, pendingIntent2);
我现在发现我的广播接收器非常可靠地获得了ACTION_1 的广播,而ACTION_2 经常没有被传送。所以onReceive 很少或从不以持有动作ACTION_2 的意图执行。怎么会这样?我想,*_WAKEUP 确保无论如何都在传送广播?
[2015 年 9 月 15 日更新]
- 出于测试目的,我试图在我的onReceive 方法中打印出一条日志消息。还是行不通。
- 我现在尝试在 AlarmManager 上使用 setExact。还是行不通。
- 我什至尝试过使用WakefulBroadcastReceiver。还是行不通。
- 但是,我发现设备在电池充电状态下可以可靠地唤醒。
什么可能导致这个问题?我在各处都读到,如果警报管理器通过未决意图触发广播接收器,则保证会执行(并且不会做太多事情)在onReceive)。我的手机上是否有一些我无法真正解决的激进节能政策(如果没有获得长唤醒锁,请参阅 cmets)?
[2015 年 9 月 19 日更新] 我刚刚在 Google Play 上测试了一些闹钟应用程序 (https://play.google.com/store/apps/details?id=com.alarmclock.xtreme.free),但它也不能可靠地唤醒手机。我想,这真的是一个错误,而不是我的错。我想我会坚持使用唤醒锁定解决方案。
【问题讨论】:
-
showAt的值是多少? -
抱歉,已修复。它本来是
time1。该应用程序基本上是关于在屏幕关闭一段时间(此处为 10 秒)后显示一个对话框(在透明活动中)并再次隐藏它,如果屏幕关闭时间过长(此处为 10+60=70 秒)。 -
我现在通过获取唤醒锁解决了我的问题,如下所示:
wakeLock.acquire(time2 - now + 5000);(保持手机唤醒 - 在上面的示例中 - 70 秒加上 5 秒作为缓冲区) - 但是,我觉得这是一个相当老套的解决方案。你怎么看?它是合法的还是太脏了,可能会导致问题? -
您测试的是哪部手机?索尼机型默认启用积极的省电模式,可以阻止服务唤醒。
-
是的,它是 Sony Xperia Z1 Compact...我猜,手动获取超时唤醒锁的方法是 - 尽管它很脏 - 那么最可靠的解决方案?
标签: android broadcastreceiver alarmmanager wakelock