Target devices.

Why only Pixel.

The reasoning behind a Pixel-only device list is not ours. It belongs to the upstream hardening tradition this project builds in. The honest thing is to credit it and follow it, not restate it as a discovery.

grapheneos.org ↗ puts the principle in one line: "Broad device support is counter to the aims of the project."

That project ties device support to the manufacturer's firmware maintenance. It drops a device when firmware, kernel and vendor code stop being actively maintained.

Three hardware properties decide the list here, and all three are upstream's criteria before they are ours.

Hardware-backed verified boot with a user-controlled key. The device has to let its owner install their own AVB key and re-lock the bootloader afterwards. GuardTalkOS depends on this more heavily than a general-purpose build does, because its trust anchor is a key the user holds. A device that will not accept a user key cannot run this OS as it is designed.

Isolated radios. The modem is meant to sit behind a boundary rather than share memory with the application processor. This matters here because GuardTalkOS removes the network from itself, not from the hardware. Isolation bounds what a baseband compromise can reach; it does not remove the baseband.

Published firmware support lifetimes. The manufacturer publishes how long a device receives firmware, and that date is the one this project cannot move. When firmware stops, nothing an OS build does above it can repair what sits below it, and the device leaves the list.

The target matrix.

Two codenames are named in the source material: tokay and rango. Which model each one is, and which other Pixel 8 and Pixel 9 codenames belong on this page, are open questions — // confirm §19.4. They are printed as open questions rather than filled in with plausible-looking values. A codename paired with the wrong model is the easiest mistake to make here, and the hardest for a reader to catch.

A row in that table means the build targets the device. It does not mean an image exists for it today, and it does not mean the device has passed on-device validation. Validation is PASS HOLD, and the dated version of that is on Status. Release artefacts, where they exist, are listed on Releases.

Two rows carry a codename because two codenames are confirmed. The other rows carry // confirm §19.4 in every cell, including the codename. Inventing a codename would be the easiest dishonesty available to this page.

Firmware pairing.

Each Pixel boots factory images at a firmware level the manufacturer sets: bootloader, radio, boot, vendor_boot and dtbo. GuardTalkOS builds system, system_ext, product and vendor, and pairs them with the factory images for one device at one firmware level.

Pairing is therefore per device and per firmware level, never per family. A system image flashed over a firmware level it was not built against falls outside the release process. This site does not describe that as a route.

The exact firmware level for each target device is not published here.

// confirm §19.4firmware level paired per target device

Where it is confirmed, it will appear per release on Releases rather than as one family-wide sentence on this page. Which partitions are ours and which are the manufacturer's is set out in the boot chain. Verified boot with your key covers the four images this project builds. The factory images carry the manufacturer's signatures instead.

Support posture.

This page says target. It does not call any device a supported device, because that phrase is a maintenance promise and this project has not made one. The wording itself is an open question — // confirm §19.4 — and until it resolves, the conservative word is the one that ships.

No update cadence appears anywhere on this site. There is no committed figure to publish, and publishing an aspirational one would be worse than the silence. The cadence field on Status carries the same open question rather than a number.

The intended lifetime policy follows upstream practice. A device stays on the target list while its manufacturer maintains firmware, kernel and vendor code. It leaves the list when that maintenance ends. The policy is not committed yet.

// confirm §19.4support-lifetime policy and the target-versus-support wording

There is no coming-soon list on this page. A device is a target or it is absent. A queue of unannounced devices is a marketing device, not a maintenance plan. It would also commit this project to work it has not scheduled.

What a fleet reader should take from this page.

If you are evaluating GuardTalkOS for a deployment, three lines here carry the weight.

The codename column has two confirmed entries. The posture column says target on both. The cadence is unstated, and on-device validation is PASS HOLD.

A board paper written honestly from this page reads: an alpha build, two confirmed target devices, no maintenance commitment, no cadence. If that is not enough to deploy on, that is the correct reading, and reaching it here costs less than reaching it after procurement.

What would change it is a resolved §19.4, an on-device PASS, and a cadence this project is willing to put in writing. All three are tracked on Status with dates, and none of them is claimed here in advance.

One thing a device list cannot answer is whether the OS fits your problem. GuardTalkOS on a target Pixel is still the endpoint of a system. Without the GuardTalk Gateway there is no checkpoint, and what remains is a stripped ROM with a Wi-Fi radio. This page says where the build runs, and the threat model says what it protects.