Android Binary Transparency Replays the Certificate Transparency Playbook

Google began logging production Android apps to a public Merkle ledger on May 1, 2026, using the same append-only design Certificate Transparency used on TLS certificates. If a Google-signed app from that date onward is missing from the log, Google says it did not intend to ship it.

Dave Kleidermacher, vice president of engineering for Android security and privacy, posted that promise on May 4, 2026 with Eric Lynch, Billy Lau, Vikram Gaur, and Kevin Chao. The May policy covers Google’s own apps and Mainline modules, not the rest of Play.

Certificate Transparency Already Wrote This Script

Google has been here before. After the 2011 DigiNotar breach, in which a compromised Dutch certificate authority minted rogue credentials including one for Google’s own domains, Google engineers put TLS certificates on public logs so anyone could see what a CA had issued.

The Certificate Transparency RFC landed in June 2013, written by Ben Laurie, Adam Langley, and Emilia Kasper at Google. Chrome then forced the issue: extended-validation certificates had to be logged from 2015, and organization-validated and domain-validated certificates followed in April 2018. A signed certificate that never appeared in a qualified log stopped being enough for the browser.

Android inherited the same idea on hardware first. The Pixel 6 security write-up on October 27, 2021 introduced Google Binary Transparency as append-only logs of signed system-image hashes, “building on the principles pioneered by Certificate Transparency.” Jay Hou of Google’s TrustFabric team spelled out the Merkle proofs on August 4, 2023 in a post on the Pixel factory image transparency log, which records a build fingerprint and a VBMeta digest for Pixel 6 and newer factory images.

THE CERTIFICATE TRANSPARENCY TIMELINE

1. 2011: DigiNotar is breached and issues rogue TLS certificates, including for Google domains.
2. June 2013: Google engineers publish the Certificate Transparency RFC for public, auditable certificate logs.
3. 2015: Chrome requires Certificate Transparency for extended-validation certificates.
4. April 2018: Chrome extends that requirement to organization-validated and domain-validated certificates.
5. October 27, 2021: Pixel 6 ships with Google Binary Transparency for factory images.
6. August 4, 2023: Google publishes the Pixel inclusion-proof and consistency-proof workflow.
7. December 4, 2025: A test APK is logged by mistake and cannot be removed.
8. May 1, 2026: Google’s production Android apps released after this date are promised a ledger entry.

Certificate Transparency worked because browsers refused certificates that skipped the logs. Android Binary Transparency copies the log. It does not yet copy that refusal on the phone.

What the May 2026 Logs Cover

The expanded Binary Transparency for Android adds two software layers that update far more often than a factory image. Google Applications include Play Services and standalone Google apps shipped across devices. Mainline Modules are the privileged, Play-updated pieces of Android itself.

Applications last updated before May 1, 2026 stay off the production ledger. Pixel owners can combine the new app logs with the older system-image log and check both the OS image and the Google apps. The family of logs is larger than that May pair. Google’s developer pages, last updated September 3, 2026, describe four public logs, including an older system-services APK log whose prior tree was archived from April 2026.

GOOGLE’S ANDROID TRANSPARENCY LOGS

Pre-installed Mainline modules are not duplicated in the Mainline log, because Pixel Binary Transparency already covers the factory image that contains them. The Mainline log is for modules that later arrive through Play.

Newer trees pack hashes into tiles of height 8, so each tile holds at most 256 hashes (2 to the 8). The original Pixel log used height 1, two hashes per tile. Before the 2026 Q3 update, the Mainline log’s first version used ECDSA with NIST P-256 and SHA-256; that V1 tree is archived and read-only, and the live Mainline log now runs on Tessera, Google’s tlog-tiles library.

A Signature Still Cannot Prove Intent

A Play-signed APK tells you who held the signing key. It does not tell you that Google meant that build to leave the building. Stolen keys, a rogue insider, and an internal development build can all carry a valid signature, which is the hole the log is meant to close.

Digital signatures are a certificate of origin, but binary transparency is a certificate of intent.

Dave Kleidermacher, VP Engineering, Android Security and Privacy, May 4, 2026 Google security post

The May 4 post is blunt about the rule that follows from that line: if a Google-signed application released after May 1, 2026 is not on the ledger, Google did not intend to release it. Kleidermacher’s group also wrote that no party, including Google, can change authorized software without leaving a public record.

BINARIES A SIGNATURE CANNOT VET

• Stolen signing keys: An attacker who can sign as Google still has to get the hash into a public log that monitors watch.
• Insider attacks: Publishing to the log is a separate step from signing, so key access alone is not enough.
• Internal development builds: A signed alpha that was never meant for public install is detectable if users only trust packages that appear in the log.

The Google Product Application Transparency log states that claim in the claimant model: Google asserts that a given SHA-256 is a specific official package meant for public consumption. Each leaf concatenates four fields with newlines: the file hash, a type string of SHA256(APK) or SHA256(APEX), the package name, and the versionCode. Split APKs and APEX packages are hashed as the whole file.

Billy Lau, an information security engineer at Google, said the company isolates code development from automated building and signing so that “no single individual has the access required to publish a binary without triggering comprehensive cryptographic verification.” The log is the public half of that split. Google also says it plans to hook the log into a public witness network using the C2SP tlog-witness protocol, and it asks independent parties to watch the tree in the meantime.

Index 39 Is Stuck in the Log Forever

The append-only claim got an accidental field test months before the May consumer post. On December 4, 2025, during a production-pipeline expansion, Google logged a test APK that was never meant for the public.

