Android Boot Completed Intent is a system broadcast sent after the device finishes booting. Apps that register for it can run code once startup is complete, which makes it a common trigger for background services, device management components, and other startup tasks.
What the Boot Completed broadcast means for Android apps
The Boot Completed broadcast is a post-startup signal, not a guaranteed invitation to run immediately or forever. It tells an app that the system has finished booting, so the app can resume a managed function, re-establish scheduled work, or bring a device-related component back into a known state.
Because the broadcast arrives at a sensitive lifecycle point, developers should treat it as a coordination event rather than a generic launch hook. The security question is not only whether code runs, but what that code can reach, how much trust it inherits from system startup, and whether the work it triggers is still appropriate at boot time.
Why startup-triggered code is security-sensitive
Code that starts at boot often has broad reach: it may touch local data, reconnect to remote services, re-register listeners, or launch background processing before the user has interacted with the device. That makes it attractive for persistence abuse, noisy background activity, and logic that is easy to forget during review.
Mobile control surfaces benefit from a focused review of boot-triggered paths, especially where the app handles device administration, credential material, or remote management. NHIMG’s Mobile App Security Guide is useful here because it covers Android intent interception, task impersonation, and related mobile abuse patterns that become more consequential when startup code is involved.
Common abuse and failure patterns
The main risk is not the broadcast itself, but the work attached to it. If an app accepts the event too broadly, attackers or misconfigurations can turn startup logic into an availability problem, a stealth persistence point, or a path to overactive background behaviour. Poorly constrained boot handlers can also re-enable stale sessions, restart unsafe services, or expose secrets that should have stayed dormant until a stronger trust check occurs.
Another failure mode is assuming that “boot complete” means “safe to proceed.” On Android, the device may be booted while user unlock state, enterprise policy enforcement, network reachability, or application-specific readiness is still incomplete. That gap can create race conditions, failed initialisation, or weakened security assumptions in code that is trying to recover state too early.
How teams should use boot-time triggers safely
Use the broadcast only for work that truly belongs in the post-boot path, then keep that work narrow, idempotent, and easy to audit. A good pattern is to separate the trigger from the action: let the broadcast schedule a controlled task, and let the task decide whether the app is in a valid state to proceed.
Where startup work depends on sensitive resources, delay access until the app can verify readiness and policy state. That reduces accidental exposure and makes it easier to distinguish legitimate startup recovery from behaviour that is simply trying to persist across reboots. The same discipline also helps when you review device-management components, because boot logic often becomes part of the trust boundary for mobile administration.
What to review after implementation
After adding a boot receiver, verify that it only activates the intended workflow, that it cannot be abused to run unrelated logic, and that its logging is clear enough to show what happened at startup. Review whether the component still needs to exist at all, because every boot-time entry point increases the amount of code that can influence early device behaviour.
Pay particular attention to any boot-triggered path that handles authentication material, management tokens, or background connectivity. Those flows should be designed so that a reboot does not silently expand privilege, resurrect stale state, or bypass the normal checks that protect the rest of the app.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | Boot-time handlers need auditable startup logging and safe error handling. |
| Recommendation — Log boot-triggered execution and handle startup failures without exposing sensitive state. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Boot-complete actions benefit from event logging and review of startup activity. |
| Recommendation — Record and review boot-triggered execution paths for unusual or repeated startup activity. | ||
| NIST SP 800-53 Rev 5 | SC-42 — Sensor Capability and Data Usage | System-triggered code paths should limit data use to the minimum needed at startup. |
| Recommendation — Constrain startup-triggered processing to the minimum data and functions required. | ||
Related resources from NHI Mgmt Group
- What happens when an Android app sends back an unvalidated intent that includes FileProvider URIs?
- What breaks when Android 15 screen sharing protections and intent filtering are not accounted for?
- What breaks when you rely on Frida-style TLS key extraction instead of a boot-time shim on Android?
- What is the difference between a runtime instrumentation approach and a boot-time shim library for Android TLS decryption?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org