@GrapheneOS 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"? And Google's move towards using a virtual device, codenamed "Cuttlefish," as its primary reference target for AOSP development - "intended to make AOSP development more hardware-agnostic"? I think we're all interested in what your plans are for Cuttlefish. But more specifically: 1. 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. 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." 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 versions. 2. 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. 3. 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. 4. 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? This appears to be part of Google's strategy to make AOSP "hardware-agnostic." 5. 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? The broader privacy community deserves transparency about whether this represents a sustainable long-term approach or if we should be preparing for reduced custom ROM viability on future Pixel generations.