DEV Community: Dilip Patel

Understanding Android Application Lifecycle and Process

Dilip Patel — Wed, 26 Jun 2024 07:54:33 +0000

Let’s dive into the details of how Android manages processes, components, and the overall lifecycle of an app.

Introduction

Understanding how Android manages processes, components, and the overall lifecycle of an application is fundamental for any developer creating apps. This article delves into the core concepts behind process creation, control, and sandboxing within the Android system. It also explores the lifecycles of key components like Activities, Services, and BroadcastReceivers, providing a roadmap for effective component management.

Processes in Android

Process Creation:
- Every Android application runs in its own Linux process.
- When an app's code needs to run (e.g., launching an activity), the system creates a process for that app.
- The process remains running until the system reclaims its memory for other applications.
Process Lifetime Control:
- Unlike traditional systems, an app's process lifetime isn't directly controlled by the app itself.
- The system determines when to start, pause, or terminate a process based on various factors:
  - Active components (e.g., Activity, Service, BroadcastReceiver)
  - Importance to the user
  - Overall system memory availability
Common Pitfall:
- Incorrectly managing components (e.g., starting threads from a BroadcastReceiver) can lead to process termination.
- Solution: Use JobService to ensure active work is recognized by the system.

Sandboxing in Android Processes

Android enforces strong process isolation through sandboxing.
Each app runs in its own sandboxed process, isolated from other apps.
Linux user-based security ensures file permissions and access control.
Inter-process communication (IPC) mechanisms allow controlled data exchange.

Viewing Android Processes with `adb shell ps`

ADB (Android Debug Bridge) is a versatile command-line tool that allows you to interact with an Android device or emulator. One of its essential features is the ability to view running processes.

Prerequisites

Before we begin, ensure that you have the following:

A computer with ADB installed.
An Android device connected to your computer via USB.
USB debugging enabled on your Android device (you can enable it in the Developer Options).

Steps to View Processes

Follow these steps to view the processes:

Open a terminal or command prompt on your computer.
Connect your Android device to your computer via USB.
Execute the following command:

adb shell ps

This will display a list of all processes, including their PIDs, UIDs, and other relevant details.

Understanding the Output

The output will include information such as:

PID (Process ID): A unique identifier for each running process.
UID (User ID): The user associated with the process.
Name: The name of the process (e.g., app package name).
Status: Whether the process is running, sleeping, or stopped.
Memory usage: Details about memory consumption.

Additional Tips

To filter the output for a specific package name (e.g., com.example.app), you can use:

adb shell ps | grep com.example.app

Some processes may run as system or root users, so their UIDs may differ.

if it's showing grep not found, you can use below command:

adb shell pgrep com.dilip.workmangagerexample

Application Object:
- The Application class (or application object) is a specific class within the Android framework.
- A single instance of this class is created when the application is launched.
- It remains alive for as long as the application is running.
- Developers can override the onCreate() method in the application class to initialize global resources.
Global Objects:
- Global objects are referenced from the application object itself.
- They remain in memory for the entire lifetime of the application.
- Use global objects to share state between different components within your app.
- Avoid using singletons; prefer global objects for better resource management.

Understanding Component Lifecycles

A well-structured app relies on a clear understanding of component lifecycles. Let's break down the key components and their lifecycle methods:

Activities:
- These are the single screens that make up your app's UI.
- Lifecycle methods (onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy()) manage how an activity behaves at different stages:
  - Creation
  - Visibility changes
  - Pausing due to another activity coming to the foreground
  - Destruction
Services:
- Designed for long-running operations or tasks that run in the background.
- Lifecycle methods (onCreate(), onStartCommand(), onDestroy()) govern their behavior.
- Different service types (bound, background, and foreground) address particular use cases.
BroadcastReceivers:
- These components respond to system-wide events or broadcasts.
- Simple lifecycle (onReceive()) executes only when a relevant broadcast is received.

Strategies for Process Optimization and Efficient App Management

Now that we understand the core concepts, let's explore strategies to optimize processes and create efficient apps:

