Android Activity Launch Modes & Lifecycle: A Interview Guide

Understanding launch modes, back-stack behavior, lifecycle callbacks, and real-world Activity communication.

In Android interviews, knowing the Activity lifecycle callbacks is only the starting point. At the interview level, interviewers often want to understand why a particular callback runs, how Android manages the Activity back stack, and how you handle data when multiple screens interact.

Let’s explore these concepts through practical scenarios.

1. What happens when an Activity launches another Activity?

Suppose an app has three Activities: A, B, and C.

When the user navigates from A to B, Android generally pauses A and brings B to the foreground. If A is no longer visible, it moves to the stopped state.

The back stack looks like this:

A → B → C

Pressing Back from C normally finishes C and returns the user to B. Pressing Back again returns to A.

Android manages this stack as part of its task system. A task represents a collection of Activities the user interacts with to complete a particular piece of work.

However, the exact back-stack behavior can change depending on launch modes, intent flags, task affinity, and how the Activity is launched.

This is where launch modes become important.

2. Activity launch modes

Launch modes control how Android creates or reuses an Activity when an Intent requests it.

1. standard

This is the default launch mode. Every launch creates a new Activity instance.

Scenario: The user taps a product twice, and each tap launches ProductActivity.

The stack could become:

ProductActivity → ProductActivity → ProductActivity

Each instance has its own lifecycle and state.

2. singleTop

Android reuses the existing Activity only if an instance is already at the top of the relevant task’s back stack.

If reused, Android calls onNewIntent() instead of creating another instance.

Scenario: A notification opens ChatActivity, which is already at the top of the stack. Android can reuse it rather than create a duplicate.

If another Activity is above ChatActivity, singleTop alone does not guarantee reuse.

3. singleTask

Android looks for an existing matching instance according to task and launch rules. If it finds one, it brings that instance forward and removes Activities above it from the stack. If no matching instance exists, Android creates one in the appropriate task.

Scenario: A user navigates through several screens before opening the app’s main destination. You want an existing destination to be reused instead of accumulating duplicate instances.

Be careful: singleTask can significantly change Back behavior because Activities above the reused instance may be removed.

4. singleInstance

The Activity runs as the sole Activity in its task. Other Activities launched from it are placed in separate tasks.

This is a specialized mode and is rarely necessary in typical modern application navigation.

5. singleInstancePerTask

This mode allows an Activity to be the root of a task, with at most one instance of that Activity in each task. Multiple tasks can contain their own instance under the applicable launch rules.

It is a more specialized option than the usual standard or singleTop modes.

Quick comparison

Comparison

Interview takeaway: Don’t just memorize launch modes. Explain how each one changes instance creation, the back stack, and Back navigation.

Actual behavior also depends on Intent flags, task affinity, and the context used to launch the Activity.

3. onNewIntent() and Intent flags

Reusing an Activity introduces another important question: how does it receive the new Intent?

Consider singleTop. If ChatActivity is already at the top and another notification launches it, Android can call:

override fun onNewIntent(intent: Intent) {
super.onNewIntent(intent)
// Handle the new notification or deep link.
}

One subtle detail: getIntent() continues to return the Intent originally associated with the Activity unless you update it.

If subsequent code should read the latest Intent, call:

override fun onNewIntent(intent: Intent) {
super.onNewIntent(intent)
setIntent(intent)
// Process the new Intent.
}

Important Intent flags

A common interview trap is assuming CLEAR_TOP always reuses an existing Activity. With the default standard launch mode, the target may be finished and recreated unless the relevant reuse behavior is also requested.

Similarly, NEW_TASK does not simply mean “always create a brand-new task.” Android considers existing tasks and other launch rules.

4. Activity lifecycle: onCreate(), onStart(), onResume(), and onRestart()

Interviewers often ask: Why do we usually call setContentView() in onCreate() instead of onStart()?

onCreate() is where we initialize the Activity and establish its initial UI. Calling setContentView() here is conventional because the view hierarchy generally needs to be created once for that Activity instance.

onStart() can run multiple times as the Activity becomes visible again. Putting UI creation there without a specific reason can lead to unnecessary work or duplicate setup.

Technically, setContentView() can be called elsewhere; onCreate() is the usual choice, not a strict API requirement.

What is the difference between these callbacks?

The key distinction is that onStart() means visible, while onResume() means in the foreground and ready for interaction.

onRestart() is not called every time an Activity regains focus. It runs when an Activity that was stopped is starting again, followed by onStart() and then onResume().

For example, if an Activity is covered by another Activity and later becomes visible again, it may receive onRestart() if it had reached the stopped state. If it was only paused, it can return through onResume() without onRestart().

5. What happens to lifecycle callbacks when navigating A → B → C?

This is a common scenario-based interview question.

Assume all three are separate Activities, and each new Activity fully covers the previous one.

A → B

Typical sequence:

1. A receives onPause().
2. B receives onCreate(), onStart(), and onResume().
3. A receives onStop() once it is no longer visible.

B → C

Get Ninad Bhase’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Similarly:

1. B receives onPause().
2. C receives onCreate(), onStart(), and onResume().
3. B receives onStop() once it is no longer visible.

