有人可以解释BroadcastReceiver
和之间的确切区别WakefulBroadcastReceiver
吗?
在什么情况下我们必须使用每个Receiver类?
BroadcastReceiver
和之间只有一个区别WakefulBroadcastReceiver
。
当您收到内部广播onReceive()
方法时,
假设,
BroadcastReceiver :
WakefulBroadcastReceiver :
completeWakefulIntent
。例:
在这里,当您接收广播时,即表示您正在使用的方式启动一项服务,直到您完成服务中的工作并触发后WakefulBroadcastReceiver
,它将保持wakelock
并且不会让CPU进入睡眠状态completeWakefulIntent
码:
public class SimpleWakefulReceiver extends WakefulBroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
// This is the Intent to deliver to our service.
Intent service = new Intent(context, SimpleWakefulService.class);
// Start the service, keeping the device awake while it is launching.
Log.i("SimpleWakefulReceiver", "Starting service @ " + SystemClock.elapsedRealtime());
startWakefulService(context, service);
}
}
class SimpleWakefulService extends IntentService {
public SimpleWakefulService() {
super("SimpleWakefulService");
}
@Override
protected void onHandleIntent(Intent intent) {
// At this point SimpleWakefulReceiver is still holding a wake lock
// for us. We can do whatever we need to here and then tell it that
// it can release the wakelock. This sample just does some slow work,
// but more complicated implementations could take their own wake
// lock here before releasing the receiver's.
//
// Note that when using this approach you should be aware that if your
// service gets killed and restarted while in the middle of such work
// (so the Intent gets re-delivered to perform the work again), it will
// at that point no longer be holding a wake lock since we are depending
// on SimpleWakefulReceiver to that for us. If this is a concern, you can
// acquire a separate wake lock here.
for (int i=0; i<5; i++) {
Log.i("SimpleWakefulReceiver", "Running service " + (i+1)
+ "/5 @ " + SystemClock.elapsedRealtime());
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
}
}
Log.i("SimpleWakefulReceiver", "Completed service @ " + SystemClock.elapsedRealtime());
SimpleWakefulReceiver.completeWakefulIntent(intent);
}
}
4.2.1.3 内部广播接收器 内部广播接收器是广播接收器,它将永远不会收到从内部应用以外发送的任何广播。 它由几个内部应用组成,用于保护内部应用处理的信息或功能。 要点(接收广播): 定义内部签名权限来接收广播。 声明使用内部签名权限来接收结果。 将导出属性显式设置为true。 需要静态广播接收器定义的内部签名权限。 需要内部签名来注册动态广播接收器。 确认内部签名权限是由内部应用定义的。 尽管
4.2.1.2 公共广播接收器 公共广播接收器是可以从未指定的大量应用程序接收广播的广播接收器,因此有必要注意,它可能从恶意软件接收广播。 要点(接收广播): 将导出属性显式设为true。 小心并安全地处理收到的意图。 返回结果时,不要包含敏感信息。 公共广播接收器的示例代码可以用于静态和动态广播接收器。 PublicReceiver.java package org.jssec.android.
4.2.1.1 私有广播接收器 私人广播接收器是最安全的广播接收器,因为只能接收到从应用内发送的广播。 动态广播接收器不能注册为私有,所以私有广播接收器只包含静态广播接收器。 要点(接收广播): 将导出属性显示设为false 小心并安全地处理收到的意图,即使意图从相同的应用中发送 敏感信息可以作为返回结果发送,因为请求来自相同应用 AndroidManifest.xml <?xml version
通知广播接收机: 谁能帮帮我吗?我不知道我做错了什么
根据谷歌提供的AndroidO迁移指南,大部分隐含的广播意图不应该在清单中注册(除了这里发现的一些例外),但显式广播意图保持不变。 我们希望将任何需要的广播从舱单上移开。但我们如何识别接收者是否是隐性的呢?有一般规则吗? 下面是我们在清单中注册的广播示例。我们是否应该只查看“action”标记,并查看它是否被列入白名单以将其保留在清单中? 例如,“com.android.vending.INSTA
我目前正在使用SharedReferences跟踪通过AlarmManager启动的BroadcastReceiver中要执行工作的项列表。除了一个特定的场景外,一切都很好。当我触发一个新项目来执行工作时,让它完成工作,然后删除该项目(全部通过SharedReferences编辑),它在应用程序运行时工作得很好。当列表中没有任何内容,我打开任务管理器并终止应用程序时,该项突然出现在Broadcas