Choose the Right Component for the Job:
- Utilize lightweight components like BroadcastReceivers for short tasks.
- Use Services with appropriate start modes (foreground for critical tasks with user notification) for long-running operations.
Asynchronous Operations:
- Long-running tasks that block the UI thread can lead to a sluggish app.
- Techniques like AsyncTask or WorkManager help execute these tasks asynchronously, keeping your UI responsive.
Handling Configuration Changes:
- Android can handles configuration changes like (e.g., screen orientation, language settings).
- onSaveInstanceState() and onRestoreInstanceState() methods allow activities to save and restore their state during such changes.
- ViewModel simplifies UI data management across configuration changes.
Background Execution with Control:
- Carefully manage background tasks.
- Explore alternatives like JobScheduler or WorkManager for background operations.
- These offer more control and flexibility over execution timing compared to traditional Services.
Leverage Profiling Tools:
- Android Studio's Profiler helps monitor app performance and identify potential memory leaks.
- Pinpoint resource bottlenecks to optimize your app's process usage and ensure a smooth user experience.

The Out-of-Memory Killer (OOM Killer)

To manage limited system resources, the Android system can terminate running applications.
Each application is started in a new process with a unique ID under a unique user.
The system follows a priority system to determine which processes to terminate:

If the Android system needs to terminate processes, it follows the following priority system:

Process Status	Description	Priority
Foreground	An application in which the user is interacting with an activity, or which has a service bound to such an activity. Also, if a service is executing one of its lifecycle methods or a broadcast receiver runs its `onReceive()` method.	1
Visible	User is not interacting with the activity, but the activity is still (partially) visible, or the application has a service used by an inactive but visible activity.	2
Service	Application with a running service that does not qualify for 1 or 2.	3
Background	Application with only stopped activities and without a service or executing receiver. Android keeps them in a least recently used (LRU) list and terminates the one that was least used when necessary.	4
Empty	Application without any active components.	5

The system maintains a least recently used (LRU) list of processes.
The out-of-memory killer (OOM killer) terminates processes from the beginning of the LRU list.
If an app is restarted by the user, it moves to the end of the queue.

Conclusion

Android applications run in their own Linux processes, with the system controlling their lifetime based on factors like active components, user importance, and memory availability. Sandboxing ensures app isolation and security. Activities, services, and broadcast receivers are the key components with their own lifecycles that need to be managed effectively. To optimize processes and create efficient apps, developers should choose the right component for the job, leverage asynchronous operations, handle configuration changes gracefully, manage background execution with control, and utilize profiling tools to identify potential issues. Finally, we discussed the Out-of-Memory (OOM) Killer, the system's mechanism for terminating processes when resources are limited, and the priority hierarchy it follows when making these decisions. By effectively managing processes and components, developers can create Android applications that are both user-friendly and resource-conscious. This article provides a solid foundation for understanding the intricacies of the Android system, allowing developers to optimize their apps for performance and efficiency.

Tasks, Back Stack & Launch Modes in Android

Dilip Patel — Wed, 19 Jun 2024 10:16:56 +0000

An activity is a screen shown in response to a user's action. For example, when you touch an app icon and it launches a screen, this first screen is the first activity. Technically speaking, an activity implements a part of the application’s visual user interface.

Activity States

An activity can have four states and we will discuss them briefly here.

Active
Activity is in an active state when it has the focus and it is ready to receive input from the user. The input can be in any form, most often a tap of a link or a button.

Inactive
When a user interacts with an activity or a screen, it usually causes a new activity to start and the system transfers the focus, or intent, to the new activity leaving the previous one inactive. An inactive activity is still there but in an inactive state. An inactive activity can receive focus and become active again.

Destroyed
An activity is destroyed when a user presses the back button. This action destroys the active activity and passes the focus to the previous one. Once an activity is destroyed, it must be created again; there is no way to bring a destroyed activity to life.

Hidden
An activity can remain active even when it is not visible to the user. This activity state is useful in certain multitasking scenarios.

All activities must be represented by the element in the manifest file or they will never run.

Tasks

