Frontend · Architecture · Interview

Rebuilding Android Launch and Persistence After Your Process Gets Killed

By 疯华整猫 · Nov 7, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Android's tightening background execution rules mean any app needing reliable background work must plan for process death and recovery. This architecture provides a compliant, modern pattern that works across Android 14/15/16 and avoids deprecated keep-alive hacks.

Summary

The article tackles the messy reality of Android background work: waking an app from a deep link, keeping a task alive, and recovering after the system kills the process. The author redesigns this as a unified five-layer architecture (trigger, launch, session, recovery, observability) instead of three separate bugs. Key pieces include a single router that handles cold/warm/hot starts without losing parameters, a state machine with persisted checkpoints and a user authorization window, and a recovery coordinator that converges four restart paths (START_STICKY, WorkManager, push, user reopening) into one idempotent flow.

Version-specific requirements get heavy treatment: foreground service types and permissions must match exactly between manifest and code, Android 15 caps dataSync at 6 hours daily and requires onTimeout handling, PendingIntent needs explicit mutability flags since 12, and boot broadcasts can only reschedule work. The article also documents a full set of adb commands for testing each layer, and a detailed workflow for using the Trae AI coding assistant with precise prompts, project rules, and iterative debugging patterns, including a compliance checklist for Android 14/15/16 and app store policies.

Takeaways

— Distinguish wake-up, persistence, and old keep-alive: each has different APIs and success criteria; the system treats them separately.

— Handle all three process states (cold, warm, hot) in a single dispatch, reading params in both onCreate and onNewIntent to avoid silent loss.

— On Android 14+, the manifest `foregroundServiceType` must exactly match the `typeMask` passed to `ServiceCompat.startForeground`, or the system throws SecurityException.

— Android 15 limits dataSync and mediaProcessing foreground services to 6 hours per day; implement `onTimeout` to checkpoint state before stopping.

— START_STICKY only best-effort recreates the service with a null intent, is often blocked by ROMs, and must be supplemented by WorkManager, push, and user reopening.

— Use a persisted state machine with `sessionId` and `dedupeKey` to guarantee idempotent recovery, and always check a user authorization window before auto-reviving.

— Background `startActivity` is banned since Android 10; route user attention through notification PendingIntents instead.

— App Links verification fails with upload-key fingerprints when Play App Signing is enabled, and server redirects or wrong Content-Type break the check.

— WorkManager periodic work has a 15-minute minimum; use it as a watchdog, not a real-time heartbeat.

— Old keep-alive schemes (dual-process, 1-pixel, silent audio) are unreliable and non-compliant; design for graceful death and recovery instead.

— Use adb commands like `adb shell pm get-app-links`, `adb shell dumpsys activity services`, and `adb shell dumpsys jobscheduler` to validate each layer.

Conclusions

The article shows that 'keep the process alive' is a lost battle on modern Android; the only viable strategy is making death harmless by persisting state and designing idempotent recovery.

AI code generation (Trae) only becomes useful when strict constraints are embedded in project rules and each generation round includes verification commands; without that, it produces outdated or version-blind code.

The comprehensive version table highlights how Android's background execution limits have effectively forced developers to adopt explicit, observable, and user-controllable background patterns—a shift that aligns background apps with privacy and battery expectations.

The emphasis on compliance (purpose dialogs, stop buttons, authorization windows) suggests that in the Chinese app ecosystem, regulatory scrutiny now shapes technical architecture as much as OS constraints do.

Concepts & terms

Foreground Service Type

A required declaration (since Android 14) specifying what a foreground service does (e.g., dataSync, location). The manifest and the code's typeMask must match exactly; otherwise the system throws SecurityException.

START_STICKY

A service return constant asking the system to recreate the service after it's killed, but with a null intent and no timing guarantee. Often blocked by vendor ROMs, so it's only a weak fallback.

DedupeKey

A unique identifier per task item used to ensure idempotent execution during recovery, preventing duplicate background work when multiple restart sources fire simultaneously.

App Links

HTTPS deep links verified via an assetlinks.json file; they open your app directly without a chooser, but require correct signing fingerprints, no redirects, and valid content-type.

PendingIntent mutability

On Android 12+, PendingIntents must explicitly specify FLAG_IMMUTABLE or FLAG_MUTABLE, or the system throws IllegalArgumentException.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