Security1 publisher2 min readPublished
Android apps can now gate tap-to-pay on whether a specific NFC fix is installed
The stable AndroidX Security State libraries report patch state for the core OS, Play system modules and the Linux kernel separately, and let an app ask whether a named CVE is fixed before it turns a feature on.
The Watch · Security desk
What happened
- Google has published stable AndroidX Security State v1.1.0 and Security State Provider v1.0.0, letting apps read patch status for individual device components instead of one build property.
- Bulletin data comes from the Open Source Vulnerabilities database, and the libraries can pull device-specific vulnerability reports so an app can audit whether one named CVE is fixed.
- Android 17 lets manufacturers record individual fixes applied beyond a device's stated security patch level, including patches backported into older software.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- capability An app can now condition one function on one fix: enable tap-to-pay only where the NFC patch is present. It no longer has to accept or refuse an entire monthly patch date.
- decision App and fleet owners have to write the policy themselves, deciding what patch state is good enough for a high-value payment or a credential enrollment, and owning the users they lock out.
- constraint Visibility ends where a manufacturer's OTA client has not adopted the standard, so the ASPL half of the picture is uneven until those clients are converted.
- exposure The install gap becomes attributable per device: a phone that has had an update waiting for weeks is now identifiable as such by any app that asks.
PSPL minus ASPL is the manufacturer's delay: Google has published the fix in the Android Security Bulletin and nothing is on offer to that handset [3][4][1]. ASPL minus DSPL is the install delay: the update is available and the device is still running the old code [2][4][1].
Google engineers said that "as Android has evolved to deliver rapid, independent component updates through modular systems like Google Play system updates, relying on a single SPL build property is no longer the best way to determine a device's true security posture" [5]. The checks cover the core operating system, the system modules that Google Play system updates replace, and the Linux kernel [6]. Kernel state comes back as a version number, 5.15.159 or 6.1.91, so a kernel check compares versions instead of monthly dates [7].
The libraries also answer per-CVE questions. They pull Android Security Bulletin data from the Open Source Vulnerabilities database and can download a device-specific vulnerability report for CVE-level auditing [8]. Google's example is verifying that critical NFC or Bluetooth fixes are installed before an app enables tap-to-pay or proximity-based data sharing [9]. Banking and enterprise apps can run a patch and update check before allowing a high-value payment or a credential enrollment [10].
Android 17 adds the other half of the record. A manufacturer can declare individual fixes applied beyond the device's stated security patch level, including fixes backported to older software [11]. A handset on an old SPL date may already carry the fix an app cares about, and an app reading only the SPL date could not see it.
The libraries measure the exposure window and do not shorten it. A fleet owner learns which devices to retire and which functions to withhold, and the OTA pipeline still has to deliver the update. Attacker capability against an unpatched kernel is the same today as it was last week.
Reporting depends on who supplies the data. Google Play system updates already provide ASPL on devices with Google Mobile Services, and Google's own GOTA client has adopted the framework [12]. Google said it is working with device manufacturers to bring their OTA update clients onto the standardized system, and did not give a timetable [13].
What to watch
- Whether OEM OTA update clients outside Google's own GOTA begin publishing ASPL, and on which device lines.
- Whether banking and MDM vendors ship gating rules built on DSPL and per-CVE checks, and what they do to users on devices that fail them.
- Whether the Android 17 record of manufacturer-declared fixes and backports gets populated in practice or stays empty.