某些广播接收器只有在通过代码注册而不是在AndroidManifest中定义时才有效。
例如：
SCREEN_ON, SCREEN_OFF
这些操作仅适用于在代码中注册的接收者。如果它们在清单中注册，则不会发生错误，但它们也永远不会被调用。
这种无证行为的原因是什么？安全
答案 0 :(得分：2)
我认为这不存在安全问题。
Manifest定义的广播接收器已注册，即使应用程序不在内存中也可以接收意图。相反的情况不会发生。
这可能是性能问题，因为为此类事件注册接收器可能会耗尽用户电池。
Main difference between Manifest and Programmatic registering of BroadcastReceiver
答案 1 :(得分：1)
我认为这是一个设计决定。我们可以静态或动态地注册我们的广播接收器。 Android系统对两种接收器类型的处理略有不同。
主要;
动态广播接收器与应用程序一起生活。我们可以多次使用它。最重要的是，它运行在UI线程上。
静态操作系统的静态广播接收器。包管理器处理其生命周期。静态注册的BroadcastReceiver的瞬态特性意味着它的onReceive（）方法不能使用任何异步的功能，例如绑定到Service。
可以连续调用SCREEN_ON，SCREEN_OFF等广播。如果我们可以注册这种广播。很多数字应用都想使用它。每次我们打开设备屏幕时，所有这个应用程序都将由操作系统触发。对于任何类型的操作系统而言，这都不是一个好的行为。
另一方面，当我们在代码中使用时，有些广播毫无意义。如“BOOT_COMPLETED”。它应该在系统范围内注册，而不是在UI线程中注册。
我认为这种决定取决于安全性，性能和用例场景。
P.S。：很久以前，我曾经搜索过，但没有找到任何文件的确切原因。
答案 2 :(得分：1)
看来这answer对我有好处，但这仍然没有说明为什么有些只能在AndroidManifest中注册而有些只能在代码中注册
清单注册接收器的主要用途是当您的代码不在内存中时可能继续播放的广播（例如，BOOT_COMPLETED，通过AlarmManager安排的警报）。
答案 3 :(得分：1)
这种行为与Diogo Bento提到的安全性没有任何关系。
如果有一个宝贵的资源并且在使用它之前需要预先准备，那么无论天气如何，您都要在清单中声明您的广播接收器或在代码中注册它。没有所需的权限，两者都将失败。
我认为仅代码操作的原因是，Googe不希望让您的应用程序通过该操作启动。 SCREEN_ON和SCREEN_OFF就是一个很好的例子。当屏幕打开时，很容易制作一个烦人的应用程序。有了这个限制就更难了。如果你真的需要在屏幕打开时启动你的应用程序，那么你必须做更多的工作才能达到同样的效果。例如，您必须维护一个侦听这些事件的服务。
此外，大多数应用程序只关注那些屏幕事件，因为它们位于前台，因此无需唤醒每个甚至不运行的应用程序。假设您有10个对SCREEN_ON操作感兴趣的应用程序。当您打开屏幕时，Android必须启动10个进程才会忽略这些事件，因为它们都没有运行。从操作系统的角度来看，流程是最昂贵的资源之一...