You do not run an Android app; the system does. It starts your components when something asks for them, destroys and rebuilds your screen when the device rotates, kills your process to reclaim memory, and hands the user a switch that revokes a permission you were using a second ago. Nearly everything that surprises a competent developer arriving here is one of those facts in a different costume. This guide is the platform's half of the contract: what it does to your code, when, and what you have to plan for.
Each chapter opens with the short version. Tap one to read the detail.
There is no entry point — and no Back button you own
~3 min
Nothing in your codebase is where the app begins: the system starts individual components and knows only the ones your manifest declares. Those components then stack into a task the system owns, and launch modes rewrite that stack in ways that are easy to get wrong.
Your screen is destroyed and rebuilt on purpose, constantly
~2 min
Rotate the device and the system destroys your activity and builds a new one. Separately it can kill the whole process for memory and rebuild it from a small saved bundle. State you did not deliberately save is gone.
Compose runs your function again, and again, and again
~3 min
A composable describes a screen; it is not a widget you mutate. Compose re-runs it whenever inputs change, possibly every animation frame, so a plain variable is invisible to it — and where you read state decides what changing it costs.
Put nothing you care about in an activity
~2 min
Activities and fragments are hosts the system destroys and recreates at will, so they are the worst place to keep data. Push state into a state holder and rules into a data layer — which also makes the logic testable without a device.
A permission is a loan the user can call in
~2 min
Install-time permissions arrive with the app. Runtime permissions are asked for in a dialog and can be taken back later — from settings, after months of disuse, or because the user only agreed to "this time".
Work you started does not follow the user out of the app
~2 min
A coroutine is only guaranteed while your app is in a valid lifecycle state; once no activity is visible, that work can simply stop. Anything that must finish belongs in WorkManager, which persists it across process death and reboots.
Where data goes, and why the network is never on the main thread
~2 min
App-specific storage is private and disappears with the app; media and documents in shared storage outlive it. Since Android 10 your reach into everything else is scoped, and a network call on the main thread throws rather than stalling.
The device is not your device
~2 min
You never hand-pick a layout for a screen size. You put alternatives in qualified directories and the system runs an elimination algorithm to choose one — and if it eliminates everything for want of an unqualified default, the app crashes.
Five seconds is the entire budget
~2 min
The main thread draws the screen and handles input. Block it for five seconds during input dispatch and the system offers the user a dialog to force-quit your app — and none of this can be measured on a debug build.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.