An activity alias is an Android manifest entry that points to an existing activity and gives it an alternate name or launchable entry point. It can present a different icon, label, or intent filter while still resolving to the underlying activity, which affects how an app is launched and exposed.
What an activity alias does
An activity alias is an Android manifest component that creates an alternate entry point for an existing activity. The app still launches the same underlying code, but the alias can present a different launch name, icon, or intent filter.
That makes the alias a routing and presentation layer, not a separate screen implementation. In practice, it changes how users, launchers, and other apps discover and invoke the activity without changing the activity’s core behavior.
How activity aliases affect app exposure
Because aliases can be exported with their own intent filters, they can widen or reshape how an app is reached. A single activity may be exposed through multiple launcher paths, deep links, or branded entry points, which is useful for product design but also increases the surface area that needs review.
The security question is not whether the code is duplicated, but whether each entry point is intentional. An alias can make a capability more visible, more easily invoked, or reachable from a context the original activity was not designed to handle.
Why activity aliases are used
Developers use aliases to support alternative app icons, seasonal branding, multi-brand builds, shortcut-style launches, or compatibility needs. They are also useful when one activity must be presented in different ways to different user journeys while keeping the implementation centralized.
That reuse reduces duplication, but it also means the real control point is the underlying activity. Any permission checks, input validation, or state assumptions must hold no matter which alias was used to enter the code path.
Security implications of alias-based entry points
Activity aliases can be benign, but they can also create confusion if teams assume the alias is “just another label.” A new alias may expose a sensitive function, bypass a user expectation about where a launch came from, or create inconsistent behavior if its intent filter differs from the parent activity.
When aliases are used for externally reachable entry points, developers should treat them as part of the app’s attack surface and review them alongside the activity itself, the manifest permissions, and any links or intents that can reach it.
Risk and Threat Considerations
Alias-based launch paths can increase exposure when an activity is reachable through more than one manifest route, especially if one alias is unintentionally exported or mapped to a broader intent filter than the original activity. The main risk is not code duplication, but inconsistent access assumptions across entry points.
Failure mechanism: A malicious app, deep link, or unintended launcher path invokes the aliased activity through a route that developers did not review as carefully as the primary one, leading to unexpected access or unsafe state handling.
Impact: Users may be directed into sensitive functionality, app behavior may differ by entry path, and weaknesses in authorization or input handling can become reachable through an alternate surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Manifest-driven entry points are configuration security concerns for app exposure and routing. |
| V8 — Authorization | An alias can expose the same activity through another route, so access decisions must remain consistent. | |
| Recommendation — Review Android manifest aliases as security-relevant configuration and verify each entry point is intentional. Enforce the same authorization checks regardless of which alias or intent reaches the activity. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Alias-based intent routing can change how information or requests flow into an app component. |
| Recommendation — Constrain alternate launch paths so only approved flows can reach sensitive activities. | ||
Practitioner Guidance
Governance implication: Review every activity alias as a real entry point, not just a UI convenience. The alias should inherit the same security scrutiny as the underlying activity, including export status, intent filters, and any permission or authentication assumptions.
What to watch for: Mismatched labels, icons, or filters that make two aliases appear equivalent when they actually route to different risk profiles. When aliases are used for launch flexibility, keep the manifest and the actual behavior aligned so entry-point exposure stays deliberate.
Related resources from NHI Mgmt Group
- How should security teams monitor AI agent activity without disrupting developers?
- How can SOC teams use identity context to improve response to agent activity?
- What is the difference between activity metrics and risk metrics in IAM?
- How can organisations tell legitimate automation from compromised service account activity?