AndroidX Security State Tracks Patches by Component

One Patch Date Was Never Telling You the Truth

If you have ever written a security check against a phone, you have used the Security Patch Level — a single date string the device reports, which you compare against the latest Android bulletin. It is a blunt instrument, and it has been getting blunter for years. Google shipped the fix on September 17 with stable releases of AndroidX Security State 1.1.0 and Security State Provider 1.0.0, which let an app ask about patch status component by component.

• The problem: Google's own engineers say relying on a single SPL build property is no longer the best way to determine a device's true security posture
• Three values per component: Device SPL (installed), Published SPL (latest in the bulletin) and Available SPL (downloadable now)
• Components covered: the system OS, Play system modules delivered through Project Mainline, and the Linux kernel
• Artifacts: androidx.security.state for client apps, androidx.security.state.provider for OEMs and update clients

Why a Single Patch Date Stopped Working

Android stopped shipping as one monolith some years ago. Project Mainline pushed large chunks of the platform — media codecs, network stacks, the runtime — into modules updated through Google Play, independently of whatever the manufacturer does with the system image. The kernel moves on its own schedule again, tracking Long-Term Support releases.

So a device can report a stale system SPL while running fully patched Mainline modules, or the reverse. A banking app that refuses access below a certain SPL date is either locking out users who are actually fine or admitting users who are actually not. Both failure modes are common and neither is visible.

The three-value model fixes the ambiguity by separating questions that were previously mashed together. Device SPL answers what is installed, and is read from device properties with no network call. Published SPL answers what the bulletin says should be installed. Available SPL answers whether an update is sitting there waiting — which is the difference between a device that cannot be patched and a user who has not tapped install.

How Does the Kernel Check Work?

This is the detail worth noticing. Kernel patch status is evaluated against LTS release versions such as 5.15.159 or 6.1.91 rather than a monthly calendar date. Anyone who has tried to map a kernel's backported fixes onto an Android bulletin month knows why that matters: the calendar date was always a proxy, and a bad one. Comparing against the LTS point release is how kernel security is actually tracked everywhere else.

The libraries also pull Android Security Bulletin data from the Open Source Vulnerabilities database, which means an app can ask whether a specific CVE is addressed on this device rather than inferring it from a date. And Android 17 adds a mechanism for manufacturers to declare supplemental security fixes through XML files, so vendor patches outside the standard bulletin cadence become visible too.

Who Should Actually Use This?

Three groups, and it is worth being precise, because the wrong use of this API is a device-discrimination engine.

Security-critical apps — banking, fintech, healthcare — get to make graduated access decisions instead of binary ones. Mobile device management platforms get a defensible fleet-wide posture view rather than a spreadsheet of SPL dates. OEM and OTA update clients get a standard way to publish what they have available.

The responsible pattern is nudging rather than blocking: if Available SPL is ahead of Device SPL, there is an update waiting and the user can act on it, which is a far better prompt than a refusal. Blocking on Published SPL punishes people for their manufacturer's release schedule, which they cannot control.

It is a good companion to the ecosystem hardening we covered in Android's encrypted passkey transfer, and it fits the same pattern as the automated review work behind AI security reviews for WordPress plugin updates — making a security property measurable so it can be acted on. More defensive tooling in our AI security coverage.

Sources: Android Developers Blog — September 17, 2026; Help Net Security — September 18, 2026.