A task is a collection of activities. Imagine a series of steps a user takes to complete a specific goal within your app. This sequence of activities, working together towards a common objective, forms a task. Tasks provide structure and maintain context for the user's journey through your app.

Same Task, Shared Workflow: Activities belonging to the same task share a common thread. They are part of a unified workflow, and their order of execution is crucial. These activities are stacked together within a single task, adhering to a Last-In, First-Out (LIFO) principle. The last activity added (launched) becomes the topmost activity in the task. When the user navigates back using the back button, the topmost activity is removed from the stack, revealing the previous activity underneath.

Example: Consider a photo editing task. You might have activities for opening an image, applying filters, and saving the edited image. These activities would all belong to the same task, with the back button allowing users to navigate back through the editing process.



// Example Kotlin code for starting an activity within the same task
val intent = Intent(this, EditImageActivity::class.java)
startActivity(intent)

Different Tasks, Independent Functionalities: Not all activities are created equal. Some tasks might be entirely independent of others. For instance, an email app and a music player would likely function as separate tasks. Each task maintains its own independent stack of activities, and activities within different tasks cannot directly influence each other’s behavior.

Example: Imagine you’re checking your email while listening to music. These actions represent two distinct tasks. Pressing the back button within the email app wouldn’t take you back to the music player, and vice versa.

Back Stack

As users navigate through your app, launching new activities, a separate entity called the back stack keeps track of their journey. The back stack functions like a stack of plates, with each plate representing an activity. As new activities are launched, they’re added on top of the back stack. Conversely, pressing the back button removes the topmost activity (plate) from the back stack, revealing the previously viewed activity (plate) underneath.

Managing Tasks

Android’s default task and back stack management is suitable for most applications, but there are times when developers need more control over their app’s navigation flow. This article explores how to manipulate task behavior using manifest attributes and intent flags.

Default Task Behavior: By default, Android places all activities started in succession within the same task, forming a “last in, first out” stack. This intuitive management allows users to navigate backward through the activity stack seamlessly.

Interrupting Normal Behavior: There are scenarios where the default behavior might not align with the desired user experience. For instance, you might want an activity to start a new task or bring an existing instance of an activity to the foreground. Android provides several ways to achieve this:

taskAffinity: Defines the relationship between different tasks and activities. Activities with the same affinity are generally grouped together in the same task.
launchMode: Specifies how an activity should be launched within a task. It can be “standard,” “singleTop,” “singleTask,” or “singleInstance.”
allowTaskReparenting: If set to true, allows an activity to move from its task to the task it has an affinity with when that task comes to the foreground.
clearTaskOnLaunch: When set to true, every time the user leaves the task and returns to it, all activities except for the root activity are finished.
alwaysRetainTaskState: If true, the task retains its state and is not reset when launched from the home screen.
finishOnTaskLaunch: Similar to clearTaskOnLaunch, but it also finishes the root activity, effectively clearing the entire task upon launch.
Using Intent Flags: In addition to manifest attributes, developers can use intent flags such as FLAG_ACTIVITY_NEW_TASK and FLAG_ACTIVITY_CLEAR_TOP to control how activities are launched and managed within a task.

Example Scenarios:

Starting a new task for an activity that serves as a distinct workflow within your app.
Bringing an existing instance of an activity to the foreground instead of creating a new one.
Clearing all activities except for the root when leaving a task.

Defining Launch Modes

Using the manifest file When you declare an activity in your manifest file, you can specify how the activity should associate with tasks when it starts.

Using Intent flags When you call startActivity(), you can include a flag in the Intent that declares how (or whether) the new activity should associate with the current task.

Activity Launch Modes: Controlling Activity Creation

Now that we understand tasks and the back stack, let’s delve into launch modes. These modes dictate how activities are created and managed within the task hierarchy:

Types of Launch Modes

standard
singleTop
singleTask
singleInstance

Standard (default)

The default mode. The system creates a new instance of the activity in the task it was started from and routes the intent to it. The activity can be instantiated multiple times, each instance can belong to different tasks, and one task can have multiple instances.

