Security Independently confirmed 2 publishers 2 min read Published Sep 18, 2026, 2:18 AM PDT Updated Oct 4, 2026, 10:38 AM PDT

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

Send a correction

Illustration accompanying Android apps can now gate tap-to-pay on whether a specific NFC fix is installed — Generated illustration

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.

Why it matters

What's now possible 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.
Who has to decide 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.
What it limits 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.
Who's exposed 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.

Next story · Product · 2d ago

Google's opt-in Messages setting has Gemini judge what unknown senders want

Confirmed6 publishers

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]^[15]. ASPL minus DSPL is the install delay: the update is available and the device is still running the old code ^[2]^[4]^[15].

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 ^[12]. 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 ^[13]. Google said it is working with device manufacturers to bring their OTA update clients onto the standardized system, and did not give a timetable ^[14].

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.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence62
Adoption30
Hype gap+15
Incentives: Not scored
Confidence60

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
Google released the stable AndroidX Security State v1.1.0 and Security State Provider v1.0.0 libraries, which let developers check the security status of individual device components and determine whether security updates are ready to download and install on a specific device.
Reported SupportedView cited source
[2]
The Device Security Patch Level (DSPL) shows what is currently installed and running on the device.
Reported SupportedView cited source
[3]
The Published Security Patch Level (PSPL) shows the latest patches officially published in the Android Security Bulletin.
Reported SupportedView cited source
[4]
The Available Security Patch Level (ASPL) shows what is available for that particular device to download and install.
Reported SupportedView cited source
[5]
Google engineers said: "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."
Reported Supported Source: Google engineers, quoted by Help Net SecurityView cited source
[6]
The checks cover the core Android operating system, system modules updated through Google Play system updates, and the Linux kernel.
Reported SupportedView cited source
[7]
Kernel security levels use version numbers, such as 5.15.159 or 6.1.91, instead of monthly security patch dates.
Reported SupportedView cited source
[8]
The libraries integrate with the Open Source Vulnerabilities (OSV) database to obtain Android Security Bulletin data and can download device-specific vulnerability reports for CVE-level auditing.
Reported SupportedView cited source
[9]
Google said developers can check whether specific CVEs have been patched, and that this could be used to verify that critical NFC or Bluetooth fixes are installed before enabling features such as tap-to-pay or proximity-based data sharing.
Reported SupportedView cited source
[10]
Banking or enterprise apps could check installed patches and available updates before allowing high-value payments or credential enrollment.
Reported SupportedView cited source
[11]
For phone manufacturers and developers who build OTA update systems, the androidx.security.state.provider library provides a standard way to let apps know when an update is available for a device.
Reported SupportedView cited source
[12]
Android 17 allows manufacturers to declare individual security fixes applied beyond a device's stated security patch level, including fixes backported to older software.
Reported SupportedView cited source
[13]
Google Play system updates already provide ASPL information on Android devices with Google Mobile Services, and Google Over-The-Air (GOTA) has adopted the framework.
Reported SupportedView cited source
[14]
Google said it is working with device manufacturers to bring their OTA update clients to the standardized system.
Reported SupportedView cited source
[15]
The three reported levels define two measurable gaps on one device: PSPL minus ASPL, the fixes published but not offered to that device, and ASPL minus DSPL, the fixes offered but not installed.
Derived Supported

Sources

2 independent publishers whose own reporting we read for this story.

helpnetsecurity.com
1 article · September 18, 2026
Android apps can now check security patches down to individual device components
infoq.com
1 article · October 4, 2026
Google's Android Security State Libraries Enable Component-Level Security Verification

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

InfoQ's account has the developer-facing detail. It names the calls: areCvesPatched(), isDeviceFullyUpdated(), queryAllAvailableUpdates(), fetchAvailableSecurityPatchLevel() and createVulnerabilityReportUrl(). Help Net Security adds the stable versions, Security State 1.1.0 and Provider 1.0.0. It also notes that kernel levels arrive as version strings such as 6.1.91, so any kernel comparison has to parse versions instead of dates. The Available level is only as complete as the update client reporting it.

Operator

For fleet and MDM teams, the useful output is the distance between what a device runs and what it could run. InfoQ says the Device level is read locally with no network call. The Available level depends on the updater. Help Net Security reports that Google Play system updates already supply it on GMS devices and that Google's OTA client has adopted the framework, while manufacturers' own OTA clients are still being brought over. On handsets from makers that have not wired up the provider library, expect that answer to be partial. Android 17's backport declarations would let a device show fixes its date-based patch level hides.

Investor

There is little here for investors. Both reports describe a free Google developer library, and neither gives pricing, revenue or usage figures. The commercial effect is indirect. Banking and enterprise apps get a standard way to refuse sensitive actions on unpatched phones, and OEMs are asked to report update availability through an interface Google defines.