Android 17 adds build verification and a Google app ledger

Google announced on May 12 an Android 17 check that reports whether a device is running an official, widely distributed build of the operating system. Called Android OS verification, the feature launches initially on Pixel devices. The announcement also introduced a public ledger for confirming the provenance of production Google applications.¹

The two tools answer different questions. The first gives a device owner information about the operating-system build. The ledger records cryptographic hashes of binaries that Google says it published. Android Verified Boot already checks a software chain during startup, while attestation can communicate part of that state to an external service.

Android 17 reached most supported Pixels on June 16.⁹ Google has not published a separate model list for OS verification, the feature’s full interface path, or a schedule for other manufacturers. Its documented availability remains “initially on Pixel devices.”¹

The new notice classifies build provenance

Google’s announcement describes two conditions for the result: a build must be official and widely distributed. The published screenshot shows an official-build notice, but the company does not explain all the signals behind the decision or how a user starts the check.¹

That boundary matters for alternative systems. A ROM built from AOSP, signed by another project, and installed deliberately may fall outside Google’s classification. The result reports provenance under the announced distribution criteria. It does not determine on its own whether an alternative ROM is malicious, secure, or suitable for its user.

The available documentation also stops short of describing OS verification as an audit of all code in an image. A recognized build can still contain bugs and vulnerabilities. The check helps identify modified versions presented as an official distribution; it does not replace security updates or technical analysis of the software.

On Pixels, the feature joins an existing system. Pixel Binary Transparency maintains a public cryptographic record of metadata for factory images released by Google. An inclusion proof can show that an image matches a published version, while a consistency proof can show that old entries were not changed as the log grew.⁸ Google’s own technical explanation notes that the metadata cannot attest to the integrity of the build and release processes.

The app ledger records versions intended for release

The second part of the announcement covers production Google applications across Android, including Google Play services and foundational GMS APIs. For versions released after May 1, 2026, Google publishes a corresponding cryptographic entry. An application last updated before that date may be absent.²

Under the Google Product Application Transparency documentation, each entry contains the SHA-256 hash of the complete APK, the hash type, package name, and versionCode. The hash acts as a fingerprint of the file: any change to the APK produces a different value. An inclusion proof lets someone compare an installed or received copy with the version Google marked for public consumption.³

Digital signatures and the ledger cover related stages. A valid signature links a binary to a developer’s signing key. The log adds a verifiable statement that Google intended to publish that particular version. It can expose an APK signed with a compromised key that never entered the official production flow.² ³

The log uses a Merkle tree, a structure that summarizes all entries in a root hash. New items can be appended without allowing earlier changes or deletions to go undetected. Its data is public and queryable. Google says a standardized network of independent witnesses is still planned and encourages third parties to monitor the log’s consistency.³ ⁴

Binary Transparency is the name of Google’s group of projects, rather than a universal catalog. Its overview separates logs for Pixel firmware, selected Google system APKs, Google applications, and Android Mainline modules.⁴ The newly announced ledger does not cover third-party applications, every installed app, or all code in an Android build.

A match between the file’s hash and the ledger entry confirms that the binary is the version Google designated as production software. It does not guarantee the absence of vulnerabilities, assess an app’s product decisions, or prove that published source code produced that exact file. The system makes unexpected versions detectable within its stated scope.

Verified Boot protects another part of the path

Android Verified Boot runs during startup. Its chain begins at a hardware-protected root of trust and verifies the bootloader, boot partition, and other partitions such as system and vendor before handing execution to the next stage. It also provides rollback protection against returning silently to older versions under protected conditions.⁵

This local verification depends on the root of trust accepted by the device. AOSP defines one state for locked devices that use a user-configured key and another for an unlocked bootloader. Verified Boot can therefore validate a chain signed by an alternative root without declaring it part of an official Google distribution.⁶

Key attestation can expose verifiable information about that state to another party. Its documented fields include the Verified Boot key, device-lock state, verification result, and protected digest.⁷ Services can use statements of this kind when deciding how much trust to grant a request.

Google has not published an architecture identifying OS verification as a layer built solely on Verified Boot or attestation. The documented promises remain distinct: local integrity at boot, cryptographic communication of device state, and recognition of a widely distributed build are separate claims.

Sources

1. What’s New in Android Security and Privacy in 2026 · Google Security Blog · https://blog.google/security/whats-new-in-android-security-privacy-2026/ · May 12, 2026
2. Evolving Verifiable Trust: Bringing Binary Transparency to the Android Ecosystem · Google Security Blog · https://blog.google/security/bringing-binary-transparency-to-the-android-ecosystem/ · May 4, 2026

Show 7 more sourcesHide sources

3. Google Product Application Transparency · Google for Developers · https://developers.google.com/android/binary_transparency/google_apk/overview · updated May 1, 2026
4. Binary Transparency · Google for Developers · https://developers.google.com/android/binary_transparency/overview · updated May 1, 2026
5. Verified Boot · Android Open Source Project · https://source.android.com/docs/security/features/verifiedboot · accessed Aug. 26, 2026
6. Boot flow · Android Open Source Project · https://source.android.com/docs/security/features/verifiedboot/boot-flow · updated June 17, 2026
7. Key and ID attestation — schema · Android Open Source Project · https://source.android.com/docs/security/features/keystore/attestation#schema · accessed Aug. 26, 2026
8. Pixel Binary Transparency: verifiable security for Pixel devices · Google Security Blog · https://security.googleblog.com/2023/08/pixel-binary-transparency-verifiable.html · Aug. 4, 2023
9. Android 17 is here · Android Developers Blog · https://android-developers.googleblog.com/2026/06/Android-17.html · June 16, 2026