The most common launch mode. Whenever an activity is launched with the standard mode (or no mode is explicitly specified), a new instance of the activity is created. This new instance is placed on top of the current task’s stack.

Example: Imagine you have activities A, B, C, and D in your app. Launching B from activity A using the standard mode would create a new instance of B and add it on top of the stack, resulting in A -> B. Launching B again from the existing instance of B would create another new instance, forming A -> B -> B.

Launches a new instance of an activity in the task.
Can create multiple instances of the same activity, assigned to the same or separate tasks.
Launches a new instance of an activity in the task.
Can create multiple instances of the same activity, assigned to the same or separate tasks.

Scenario:

A -> B -> C -> D

Launching B again results in: A -> B -> C -> D -> B (B is created again)



// Example Kotlin code for standard launch mode
val intent = Intent(this, ActivityB::class.java)
startActivity(intent)

Single Top

If an instance of the activity already exists at the top of the current task, the system routes the intent to that instance through a call to its onNewIntent() method, rather than creating a new instance of the activity. The activity is instantiated multiple times, each instance can belong to different tasks, and one task can have multiple instances (but only if the activity at the top of the back stack is not an existing instance of the activity).

This mode offers more control over activity creation. If an activity is declared with launchMode=“singleTop” in the manifest file, the following behavior occurs:

If an instance of the activity already exists at the top of the stack within the current task, a new instance won’t be created. Instead, the existing activity receives the intent that triggered the launch through its onNewIntent() method. This method allows you to handle updates within the existing activity instance.

If the target activity with singleTop mode resides lower in the stack (not on top), a new instance is still created as usual.

Example: Let’s say activities A, B (with singleTop mode), C, and D are present. Launching D from C creates a new instance (A -> B -> C -> D). Now, launching B again from D would not create a new instance of B if it’s already at the top of the stack; instead, B’s onNewIntent() is called.

Will not create a new activity if it’s already at the top of the stack.

Scenario:

A -> B -> C -> D

Launching D again results in: A -> B -> C -> D (D is not created again)

Launching B results in: A -> B -> C -> D -> B (B is created again because it’s not at the top)



// Single Top launch mode example
val singleTopIntent = Intent(this, SingleTopActivity::class.java)
singleTopIntent.flags = Intent.FLAG_ACTIVITY_SINGLE_TOP
startActivity(singleTopIntent)

// In SingleTopActivity:
override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    // Handle the new intent here
}



<activity android:name=".ActivityB"
    android:launchMode="singleTop">
</activity>

Single Top If an activity is already at the top of the stack, it will not be launched again. Instead, the onNewIntent() method will be called with the new intent.

Single Task

The system creates the activity at the root of a new task or locates the activity on an existing task with the same affinity. If an instance of the activity already exists, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Meanwhile all of the other activities on top of it are destroyed.

The singleTask launch mode ensures that only one instance of the activity exists in a task. If you launch an activity with singleTask mode, and it already exists in the current task (potentially with other activities on top of it in the stack), those previous activities will be destroyed, and the existing activity will receive the intent through its onNewIntent() method. This effectively creates a new single-activity task if the activity wasn't already running, or brings the existing task to the foreground if it was running in the background.

Example: Consider activities A, B (with singleTask mode), C, and D. Launching B from A creates a new task with B at the root (B). Launching C from B adds C on top of the stack (B -> C). Now, launching A again from C wouldn't create a new instance of A or add it to the current task. Instead, the existing task containing B would be brought to the foreground, destroying C on top, and B would likely receive the intent through onNewIntent() (B).

Destroys any activities on top of the said activity if it’s already in the stack.

Scenario:

A -> B -> C

Launching D results in: A -> B -> C -> D (D is created)

Launching B after D results in: A -> B (B is brought to top, others are destroyed)



// Single Task launch mode example
val singleTaskIntent = Intent(this, SingleTaskActivity::class.java)
singleTaskIntent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
startActivity(singleTaskIntent)

// In SingleTaskActivity:
override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)
    // Handle the new intent here
}



