Introduction

Android can notify your app when the device finishes booting, but that does not mean you should immediately launch a screen. The correct pattern is usually to receive the boot broadcast, do lightweight initialization, and schedule background work or a service only when the app’s purpose truly requires it.

How Boot Startup Works

After the system finishes booting, Android sends the BOOT_COMPLETED broadcast. Apps that declare the RECEIVE_BOOT_COMPLETED permission and a matching BroadcastReceiver can react to it.

At a minimum, you need two things:

• the permission in the manifest
• a receiver that listens for the boot action

Here is a basic manifest setup.

1<manifest xmlns:android="http://schemas.android.com/apk/res/android"
2    package="com.example.bootdemo">
3
4    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
5
6    <application
7        android:allowBackup="true"
8        android:label="@string/app_name"
9        android:supportsRtl="true"
10        android:theme="@style/Theme.BootDemo">
11
12        <receiver
13            android:name=".BootReceiver"
14            android:enabled="true"
15            android:exported="true">
16            <intent-filter>
17                <action android:name="android.intent.action.BOOT_COMPLETED" />
18            </intent-filter>
19        </receiver>
20
21    </application>
22</manifest>

Implement the Receiver

The receiver should stay small. Boot is a sensitive phase of device startup, and heavy work here can hurt performance.

1package com.example.bootdemo
2
3import android.content.BroadcastReceiver
4import android.content.Context
5import android.content.Intent
6import androidx.work.OneTimeWorkRequestBuilder
7import androidx.work.WorkManager
8
9class BootReceiver : BroadcastReceiver() {
10    override fun onReceive(context: Context, intent: Intent) {
11        if (intent.action == Intent.ACTION_BOOT_COMPLETED) {
12            val request = OneTimeWorkRequestBuilder<StartupWorker>().build()
13            WorkManager.getInstance(context).enqueue(request)
14        }
15    }
16}

Using WorkManager is a good default because it lets Android schedule the follow-up work appropriately instead of forcing the receiver to do everything immediately.

Do Not Launch an Activity Unless You Truly Mean To

A lot of older answers suggest starting your main activity directly from the boot receiver. That is usually a poor user experience and, on modern Android, may not behave the way you expect because of background-start restrictions.

If the goal is to resume syncing, monitoring, scheduled jobs, or notification setup, start background work instead. Only launch a visible activity automatically when the product genuinely requires kiosk-like behavior and you have designed for platform restrictions and user expectations.

Example Worker

The boot receiver above schedules a worker. The worker can refresh alarms, restore a periodic job schedule, or reinitialize app state.

1package com.example.bootdemo
2
3import android.content.Context
4import androidx.work.Worker
5import androidx.work.WorkerParameters
6
7class StartupWorker(
8    appContext: Context,
9    params: WorkerParameters
10) : Worker(appContext, params) {
11    override fun doWork(): Result {
12        // Re-register alarms, warm caches, or restore background scheduling.
13        return Result.success()
14    }
15}

This separation keeps the receiver fast and makes the post-boot workflow easier to test.

Version and Device Considerations

Boot behavior has become stricter over time. Background execution limits, battery optimizations, and manufacturer customizations can all affect what happens after boot.

A few practical rules help:

• assume the receiver will not be the right place for long-running work
• test on the Android versions and device vendors you actually support
• expect users to care if your app starts doing work at boot without a clear reason

Some apps also need to handle LOCKED_BOOT_COMPLETED if they must run before the user unlocks the device. That is a more specialized case and requires direct-boot-aware design.

Common Pitfalls

Starting a full UI from the receiver is the most common architectural mistake. It is usually better to schedule background work and let the user open the app normally.

Forgetting the RECEIVE_BOOT_COMPLETED permission will prevent the receiver from being called.

Doing expensive work directly inside onReceive() is another problem because the receiver is expected to finish quickly.

Finally, do not assume all device vendors treat boot-time behavior identically. Test on real hardware, not only an emulator.

Summary

• listen for BOOT_COMPLETED with a manifest-declared BroadcastReceiver
• include the RECEIVE_BOOT_COMPLETED permission
• keep the receiver lightweight and hand off real work to WorkManager or another appropriate mechanism
• avoid launching an activity at boot unless the product explicitly requires that behavior
• test boot-time flows on the Android versions and devices you support