Google’s new security‑state toolkit for Android
On 17 September 2026 Google announced the stable launch of two AndroidX libraries – androidx.security.state (v1.1.0) and androidx.security.state.provider (v1.0.0). The pair is designed to replace the long‑standing “Security Patch Level” (SPL) string with a richer, component‑by‑component picture of how up‑to‑date a device really is. For anyone building banking, fintech, health‑care or Mobile Device Management (MDM) solutions, the change promises far more precise control over when an app should allow a sensitive transaction.
Why the old SPL model was losing relevance
Android’s modular update architecture – Google Play system updates, Project Mainline modules and OEM‑specific OTA streams – means that different parts of the OS can be patched on different schedules. The single SPL value, which simply reports the calendar month of the latest security bulletin applied to the whole device, no longer tells the full story. A phone might be running the latest kernel but still be waiting on a system‑module fix, or vice‑versa. Until now, third‑party apps had no standard way to discover those nuances.
Three new metrics, three clear windows into security
The Security State library introduces three distinct patch‑level concepts, each exposed through a lightweight API:
| Metric | What it shows | How it’s gathered |
|---|---|---|
| Device SPL (DSPL) | The patch level that is currently installed on the device for a given component. | Read directly from system properties – no network traffic required. |
| Published SPL (PSPL) | The most recent patch level published in the official Android Security Bulletin for that component. | Pulled from the bulletin data bundled with the library. |
| Available SPL (ASPL) | The patch level that is ready to be downloaded and installed on the device. | Obtained asynchronously via IPC with the on‑device update client (OEM OTA or Google Play). |
These metrics are available for three key areas:
- System – the core Android OS delivered through traditional OTA updates.
- System modules – Mainline components that Google can push via the Play Store.
- Kernel – the low‑level Linux kernel, identified by its LTS version (e.g., 5.15.159) rather than a month‑based label.
How developers can act on the data
1. Immediate posture checks (DSPL)
An app can query the DSPL values at launch and compare them with the PSPL baseline required by the organisation. If the device falls short, the app can block access to corporate resources, biometric login or high‑value payments until the missing patches are applied.
2. Smart prompting for pending updates (ASPL)
Instead of outright denying a user whose device is a month behind, the app can look at ASPL to see whether an update is already staged. If a pending update exists, the app can display an in‑app banner directing the user to the system settings, improving the user experience while still maintaining security.
3. CVE‑level verification
For ultra‑sensitive workflows, the library can fetch vulnerability data from the Open Source Vulnerabilities (OSV) database and confirm that specific high‑risk CVEs – for example, NFC or Bluetooth exploits – have been patched. This granular check is especially useful for contact‑less payments or health‑data exchange.
OEMs and OTA clients finally get a common language
The companion androidx.security.state.provider library gives OEMs a standard Android IPC channel to publish ASPL information. Historically, proprietary OTA clients kept update status hidden, forcing third‑party apps to guess or rely on user‑reported prompts. With the new provider, any OTA client – whether it’s Google’s own GOTA, a Samsung One UI updater, or a carrier‑branded solution – can expose the same data structure. Google Play system updates already support this, and the company is actively working with manufacturers worldwide to bring them on board.
Going beyond the month‑based SPL: supplemental patches and effective security state
Two recent Android platform features complement the libraries:
- Effective security level – If a monthly bulletin contains no new fixes for a component, the library automatically increments the component’s effective level, ensuring devices aren’t penalised for having nothing new to install.
- Supplemental Patches XML – Introduced in Android 17, this file lets OEMs declare back‑ported fixes that sit above the official SPL. Apps can see those patches instantly, meaning a device that received a critical fix outside the regular update cycle can still be recognised as compliant.
Why UK Android buyers should care
For consumers in the United Kingdom, the new libraries translate into a more transparent security story for the phones they lease or buy on contract. Mobile carriers and finance‑focused apps can now programmatically verify that a handset meets the latest security baseline before allowing services such as Apple Pay‑style Android Pay, contact‑less travel tickets or NHS health‑record access. In practice, this could mean fewer “Your device is out of date” pop‑ups and more targeted prompts that guide users to install a pending update with a single tap.
Getting started
- App developers & MDM vendors – Follow Google’s Understand device security state guide to integrate the
androidx.security.stateAPIs into your codebase. - OEMs & OTA teams – Implement the
androidx.security.state.providerlibrary, expose ASPL through the standard IPC, and publish any supplemental‑patch XML files. - Full changelogs – Detailed release notes are available on the AndroidX site for both libraries.
Google encourages feedback via the public Android Issue Tracker, so developers can report bugs or suggest enhancements as the ecosystem adopts the new model.
Bottom line
The AndroidX Security State libraries give the Android ecosystem a much‑needed upgrade from a single, coarse‑grained SPL number to a nuanced, component‑level view of security. For UK users, this means the apps they rely on for banking, travel and health can make smarter, context‑aware decisions about when a device is truly safe. For OEMs and OTA providers, the standardized IPC removes a long‑standing barrier to sharing update status with third‑party software. As the libraries roll out across more devices, we can expect a smoother balance between security compliance and user convenience in the next wave of Android contracts and upgrades.