<activity android:name=".SingleTaskActivity" android:launchMode="singleTask" />

Single Task Creates a new task and instantiates the activity at the root of the new task. If an instance already exists, it brings that task to the foreground.

Single Instance

The behavior is the same as for "singleTask", except that the system doesn't launch any other activities into the task holding the instance. The activity is always the single and only member of its task. Any activities started by this one open in a separate task.

Similar to singleTask, but even more restrictive. It allows only one instance of the activity to exist in the entire system, not just within a single task. Any other activity started from an activity with singleInstance mode will be launched in a new task. This mode is typically used for very specific scenarios, like splash screens or login activities that should only have one instance running at a time.

Example: Suppose, activity D has "launchMode = singleInstance". Launching D creates a new task with D at the root (D). Launching any other activity (like A) would create a new task with that activity at the root (A), leaving D's task unaffected (separate tasks: D and A).

Activity is launched in a new task, and this task can’t have any other activities.

Scenario:

Task1: A -> B -> C

Launching D results in:

Task1: A -> B -> C

Task2: D (D is created in a separate task)

Launching D again results in:

Task1: A -> B -> C

Task2: D (D is not created again, retrieved in its old state)

Creating a new activity E (not on singleInstance mode) results in:

Task1: A -> B -> C -> E (E is created on task1)

Task2: D



// Single Instance launch mode example
val singleInstanceIntent = Intent(this, SingleInstanceActivity::class.java)
singleInstanceIntent.flags = Intent.FLAG_ACTIVITY_NEW_DOCUMENT or Intent.FLAG_ACTIVITY_MULTIPLE_TASK
startActivity(singleInstanceIntent)



<activity android:name=".SingleInstanceActivity" android:launchMode="singleInstance" />

singleInstancePerTask

The activity can only run as the root activity of the task, the first activity that created the task, and therefore there can only be one instance of this activity in a task. In contrast to the singleTask launch mode, this activity can be started in multiple instances in different tasks if the FLAG_ACTIVITY_MULTIPLE_TASK or FLAG_ACTIVITY_NEW_DOCUMENT flag is set.

Note: "singleTask" and "singleInstancePerTask" remove all activities that are above the starting activity from the task. For example, suppose a task consists of root activity A with activities B and C. The task is A-B-C, with C on top. An intent arrives for an activity of type A. If A's launch mode is "singleTask" or "singleInstancePerTask", the existing instance of A receives the intent through onNewIntent(). B and C are finished, and the task is now A.

Choosing the Right Launch Mode

The appropriate launch mode depends on the specific functionality you aim to achieve within your app.

Use standard mode for activities that don't require special handling of multiple instances or updates within a single instance.
Use singleTop mode for activities that act as containers or entry points for tasks, where you only want one active instance at a time, and want to handle updates within that instance using onNewIntent().
Use singleTask mode for activities that represent the core functionality of a distinct task, ensuring only one instance exists per task and potentially clearing the task stack to get there.
Use singleInstance mode sparingly, for special cases where you truly need only one instance of an activity in the entire system (e.g., login or splash screen).

Android Activity Launch Modes Through Practical Implementation

MainActivity Implementation: MainActivity acts as our control panel, with buttons to initiate activities with each launch mode. Here’s how to set it up:



