Menu
There seems to be a very important change in the way ACTION_BOOT_COMPLETED broadcast is sent out in the latest android release. In JB 4.3, the boot complete broadcast was processed in parallel. Where as in KK 4.4.2 its being processed serially. This is delaying the start of services after boot up.
KITKAT 4.4.2
JELLY BEAN 4.3
Because of this change by Google, my service start is being delayed after boot complete. One can observe that the device gets sluggish and audio for touch doesn't play-out. All of these because the respective services are starting late.
Also, from the logs I see that the first guy to receive ACTION_BOOT_COMPLETED after its is sent out, is receiving it after 16-19 seconds, where as on JBP it hardly takes 10 milliseconds for the first guy in the receiver-queue to get it.
Could anyone who is aware of this change explain why this was made. It would be a great help.
Thanks a lot!
228
Broadcast Receivers are used to respond to these system-wide events. Broadcast Receivers allow us to register for the system and application events, and when that event happens, then the register receivers get notified.
Android BroadcastReceiver is a dormant component of android that listens to system-wide broadcast events or intents. When any of these events occur it brings the application into action by either creating a status bar notification or performing a task.
System broadcasts are sent to all apps that are subscribed to receive the event. The broadcast message itself is wrapped in an Intent object whose action string identifies the event that occurred (for example android. intent. action. AIRPLANE_MODE ).
An application listens for specific broadcast intents by registering a broadcast receiver in AndroidManifest. xml file. Consider we are going to register MyReceiver for system generated event ACTION_BOOT_COMPLETED which is fired by the system once the Android system has completed the boot process.
The change was made by @hackbod, perhaps she can shed light on the reason.
Her checkin note states:
Finish issue #10779747: Calendar Storage crash observed...
...while setting up a new user from settings.
We can now delay broadcasts when there are enough background services currently starting (still set to 1 for svelte devices, 3 for normal devices).
Add new intent flag to not allow receivers to abort broadcasts, which I use to fix an issue with the initial BOOT_COMPLETED broadcast not actually requesting pss data at the right time -- it can now be sent as an ordered broadcast without the ability for the receivers to cancel it.
Checkin diff
75
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
