Some broadcast receivers only work if they are registered via code rather than defined in AndroidManifest.
For example:
SCREEN_ON, SCREEN_OFF
These actions will only work with receivers registered in code. No errors happen if they are registered in the manifest, but they never get called either.
What are the reasons for this undocumented behavior? Security?
I don't think there is a security issue around this.
Manifest defined broadcast receivers are registered and can receive intents even if the application is not in memory. The opposite doesn't occur.
It could be a performance issue because registering a receiver for this type of events, may drain the user battery.
Main difference between Manifest and Programmatic registering of BroadcastReceiver
I think this is a design decision. We can register our broadcast receivers statically or dynamically. Both receiver types treated slightly different by Android system.
Mainly;
Dynamic broadcast receiver live with application. We can use it multiple times. Most important thing about it, it runs on UI thread.
Statical broadcast receiver live with OS. Package manager handles its life cycle. The transient nature of a statically registered BroadcastReceiver means that its onReceive() method cannot use any functionality which is asynchronous, for example, binding to a Service.
And some broadcast like SCREEN_ON, SCREEN_OFF... can be called continuously. If we can register this kind of broadcast. A lot of number app want to use it. And every time we open device screen, all of this app will be triggered by OS. This is not a good behavior for any kind of OS.
On the other hand, there are some broadcast that is meaningless when we use in code. Such as "BOOT_COMPLETED". It should be registered system-wide, not in UI thread.
I think this kind of decisions depends on security, performance and use case scenario.
P.S.: Long time ago, I had searched but didn't find any documentation for exact reason about it.
It seems this answer is good for me but still this is not telling the reason why some can only be registered in AndroidManifest and some only through code
The primary use of manifest-registered receivers is for broadcasts that may go on while your code is not in memory (e.g., BOOT_COMPLETED, your scheduled alarms via AlarmManager).
This behaviour does not have any relation to security as Diogo Bento mentioned it.
If there is a resource that is precious and prermission is needed before using it, then you have to ask for that permissions, no matter weather you declare your Broadcast Receiver in the manifest or register it in the code. Without the required permissions, both will fail.
I think the reason of the code only actions is that, Googe does not want to let your app being started by that action. SCREEN_ON and SCREEN_OFF is a good example. It would be easy to make an annoying application that would do something as the screen turns on. With this restriction its much harder. If you really need your application to be started as the screen turns on, then you have to do more work to accomplish the same effect. For example you have to maintain a Service that listens for those events.
In addition, most applications care about those screen events only if they are in the foreground, so there is no need to wake up every applications, which not even running. Lets say that you have 10 apps that in a way interested in the SCREEN_ON action. As you turn your screen on, 10 process would have to be started by Android just to ignore those events, because none of them running. And process is one of the most expensive resource from the perspective of an OS...