The stack is now:

A → B → C

Back: C → B

When the user presses Back:

1. C receives onPause().
2. B, which was stopped, receives onRestart(), onStart(), and onResume().
3. C finishes and typically receives onStop() and onDestroy().

The exact timing and ordering of callbacks around transitions can vary with the Android version, windowing behavior, and Activity configuration. The sequence above is the typical case for fully covering Activities.

Follow-up question: Does B get recreated when returning from C?

Not normally. If B was retained in the back stack, Android brings that existing instance back. Its fields may still hold their values, but they should not be relied on for durable state: the process could have been killed while B was stopped.

Use saved state, a ViewModel, or persistent storage depending on how long the state must survive.

6. How should Activity A receive data after an API call in Activity C?

Imagine this flow:

Activity A → Activity B → Activity C

Activity C performs an API call, updates a user’s profile, and then the user presses Back. Activity A needs to display the updated profile.

There are several approaches. The right one depends on whether you need a one-time result or ongoing data consistency.

Option 1: Activity Result API

Use the Activity Result API when a screen returns a specific result to the screen that launched it.

For example, A launches B, and B launches C. If C returns a result directly to its launcher, B is the recipient, not A. B can then forward the result to A, or the navigation flow can be redesigned to make the intended recipient the launcher.

This works well for one-time results such as selecting an image, choosing a document, or completing a small user flow.

Option 2: Refresh data when A resumes

If Activity A should show the latest server state whenever the user returns, trigger a refresh from its ViewModel when appropriate.

For example:

override fun onResume() {
super.onResume()
viewModel.refreshProfile()
}

The ViewModel should own the data-loading logic rather than putting the network request directly in the Activity.

This approach is straightforward, but onResume() can run for reasons other than returning from C. Avoid unnecessary requests by using caching, freshness checks, or explicit navigation-result signals when needed.

Option 3: Repository and observable state

For applications where multiple screens display or update the same data, use a shared source of truth such as a repository backed by a database.

A typical flow is:

1. C performs the API call.
2. The repository updates the local database with the response.
3. A observes the relevant data through its ViewModel.
4. When the database emits the updated value, A’s UI updates.

With Kotlin Flow, the repository might expose:

fun observeProfile(): Flow<Profile>

Activity A’s ViewModel collects this stream and exposes UI state to the screen.

This reduces tight coupling between Activities and helps keep data consistent across screens. Separate Activities do not automatically share the same ViewModel instance, so shared data should be coordinated through an appropriately scoped repository or another shared source of truth.

For an interview, explain the trade-off rather than declaring one solution universally best.

7. How Android launches an Activity internally

At a high level, starting an Activity involves more than calling a method on an object.

When you call:

startActivity(intent)

Android processes the launch request through its system Activity and task-management machinery. The system resolves the target, applies task and launch-mode rules, and arranges for the target process and Activity to be created or reused as needed.

The app’s main thread then participates in Activity lifecycle dispatch. Framework code creates and attaches the Activity, invokes lifecycle callbacks, and coordinates its window with the system.

You generally do not need to memorize every internal class for an interview. What matters is understanding that Activity launch behavior is coordinated by Android’s system, not determined solely by the startActivity() call.

8. Common interview questions

Q1. Does singleTop guarantee only one instance of an Activity?

No. It reuses the Activity only when the matching instance is already at the top of the relevant task. Launching it from elsewhere can still create another instance.

Q2. What is the difference between onStart() and onResume()?

onStart() indicates that the Activity is becoming visible. onResume() indicates that it has entered the foreground and can interact with the user.

Q3. When is onRestart() called?

When a stopped Activity is about to start again. It is followed by onStart() and onResume().

Q4. Why call setContentView() in onCreate()?

It is the conventional place to establish the initial view hierarchy once per Activity instance. onStart() may run repeatedly, so it is generally not the right place for initial UI creation.

Q5. What happens to an Activity when another Activity opens on top of it?

The first Activity is typically paused and then stopped if it is no longer visible. Its instance usually remains in the back stack unless it is finished or otherwise removed.

Q6. When should you use onNewIntent()?

When Android reuses an existing Activity instance for a new Intent, such as with applicable singleTop or flag-based launches.

Q7. How would you update Activity A after Activity C changes data?

For a one-time result, use the Activity Result API and forward the result through intermediate screens as needed. For shared or persistent data, prefer a repository and observable state, or refresh from A’s ViewModel when it resumes.

Q8. Can Android destroy a stopped Activity?

Yes. The system can kill the app process under memory pressure. Do not rely on Activity fields alone to preserve important state.

Final takeaway

Activity launch modes determine how instances are created and reused. Lifecycle callbacks describe the Activity’s visibility and interaction state. Intent flags influence task and back-stack behavior, while repositories and lifecycle-aware state help screens stay consistent.

For interviews, focus on three things: predict the back stack, explain the lifecycle sequence, and justify your data-flow design.

Thanks for reading! Follow along for more Android engineering concepts explained through practical interview scenarios.

Happy to connect on LinkedIn: https://www.linkedin.com/in/ninadbhase/