Let’s take a more in-depth look at processes, a concept you’ve almost certainly encountered before. Processes exist on desktop operating systems as well as on mobile devices, and since Android is built on Linux, it naturally adopts Linux’s process model. At a fundamental level, every piece of running code must execute within a process. processes Read the previous article in this series here. Read the previous article in this series here. here A process is essentially an isolated container for a program. Each process manages its own memory space, which is used to allocate variables and objects. This memory space is protected so that other processes cannot overwrite it, ensuring isolation and stability across the system. process In addition to memory, a process owns certain system resources and—most importantly—contains at least one thread responsible for executing code. On Android, this primary thread is known as the main thread. While a process can host multiple threads, it must have at least one; without a thread, no code can be executed. main thread What Makes Up a Process? What Makes Up a Process? If we examine a process more closely, it consists of several core components: Application Code Application Code Application Code This is the actual Android code that needs to be executed. Data Segment Data Segment Data Segment The data segment stores global and static variables. These variables exist for the entire lifetime of the process, which is why they are stored separately from temporary data. Heap Storage Heap Storage Heap Storage The heap is used for dynamically allocated memory. Objects that outlive a single function call—such as objects shared across multiple methods—are stored here. For example, a global variable like counter would be allocated on the heap. counter class MainActivity : ComponentActivity() {

    private var counter = 0

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        val string = helloWorld()

        setContent {
            AndroidInternalsTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
                    Greeting(
                        name = "Android",
                        modifier = Modifier.padding(innerPadding)
                    )
                }
            }
        }
    }
} class MainActivity : ComponentActivity() {

    private var counter = 0

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        val string = helloWorld()

        setContent {
            AndroidInternalsTheme {
                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
                    Greeting(
                        name = "Android",
                        modifier = Modifier.padding(innerPadding)
                    )
                }
            }
        }
    }
} Stack Stack Stack The stack stores data related to function calls, including local variables, function parameters, and return addresses. Variables declared inside a function are allocated on the stack and are removed once the function finishes execution. private fun helloWorld(): String {
        var count = 0

        return "Hello world!"
 } private fun helloWorld(): String {
        var count = 0

        return "Hello world!"
 } CPU Pointers CPU Pointers CPU Pointers CPU pointers reference the next instruction to be executed. One of the most important of these is the program counter, which tells the CPU which instruction should run next. program counter Resource Handles Resource Handles Resource Handles Resource handles represent access points to system resources such as files, network sockets, or hardware components. For example, open file descriptors, Bluetooth connections, or web sockets are all managed through resource handles. This model describes how processes work in a pure Linux environment. Android builds on top of this foundation and introduces additional constraints and abstractions. Android aims to exercise more control than a traditional Linux system, particularly to manage limited resources on mobile devices. Because apps run inside processes, Android can monitor how much CPU time a process consumes, how much memory it uses, and how much battery it drains. The system uses this information to decide whether a process should remain alive. If a process is consuming excessive resources while providing little user value, Android may terminate it to preserve system health. Processes vs. Components on Android Processes vs. Components on Android On Android, it’s important to distinguish between a process and a component. process component When you tap an app icon, the app is launched inside a process. In a simple app, that process might initially host only a single MainActivity. However, activities are just one type of Android component. Other component types include services, broadcast receivers, and content providers. MainActivity services broadcast receivers content providers Multiple components can run inside the same process. Just because an app contains several activities or services does not mean each one runs in its own process by default. That said, developers can explicitly configure certain components to run in separate processes. This is done in the AndroidManifest.xml file using the android:process=":process_name" attribute. Running components in separate processes is useful when isolation or dedicated resources are required. AndroidManifest.xml android:process=":process_name" <?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application
        android:allowBackup="true"
        android:dataExtractionRules="@xml/data_extraction_rules"
        android:fullBackupContent="@xml/backup_rules"
        ...>
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:process=":" //launch new process for this activity
            ...>
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest> <?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application
        android:allowBackup="true"
        android:dataExtractionRules="@xml/data_extraction_rules"
        android:fullBackupContent="@xml/backup_rules"
        ...>
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:process=":" //launch new process for this activity
            ...>
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest> Inspecting and Managing Processes with ADB Inspecting and Managing Processes with ADB You can inspect all running processes on an Android device or emulator using the Android Debug Bridge (ADB), which provides a command-line interface to connected devices. To list all active processes, run: adb shell ps -A adb shell ps -A This command outputs every running process, including your app’s process. You can identify your app by its package name in the NAME column, along with additional information such as the process ID (PID) and the user under which it is running. NAME To simulate a process being killed—a useful technique for testing lifecycle handling and resilience—you can force-stop your app with the following command: adb shell am force-stop <your_app_package_name> adb shell am force-stop <your_app_package_name> Understanding how processes work and testing how your app behaves when they are terminated, is essential for building robust Android applications that can handle crashes, background kills, and memory pressure gracefully. In the next article, we’ll look at the zygote process, followed by process lifecycle and importance hierarchy. next article zygote process process lifecycle and importance hierarchy

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Android OS Architecture, Part 4: Understanding Processes, Memory, and Threads

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Android OS Architecture, Part 2: How the Android System Fits Together

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

11 Tips to Save Time on App Development & Launch Processes

Android OS Architecture, Part 2: How the Android System Fits Together

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

11 Tips to Save Time on App Development & Launch Processes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps