Android groups an app's screens into a task, the stack of activities you move through and see in the recents view. That task system can be abused: a malicious app can arrange for its own screen to appear inside or in place of your app's task, so when the user thinks they are looking at your login screen, they are actually looking at the attacker's. This is task hijacking, and the StrandHogg vulnerabilities made it well known. It is largely a manifest-configuration issue, which means it is both easy to introduce by leaving defaults and straightforward to defend against. Here is how task hijacking works and how to protect your app.
Short answer
Task hijacking is an Android attack where a malicious app manipulates the task and activity system, historically through taskAffinity and task reparenting, the StrandHogg vulnerabilities, so that its own activity is displayed in place of or inserted into a victim app's task. Per security research on StrandHogg, this lets the attacker show a phishing screen the user believes belongs to the legitimate app, or intercept its flow. The defense is configuration: set taskAffinity to an empty string so your activities are not grouped into another app's task, choose an appropriate launchMode for your launcher activity, and keep your target API level current, since newer Android versions have hardened against these techniques. Review your manifest's task-related settings rather than leaving defaults.
What you should know
- Android groups screens into tasks: the activity stack shown in recents.
- Task hijacking abuses that system: inserting or substituting an attacker activity.
- StrandHogg made it known: exploiting
taskAffinityand task reparenting. - The impact is phishing or interception: a fake screen the user trusts.
- The defense is manifest configuration:
taskAffinity,launchMode, target API.
What is task hijacking?
It is the abuse of Android's task management to place an attacker's activity where the user expects the victim app's. By default, an activity's taskAffinity is its package name, and Android uses affinity, along with features like task reparenting, to decide which task an activity belongs to. A malicious app can set its own taskAffinity to match a target app, so that under certain launch conditions its activity ends up in the target's task, or appears when the user opens the target. The StrandHogg vulnerabilities demonstrated this concretely: by manipulating affinity and reparenting, a malicious app could present its own screen, a fake login, for instance, while the user believed they were interacting with the legitimate app, capturing credentials or hijacking the flow. A later variant achieved similar results through Intent manipulation rather than the manifest. The common thread is that the user's trust in what is on screen is misplaced because an attacker has inserted themselves into the task.
How does the attack work?
By matching affinity and exploiting how tasks are assembled. The table outlines it.
| Step | What happens |
|---|---|
| Malicious app installed | The attacker app is on the device |
Matching taskAffinity | It sets affinity to the target app's task |
| Task reparenting or launch timing | Its activity lands in or fronts the target's task |
| User opens the target | The attacker's screen is shown instead |
| Phishing or interception | Credentials captured or the flow hijacked |
The attack depends on a malicious app already being on the device, which is the precondition, and on the target app, or the platform version, allowing affinity-based task manipulation. When those line up, the attacker's activity can be displayed when the user launches the legitimate app, and because it sits in what looks like the right task, the user has no obvious cue that the screen is not genuine, which is what makes it effective for phishing. The defense is to deny the affinity match and the reparenting that the attack relies on.
How do you defend against it?
Configure your manifest so your activities cannot be grouped into another app's task, and stay current. The most direct step is to set taskAffinity to an empty string, at the application or activity level, which removes the default package-name affinity that the attack matches against, so your activities are not pulled into a task by affinity. Choose an appropriate launchMode for your launcher activity, such as a mode that keeps it as the root of its own task, to reduce the room for an activity to be inserted ahead of or around it. Keep your app's target API level current, since Android has progressively hardened task and activity handling against these techniques in newer versions, so a current target benefits from those platform mitigations. Review the task-related attributes in your manifest deliberately rather than leaving them at defaults, since this is a configuration exposure that does not affect how the app works for legitimate users. The principle is to remove the affinity and reparenting behaviors the hijack relies on, and to ride the platform's own improvements by targeting a recent API level.
What to watch out for
The first trap is leaving task-related manifest settings at their defaults, where the default taskAffinity of the package name is exactly what the attack matches; set it to empty. The second is an old target API level that misses the platform hardening against task manipulation. The third is assuming task hijacking is only theoretical, when StrandHogg showed real phishing potential. This is a manifest-configuration matter, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, surfaces your manifest configuration and target API level, helping you confirm your task settings and API target are not leaving the door open.
What to take away
- Task hijacking abuses Android's task system, historically via
taskAffinityand reparenting (StrandHogg), to show an attacker's activity where the user expects the legitimate app's, enabling phishing. - The attack needs a malicious app on the device and a target or platform that allows affinity-based task manipulation, and it succeeds because the fake screen sits in a trusted-looking task.
- Defend by setting
taskAffinityto an empty string, choosing an appropriatelaunchMode, and keeping your target API level current to benefit from platform hardening. - Use a pre-submission scan such as PTKD.com to surface your manifest's task configuration and target API level, then harden them rather than leaving defaults.
