android:launchMode="singleInstance" is an Android activity launch mode that places an activity in its own task and allows only that one activity in the task. Subsequent launches reuse the existing instance, which changes back stack behaviour and can be used to isolate or route specific app flows.
How singleInstance launch mode changes activity behaviour
SingleInstance places one activity in its own task, so the same activity is not duplicated into multiple instances. That changes how Android resolves back stack state, task switching, and return paths after a launch intent arrives.
The practical effect is that navigation becomes highly controlled: the activity can behave like a dedicated entry point, launcher, or redirect surface rather than a normal screen in a shared task flow. That makes the mode useful when one screen must stay isolated from other app paths or when repeated launches should converge on the same running instance.
Why app flows use a dedicated task
A separate task can reduce ambiguity about where the user lands and what happens when the activity is invoked again. Instead of creating parallel copies of the same screen, Android routes the launch to the existing instance, which preserves the task identity and avoids stack duplication.
This is different from ordinary activity launching, where each start can add another instance to the back stack. With singleInstance, the routing decision becomes part of the app’s navigation architecture, not just a screen-level implementation detail.
Behaviour on relaunch, back navigation, and task reuse
When the activity already exists, Android brings that instance forward rather than creating a new one. The surrounding task and back stack therefore determine whether the user returns to an earlier state, resumes a prior flow, or sees a refreshed intent delivered to the same activity.
That reuse has two implications. First, developers need to think about idempotent entry handling, because a relaunch may arrive while the activity is already alive. Second, back navigation behaves differently from multi-instance screens, because the activity sits alone in its task and may not have the same surrounding stack context that a normal flow expects.
In practice, this launch mode is best understood as a routing constraint. It is not simply a performance option or a cosmetic setting; it changes how Android models ownership of that activity within the broader application experience.
When singleInstance is the right fit
SingleInstance is most useful when one activity must remain logically distinct from the rest of the app, such as a specialized launcher surface, a handoff screen, or a flow that should never be embedded alongside other app activities. It can also simplify state handling when repeated launches should always converge on one active screen.
It is less suitable for ordinary in-app navigation, where users expect natural back stack behaviour and multiple entry points to coexist. Used too broadly, it can make task switching feel unusual and can complicate assumptions about how users return to previous screens. In Android, launch mode choices are part of the app’s security and usability posture because they shape how much control the app has over navigation, state retention, and rerouting.
Risk and Threat Considerations
SingleInstance can create navigation safety and trust issues if an app assumes the activity will behave like a normal screen. Because relaunches reuse the same instance and task, stale state, unexpected intent handling, or overly broad task exposure can lead to confusion about what screen is active and what action the user is actually performing.
Failure mechanism: The app reuses an existing activity instance without fully validating the incoming intent or resetting sensitive UI state, so a later launch lands on an unexpected context or preserves assumptions from an earlier flow.
Impact: Users may see the wrong screen state, flow transitions may bypass intended checks, and sensitive actions can be exposed to misrouting or unintended reuse of prior task context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | SingleInstance changes how app flows are routed and isolated. |
| IA-2 — Identification and Authentication (Organizational Users) | Relaunched activities may front sensitive user actions that depend on authenticated state. | |
| Recommendation — Enforce AC-4 to constrain how sensitive activity flows are reached and reused. Apply IA-2 to confirm users are authenticated before sensitive activity reuse. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Dedicated task routing affects who can reach privileged or sensitive app functions. |
| Recommendation — Use CIS-6 to restrict access paths into sensitive screens and tasks. | ||
| OWASP ASVS | V7 — Session Management | Single-instance reuse can preserve or revive application state across launches. |
| V8 — Authorization | Repeated launches must not bypass authorization checks when the same instance is reused. | |
| Recommendation — Apply V7 to ensure reused activity state does not expose stale or unsafe session context. Apply V8 so reused activities re-check authorization before sensitive actions. | ||
Practitioner Guidance
What to watch for: Treat singleInstance as an architectural exception, not a default. It should be reserved for activities that truly need exclusive task placement and predictable reuse semantics, because the mode changes how lifecycle callbacks, intent delivery, and back navigation must be handled.
Governance implication: Review every use of this mode against the app’s intended user journey, especially where the activity can receive external intents or handle sensitive transitions. The key question is whether the routing behaviour is deliberate and documented, not merely whether the screen appears to work in testing.
Related resources from NHI Mgmt Group
- How should security teams detect Android malware that abuses cloud services for exfiltration?
- How can mobile threat teams reduce the blast radius of Android RAT activity?
- How should security teams respond when Android apps request Accessibility permissions?
- Why do Android WebView UXSS bugs become account takeover risks so quickly?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org