A long Q&A with three Google engineers on Android Q and Project Mainline, which aims to let Google and OEMs only update certain parts of the OS at a time
Ars interviews Android Engineers Dave Burke, Iliyan Malchev, and Anwar Ghuloum. — As has become tradition for Ars at Google I/O … Tweets: @topjohnwu , @ronamadeo , and @arstechnica Tweets: John Wu / @topjohnwu : This article written by @RonAmadeo contains tons of interesting stuff regarding Q. One that I wanted to point out is that ALL devices launching with Q will be forced to use dynamic logical partitions. RIP system rw, and dunno how custom ROMs will work. https://arstechnica.com/... Ron Amadeo / @ronamadeo : ICYMI my super fun interview with @davey_burke, @imalchev, and Anwar Ghuloum went up today. There's lots of insightful Android Q tidbits in there. https://arstechnica.com/... @arstechnica : Getting philosophical in this year's big @RonAmadeo #Android engineer Q&A: “What's the right thing for the majority of users? Is simple better?” https://arstechnica.com/...
Context & Ripple Effects
The interview extends a line Ars has been tracing since 2017, when Google's Project Treble split vendor implementations from the framework to speed OS upgrades. Project Mainline takes the same logic further: instead of just isolating layers, Google and OEMs can now push updates to individual system components without shipping a whole new Android version — a shift previewed in Ars's earlier first look at Android Q.
The stakes show up in engineer Dave Burke's own community reaction: John Wu, the Magisk developer, flagged that every device launching with Q must use dynamic logical partitions, ending the writable system partition that custom ROMs depend on. The same engineers reappear a year later discussing the Generic Kernel Image, confirming modularization as a sustained architectural program rather than a one-off feature.
First-order effects
- Google and OEMs gain the ability to patch specific Android components — security-critical code among them — through Mainline modules, decoupling those fixes from the full OS upgrade cycle that historically waited on OEM and carrier testing.
- Custom ROM developers lose their standard attack surface: with dynamic logical partitions mandatory on all Q-launch devices, the read-write system partition disappears, forcing the modding community onto new techniques like system-as-root modifications.
Second-order effects
- OEMs' control over the software stack narrows wherever Google ships functionality as an updatable module, shifting differentiation toward hardware and skins while Google assumes responsibility — and blame — for more of the update pipeline.
- Security-update latency, long a differentiator between Pixel and non-Pixel devices, compresses across the ecosystem as critical components update through the Play infrastructure rather than waiting for full image rollouts.
Third-order effects
- If the Treble-to-Mainline-to-GKI sequence holds, Android's architecture consolidates around Google-controlled, individually updatable components — trading the openness that enabled custom ROMs for a faster, more centrally managed platform.
- The pattern points toward regulation-relevant territory: as Google takes direct update authority over more of the OS on third-party hardware, questions about who controls Android devices sharpen for OEMs and antitrust watchers alike.
The trend: Android is being rebuilt from a monolithic OS into a set of Google-updatable modules, with each release since Treble transferring more of the stack under Google's direct control.