Which Android versions support which NFC features?
Reading tags and writing NDEF content have been present across many versions, so whether an ordinary tag works does not depend on the version. What happens next can: from Android 17, a tag holding a web link waits for the user on a notification. The rest of what has moved, card emulation and the finer control given to applications, affects developers rather than the tags on a wall.
The everyday capability is stable
Reading a tag and writing NDEF content to it are long standing capabilities. A deployment writing a web address to a Type 2 tag is not depending on anything recent.
That is worth stating because version anxiety is common and misplaced. Whether an Android deployment works almost never depends on the Android version.
Where a phone fails, the cause is usually the setting, the case, the antenna position or the tag, all of which are covered separately.
What has moved
Card emulation without a secure element arrived at a specific point and changed what applications could do, which matters to developers building payment or access flows.
Control given to applications over tag handling has been refined over time, including the way a foreground application claims tags.
Manufacturer behaviour around locked and sleeping devices has also shifted, which is variation rather than a version feature.
Android 16 and 17 changed what the person tapping sees. From Android 16, the NFC basics guide says a tag holding an http or https link is opened like any other link rather than handed to apps listening for tags, and a user can stop a given app being started by tags. From Android 17, the same web link first shows an open link notification and opens only when the user acts on it.
None of that changes whether a tag on a wall works when someone taps it.
The Android documentation places the milestones early: API level 9 dispatched tags only through a single action and exposed nothing but NDEF messages, API level 10 brought comprehensive reader and writer support, and API level 14 added convenience methods for building records. Everything since has refined behaviour rather than added capability.
What this means in practice
Do not specify an Android version for a tag deployment. Specify the tag type and the record type, and test a web link on Android 17 and on an earlier version, since the two do not behave alike.
Do test on an old device, because old devices differ in ways that have nothing to do with the version number: weaker fields, thicker cases, worn hardware.
Do check version requirements when an application is part of the deployment, since the application has its own minimum.
And treat a claim that a feature needs a recent Android with suspicion unless it concerns emulation, application level control or what a web link does from Android 16 and 17.
Checking a specific claim
The Android developer documentation is the authority, and its reference pages state the level at which each capability was added.
Retailer pages, forum answers and comparison articles are not authorities, and this is an area where confident wrong answers are abundant.
If a claim matters to a purchase or a deployment, trace it to the reference page for the specific capability rather than accepting a summary.
And where the answer turns out to be about an application rather than the platform, the application's own documentation is the place to look.
Frequently asked questions
Do I need a recent Android to read tags?
No. Tag reading is long standing, and an ordinary deployment does not depend on a recent version.
Which version added card emulation without a secure element?
It arrived at a specific release and is documented in the Android reference. Check the reference page rather than a summary, since this is an area where wrong answers circulate.
Will an update break my deployment?
Updates do not change what a tag holds, and it keeps reading. What can change is what follows: from Android 17 a web link waits for the user on a notification, from Android 16 an app no longer receives a web link through its tag filters, and manufacturer behaviour around locked devices can change as well.
Should I state a minimum Android version?
Only if an application is part of the deployment. For tags, state the tag type and the record type instead.