// MainActivity.kt
import android.content.Intent
import android.os.Bundle
import android.widget.Button
import android.widget.Toast
import androidx.appcompat.app.AppCompatActivity

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

        val buttonStandard = findViewById<Button>(R.id.button_standard_launch)
        buttonStandard.setOnClickListener {
            Toast.makeText(this, "Standard Launch", Toast.LENGTH_SHORT).show()
            startActivity(Intent(this, ActivityA::class.java))
        }

        val buttonSingleTop = findViewById<Button>(R.id.button_single_top_launch)
        buttonSingleTop.setOnClickListener {
            Toast.makeText(this, "SingleTop Launch", Toast.LENGTH_SHORT).show()
            startActivity(Intent(this, ActivityA::class.java))
        }

        val buttonSingleTask = findViewById<Button>(R.id.button_single_task_launch)
        buttonSingleTask.setOnClickListener {
            Toast.makeText(this, "SingleTask Launch", Toast.LENGTH_SHORT).show()
            startActivity(Intent(this, ActivityB::class.java))
        }

        val buttonSingleInstance = findViewById<Button>(R.id.button_single_instance_launch)
        buttonSingleInstance.setOnClickListener {
            Toast.makeText(this, "SingleInstance Launch", Toast.LENGTH_SHORT).show()
            startActivity(Intent(this, ActivityC::class.java))
        }

        val buttonNewTaskClearTop = findViewById<Button>(R.id.button_new_task_clear_top_launch)
        buttonNewTaskClearTop.setOnClickListener {
            Toast.makeText(this, "New Task and Clear Top", Toast.LENGTH_SHORT).show()
            val intent = Intent(this, ActivityD::class.java)
            intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP
            startActivity(intent)
        }
    }
}

In this code, we define buttons that, when clicked, start activities with different launch modes using intents. We also display toast messages to indicate which mode is being activated.

XML Layout for Buttons: The user interface for MainActivity is defined in activity_main.xml. It includes buttons that correspond to each launch mode:



<!-- activity_main.xml -->
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:padding="16dp">

    <!-- Standard Launch: Adds ActivityA on top of MainActivity -->
    <Button
        android:id="@+id/button_standard_launch"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Standard Launch"
        android:layout_marginBottom="8dp" />

    <!-- SingleTop Launch: Adds ActivityA on top if not already there or brings it to top if it's already there -->
    <Button
        android:id="@+id/button_single_top_launch"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="SingleTop Launch"
        android:layout_marginBottom="8dp" />

    <!-- SingleTask Launch: Brings ActivityB to the top of the stack, clearing above it -->
    <Button
        android:id="@+id/button_single_task_launch"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="SingleTask Launch"
        android:layout_marginBottom="8dp" />

    <!-- SingleInstance Launch: Opens ActivityC in a new task with its own backstack -->
    <Button
        android:id="@+id/button_single_instance_launch"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="SingleInstance Launch"
        android:layout_marginBottom="8dp" />

    <!-- New Task and Clear Top: Starts ActivityD in a new task and clears any existing instances of it -->
    <Button
        android:id="@+id/button_new_task_clear_top_launch"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="New Task and Clear Top"
        android:layout_marginBottom="8dp" />
</LinearLayout>

Other layout files:



<!-- activity_b.xml -->
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <Button
        android:id="@+id/button_start_activity_c"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Start Activity C"
        android:layout_centerInParent="true" />
</RelativeLayout>

<!-- activity_c.xml -->
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <Button
        android:id="@+id/button_start_activity_d"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Start Activity D"
        android:layout_centerInParent="true" />
</RelativeLayout>

<!-- activity_d.xml -->
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <Button
        android:id="@+id/button_start_activity_e"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Start Activity E"
        android:layout_centerInParent="true" />
</RelativeLayout>

<!-- activity_e.xml -->
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <!-- No button needed for Activity E as it's the last one in the sequence -->
    <TextView
        android:id="@+id/text_view_activity_e"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Activity E"
        android:layout_centerInParent="true" />
</RelativeLayout>

Manifest for Example:



<activity android:name=".MainActivity">

    <!-- MainActivity has standard launch mode by default -->

</activity>

<activity android:name=".ActivityA"

          android:launchMode="singleTop">

    <!-- ActivityA has singleTop launch mode -->

</activity>

<activity android:name=".ActivityB"

          android:launchMode="singleTask">

    <!-- ActivityB has singleTask launch mode -->

</activity>

<activity android:name=".ActivityC"

          android:launchMode="singleInstance">

    <!-- ActivityC has singleInstance launch mode -->

</activity>

<activity android:name=".ActivityD">

    <!-- ActivityD will use flags for new task and clear top -->

</activity>

<activity android:name=".ActivityE">

    <!-- ActivityE has no specific launch mode requirements -->

</activity>

Conclusion

