Setting the Stage

Android app architecture is one of those topics where the surface looks simple (activities, intents, lifecycle callbacks) but the deeper you go, the more you realize how much the OS is doing on your behalf. A strong answer here covers how the system bootstraps a process, how the component model works, how the lifecycle ties into memory management, and how everything fits together in a real app. Let's walk through it layer by layer.

Clarifying the Scope

Before diving in, it's worth asking: are we focused on a single-process app, or are we talking about multi-process architectures? Are we covering modern architecture patterns (ViewModel, Jetpack Compose lifecycle) or just the raw platform primitives? For this guide, we'll cover the core platform model first, then touch on how modern patterns sit on top of it.

How an App Process is Born

This is where most people start too late. Android apps don't just "launch." The OS has to spin up a new Linux process for them. Let's trace the path from "user taps an icon" to "first line of app code runs."

Zygote and process forking: Android runs a special process called Zygote that boots at system startup and pre-loads the Android runtime (ART), core libraries, and class loaders. When a new app process is needed, the system forks Zygote rather than spawning a fresh process from scratch. This is a massive optimization because fork() uses copy-on-write semantics, so the new process shares all those pre-loaded pages with Zygote until it writes to them. Cold start time is dramatically reduced because the VM is already warm.
ActivityManagerService (AMS): The system-level service that orchestrates everything. When the user taps an icon, the launcher sends an Intent to AMS. AMS checks if a suitable process already exists (hot start), and if not, asks Zygote to fork a new one.
Application object: Once the process exists, the runtime instantiates your Application subclass (or the default one) and calls onCreate(). This is the very first app code that runs, before any Activity or Service. It's a common place for global initialization like dependency injection graphs, crash reporting SDKs, or network client configuration. The caveat is that heavy work here blocks every cold start, so you want to be disciplined.

The Four Core Components

Android's architecture is built around four types of app components, each with its own lifecycle and purpose. The interesting design choice here is that these aren't just classes you instantiate. The system is the one that creates and destroys them, which is why lifecycle management exists at all.

Activity: Represents a single screen with a UI. This is the most visible component and has the most complex lifecycle. We'll go deep on this below.
Service: Runs in the background without a UI. A started service does work and stops itself when done. A bound service exposes an interface that other components can call into. A foreground service is a started service that shows a persistent notification, giving it protection from the low-memory killer (more on that soon).
BroadcastReceiver: A lightweight component for responding to system-wide or app-level events (e.g., connectivity changes, battery low, custom app broadcasts). Receivers have no UI and are meant to do minimal work, often just kicking off a Service or scheduling a WorkManager job. Since Android 8.0, implicit broadcast receivers registered in the manifest are heavily restricted to reduce background battery drain.
ContentProvider: Manages structured data and exposes it to other apps via a URI-based API. It's the standard way to share data across process boundaries safely. Under the hood, ContentProviders use Binder IPC for cross-process calls. One subtle thing: ContentProviders are initialized very early, even before Application.onCreate(), which is why some libraries (like WorkManager's initializer) abuse this to bootstrap themselves without requiring manual setup.

The Activity Lifecycle in Detail

The lifecycle is probably the most interview-tested topic here, but the interesting question isn't "what callbacks exist" but "why does this design exist at all." The answer is that Android runs on constrained hardware and needs to reclaim resources aggressively. The lifecycle is the contract between the OS and your app about who owns the screen and when resources should be released.

The key states and their transitions:

onCreate: Called once when the Activity is first created. Do your heavy one-time setup here: inflate views, set up ViewModels, bind adapters. Note that the Bundle parameter carries saved instance state, which we'll discuss under configuration changes.
onStart / onStop: The Activity becomes visible / invisible to the user. Resources tied to visibility (like registering a location listener to update a map) should be acquired in onStart and released in onStop.
onResume / onPause: The Activity gains / loses focus. This is the narrowest pair. In onPause you should persist any data that needs to survive the activity going into the background, but you can't do heavy work here because it blocks the incoming activity from starting. Keep onPause fast.
onDestroy: Called when the Activity is truly being destroyed, either by the user finishing it or the system killing the process. Do final cleanup here, but don't rely on it being called in low-memory situations because the system may just kill the process outright.

The tricky edge cases come from configuration changes (rotating the screen, changing locale, switching to multi-window). By default, Android destroys and recreates the Activity on any configuration change. If you've stored UI state in instance variables, it's gone. The solution is the ViewModel (from Android Jetpack), which survives configuration changes by living outside the Activity's lifecycle but being scoped to its logical session. The ViewModel is stored in a ViewModelStore that the system retains across recreations. Combine that with SavedStateHandle inside the ViewModel for state that also needs to survive process death, and you have a clean, layered solution.

The Intent System and Back Stack

Components communicate via Intents, which are message objects describing an operation to perform. An explicit Intent names the target component directly. An implicit Intent describes a capability (e.g., "view a URL"), and the system resolves which app can handle it at runtime. This is how Android achieves app interoperability without tight coupling.

