Keeping Android devices secure is a monumental task, especially given the diverse ecosystem. That's why Google has taken a significant step forward by launching the AndroidX Security State and Security State Provider libraries , game-changing tools that offer complete transparency into a device's actual Android security status , moving beyond the generic metrics of the past.
Whether you're developing a banking application, a healthcare platform, or managing fleets of corporate devices using MDM, these libraries allow you to programmatically check the security of each component. Instead of relying on a global patch date that sometimes doesn't tell you much, you can now know exactly what's protected and what updates are pending.
The end of the monolithic patch: Understanding the three levels of SPL
Previously, we relied on the Security Patch Level (SPL), a single property that indicated the patch date. But with the arrival of modular Google Play updates, this fell short. To solve this problem, the new libraries introduce three distinct visibility levels that provide a much more accurate picture of reality:
- Device SPL (DSPL): It refers to the patch that is installed and running on the device at that precise moment. It is accessed locally without needing to make calls to the network.
- Published SPL (PSPL): It is the most recent patch level that has been officially published in the Android Security Bulletin for those components.
- Available SPL (ASPL): Indicates the patch that is already in place ready to be downloaded and installed on that specific device, obtained through IPC communication with the upgrade clients.
This breakdown applies to three critical areas: the core operating system (updated over-the-air), system modules (managed by Project Mainline), and the Linux kernel . It's worth noting that the kernel doesn't use monthly release dates; instead, it's evaluated using Long Term Support (LTS) versions , such as 5.15.159.
Smart decision making and CVE auditing
Having so much information allows developers to move away from an "all or nothing" approach. For example, a financial app can compare the DSPL with the ASPL and, if it detects a critical update pending, prompt the user to update their phone before authorizing a large payment. This represents a shift from blind blocking to contextual security management , following best practices for using banking apps on Android securely.
But it doesn't stop at dates. The real power lies in the verification of specific vulnerabilities (CVEs) . Thanks to integration with the Open Source Vulnerabilities (OSV) database, apps can check if a specific Bluetooth or NFC flaw has been fixed. This is vital for authorizing contactless payment functions or sharing data via proximity only when the risk has been mitigated.
The role of the Security State Provider and the manufacturers
For all of this to work, manufacturers (OEMs) and OTA clients need to speak the same language. This is where androidx.security.state.provider comes in . Previously, update information was locked in proprietary silos, and third-party apps couldn't access it. Now, a standardized IPC mechanism is in place.
This provider allows update clients to declare patch availability in a unified way. While Google Play already does this, work is underway with manufacturers worldwide to bring their OTA clients into this framework , allowing any authorized app to know if a patch is available regardless of who delivers it.
Innovations in Android 17 and the RBUS system
The ecosystem continues to evolve, and Android 17 introduces a very interesting feature: Supplemental Patch XML files . This allows manufacturers to declare specific fixes they have applied beyond the official SPL. Thus, if an OEM backports a critical security patch, they can demonstrate compliance immediately without waiting for a global change in the monthly patch date.
In addition, the Risk Based Update System (RBUS) has been implemented . This means that if no new threats are detected for a specific component in a given month, the libraries automatically increase the "effective" security level of that component, ensuring that the device is not unfairly penalized in security checks.
Other tools from the AndroidX Security group
While the focus is on security, the library group includes other gems. For example, Security Crypto (although some of its APIs have been deprecated in favor of Android Keystore ) has been fundamental for managing encrypted files and secure shared preferences. It's so important that unofficial forks exist to maintain support for EncryptedSharedPreferences in versions where Google no longer prioritizes it, although it's always recommended to avoid storing sensitive data on the device if possible.
We also have Security App Authenticator , which simplifies verifying the trustworthiness of an app based on its signing identity, and Security Identity Credential , which allows you to manage digital identity documents (such as mobile driver's licenses) following the ISO/IEC 18013-5 standard, using the device's secure hardware when available.
Implementing these tools allows a transition to a zero-trust model based on evidence , where the security of a device is no longer simply a date, but a detailed analysis of its components, verification of real vulnerabilities, and seamless communication between hardware and software to ensure that every critical patch is in place.
