What is Android's tag dispatch system?
The part of Android that decides which application receives a tag. It analyses what was read and tries three levels in a fixed order, from a match on the actual content down to a last resort that simply announces a tag was found. From Android 16, a tag holding a web link is opened like any other link instead, and from Android 17 the last resort is deprecated.
Three levels, in order
The Android documentation describes the system as analysing a discovered tag, categorising the data, and starting an application interested in it.
The first level applies when the tag holds NDEF content the system can map to a type. Applications registered for that type are the candidates.
Web links are the exception from Android 16. The NFC basics guide says a tag holding an http or https link then triggers the ordinary request to open a link, which the browser or an app verified for the address answers, and from Android 17 only once the user has acted on an open link notification.
The second applies when the content cannot be mapped that way. The tag's technologies are used instead, so applications registered for a technology are the candidates.
The third is the fallback, started when nothing handled either of the first two. It carries the tag and no interpretation, and the documentation deprecates it from Android 17.
Why the order matters
Specificity wins. An application registered for the exact content beats one registered for the technology, which beats the general case.
So a tag that opens the wrong thing is usually a tag whose content matched something more specific than you expected, rather than a system behaving unpredictably.
It also explains why the same tag behaves differently on two phones. The tag is identical and the set of installed candidates is not.
And it explains the chooser: two applications at the same level, both eligible, and no basis for the system to prefer one.
Naming an application from the tag
A tag can carry a record naming an Android application, which expresses a preference for that application rather than leaving the choice open.
The documentation notes that this can be overridden by the foreground dispatch system, so a naming record is a strong hint rather than an instruction.
It also costs bytes and does nothing on other platforms, so it is worth adding only where the application is genuinely the point of the tag.
For a public deployment, a web address is more predictable. It works on every phone whether or not anything is installed.
What a deployment should take from this
Write content whose handling you can predict, which in practice means a web address.
Test on a device that resembles your audience rather than on yours, since the candidate list is what differs between them.
Expect a chooser on some phones and design so that it is not a disaster: a clear destination that makes sense whichever browser opens it.
And do not rely on a specific application opening unless you control the phones, because you control the tag and not what is installed on the other side.
Frequently asked questions
Can I force one app to receive my tag?
Only where you control the device. A record naming an application expresses a preference, and a foreground application can override it. From Android 16, the user can also stop an app receiving tags altogether.
Why does a chooser appear?
Two or more installed applications are eligible at the same level, so the system asks rather than guessing.
What happens with a non NDEF tag?
The technology level applies instead of the content level, so applications registered for that technology are the candidates.
Does iOS work the same way?
No. iOS acts on a narrower set of record types and inserts a confirmation step in the background path, so the same tag behaves differently.