Join our Newsletter — 33% off our NHI Course

Android Activities

Android Activities are application components that present a single screen and manage user interaction in an Android app. They matter to security because activity transitions, intent handling and lifecycle mistakes can expose data, allow unintended navigation or enable component hijacking. Developers should restrict exported activities, validate intents and protect sensitive screens from being invoked unexpectedly.

Android activities as the app’s screen-level control point

An Android activity is more than a UI container. It is often the entry point for a user journey, so its exported status, intent filters and launch behaviour shape who can reach a screen and under what conditions. Security issues here usually come from trusting navigation paths too much.

Because activities sit at the boundary between the app and the Android framework, a design mistake can make a private screen reachable from outside the app, or let an attacker steer the app into an unexpected state. That is why activity security is closely tied to component exposure, intent validation and explicit access checks.

How activity lifecycle mistakes create security exposure

Activities move through a lifecycle that includes creation, pause, stop, restart and destruction. If sensitive state is loaded too early, cached too long, or not cleared at the right time, another app or a later user session may see information that should have been transient.

Lifecycle handling also affects resilience. A screen that restores state incorrectly after process death, rotation or task switching may reopen a privileged view, repeat an action, or reveal data that should only exist briefly in memory. Secure lifecycle code treats state restoration as a security boundary, not just a usability feature.

When an activity can be relaunched from notifications, deep links or task history, the developer should assume it may be invoked in a context different from the original user flow. The safe pattern is to recheck authorization and reconstruct sensitive state from trusted inputs instead of relying on what the previous screen already knew.

Intents, task switching and component hijacking

Android uses intents to move between components. That flexibility is useful, but it also creates a common attack surface: an intent can carry extras, trigger a different code path, or land in a screen the app did not intend to expose. Mobile App Security Guide covers related patterns such as Android intent intercept, activity hijack and task impersonation.

If an activity accepts untrusted intent data without validation, attackers may be able to change the requested object, manipulate navigation, or induce unsafe side effects. Task switching can also create confusion when a sensitive screen remains in the recent-apps stack or can be re-entered through stale state.

In practice, the danger is not only direct data exposure. A hijacked or misrouted activity can become a stepping stone to phishing, privilege misuse or unauthorized action inside the app, especially when the screen performs a high-value workflow such as payment, account management or admin functions.

Restricting exposure and protecting sensitive screens

The safest Android activity is one that is intentionally reachable and narrowly scoped. Export only the components that must be callable from outside the app, and keep internal screens private unless there is a clear interoperability reason to expose them. Sensitive activities should require explicit validation before they reveal content or perform action.

Developers should also treat navigation input as untrusted. Validate intent extras, confirm the caller when that is part of the trust model, and avoid assuming that a screen was reached through the app’s normal UI. If an activity displays secrets, personal data or privileged functions, add compensating controls such as re-authentication, screen redaction, or blocking insecure transitions.

Secure activity design is ultimately about preserving the app’s own trust boundaries. When those boundaries are clear, the Android framework remains a routing mechanism rather than an attack surface.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP ASVS V4 — API and Web Service Activity intent handling and exposed entry points mirror interface trust and input control concerns.
Recommendation — Validate all activity inputs and entry conditions before dispatching sensitive app logic.
NIST SP 800-53 Rev 5 AC-6 — Least Privilege Restricted activity exposure and narrow launch paths implement least-privilege access to app components.
Recommendation — Limit which activities are exported and grant only the minimum component access required.
CIS Controls v8 CIS-4 — Secure Configuration of Enterprise Assets and Software Activity export settings, lifecycle handling and launch restrictions are secure configuration decisions in mobile software.
Recommendation — Harden mobile app component configuration so only intended activities are reachable.