Launch your app on boot

A field device should never show the Android launcher. This guide makes your app start on its own the moment the board finishes booting — the foundation under every kiosk build.

The mechanism

Android broadcasts BOOT_COMPLETED when the system is ready. You register a receiver for it and launch your activity. That is the whole idea; the details are where devices trip up.

Step 1 — Declare the permission and receiver

AndroidManifest.xml

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

<receiver
    android:name=".BootReceiver"
    android:enabled="true"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

exported="true" is required — the broadcast comes from the system, not your process.

Step 2 — Launch from the receiver

public class BootReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) {
            Intent app = new Intent(context, MainActivity.class);
            app.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
            context.startActivity(app);
        }
    }
}

FLAG_ACTIVITY_NEW_TASK is mandatory — a receiver has no activity task of its own to launch into.

Step 3 — The app must run once before the receiver works

Android does not deliver BOOT_COMPLETED to an app that has never been launched since install. After installing your APK, open it manually once. From then on it starts on every boot. This catches almost everyone the first time — the app "won't auto-start", but it simply was never woken to arm the receiver.

If it does not start

Symptom	Cause	Fix
Never starts after install	App never opened once	Launch it manually one time
Starts then vanishes	Crash on cold boot	Check logs; the system may be slower at boot than in normal use
Starts under the launcher	Launched too early	Add a short delay, or handle the race with a foreground service
Works on USB, not on power-cut	Timing difference	Test the real power-cut path, not just adb reboot

Making it robust

On a cold boot the system is busy and slower than when you test interactively. Two hardening steps:

Give it a moment. A brief delay before startActivity avoids racing the launcher on slower cold boots.

Consider a foreground service. For a device that must never fall out of your app, a foreground service started at boot — which then launches and re-launches the activity if it ever dies — is more resilient than a one-shot receiver. Pair this with the scheduled reboot in Power and scheduling so a total freeze still recovers overnight.

Verify

The honest test is a real power cut, not adb reboot:

1. Fully power the board down.
2. Restore power.
3. Confirm your app is on screen, unattended, within the expected time.

If you are also running kiosk lockdown, confirm the bars are hidden after this cold-boot path too — not just after a warm launch.

Related

• Kiosk mode — the full lockdown this feeds into
• Power and scheduling — scheduled reboot for recovery