Android Mainline Modules Transparency Log

The Android Mainline Modules Transparency Log uses verifiable data structures to ensure the integrity of Mainline modules.

The utility of transparency logs has been proven by projects like Pixel Binary Transparency and Certificate Transparency.

Transparency logs are built on 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 efforts within Android.

Log Implementation

The Android Mainline Modules 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/mainline/2026/02/tile/entries/

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

Note that these URLs are not standard web pages. Instead, the log entries in its subdirectories should be accessed programmatically using tools like Tessera or the Golang SumDB Tlog library.

  • 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/mainline/2026/02/checkpoint in the checkpoint format. The checkpoint origin is android.transparency.goog/mainline/modules/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/mainline/modules/2026/1+1a8e4064+AfwnHm59rNQTJICchMd7a2W5PQa7nC5h2gTEfq3fhCEI
  • PEM format (SubjectPublicKeyInfo):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEA/Ccebn2s1BMkgJyEx3trZbk9BrucLmHaBMR+rd+EIQg=
-----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-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEr6nPds8eKCYU42avidXNM1GDCtQ/
66GjGuIpUcZjqQNngwRFVCFZDpWuvDnqXzhJRxqccL9lbeEVVZGpa4x6pg==
-----END PUBLIC KEY-----

Because Mainline modules are similar to APKs, the verification methods described on the Google APKs verification page apply here as well. You can use the methods there to verify the claims made in the Claimant Model.