The Missing Guarantee: A Checkpoint Before the Consequences

Android’s RW dispatch problem becomes easier to judge once several different meanings of “tap” are separated. This checkpoint connects the established ideas—physical discovery, Intent routing, handler entry, visibility, and downstream effect—and turns them into a practical test. The result is a way to evaluate an NFC claim without treating a successful Activity launch as proof of either a physical event or a completed exploit.

One apparent event contains several different claims

The first claim is about discovery. Did the NFC controller and Android’s NFC stack observe a tag interaction? In the ordinary path, that is the event that begins the chain. It belongs to the hardware and system-discovery boundary. It is a statement about what happened in the physical environment immediately before Android prepared an application delivery.

The second claim is about routing. Which Activity did Android select, and why? The resolver answers this by applying action, category, data, and technology predicates, then considering the ordinary rules for starting the selected component. Routing is a decision about destination. It can be correct even if the request’s origin is not what the application assumes.

The third claim is about handler entry. Did the target Activity actually receive the request and begin executing? This is more than a filter match, but it is still not the same as discovery. A handler can be reached because a request satisfied the route and the component-start checks. The fact that the Activity opened tells us that the software transition occurred; it does not, by itself, tell us which permitted source caused that transition.

The fourth claim is about visibility. Did the Activity become the top-resumed or foreground-visible screen? A visible transition matters to user experience and can make an unexpected event easier to notice. But visibility is not a reliable proxy for execution. A handler may perform logic, parse input, or invoke another operation without remaining the top-visible Activity. Conversely, a visible screen may appear and then stop without producing a meaningful state change.

The fifth claim is about business effect. Did the application change a configuration, begin pairing, contact a service, or complete a transaction? This is the claim with the most obvious practical stakes, but it is also the most application-specific. It depends on the handler’s code, the data it accepts, later user decisions, server-side authorization, device state, and sometimes an additional physical or network condition.

These claims form a chain, but they are not interchangeable links. A physical discovery normally leads to routing. Routing normally leads to handler entry. Handler entry may lead to visible UI or background logic. Application logic may lead to a durable state change or a completed operation. A weakness at one boundary can make a later assumption unsafe, while a later gate can still stop the final effect.