How Wide Is the Exposure?
The Android RW finding matters beyond the four applications used as case studies, but its scale has to be measured carefully. This chapter explains how the paper moves from manifest-declared handlers to on-device delivery, interprets the reported app and handler counts with their denominators, and separates confirmed reachability from visibility and downstream harm. The goal is to understand what the numbers establish without turning a candidate count into a universal exploit count.
From an app declaring NFC to a confirmed delivery
The study begins with a Google-Play-scoped dataset assembled from AndroZoo metadata. It retains popular Android packages with at least one million downloads and keeps the latest release for each package. The resulting population contains 76,333 apps. That is a large ecosystem snapshot, but it is not “all Android apps,” nor is it a timeless description of the platform. It reflects what was available, retrievable, and parseable in the study’s selected snapshot.
The paper uses a sequence of definitions because “affected app” can mean several different things. An RW app is one that declares at least one Activity handler for an NFC Reader/Writer discovery action in its manifest. This is a presence measure. It says that the package has told Android it can receive a class of RW dispatches. It does not say that the handler is exposed to other apps, that it can be started on a given device, or that the app treats entry as a sensitive event.
A handler becomes potentially vulnerable under the paper’s manifest criterion when it is externally startable under ordinary Android component rules. In practical terms, the Activity is exported and does not require a caller permission that the test sender lacks. This is an exposure measure. It identifies a route that a local third-party app may be able to exercise, but it does not yet prove that a particular installed build will accept delivery at runtime.
The strongest reachability measure in the study is PoC-confirmed triggerability. The researchers attempted to start potentially exposed handlers on a real device using a TDFA proof of concept and treated delivery as successful when instrumentation confirmed that the target component received the request. This is a delivery measure. It is stronger than finding a matching manifest entry and narrower than claiming that the application performed a harmful operation.
The pipeline therefore has three conceptual stages:
- Presence: does the app declare an RW handler?
- Manifest exposure: can ordinary cross-app component rules potentially admit a third-party caller?
- On-device delivery: does a test invocation reach the handler without physical NFC at trigger time?
A fourth observation records whether the Activity becomes top-visible. That information is useful for understanding user notice and interface behavior, but the paper does not make it the primary success condition. A handler can execute logic without becoming the top-resumed Activity, so visibility is not a reliable substitute for delivery.