Tasks are a collection of activities that users interact with when performing a certain job.
The Back Stack is the order in which activities are opened and stored in a task.
Launch Modes determine how an activity instance is associated with a task and how it interacts with the back stack.

Launch modes allow developers to control the creation and organization of activities within tasks:

Standard: Creates a new instance every time.
Single Top: Reuses the top activity if it’s the same type being launched.
Single Task: Ensures only one instance exists within a task, clearing others if necessary.
Single Instance: Ensures one instance across all tasks, ideal for activities that must not be interrupted.

By choosing the appropriate launch mode, you can optimize the user experience by managing how activities are instantiated, reused, or cleared from memory. This knowledge helps in designing efficient, user-friendly app navigation flows.

Main components of android application

Dilip Patel — Wed, 19 Jun 2024 08:01:06 +0000

Application Components

Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your application’s overall behavior.

Activities

An activity represents a single, full-screen user interface (UI) within your application.

Each activity focuses on a specific task or feature, providing a cohesive and focused experience for the user. It's the primary touchpoint for user interaction within your application.

To navigate transitions between stages of the activity lifecycle, the Activity class provides a core set of six callbacks: onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy(). The system invokes each of these callbacks as an activity enters a new state.

Here's a basic example of an activity written in Kotlin:

class MainActivity : Activity() {

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

This code defines a MainActivityclass that inherits from the Activity class. The onCreatemethod, overridden here, is called when the activity is first created. This is where you would typically inflate your layout (the visual design of the screen) using setContentViewand set up UI elements for user interaction.

Key Points:

Activities manage the application's lifecycle, meaning they are created, paused, resumed, and destroyed as the user navigates through the app.
Each activity is independent, allowing different applications to potentially launch specific activities within your app (if permissions allow).
For a more feature-rich UI, activities often work together, passing data and triggering actions between them.
Activities can handle user input through UI elements like buttons, text fields, and touch gestures.
They can also launch other activities or system services within the Android framework.

Services

A Service is an application component that can perform long-running operations in the background, and it doesn't provide a user interface.

Unlike activities, services run in the background to perform long-running operations or tasks for remote processes. They don't provide a UI directly.
A service can be started, bound, or both:

Started

A service is "started" when an application component (such as an activity) starts it by calling startService(). Once started, a service can run in the background indefinitely, even if the component that started it is destroyed. Usually, a started service performs a single operation and does not return a result to the caller. For example, it might download or upload a file over the network. When the operation is done, the service should stop itself. The service runs indefinitely and must stop itself by calling stopSelf(). Another component can also stop the service by calling stopService(). When the service is stopped, the system destroys it.

Bound

A service is "bound" when an application component binds to it by calling bindService(). A bound service offers a client-server interface that allows components to interact with the service, send requests, get results, and even do so across processes with interprocess communication (IPC). A bound service runs only as long as another application component is bound to it. Multiple components can bind to the service at once, but when all of them unbind, the service is destroyed. The service is created when another component (a client) calls bindService(). The client then communicates with the service through an IBinder interface. The client can close the connection by calling unbindService(). Multiple clients can bind to the same service and when all of them unbind, the system destroys the service. The service does not need to stop itself.

Foreground

A foreground service performs some operation that is noticeable to the user. For example, an audio app would use a foreground service to play an audio track. Foreground services must display a Notification. Foreground services continue running even when the user isn't interacting with the app. Although both Activities and Services can be killed if the system is low on memory, a foreground service has priority over other resources. To request that a service run in the foreground, call startForeground() instead of startService().

Here's a simplified example of a service:

class MyService : Service() {

  override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    // Perform background task here
    return START_STICKY
  }
}

This code defines a MyServiceclass that extends the Serviceclass. The onStartCommand method is called when the service is started, typically by an activity or another component. This is where you would place your background operations, like playing music or fetching data from a network.

Key Points:

Services are ideal for long-running tasks that shouldn't be interrupted by the user interacting with the UI.
They can be started, stopped, or bound to by other components in your application.
There are different service lifecycle methods to handle various scenarios, such as when the system is running low on memory.
Services can run even when the user is not actively using the application, as long as the system allows it.
They can communicate with activities or other components through mechanisms like intents or binders.

