SECOND MEASUREMENT SM-001
Google's Pixel ledger promised every release. January went missing, and stayed missing for eight months
Every Pixel update is supposed to land in a public ledger, so anyone can prove their phone got the same software as everyone else's. In September we went looking for January 2026 and found an empty month: all 29 factory images, missing from the record for eight months. We told Google. Within a week they'd traced it to a skipped update run and written the month back in, without disturbing a single earlier entry. One loose end is still dangling: 128 newer entries filed under a label phones never report, so those phones can't find their own.
- Google says its Pixel transparency log covers every factory image from Pixel 6 on.
- In September the whole January 2026 release was missing: 29 images, absent for eight months.
- Google confirmed it, traced it to a skipped update run, and added them on 22 September.
- The fix rewrote nothing: the log’s earlier history still checks out.
- Still open: entries filed under a label phones don’t report, 103 when we measured, 128 now.
Round trip. The operator replied, fixed what we measured, and the recheck confirmed it. The seal is theirs; it links here and to the log leaf that pins this page.
Disclosure: Markovian Protocol holds no financial position in any organisation named here, was paid by no one for this work, and showed it to no one before publication except the organisation measured. How we work.
Google says its Pixel transparency log covers every factory image it offers for download for Pixel 6 and newer. On 15 September we took every image on the download page and looked each one up in the log. 54 of 1,091 weren't there. 29 of those were the whole January 2026 release (build BP4A.260105.004, for 15 devices). For one of them we also checked by its hash, a unique code computed from the file, to be sure it was really missing and not just misnamed.
Separately, 103 Android 17 images were logged under a generic label that no real phone reports, so a phone checking itself won't find them. Google confirmed both problems. They said a run that adds new images to the log had been skipped, and they added the 29 as entries 1134 to 1162. When we checked again on 30 September, 0 of 1,091 were missing. The Android 17 label problem is still open.
What Google says, what we found
| Google says | We found |
|---|---|
| The log holds “all factory images, beginning from Pixel 6, available for download from the official Android factory images website.”1 | On 15 September, 54 of the 1,091 images on that website weren't in the log. 29 of them were the entire January 2026 release. |
| Each entry is filed under the build fingerprint, the name tag a phone reports for its software.3 | All 103 Android 17 images are filed under a generic tag that no phone reports, so a phone checking itself comes up empty. |
| After our report, the missing images were added. | On 30 September, 0 of 1,091 were missing, and nothing already in the log had changed. |
Why a log can look complete and still have holes
A signed log proves Google committed to everything that's in it.4 It can't prove nothing was left out. The only way to test that is to hold it up against an outside list of what should be there. Google's own download page is that list.2 It's published separately from the log, so we fetched both and matched every image on the page, for all 25 Pixel 6-and-newer phones, against the log.
The missing month
The log had December 2025. It had February 2026. January wasn't there at all: build BP4A.260105.004 (versions .E1, .A2, .B2 and .C2) for 15 devices, from the Pixel 7a and Pixel Tablet to the Pixel 10 Pro Fold, 29 images.
Matching by name can miss an image that's filed under a different name, so we checked one by its contents too. We downloaded just the small vbmeta part of the Pixel 9 (tokay) January image and computed its hash with Google's own tool, avbtool:6
b1eca34c41d308c91abcea66cf5852814cd526020041a590bd7f865aaa0900b6
That hash appeared 0 times in the whole log. It really was missing, not misfiled.
The other 25 missing images were September 2026 builds (CP3A.260905.009 for 21 phones and CD1A.260905.001.B1 for the four launched that month); the log had last been updated on 21 August, so we reported those as lag. The log had last been updated on 21 August, so we reported those as ordinary lag rather than a hole.
| What happened to each image | Images |
|---|---|
| In the log under the phone's own name | 934 |
| In the log only under the generic name | 103 |
| Not in the log | 54 |
| Total on the download page | 1,091 |
15 September 2026, log size 1,109.
The phones that can't find themselves
Every Android 17 image is in the log, 103 of them, but filed under google/generic_system_google/generic:17/… instead of the phone's own name. Take the Pixel 9 build CP2A.260705.006: its hash is entry 1073, under the generic name.
Inside the image, only one field (com.android.build.system.fingerprint) says generic. Everything else, including the fingerprint the phone actually reports (ro.build.fingerprint), says google/tokay/tokay:17/…. Google's own verifier accepts the entry with the generic name and rejects it with the phone's name. So the image is logged, but a phone that checks itself using its own fingerprint comes up empty.
What Google said back
We filed both findings on 15 September as issue #20.5 On 22 September the log's maintainer replied:
The cause was a missed run of the log-append step for that release, not a discrepancy in the images themselves. They should now have been appended (backfilled) at indices 1134-1162; the log is at tree size 1163.
The same reply confirmed the Android 17 problem: on an Android 17 phone, a check built from ro.build.fingerprint won't verify even though the image is logged. A fix for that is pending.
Did the fix rewrite history?
Adding missing entries is fine. Quietly changing old ones wouldn't be. Our vendor-log monitor7 had saved the log's state at 1,134 entries on 18 September. On 23 September it checked a proof that the new 1,163-entry log starts with exactly those 1,134 entries. It does: the 29 were added on the end, and nothing earlier changed. The missing Pixel 9 image from above is now entry 1161:
1161 google/tokay/tokay:16/BP4A.260105.004.E1/14587043:user/release-keys b1eca34c41d308c91abcea66cf5852814cd526020041a590bd7f865aaa0900b6
| 15 Sept | 30 Sept | |
|---|---|---|
| In the log under the phone's own name | 934 | 963 |
| In the log only under the generic name | 103 | 128 |
| Not in the log | 54 | 0 |
| Log size | 1,109 | 1,163 |
Same script both days. The September lag images are in now. The 25 September images were logged by 18 September, all under the generic label, which is why that count went from 103 to 128.
The evidence
Every quote below was checked against a saved copy, fetched 2026-10-02T18:09:27Z. Copies and SHA-256 hashes: SHA256SUMS.
Exhibit 1 · The claim, Google’s log overview
“Claim FactoryImage : (I, Google, claim that $factoryImage_instance is for $deviceNameOrSku ), where: $factoryImage_instance are all factory images, beginning from Pixel 6, available for download from the official Android factory images website.”
developers.google.com/android/binary_transparency/pixel_overview · saved copy pixel_overview.html
Exhibit 2 · Google’s reply, 22 September
“Both findings were correct… You were right that all 29 images across 15 devices were absent. The cause was a missed run of the log-append step for that release… They should now have been appended (backfilled) at indices 1134-1162; the log is at tree size 1163.”
android/android-binary-transparency#20, comment by billy-lau · saved: issue-20-comments.json
Exhibit 3 · Same reply, on why it matters
“This is exactly the kind of external check the log exists to make possible. Thank you for doing it carefully and writing it up so precisely!”
Exhibit 4 · The log today
developers.google.com/android/binary_transparency/0 1163 7XhtRE3AhCPZlIedbcQ2fXo4cs21fc15PR+Ahv5lIJc=
The signed size includes the 29 backfilled entries (1134–1162).
developers.google.com/android/binary_transparency/checkpoint.txt · raw checkpoint.txt
Disclosure timeline
| 15 Sep | Reported to Google on the log’s public issue tracker (#20). |
| 22 Sep | Google confirms both findings and backfills the missing month. |
| 30 Sep | Published. |
| 2 Oct | Rechecked: 0 images missing. |
| 3 Oct | Round-trip seal given, on the issue where Google fixed it. |
What we can't be sure of
- We compared the log against one page. Software sent only as over-the-air updates, images Google has taken down, and images published anywhere else aren't covered.
- That's the other direction, and Google's claim doesn't cover it.
Run it yourself
The scripts are also on GitHub: github.com/MarkovianProtocol/second-measurements/sm-001.
The script uses only Python's standard library. It prints any absent images and a summary line.
curl -O https://markovianprotocol.com/measurements/sm-001/check_public.py
shasum -a 256 check_public.py
# fcc67371bd9f8bccbaac25903571aced8bed71234024d716a6209225eb1b522c
python3 check_public.py
# tree size 1163: {'logged': 963, 'logged as generic': 128}
The script does not verify the checkpoint signature. Verify it with Google's verifier3 or against the Armored Witness cosigned copy.8 The same completeness check runs daily and publishes signed results.7
Corrections
23 September: in a follow-up on issue #20 we said nobody was cosigning the Pixel log. That was wrong. The Armored Witness fleet cosigns it through the transparency-dev distributor, which served checkpoint.3 at size 1,163 with three Armored Witness signatures and the same root as Google's.8 We had only checked the witnesses' own endpoints. We posted the correction in the same thread.
Reproduced from the public repository on 3 October 2026 on a clean machine: exact (tree size 1,163, 963 logged, 128 under the generic label). Full table on the track record.
What you can do with this
- If you own a Pixel 6 or later, the factory image you install should be findable in the log by its build number; the verifier in Google's repository does this, and the January 2026 builds now resolve.
- If you run a binary transparency log, publish the fingerprint phones actually report; 128 entries here still carry one they don't.
References
- Google. Pixel Binary Transparency overview. developers.google.com/android/binary_transparency/pixel_overview. Accessed 2026-09-30.
- Google. Factory Images for Nexus and Pixel Devices. developers.google.com/android/images. Accessed 2026-09-15 and 2026-09-30.
- Google. android-binary-transparency (verifier and log files
checkpoint.txt,image_info.txt). github.com/android/android-binary-transparency. - B. Laurie, A. Langley, E. Kasper. Certificate Transparency. RFC 6962, 2013. rfc-editor.org/rfc/rfc6962.
- Markovian Protocol. Pixel log: January 2026 factory images are missing, and Android 17 entries use the system fingerprint. android/android-binary-transparency#20, 2026-09-15; maintainer reply 2026-09-22. github.com/android/android-binary-transparency/issues/20.
- Android Open Source Project. Android Verified Boot 2.0, avbtool. android.googlesource.com/platform/external/avb.
- Markovian Protocol. Vendor log monitor and signed statements. markovianprotocol.com/bt/.
- transparency-dev. Distributor API, Pixel log checkpoint.3. api.transparency.dev/distributor/v0/logs. Accessed 2026-09-23.
Cite as
@misc{markovian-sm001,
author = {{Markovian Protocol}},
title = {Completeness of the Pixel Binary Transparency log
against Google's factory images page},
number = {SM-001},
doi = {10.5281/zenodo.23070510},
year = {2026},
month = sep,
url = {https://markovianprotocol.com/measurements/sm-001.html}
}