> What about the "real possibility that some hardware components or features could be permanently broken on custom ROMs. Features that rely on heavily customized drivers, such as advanced camera functionalities, may be particularly difficult to implement perfectly"?
Unsure what you're trying to ask here. We aren't using any custom drivers, but the same official ones. They're the same operating system within. For certain devices like Samsung this is only a problem because they use eFuses to kill said features. We are still able to make changes. Notice we have the hardware USB-C port control functionality.
> You acknowledge that "device tree configurations were dropped"—so why do you dismiss this as the article "not quite understanding what changed"? The loss of device tree configurations is exactly what multiple sources identify as the core problem requiring reverse engineering.
Every other AOSP distribution has to make /. reverse engineer a device tree from every other device that isn't Pixels prior to this. It is a small loss that was a disruption when it was realised because it was unprepared. We don't use the old device tree code at all anymore and we completely automate creating a device tree.
We replaced Android 15 QPR2 device trees with heavily stripped down device trees depending on our automated device support generation. We're not using the Android 15 QPR2 device trees. We can make new minimal device trees for the Pixel 10 similarly depending on our automation as well.
>While you're correct that userspace driver code remains available, the missing device trees are what force developers into "blind guessing and reverse engineering from prebuilt binaries."
As above we have a tool that automates this, you can check it out here:
GitHub
GitHub - GrapheneOS/adevtool: Android device support and bringup tool, designed for maximum automation and speed.
Android device support and bringup tool, designed for maximum automation and speed. - GrapheneOS/adevtool
Readme is not entirely complete so feel free to check commit histories etc.
>Your response seems to minimize the significance of losing these configurations. How substantial is the impact of having to recreate device tree configurations without Google's official version?
Thanks to above, very little, and it was not much of a problem for many other AOSP distributions who never had any provided to begin with.
>Without complete kernel commit history, how do you ensure that monthly security patches don't inadvertently break hardware functionality? The HowToGeek article specifically mentions this as a major concern for maintaining feature parity.
Google is using the same security patches on the stock OS, so this isn't an issue. It's not like Google is no longer using any of their AOSP code.
All code changes per AOSP version are now all pushed at once instead of commits in-between them. It doesn't mean much in the grand scheme of things since we can just diff check everything. The stock OS is still just AOSP with their proprietary software and apps bundled. Serious doubt this would cause problems even if they aren't officially supporting Pixels on AOSP.
We also use a different kernel image to AOSP, ours is far more up-to-date and patched. When we've found compatibility bugs, we fix it. We've worked like that for a long time.
>Regarding automation improvements—are you building tooling to automatically extract and reverse engineer the missing device tree configurations from Google's proprietary builds each month? This would represent a significant ongoing maintenance burden that wasn't present before.
Yes as per above answers. We had used this approach for many years already because it allowed us to do certain processes much faster AND that is how we backported drivers or other of-interest fixes only available in stock OS beta builds.
We already needed a lot of automated tooling for device support before this. If we knew the device trees were going to be removed in Android 16, we could have prepared for it instead of it taking 20 days to port to Android 16. It would have gone much smoother.
As for getting patches each month while Google has stopped releasing them to move a quarterly release cycle, we have access to a partner to get monthly code and we use GPL code requests to Google to get the rest.
The above has disrupted other AOSP distributions far more. Many of them haven't issued a complete security patch since June. CalyxOS is still on 2025-06-01 patch level. To my knowledge LineageOS hasn't moved to Android 16 yet and Pixels only provide driver/firmware updates for Android 16, so they are unmatched.
>What's your contingency if Google's shift to Cuttlefish as the primary AOSP reference eventually leads to reduced Pixel-specific support in future Android versions?
It is already. AOSP no longer supports Pixels officially.
>Can you quantify the development time impact? While you've maintained Android 16 support, how much additional development time per release cycle are you now allocating to reverse engineering that was previously unnecessary?
In terms of standard updates, very little, often none. We only ever did reverse engineering to get something from a proprietary Beta build on the Stock OS. We already have the port complete and AOSP is still open source. We may need to take additional preparation on major version upgrades though, and we likely can't push them immediately like we used to. It shouldn't take as long as the transition to 16 though.
