Introduction
GrapheneOS has built a reputation as the most hardened, privacy-focused Android variant available today. But if you’ve ever wondered why it only runs on Google Pixel devices, the answer lies in a unique mix of hardware security, long-term firmware support, and openness in the Android ecosystem. With Android 16 introducing major changes to how hardware support is shared – and Google facing antitrust pressures in the U.S. – the future of projects like GrapheneOS is becoming more complex. This article breaks down what device trees, firmware blobs, and Pixel repositories really are, why they matter, and why Pixel devices remain the only realistic foundation for a secure, open Android alternative.
Here’s a breakdown of what I found, simplified. A lot of info is floating around; some confirmed, some speculative. I’ll lay out what is known, what GrapheneOS is worried about, what DOJ/antitrust stuff has to do with it, and what this means in practical terms.
What we do know
- Android 16, AOSP, and missing Pixel-specific components
- Google released Android 16 source code to AOSP (Android Open Source Project), but did not release the hardware-specific “device trees / Pixel repositories / firmware bits” usually needed for porting custom ROMs to new hardware (like Pixels). Developer Tech News
- For GrapheneOS and other third-party ROMs, having those hardware-specific resources helps a lot; without them, porting becomes harder. CyberInsider+1
- Structural changes in Android 16
- Android 16 apparently includes architectural changes (kernel, firmware, hardware abstraction) that raise the complexity of supporting custom ROMs. GrapheneOS claims these changes make porting harder than ever. CyberInsider
- The “Pixel target” (official support for Pixel hardware in AOSP) is less accessible. GrapheneOS says that Pixel hardware being stripped out (or de-emphasized in how the code is shared) means that they (and others) must reverse-engineer more, write more custom firmware/kernel patches, etc. CyberInsider+1
- Antitrust / DOJ rulings affecting Google’s OEM deals & default apps
- The U.S. Department of Justice (DOJ) has been suing Google for antitrust violations, including issues around how Google bundles its apps (like Chrome, Search, etc.) and how OEMs have deals that make Google’s software “the default.” MEDIANAMA+1
- A recent court ruling (Judge Amit Mehta) forbids Google from exclusive or restrictive OEM deals that force OEMs to make Google apps (Chrome, Search) the default. MEDIANAMA
- But Google isn’t being forced to sell Chrome or divest Android itself under this ruling (i.e. no requirement to spin off the Android OS or Chrome browser entirely). MEDIANAMA
- GrapheneOS’s concerns and interpretations
- GrapheneOS has publicly warned that with Android 16, Google is “locking down Android” in a way that makes it harder for privacy/security-focused, open ROMs to keep up. CyberInsider
- They believe Google is treating non-Google Android-based platforms more like competitors than collaborators. That means less cooperation (especially hardware OEM access, firmware, etc.). CyberInsider+1
- GrapheneOS also suggests that these changes may be related to Google preparing for antitrust outcomes — e.g. if Android/Chrome must be separated or if Google loses some power over OEM deals. Developer Tech News+2
What’s speculative or unclear
- Whether Google will be forced to divest Android or fully spin out Android or Chrome remains uncertain. GrapheneOS and others speculate this because of DOJ motions, but no final decision has mandated that yet. GrapheneOS Discussion Forum+2MEDIANAMA+2
- How many or which OEMs will still share the required firmware / HAL code, driver blobs, etc. It’s unclear whether Google is fully cutting off access, or just raising barriers (e.g. stricter licensing, delayed access).
- Whether GrapheneOS (or similar ROMs) can negotiate OEM partnerships or get “OEM partner access” to hardware resources. The lack of partner access is one of their big complaints. But might be possible in some cases. CyberInsider
Why this matters practically (for GrapheneOS / other ROMs / users)
- Harder to port to new devices – Without hardware-specific code / driver blobs, ROMs must reverse-engineer more, write or adapt more parts themselves. This increases development time, errors, maintenance burden.
- Possible delay or lack of support for new Pixel devices – GrapheneOS often uses Pixel devices for support because Google tends to make those available / relatively easier. If Pixel targets are no longer shared fully or officially, GrapheneOS may take longer to bring Android 16 support to new Pixel devices (or possibly skip some).
- More work (kernel, bootloader, firmware) – More integration work is needed for firmware, bootloader/hardware drivers, device-trees, etc., because you can’t rely as much on Google’s “official” shared code.
- Increased cost / effort for OEM deals – If GrapheneOS wants to ship devices (or collaborates with OEMs) with full support, they may need to create their own OEM-partner relationships, pay for certification, etc.
- Potential impact of DOJ antitrust ruling – Because Google cannot force OEMs to preinstall or make Google apps default in exclusive ways, OEMs may have more freedom. That could open opportunities for GrapheneOS (or OEMs to use GrapheneOS), since Google’s leverage is reduced. But changes in Android 16 make the technical barrier higher regardless.
Lets get into the nuts and bolts of how Android actually runs on specific hardware. Let’s break them down one by one:
Device Trees
- What they are: Configuration files and scripts that tell Android how to talk to a specific phone’s hardware.
- Why needed: Android runs on many different devices – each with different CPUs, displays, cameras, radios. The device tree defines those hardware characteristics so the OS knows what’s available and how to initialize it.
- Example: The Pixel 7’s device tree contains info about its Tensor chip, screen resolution, camera modules, and power management.
- In practice: Custom ROM builders pull the device tree to create a build of Android that boots and works correctly on that model.
Pixel Repositories
- What they are: Google maintains special repositories in AOSP (Android Open Source Project) with extra code specifically for Pixel devices.
- Contents: These often include build configs, Pixel-only features, vendor-specific HALs (Hardware Abstraction Layers), and other Pixel-specific adaptations.
- Why important: Without these repos, developers of custom ROMs (like GrapheneOS) have to reverse engineer or manually adapt support for Pixels.
- In practice: GrapheneOS normally relies on these Pixel repos as their base because Pixels are the “reference devices” for Android.
Firmware Bits (a.k.a. Blobs / Binaries)
- What they are: Closed-source binary drivers and firmware needed to operate low-level hardware like the modem, GPU, Wi-Fi, fingerprint sensor, camera ISP, etc.
- Why needed: Many parts of a smartphone rely on proprietary code that isn’t open-sourced. Without these blobs, the OS can’t make the hardware work.
- Example: The Wi-Fi chip might need a specific firmware binary loaded at boot to function; the fingerprint sensor driver is usually closed-source too.
- In practice: ROMs like GrapheneOS include these firmware bits from Google’s factory images, since you can’t realistically re-implement them from scratch.
How they fit together
When you build Android for a specific phone (say, Pixel 8), you need:
- AOSP base → the open-source Android code.
- Device tree → tells the OS “this hardware has Tensor G3 CPU, X camera modules, Y screen panel.”
- Pixel repos → special glue and HALs from Google for Pixels.
- Firmware blobs → closed-source drivers/firmware needed to actually make radios, graphics, sensors work.
Without these, you can boot Android, but you’ll often end up with a system where Wi-Fi, cellular, camera, or GPU acceleration simply don’t work.
Here’s a visual breakdown of how everything stacks together:
- Hardware at the base (CPU, GPU, radios, sensors).
- Firmware bits / blobs let Android actually talk to that hardware.
- HALs + Device Trees + Pixel repos bridge the gap by defining configs and hardware interfaces.
- AOSP Framework builds the Android system.
- Apps (user + system) sit on top of it all.
Understanding the Android Build Layers
The diagram below shows how Android is layered from raw hardware all the way up to apps:
- Hardware
At the base are the physical components: CPU, GPU, radios, sensors, and camera modules. For example, Pixel devices use Google’s Tensor SoC, custom camera sensors, and Wi-Fi/5G chips. - Firmware bits / binary blobs
Many of these hardware components require proprietary code to function. These include Wi-Fi firmware, GPU drivers, and fingerprint sensor binaries. They are closed-source and must be loaded into the device at boot. - Hardware Abstraction Layer (HALs)
HALs act as translators between the hardware/firmware and the higher-level Android system. Examples include the Camera HAL, Audio HAL, and Radio Interface Layer. Without HALs, Android wouldn’t know how to issue instructions to specific hardware. - Device Tree + Pixel repositories
These define how Android should configure and initialize a particular device model. A device tree might specify board configs, display panels, or power management details. Pixel repositories add Google-specific patches and vendor glue code that make Pixels unique. - Android Framework (AOSP)
This is the open-source “Android OS” layer – system services, APIs, and managers (like the Activity Manager or Notification Manager) that developers interact with. - Apps
At the top, everything comes together for the end user: system apps (Phone, Messages), user apps (like Signal), and OS-specific tools (such as GrapheneOS’s enhanced security apps).
GrapheneOS risks losing its foundation because Google’s focus is shifting away from real Pixels to virtual test devices.
Another big piece of this puzzle and ties directly into GrapheneOS’s concern about the future. Let’s unpack it clearly:
What is Cuttlefish?
- Cuttlefish is Google’s virtual device environment for testing Android.
- Instead of testing Android builds on physical hardware (like a Pixel 8), OEMs can boot Android inside Cuttlefish, which emulates hardware components virtually.
- It’s basically a virtual reference device that runs on a host machine, used by OEMs and developers to validate builds and features.
The Shift: Physical → Virtual Testing
- Historically, OEMs (and projects like GrapheneOS) relied on physical Pixel device targets in AOSP – the “canonical” hardware reference.
- With Android 16, Google is shifting emphasis to Cuttlefish as the reference testbed.
- This means less priority on publishing Pixel-specific device trees, repos, and binaries, since the official expectation is that testing happens in a virtualized environment, not on a specific piece of consumer hardware.
Why This Is a Problem for GrapheneOS
- Loss of a Real-Device Baseline
- GrapheneOS depends on Pixel hardware because of Titan M, hardware attestation, and Google’s historically good device support.
- If Google deprioritizes Pixels in AOSP in favor of Cuttlefish, custom OS projects lose their best “entry point” into building for real hardware.
- Virtual ≠ Secure Hardware
- Cuttlefish can’t emulate Titan M chips or true hardware attestation.
- For GrapheneOS, which relies on real secure hardware for its security guarantees, a virtual reference device is almost useless.
- OEM Lock-In Pressure
- By focusing on virtual testing, Google can provide a generic environment that OEMs can adapt – but without needing to share Pixel repos or firmware bits.
- That leaves projects like GrapheneOS “outside the club,” since only official OEM partners would have the real hardware details.
The move to Cuttlefish as the main reference device signals a future where:
- Google’s Pixel hardware may no longer be the public development baseline.
- GrapheneOS (and other ROMs) will face even more reverse-engineering to get new Pixels working.
- The “bridge” between open-source Android (AOSP) and real devices may narrow to OEMs only.
Why GrapheneOS depends on Google Pixel devices
- Hardware-backed Security Features
- Pixels ship with Titan M / M2 security chips (custom secure elements) that handle verified boot, key storage, rollback protection, etc.
- GrapheneOS relies on these chips to enforce integrity and protect against firmware tampering.
- Without a secure enclave like Titan, GrapheneOS couldn’t provide the same guarantees.
- Strong Hardware Attestation
- Pixels have the most advanced hardware attestation pipeline of any Android device.
- This lets GrapheneOS cryptographically prove a device’s identity and integrity (secure boot, OS version, patch level) in a way third-party ROMs can’t fake.
- That’s critical for enterprise trust, app security (banking, payments), and system resilience.
- Long-term Update Support
- Google guarantees 7 years of OS and firmware updates on Pixels (as of Pixel 8).
- That includes kernel patches, firmware updates for radios/cameras, and Titan chip updates.
- GrapheneOS depends on this supply of vendor patches; if OEMs stop after 2–3 years (common outside Pixels), GrapheneOS would inherit insecure, unpatched firmware.
- Open Development Model (relative to OEMs)
- Pixels are the “reference” devices for AOSP. Even though Android 16 made this trickier, historically Google provided better device trees, repos, and factory images than other OEMs.
- This makes Pixels the only realistic baseline for a hardened Android distribution.
- No Alternative OEMs with Equivalent Stack
- Samsung, OnePlus, Xiaomi, etc. don’t expose the same secure boot pipelines, attestation, or long patch lifetimes.
- They often bundle heavy proprietary modifications and provide fewer developer resources.
- That means GrapheneOS can’t replicate its model on those devices without sacrificing core security promises.
GrapheneOS depends on Pixels because only Google devices combine:
- A secure enclave (Titan M/M2)
- Verified boot and rollback protection
- Strong hardware attestation
- 7 years of firmware + OS updates
- (Historically) better AOSP integration
That unique combination is what lets GrapheneOS build a hardened OS that is provably more secure than stock Android.
Here’s the comparison table showing why GrapheneOS depends on Google Pixels versus Samsung or OnePlus.
Pixels stand out with the Titan M/M2 chip, stronger attestation, and 7 years of updates, while Samsung/OnePlus either lack secure enclaves, provide weaker attestation, or lock down their repos/bootloaders – making them poor candidates for GrapheneOS.
| Feature | Google Pixel | Samsung | OnePlus |
| Secure Enclave (Titan M/M2) | ✔ Titan M/M2 chip | ✘ (no Titan, Knox is weaker) | ✘ No dedicated secure chip |
| Verified Boot & Rollback Protection | ✔ Strong, fully enforced | ✔ Enforced but less open | ⚠️ Basic enforcement |
| Hardware Attestation Strength | ✔ Strongest (industry-leading) | ⚠️ Weaker, proprietary pipeline | ⚠️ Limited, weaker than Pixel |
| OS/Firmware Update Duration | ✔ ~7 years (Pixel 8+) | ⚠️ ~4 years OS / 5 years patches | ⚠️ ~3–4 years support |
| Openness of Device Trees / Repos | ✔ Historically best AOSP support | ✘ Proprietary repos, hard for ROMs | ✘ Proprietary, locked bootloaders |
| OEM Bloatware & Modifications | Minimal (close to AOSP) | Heavy modifications (OneUI, Knox) | Heavy modifications (OxygenOS/ColorOS) |
