Introducing the AndroidX Security State Libraries: A Unified View of Device Security
Google’s Android team—represented by Maunik Shah, Alec Garcia and Joseph Yong—has shipped the stable AndroidX Security State library (v1.1.0) together with a companion provider library (v1.0.0). The APIs expose three distinct patch‑level metrics for each core component (system, system modules, kernel): Device SPL (the currently installed level), Published SPL (the latest level listed in the Android Security Bulletin) and Available SPL (the update ready to be installed). By querying these values locally or via IPC with on‑device OTA clients, developers can programmatically decide whether to allow high‑risk actions, prompt users to install pending updates, or verify that specific CVEs have been remediated. The provider library also standardizes how OEM OTA clients report update availability, breaking the historic silo that kept such data hidden from third‑party apps.
This move reflects Android’s shift away from a monolithic “Security Patch Level” string toward granular, module‑by‑module security reporting. Since the introduction of Project Mainline and Google Play system updates, components are patched on independent schedules, making a single calendar date an unreliable indicator of true security posture. By aligning with the Open Source Vulnerabilities (OSV) database and the new Android 17 supplemental‑patches XML, Google gives enterprises the same fine‑grained telemetry that iOS offers through its DeviceCheck and Apple Security Frameworks, while also catering to the growing MDM market that needs real‑time compliance data across heterogeneous device fleets.
The libraries open a path for apps to enforce contextual security policies without outright blocking users whose devices are merely a patch behind. However, the benefits hinge on OEMs adopting the provider interface; without widespread OTA client integration, the Available SPL metric will remain limited to Google Play updates. Privacy‑focused developers must also consider the implications of exposing detailed vulnerability status to apps. Watch for Android 17’s supplemental‑patches XML rollout, OEM onboarding progress, and whether third‑party security platforms begin to incorporate these APIs into their compliance dashboards.
Key Takeaways
AndroidX Security State now lets apps read DSPL, PSPL and ASPL for system, modules and kernel, enabling component‑level security checks.
The provider library creates a unified IPC channel for OEM OTA clients to expose pending updates to any app.
Integration with OSV and supplemental‑patches XML lets developers verify specific CVE fixes rather than relying on calendar dates.
Adoption by OEMs will determine how broadly the Available SPL signal can replace the legacy monolithic SPL metric.
About the Source
This analysis is based on reporting by Android Developers. Here is a short excerpt for context:
Posted by Maunik Shah, Staff Software Engineer, Alec Garcia, Software Engineer, and Joseph Yong, Technical Program Manager At Android, we are constantly working to provide developers and enterprise partners with the data they need to keep devices protected. Today, we're thrilled to announce the stable release of the AndroidX Security State version 1.1.0 and Security State Provider version 1.0.0 libraries which provides a centralized mechanism designed to bring further transparency to the comprehensive security posture and pending updates across the Android ecosystem. Whether you develop security-critical, consumer-facing apps (such as banking, fintech, or healthcare) or Mobile Device Management (MDM) solutions, these libraries enable you to programmatically verify the security state of the device per component. Rather than relying on a coarse, monolithic Security Patch Level (SPL), you can evaluate true component-level protection and whether remediations are actively pending via the androidx.security.state library. For OEMs and Over-The-Air (OTA) client developers, the companion androidx.security.state.provider library allows you to expose update availability via standardized mechanisms. Understanding Security Patch Levels (SPL) Device SPL (DSPL): The security patch level currently installed and running on the device for specific system components, queried from device properties and configs without network calls. Published SPL (PSPL): The latest patch level officially published in the Android Security Bulletin for those components. Available SPL (ASPL): The patch level ready to be downloaded and installed on the specific device, queried asynchronously via inter-process communication (IPC) with on-device update clients. System: The core Android operating system, updated via standard/OEM system OTA updates. System modules: Modular OS subsystems updated seamlessly in the background via Google Play system updates (Project Mainline). Kernel: The foundational layer connecting the device's hardware and software, evaluated via Long-Term Support (LTS) release versions (such as 5.15.159 or 6.1.91) rather than monthly calendar dates. By surfacing these three distinct patch levels at the component level, developers and enterprises can now understand exactly how secure a device is, identify missing patches, and take proactive remediation steps. One way of doing so can be seen in the example below. Rather than taking an all-or-nothing approach to device access, developers and enterprises can combine DSPL, PSPL, and ASPL to make smart, contextual security decisions. For example, a banking or enterprise app can compare a device's current security patch (DSPL) against pending updates (ASPL) before initiating sensitive workflows like high-value payments or credential enrollment. If an update is waiting to be installed, developers and enterprises can require the user to update their device first. For even finer control, developers and enterprises can query whether specific high-risk vulnerabilities (CVEs) have been patched on the device, such as verifying that critical NFC or Bluetooth fixes are in place before authorizing tap-to-pay or proximity data sharing. High-level flow For app developers and enterprise management androidx.security.state library to make informed, context-aware decisions: Synchronous Posture Checks (DSPL): Apps can immediately inspect the installed patch levels of the system, system modules, and kernel on app launch and compare with PSPL to verify whether the device meets an organization's required security baseline before unlocking sensitive corporate resources or biometric access. Pending Update Prompting (ASPL): Instead of immediately blocking an employee whose device is slightly behind on patches, enterprise apps can query ASPL to check if a pending system update or Google Play system update is staged and ready to install. If so, apps can display tailored in-app guidance directing the user to System Settings to complete the installation. Vulnerability-Level Auditing (CVEs): For high-assurance use cases, the library provides ability to download device-specific vulnerability reports from Open Source Vulnerabilities (OSV) to programmatically audit whether specific, critical CVEs have been resolved on the device. androidx.security.state.provider library establishes a standardized, Android IPC mechanism for update clients to report update availability directly on the device. Historically, even if proprietary OTA clients surfaced update availability, this information was siloed and not queryable by third-party applications. Going forward, apps can access ASPL details through a single, unified API, regardless of whether the update is delivered via an OEM’s dedicated OTA client or Google Play, as long as it is provided by the update client. Google Play system updates already expose ASPL across GMS Android devices. Google Over-The-Air (GOTA) has also been onboarded and we are working with OEMs worldwide to onboard their OTA clients to this standardized framework. Incorporating bulletin-level data OSV) database to obtain Android Security Bulletin data, the libraries can look deeper than ever before. Instead of just asking if a specific threat, such as a CVE entry, is blocked, this data also allows the libraries to provide the “effective” and granular security state of the device. Here are two ways this approach benefits enterprises and Android OEMs: Sometimes, a monthly security update does not contain any new threats for a specific component. In this case, the libraries automatically increments the security level for that component to reflect its "effective" security state. This ensures that a device is accurately credited for being fully protected against all known security threats. A new feature introduced in Android 17 allows OEMs to declare specific security fixes that have been applied above the SPL via a Supplemental Patches XML file. This feature allows OEMs who backport specific security fixes to immediately prove device compliance without having to wait for a full monolithic SPL bump, ensuring continuous patching efforts are properly credited. The Security State libraries surface this granular information to apps and services, ensuring that continuous patching efforts are recognized the moment they are implemented. Get started App Developers & MDMs: To start protecting your users and evaluating real-time patch posture, explore the official Understand device security state guide. OEMs and Update Clients: Onboard your update clients to expose ASPL using the AndroidX Security State Provider library. Claim immediate credit for backported patches by publishing Supplemental Patches XMLs. Release Notes: Check out the official AndroidX Release Notes for Security-State and Security-State-Provider libraries for complete changelogs and API signatures. We value your feedback! Please try out the libraries and let us know your thoughts or report any issues on the public Android Issue Tracker.Read the original at Android Developers