That leaf is index 39 on the first-party log: SHA-256 3a1fbc455a2c9ad4930dd266f44ae7f7009a294ec1ad4dfe5c3e3af591fd60c4, type SHA256(APK), package com.google.android.apps.internal.release.buster, versionCode 496557. Google says the process error was patched, and that to its knowledge the APK was never released to users.

The company cannot take the leaf back. Its errata page says no entries in Android Binary Transparency logs can be rewritten, even to correct honest mistakes, and that the test package at index 39 will remain permanently as a canary that the architecture works. That is the same immutability Certificate Transparency taught certificate authorities: once a bad or extra item is in the tree, the public record is the record.

It also shows the May 1, 2026 date is a policy line, not the birth of the log. First-party packages were already being written into a production tree in 2025. May 1 is when Google started promising that a missing entry for a newly released Google-signed app means the company did not intend to ship it.

Checking an APK Still Means Cloning a Repo

There is no Settings toggle. Verification lives in the Android Binary Transparency GitHub repository, which publishes Go inclusion-proof tools and pulls Android Verified Boot code as a submodule. A Pixel factory-image check means extracting ro.build.fingerprint and ro.boot.vbmeta.digest over adb, building a payload, and running the verifier against the checkpoint and tiles. App and Mainline checks follow the same pattern against their own trees.

Mishaal Rahman, who handles community engagement for Android at Google, posted the expansion on May 11, 2026 and put the gap in one sentence: “just because a new version of an app was signed with the same key as past releases doesn’t mean the new version was intended to be released.” The thread then went quiet. The sharp public objection that did show up treated the log as another Play Integrity-style gate.

It is not that kind of gate. Play Integrity is a Google-run attestation verdict returned to an app. Binary Transparency is a public Merkle tree anyone can query with the published keys and tile endpoints. The confusion is still useful, because a log that only researchers clone a repo to read behaves, for everyone else, like a press release. Certificate Transparency changed the web when Chrome started failing certificates that skipped the logs. Android’s app logs still wait for someone to look.

Google’s own Pixel documentation says most owners will never run the proofs, because Verified Boot already checks hashes and signatures at boot, and because third parties are expected to keep running consistency proofs on the tree. That is the CT division of labor again: logs plus monitors. The missing piece is a client that refuses software the monitors never saw.

Third-Party Apps Are Still Off the Ledger

Lau said on May 6, 2026 that Google is “actively working to extend Binary Transparency to third-party developers to strengthen the security of the global software supply chain,” and that the work is about scaling infrastructure and showing partners why they should join. The September 3, 2026 developer documentation still lists only Google’s own logs. No third-party intake, no Play requirement, and no phone UI have been published.

The May promise therefore covers Google software on any Android device, which is a wide net for Play Services and Gmail and a narrow one for everything else the same user installs. Pixel owners get an extra check on the factory image. Other OEMs have been invited since 2021 to publish their own firmware logs; Google’s pages still hold Pixel up as the example rather than a populated directory of peers.

WHAT WE KNOW

• Google production apps: Releases after May 1, 2026 are supposed to have a cryptographic ledger entry.
• Mainline updates: Play-delivered OS modules sit in a separate Tessera log after the 2026 Q3 cutover.
• Pixel images: Pixel 6 and newer factory images have been loggable since the 2021 Binary Transparency work.
• Third-party status: Lau’s May 6, 2026 statement is still the latest public word, and the September 3 docs do not add outside developers.

WHAT IS UNCONFIRMED

• A join date: Google has not published when third-party developers can write to a production log.
• On-device checks: No shipping Android UI is documented that fails an update missing from the ledger.
• Witness network: Integration with the standard witness protocol is planned, not described as live.
• Play enforcement: There is no stated rule that a Play listing must present a log receipt the way Chrome required signed certificate timestamps.

The Q3 Mainline move onto Tessera is the one operational change that landed after the May post, a sign that Google is building the log machinery for higher write volume even while partner onboarding stays unpublished. Until those partners appear, a signed banking app or a signed messaging client on the same phone as Play Services remains in the older world: origin without a public claim of intent.

Google has now done for its own Android binaries what it spent the 2010s doing for certificates: publish the leaf, freeze the tree, and dare anyone to find a build that is signed but absent. Index 39 shows the freeze is real. The next test is whether anyone besides Google has to pass it.

Frequently Asked Questions

What Does an Android Binary Transparency Log Entry Contain?

A Google app or Mainline leaf is four newline-separated fields: the SHA-256 digest of the entire APK or APEX file, a type string of SHA256(APK) or SHA256(APEX), the Android package name, and the integer versionCode. Pixel factory-image leaves are different and store a build fingerprint plus a VBMeta digest instead of an APK hash.

Which Pixel Phones Can Check Factory Images Against the Log?

Google publishes Pixel Binary Transparency entries for Pixel 6 and newer factory images. The documented high-confidence method is to download the matching factory image, or to read ro.build.fingerprint and ro.boot.vbmeta.digest from a device over adb, then run the Go inclusion-proof verifier against the Pixel checkpoint and tiles.

Are Factory-Installed Mainline Modules in the Mainline Log?

No. Google’s Mainline transparency overview says pre-installed modules are not explicitly listed there because they are already part of the factory image covered by Pixel Binary Transparency. The Mainline log is for modules later offered as updates through Google Play, which can be APK or APEX files.

What Proofs Does the Verifier Run Against the Merkle Tree?

An inclusion proof shows that a specific payload is a leaf in the current tree. A consistency proof shows that a newer checkpoint grew only by appending leaves, not by rewriting old ones. Google’s Pixel documentation treats inclusion as the check a user runs on an image and consistency as optional for that user, because independent monitors are expected to watch the tree continuously.