TapTrap: Animation-Driven Tapjacking on Android

We assume that a malicious app is installed on the user’s device, for example, via an app market. The app does not require any permissions, making it appear harmless and unintrusive to the user. Notably, we do not assume the SYSTEM_ALERT_WINDOW permission, which prior work often relied on. However, we assume that animations are enabled on the device. By default, animations are enabled unless explicitly disabled through developer options or accessibility settings.

A TapTrap attack consists of the following steps:

1. Launch a Target Activity

The attack begins when a malicious app launches a new activity using startActivity() or a related method. This new activity (let’s call it Activity B) can be part of another app or a system component (e.g., a permission dialog). The malicious app (with Activity A) specifies a custom animation using overridePendingTransition() or ActivityOptions.makeCustomAnimation() that controls how this transition appears to the user. Note that custom transitions can only be applied to activity transition that happen within the same task. If the target activity is in a different task, Android will use a system-defined slide animation instead and TapTrap will not work.

2. Crafting the Animation

The key to TapTrap is using an animation that renders the target activity nearly invisible. This can be achieved by defining a custom animation with both the starting and ending opacity (alpha) set to a low value, such as 0.01. Optionally, a scale animation can be applied to zoom into a specific UI element (e.g., a permission button), making it occupy the full screen and increasing the chance the user will tap it.

3. Tricking the User

While Activity A remains visible, Android places Activity B on top of the activity stack. Despite being transparent, Activity B receives all touch events, not Activity A. The malicious app places decoy UI elements (like a “Next” button) that align precisely with real interactive elements (like an “Allow” or “Activate” button) in Activity B. When the user taps what they think is a harmless button, they are actually interacting with the sensitive UI of Activity B.

4. Re-launching the Malicious Activity

Before the animation completes and Activity B becomes fully visible, the malicious app quickly relaunches itself (Activity A) to regain visibility and push B to the background. This prevents the user from seeing that anything abnormal occurred.

We analyzed 99,705 Android apps from the Play Store to understand how many are vulnerable to TapTrap. For an app to be vulnerable, it must include a screen (called an "activity") that:

• can be launched by another app,
• runs in the same task as the calling app,
• does not override the transition animation, and
• does not wait for the animation to finish before reacting to user input.

Our analysis found that 76.3% of all apps met these conditions and are therefore vulnerable to TapTrap. These findings show that TapTrap is not just a theoretical attack, but is a threat to the whole Android ecosytem.

We provide the analysis pipeline and its results in our GitHub repository.

We developed an automated analysis pipeline to investigate whether TapTrap is actively exploited in Android apps. Using a dataset of 99,705 Play Store apps, we extracted all animations that an app can use for TapTrap from these apps and then ran the animations in a controlled environment via Robolectric, which allowed us to analyze their behavior over time. We assigned each animation an opacity and a scale score ranging from 0 to 100 to identify those with characteristics exploitable by TapTrap, where 0 means it's unlikely that it can be exploited for TapTrap and 100 means it is very likely to be exploitable.

The following figure illustrates the analysis pipeline:

Our analysis revealed 28 apps with a score of at least 50, but manual inspection confirmed none of them used these animations maliciously. We also discovered an off-by-one bug in Android’s animation system, allowing animations to run up to 6 seconds instead of the intended 3, effectively doubling the TapTrap attack window.

We provide the analysis pipeline and its results in our GitHub repository.

We conducted a user study with 20 participants to evaluate whether users can detect TapTrap during typical app interactions. Participants played KillTheBugs, a game we developed that embedded three TapTrap attack scenarios, each targeting a different permission: location, camera, and device admin. They played the game twice, once without any prior knowledge of the attack, and again after informing participants that an attack might occur.

After the first game session, two participants noticed minor glitches, such as a quick flash on the screen, and one mentioned needing to tap twice on a bug. Four participants noticed a camera icon appearing during camera access.

In the second round, after being informed about a possible attack, 14 participants noticed the camera indicator. However, the location-based attack remained undetected by all participants, and only three noticed anomalies after silently granting device admin permissions.

These results show that without visible security indicators, users are unlikely to detect TapTrap. Even when indicators are present, they are often missed: in the camera-based attack, only four participants noticed the camera icon. While detection improved in the second round for the camera-based attack, attacks that don’t trigger any visible indicator went largely unnoticed.

The following video shows the full user study app that participants played. We provide all materials used in the user study, such as the questionnaires and the information sheet in our GitHub repository.