An Activity is a screen, and the Android system constantly creates, pauses, and destroys it as the user navigates and rotates the device. Master the lifecycle callbacks — the single most important Android concept.
An Activity is the entry point for interacting with the user — essentially one screen. Unlike a desktop program with a single main(), an Android app is a set of Activities the system starts and stops as needed, even launching one directly (a share sheet opening your compose screen). Your MainActivity’s onCreate is where you set up the UI.
import android.app.Activity
import android.os.Bundle
class MainActivity : Activity() {
// onCreate is the entry point for THIS screen — called when it's created
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main) // attach the UI
// (modern apps call setContent { } with Jetpack Compose instead)
}
}
// an app = many Activities the SYSTEM starts/stops — not one main() you control.The system drives an Activity through a lifecycle: created, started, resumed (visible and interactive), paused, stopped, destroyed. You override the callbacks to acquire and release resources at the right moments — start a camera in onStart, release it in onStop. Ignoring the lifecycle is the root cause of the most common Android bugs: leaks, crashes, and wasted battery.
onCreate -> onStart -> onResume (now visible + interactive)
|
user leaves / another screen comes forward
v
onPause <- the classic sequence back down
onStop <- no longer visible
onDestroy <- being destroyed
Rules of thumb:
onCreate set up UI + one-time init
onStart/onResume acquire resources you need while visible (sensors, camera)
onPause/onStop RELEASE them promptly (or you leak + drain battery)
onDestroy final cleanup
Getting acquire/release paired with the lifecycle is 80% of Android correctness.A rotation, language change, or theme switch is a configuration change: Android destroys and recreates the Activity from scratch, running onCreate again. Any state held in plain fields is lost, which is why unhandled rotation wipes what the user typed. This surprising behavior is why Android has dedicated state-holding mechanisms (next topic and the ViewModel in the Architecture course).
class MainActivity : Activity() {
var counter = 0 // WARNING: this is LOST when the screen rotates!
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// on rotation: Android DESTROYS this Activity and creates a NEW one
// -> onCreate runs again -> 'counter' is back to 0, user's input gone.
}
}
// this is the #1 "why did my data disappear?" bug for new Android devs.
// the fix is dedicated state holders, not plain fields (next).To survive recreation, you persist transient UI state in the savedInstanceState Bundle: write it in onSaveInstanceState and read it back in onCreate. This handles rotation and process death for small UI state. For anything beyond trivial state you use a ViewModel (Architecture course), which survives configuration changes without this ceremony — but knowing the Bundle mechanism explains why the platform behaves as it does.
class MainActivity : Activity() {
private var counter = 0
override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
outState.putInt("counter", counter) // save before destruction
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// restore after recreation (rotation, process death)
counter = savedInstanceState?.getInt("counter") ?: 0
}
}
// good for SMALL UI state. For real state, a ViewModel survives rotation
// automatically — see the Android Architecture course.