Master Android
Lifecycle

The 7 core callbacks

Every Activity moves through a defined set of states. The system calls these methods to signal transitions. Implementing them correctly is the difference between an app that feels solid and one that leaks memory, loses user data, or crashes on rotation.

Deep dive: each callback

onCreate() — The setup callback

Called once when the Activity is first created, or after a process kill when the user returns. Receives a savedInstanceState Bundle — null on first launch, non-null when restoring. This is where you call setContentView(), initialize ViewModels, set up RecyclerView adapters, and restore saved UI state.

onStart() — Becoming visible

The Activity is about to become visible. At this point it's not yet interactive. This is a good place to register BroadcastReceivers that are only needed when the Activity is visible, or to begin animating UI elements that are always shown.

onResume() — Taking focus

The Activity is now fully visible, in the foreground, and receiving user input. This is the "running" state. Acquire exclusive resources here: camera, microphone, sensors. Resume paused animations. This callback is called every time the Activity comes to the foreground — including when returning from another Activity or dismissing a dialog.

onPause() — Losing focus (fast!)

Called when the Activity is partially obscured — another Activity in multi-window, a dialog, or the system about to transition away. Must complete very quickly — the next Activity cannot start until onPause returns. Release camera/mic here. Save critical but lightweight state. Do NOT do disk I/O, network calls, or complex animations.

onStop() — Invisible

The Activity is completely hidden. This is where you release expensive resources: database cursors, location updates, expensive animations. The system may call onSaveInstanceState just before this if it may need to restore the Activity later. After onStop the process can be killed without further callbacks — this makes onStop the last guaranteed callback for saves.

onRestart() — Coming back from stopped

Called when an Activity that was stopped (but not destroyed) is about to start again. Followed immediately by onStart. Use this to refresh data that might have changed while the user was away — for example, re-querying a contact that might have been edited in another app.

onDestroy() — Cleanup

Called before the Activity is destroyed. This happens either because the user finished the Activity, or because the system is destroying it due to a configuration change. Check isFinishing() to distinguish. Release any remaining resources, close threads, unregister any remaining listeners. Not guaranteed to be called if the process is killed — never rely on it for critical saves.

class MainActivity : AppCompatActivity() {

    private val viewModel: MainViewModel by viewModels()
    private var camera: Camera? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // ViewModel survives rotation — data already loaded
        viewModel.uiState.observe(this) { state -> render(state) }

        // Restore transient UI state (e.g. scroll position)
        savedInstanceState?.let {
            binding.recycler.scrollToPosition(it.getInt("scroll_pos", 0))
        }
    }

    override fun onResume() {
        super.onResume()
        camera = Camera.open()  // acquire exclusive resource
    }

    override fun onPause() {
        super.onPause()
        camera?.release()   // must release before next Activity can use camera
        camera = null
    }

    override fun onStop() {
        super.onStop()
        // Heavy resource release, last guaranteed callback
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putInt("scroll_pos", binding.recycler.computeVerticalScrollOffset())
        outState.putString("search_query", binding.searchView.query.toString())
    }

    override fun onDestroy() {
        super.onDestroy()
        if (isFinishing()) {
            // Permanent destruction — user navigated away
        } else {
            // Config change (rotation) — ViewModel will re-attach
        }
    }
}

Configuration changes & rotation

Screen rotation triggers a full destroy-recreate cycle by default. The system calls onSaveInstanceState, destroys the Activity, then creates a new one with the saved Bundle. The ViewModel is kept alive across this — it's the primary tool for surviving rotation without saving/restoring complex data through a Bundle.