Skip to content

MASTG-KNOW-0132: Android Activities

An activity is an app component that provides a single screen with a user interface. An app typically implements one activity per screen, so an app with three screens implements three activities. Each activity extends the Activity class (or a subclass such as AppCompatActivity) and hosts the user interface elements of that screen, including fragments, views, and layouts.

Activities are a fundamental inter-process communication (IPC) entry points. Other apps and the system can start an activity by sending it an Intent, subject to manifest access controls such as android:exported and android:permission. This makes activity visibility directly relevant to the app's attack surface. See Inter-Process Communication (IPC) Mechanisms for the IPC model and Implicit Intents for how implicit intents reach activities.

Declaration

Each activity must be declared in the AndroidManifest.xml file with an <activity> element nested inside <application>:

<activity android:name=".MainActivity" />

Activities that aren't declared in the manifest can't be displayed, and attempting to launch them raises an exception. The system instantiates each activity when it's started and routes user interaction and lifecycle events to it.

Lifecycle

Activities have their own lifecycle managed by the Android system. An activity can be in one of several states (for example, created, started, resumed, paused, stopped, and destroyed) and receives callbacks as it transitions between them. The most common callbacks are:

  • onCreate: initializes the activity and is where the user interface is usually built.
  • onStart, onResume: the activity becomes visible and then interactive.
  • onPause, onStop: the activity loses focus and then visibility.
  • onDestroy: the activity is being removed; release resources here.
  • onSaveInstanceState and onRestoreInstanceState: persist and restore transient UI state.

For the full description, see The activity lifecycle.

Starting an Activity

An activity is started by passing an Intent to startActivity or, when a result is expected, through the Activity Result APIs. Intents can be:

  • Explicit: they name the target component by class, typically to start an activity within the same app, or an exported component in another app if access controls allow it.
  • Implicit: they describe an action and let the system resolve which component handles it, based on the <intent-filter> declarations of installed apps.

See Implicit Intents for the distinction between explicit and implicit intents.

Intent Filters

An <intent-filter> declares the actions, categories, and data an activity can respond to. The launcher activity, for example, declares the MAIN action and LAUNCHER category:

<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>

An activity can only be started by an implicit intent if it declares a matching intent filter. For implicit activity launches, the filter normally needs the CATEGORY_DEFAULT category because startActivity treats implicit intents as if they included it. Intent filters are not an access-control mechanism; use android:exported and permissions to control which external callers can start an activity. Deep links are a special case of intent filter that map web or custom URIs to activities; see Deep Links.

Access Control

Whether other apps can start an activity is governed by manifest attributes:

  • android:exported: when true, components of other apps can start the activity unless another control, such as android:permission, blocks the caller. When false, only the same app, apps with the same user ID, or privileged system components can start it. The default is false when an activity has no intent filters.
  • <intent-filter>: declares the implicit intents an activity can receive. Historically, activities with intent filters and no explicit android:exported value could become reachable by other apps on older target SDK versions. Relying on defaults is discouraged; apps targeting Android 12 (API level 31) or higher must set android:exported explicitly on activities with intent filters, or the app fails to install.
  • android:permission: requires the caller to hold a specific permission to start the activity. If the caller is not granted the permission, the intent is not delivered to the activity. Combined with a custom permission and an appropriate android:protectionLevel (for example, signature), this restricts which apps can interact with the component. See App Permissions for permission protection levels, component permission enforcement, and custom permissions, and see Permission-based access control to exported components.

For an overview of how to restrict access to exported components, see Restrict Access to Android App Components.