Activities are managed in a back stack per task. When you start a new Activity, it's pushed on the stack. When the user presses back, it's popped and destroyed. Launch modes (singleTop, singleTask, singleInstance) let you control whether a new instance is created or an existing one is reused. These matter a lot for things like notification deep links where you don't want to keep stacking the same screen.

Memory Management and the Process Lifecycle

This is the trickiest part of Android design because the system can kill your process at any time without warning if it needs memory. There's no OS-level guarantee that onDestroy will be called. The system uses a priority ladder to decide who to kill first:

Foreground process (has a visible Activity or foreground Service)
Visible process (Activity is visible but not focused, like behind a dialog)
Service process (running a background Service)
Cached process (no active components, kept alive as a warmup cache)

The practical implication: if your app is in the cached state and the user gets a phone call while playing a memory-intensive game, your process may be silently killed. When the user returns to your app, the system will try to restore the UI using the saved instance state (a Bundle that survives process death). This is why you need onSaveInstanceState for transient UI state and a persistent store (Room database, DataStore) for anything durable.

The low-memory killer (LMK) is a kernel-level driver that enforces this. Each process has an oom_adj score updated by AMS as the process's importance changes. The higher the score, the more likely it gets killed under pressure.

Threading Model

Every Android app has a main thread (also called the UI thread). All lifecycle callbacks and View updates happen on this thread. The rule is simple: never block the main thread. A blocked main thread for more than 5 seconds triggers an Application Not Responding (ANR) dialog, which is a terrible user experience.

For background work you have several options, and the right choice depends on the work's nature:

Kotlin Coroutines with viewModelScope / lifecycleScope: The modern default. Coroutines launched in viewModelScope are automatically cancelled when the ViewModel is cleared, preventing memory leaks. lifecycleScope ties to the Activity/Fragment lifecycle.
WorkManager: For deferrable, guaranteed background work that needs to survive process death and device reboots. Think syncing data, uploading logs. WorkManager picks the right underlying mechanism (JobScheduler on API 23+) and handles constraints like "only run on Wi-Fi."
Executors / Thread Pools: Lower-level, useful when you're working in Java or need fine-grained control. The main downside is manual lifecycle management.

Inter-Process Communication (Binder IPC)

Android's security model gives every app its own Linux user ID and a sandboxed process. Components in different apps can't share memory directly. The Binder kernel driver is the IPC mechanism that makes cross-process calls feel like local method calls. When you bind to a Service in another app, you get an IBinder handle. Under the hood, the Binder driver copies the call arguments from the calling process into kernel space and then into the target process. It's efficient (single copy, not two), and it enforces permission checks at the kernel level.

You describe the IPC interface in an .aidl file (Android Interface Definition Language), and the build tools generate the stub and proxy boilerplate. In practice, most developers don't write AIDL directly unless building SDK-style services. ContentProviders and Intents abstract the Binder calls for the common patterns.

The AndroidManifest.xml as the Contract

Every component (Activity, Service, Receiver, Provider) must be declared in the manifest. The manifest is how the OS knows what your app can do before it even runs. The PackageManager reads the manifest at install time and registers the app's capabilities. Intent filters declared here tell the system which implicit Intents this app can handle. Permissions declared here tell users what data the app needs. The manifest is essentially the app's static metadata that the OS reasons about independently of the app's runtime behavior.

Modern Architecture Patterns on Top of the Platform

Raw platform APIs give you power but not guardrails. The Android team's recommended architecture layered on top is:

UI Layer: Activities/Fragments (or Composables) observe state from ViewModels. They only render and forward user events, containing no business logic.
ViewModel Layer: Holds and exposes UI state as flows or LiveData. Calls into the domain or data layer. Survives configuration changes.
Data Layer: Repositories abstract over data sources (Room for local, Retrofit for remote). The ViewModel doesn't know if data came from a cache or the network.

Jetpack Compose changes the UI layer's surface but not the underlying lifecycle model. Composables have their own composition lifecycle (remember, LaunchedEffect, DisposableEffect), which maps onto the conceptual activity/fragment lifecycle without the historical baggage of XML views and fragment transactions.

Key Tradeoffs and Hard Parts

The hardest part of Android architecture is that the component lifecycle and the process lifecycle are decoupled. Your Activity can be destroyed and recreated without the process dying. Your process can die without any lifecycle callback being called. These two failure modes require two different defense strategies: ViewModel for configuration-change survival, and persistent state plus savedInstanceState for process-death survival. Getting confused about which problem you're solving is the source of most Android state bugs.

Another genuine tension: the manifest-driven component model makes apps very testable and decoupled in theory, but in practice it makes dependency injection at startup harder because the system creates component instances, not your code. That's why frameworks like Hilt (which wraps Dagger and generates component factories that hook into the Application/Activity lifecycle) exist. They bridge the gap between the OS's control over object creation and your desire to inject dependencies cleanly.

2011. Android App Architecture

Similar Questions