Activity — what it is, Android app screen and its Lifecycle

What is Activity?

Activity — a key Android application component that provides a window for user interaction. Each Activity manages a separate screen: task list, login form, photo viewer. The Android system creates an Activity when requested and destroys it when memory is needed by other applications.

Activity first appeared in Android 1.0 (2008) and remains the main building block of the interface. According to Google (2026), 98% of apps on Google Play contain at least one Activity. In modern architecture, Google recommends one Activity with multiple Fragments, however the classic multi-screen application remains a common practice.

Activity stack (back stack) — a task stack that stores navigation history. When the user presses "Back", the current Activity is destroyed and the previous one is restored. The system manages the stack automatically, but the developer can control behavior through launchMode and Intent flags.

Activity Lifecycle

The Activity lifecycle is a set of states and callbacks through which a screen passes from creation to destruction. Understanding the Lifecycle is critically important: incorrect state handling leads to memory leaks, data loss, and app crashes.

The Android system calls callbacks in a strict order. The developer overrides the necessary methods to initialize resources, save data, and free memory. Each callback has a corresponding pair: onCreate ↔ onDestroy, onStart ↔ onStop, onResume ↔ onPause.

Activity States

There are four states of Activity: Running (onResume active), Paused (visible but without focus), Stopped (not visible), Destroyed (destroyed). The system can kill an Activity in the Stopped state when memory is low — data must be saved in onSaveInstanceState.

Lifecycle methods: onCreate, onStart, onResume

Let's look at three key Activity lifecycle methods with a Kotlin example. onCreate — the entry point, called once. Here layout binding via setContentView, RecyclerView initialization, LiveData subscription happen. onStart — the Activity becomes visible to the user. onResume — the Activity gets focus and is ready for interaction.

class MainActivity : AppCompatActivity() {

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

        val recyclerView = findViewById<RecyclerView>(R.id.rv_items)
        recyclerView.layoutManager = LinearLayoutManager(this)
        loadItems()
    }

    override fun onStart() {
        super.onStart()
        startLocationUpdates()
    }

    override fun onResume() {
        super.onResume()
        resumeVideoPlayer()
    }
}

In the example, onCreate initializes RecyclerView and loads data. onStart starts geolocation updates — a resource that should only work when the screen is visible. onResume resumes the video that was paused in onPause. This separation prevents unnecessary background work.

Declaring Activity in AndroidManifest.xml

Each Activity must be declared in the AndroidManifest.xml file. Without registration, the system won't find the screen and will throw an ActivityNotFoundException. The manifest specifies the class name, theme, orientation, launchMode, and Intent filters.

<application
    android:allowBackup="true"
    android:label="@string/app_name"
    android:theme="@style/Theme.MyApp">

    <activity
        android:name=".MainActivity"
        android:exported="true">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>

    <activity
        android:name=".DetailActivity"
        android:parentActivityName=".MainActivity" />
</application>

The exported flag determines whether other applications can launch the Activity. For the main screen exported=true, for internal screens — false. The parentActivityName attribute enables standard Up Navigation.

Launching Activity via Intent

Intent — an object that describes an action to perform. In the context of Activity, Intent is used to launch another screen with data passing. Intent can be explicit (specifies a specific class) and implicit (specifies an action, the system selects a suitable component).

// Explicit Intent — launching DetailActivity with data
val intent = Intent(this, DetailActivity::class.java).apply {
    putExtra("item_id", itemId)
    putExtra("item_name", itemName)
}
startActivity(intent)

// Getting data in DetailActivity
val itemId = intent.getLongExtra("item_id", 0L)
val itemName = intent.getStringExtra("item_name") ?: ""

To get a result from a launched Activity, the Activity Result API is used, which replaced the deprecated startActivityForResult. The new API is type-safe, declarative, and works with Jetpack Compose.

private val getResult = registerForActivityResult(
    ActivityResultContracts.StartActivityForResult()
) { result ->
    if (result.resultCode == Activity.RESULT_OK) {
        val data = result.data?.getStringExtra("result_key")
    }
}

fun openPicker() {
    val intent = Intent(this, PickerActivity::class.java)
    getResult.launch(intent)
}

Saving state on recreation

When the screen rotates or configuration changes, Android recreates the Activity — sequentially calls onDestroy and onCreate. Without state saving, the user loses entered data, scroll position, and selected items. Android provides two mechanisms to solve this problem: onSaveInstanceState and ViewModel.

onSaveInstanceState saves simple data in Bundle before onDestroy is called. ViewModel from Jetpack survives Activity recreation and stores data in memory, which is more efficient for complex objects and network requests.

class MainActivity : AppCompatActivity() {

    private val viewModel: MainViewModel by viewModels()

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

        // ViewModel automatically saves data
        viewModel.items.observe(this) { items ->
            updateAdapter(items)
        }
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putInt("scroll_position", recyclerView.computeVerticalScrollOffset())
    }
}

Single Activity Architecture and Jetpack

Google's modern approach is Single Activity architecture with one Activity and multiple Fragments. The app uses one MainActivity, and all navigation is handled by Navigation Component through NavHostFragment. Advantages: centralized navigation, shared ViewModel per screen, correct Deep Links handling.

Jetpack Navigation Component automates back stack management, transition animations, and argument passing. NavHostFragment is placed in the Activity layout, and the navigation graph (NavGraph) describes all screens and connections between them. This approach is recommended by Google for new projects and follows Material Design principles.

class MainActivity : AppCompatActivity() {

    private val navController by lazy {
        findViewById<NavHostFragment>(R.id.nav_host_fragment)
            .navController
    }

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

        // Setting up NavigationUI for AppBar
        setupActionBarWithNavController(navController)
    }

    override fun onSupportNavigateUp() = 
        navController.navigateUp() || super.onSupportNavigateUp()
}