Google Product Application Transparency Log

The Google Product Application Transparency Log leverages transparency log technology.

The utilities of transparency logs have been proven by projects such as Pixel Binary Transparency and also Certificate Transparency.

Transparency logs are implemented with Merkle trees. This page assumes general knowledge of Merkle trees and binary transparency. See Verifiable Data Structures for an overview of Merkle trees and the main page for an overview of binary transparency effort within Android.

Log Implementation

The Google Product Application Transparency Log is implemented using Tessera and adheres to the tlog-tiles specification with a tile height of 8 (each tile or bundle contains at most 28 = 256 items).

The root of the log contents is served at: https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/entries/

The root of the tile contents is served at: https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/

Note that these are not regular web pages: the log entries contained in the subdirectories should be read programmatically with a tlog-tiles client library (such as Tessera or Golang SumDB Tlog library) and not through a browser. We state the link here for clarity.

  • Tree Tiles: Merkle tree interior and leaf node hashes are served under tile/<level>/<path> (e.g., tile/0/000, tile/1/000).
  • Entry Bundles: Log leaf payloads are organized into entry bundles under tile/entries/<path> (e.g., tile/entries/000, tile/entries/001), with each bundle holding up to 256 concatenated entries.

Refer to Log Content for a description of what each entry contains.

The Merkle tree root hash of the log, contained in a checkpoint, is served at https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/checkpoint in the checkpoint format. The checkpoint origin is android.transparency.goog/google1p/apk/2026/1.

Checkpoint signatures are generated using the Ed25519 signature algorithm. The signature of the checkpoint can be verified with the following public key in either note verifier format (as defined in golang.org/x/mod/sumdb/note) or standard PEM format:

  • Note verifier format (<name>+<key_hash>+<public_key_bytes>):
android.transparency.goog/google1p/apk/2026/1+fc654374+ATr9NQE0gvOtVfj5cCStUzdlflEp3oZoNHD8pImzPj5O
  • PEM format (SubjectPublicKeyInfo):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAOv01ATSC861V+PlwJK1TN2V+USnehmg0cPykibM+Pk4=
-----END PUBLIC KEY-----

Archived Log (V1)

Prior to the 2026 Q3 update, the log operated under an earlier V1 implementation using ECDSA (NIST P-256 with SHA-256) signatures. The V1 log is archived and read-only, but remains publicly accessible for verifying historical entries:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaP7xodTP5/teDOUYFAUHF0MqvOXt
+jamtcDYWxTjY99hyYczpB/cF2fxHhIqEznNpLcI2Vorl+iEchWhZ0y3Mg==
-----END PUBLIC KEY-----

Verify Log Claims

The verification page describes in more detail how the various components of the log are used to verify the claims made in the Claimant Model.