Broadcast Receivers

Broadcast receivers are lightweight components that listen for system-wide broadcast announcements.

Broadcasts are messages that the Android system and Android apps send when events occur that might affect the functionality of other apps. These announcements can originate from the system itself (e.g., low battery) or from other applications.

There are two types of broadcasts:

System broadcasts are delivered by the system.
Custom broadcasts are delivered by your app.

Apps can receive broadcasts in two ways:

Manifest-declared receivers
Context-registered receivers

There are two kinds of Broadcast Receivers.

Static Broadcast Receivers: These types of Receivers are declared in the manifest file and works even if the app is closed.

Dynamic Broadcast Receivers: These types of receivers work only if the app is active or minimized.

Here's an example of a broadcast receiver:

class BatteryLevelReceiver : BroadcastReceiver() {

  override fun onReceive(context: Context, intent: Intent) {
    val level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1)
    // Handle low battery level if needed
  }
}

Key Points:

Broadcast receivers are event-driven, meaning they are triggered only when a specific broadcast is sent. This makes them efficient for reacting to system changes or application events without constantly monitoring the system state.
They are lightweight and have a simple lifecycle, making them suitable for short-lived tasks like updating the UI based on a broadcast.
Broadcast receivers can be registered dynamically at runtime or declared statically in the Android Manifest file. This allows for flexibility in how you choose to listen for broadcasts.
They cannot directly interact with the UI themselves. However, they can trigger actions within activities or services that can then update the UI or perform other necessary actions.
Broadcast receivers can be permission-protected, ensuring that only authorized applications can receive specific broadcasts.

Content Providers

Content providers act as a central hub for managing shared sets of application data. They allow other applications to access and potentially modify this data, if your content provider grants permission.

These are handled by the class ContentResolver class. This class implements a set of APIs(Application Programming Interface) that enables the other applications to perform the transactions. Any Content Provider must implement the Parent Class of ContentProvider class.

Here's a peek at a content provider :

class NoteProvider : ContentProvider() {

  override fun onCreate(): Boolean {
    // Initialize content provider
    return true
  }

  // Implement methods for querying and modifying data
}

This code defines a NoteProvider class extending the ContentProviderclass. The onCreatemethod is used for initialization. Content providers offer a standard set of methods for other applications to interact with the data, including querying for specific information or updating existing data.

Key Points:

Content providers are useful for sharing data between your application and others, enabling functionalities like contact access or data exchange.
They can also be used for private data management within your application.
Security is crucial when dealing with content providers, as you control access permissions for other applications.
Content providers offer a structured way to access and modify data, often using a relational database model.
They can be used to synchronize data between your application and other applications or services.

Conclusion

In conclusion, Android applications are built upon four fundamental components: activities, services, content providers, and broadcast receivers.

Activities represent individual screens with user interfaces, providing the primary touchpoint for user interaction.
Services handle long-running background tasks, operating independently of the UI.
Content providers manage shared sets of data, enabling data exchange between your application and others.
Broadcast receivers act as event listeners, responding to system-wide announcements and triggering appropriate actions.

DEV Community: Dilip Patel

Understanding Android Application Lifecycle and Process

Introduction

Processes in Android

Sandboxing in Android Processes

Viewing Android Processes with adb shell ps

Prerequisites

Steps to View Processes

Understanding the Output

Additional Tips

Understanding Component Lifecycles

Strategies for Process Optimization and Efficient App Management

The Out-of-Memory Killer (OOM Killer)

Conclusion

Tasks, Back Stack & Launch Modes in Android

Activity States

Tasks

Back Stack

Managing Tasks

Defining Launch Modes

Activity Launch Modes: Controlling Activity Creation

Android Activity Launch Modes Through Practical Implementation

Conclusion

Main components of android application

Application Components

Activities

Services

Broadcast Receivers

Content Providers

Conclusion

Viewing Android Processes with `adb shell ps`