1

Posts of people trying to register a broadcast receiver in the manifest for events SCREEN_ON and SCREEN_OFF are numerous. The solution was given many times: register it in the java code.

My question is: WHY?

This makes no sense to me... And makes no sense to many others, as we can see:

Does anyone have any insight?

Community
  • 1
  • 1
JM Lord
  • 1,031
  • 1
  • 13
  • 29
  • 1
    Various system broadcasts, particularly those related to power, have this restriction, so Android does not have to go fork a bunch of processes to handle all the requests for the broadcast from apps that are not presently running. – CommonsWare Dec 01 '15 at 15:30
  • Yes, that would make sense. It would be for performance. I guess the manifest intent filters are kept only on disk while the java registered ones are in memory. Is that correct? – JM Lord Dec 01 '15 at 16:15
  • 2
    The filters are always in memory AFAIK, but in a core OS process. What matters is the *app's* process, which always exists for `registerReceiver()` and may or may not exist for manifest-registered receivers. The pre-eminent example is `ACTION_BATTERY_CHANGED`, which has the same restriction. If Android had to go run a bunch of apps, forking processes for each, every time the battery drops a bit of charge, that's a lot of system churn. Worst-case? All that work causes the battery to drop another bit of charge, and you have to do all that work all over again, in a death spiral. :-) – CommonsWare Dec 01 '15 at 16:20
  • Thanks for sharing your knowledge. I'm satisfied with this explanation. – JM Lord Dec 02 '15 at 16:10

0 Answers0