Wait, did Google really announce the plan to mash its two OSes together? Pretty much. Android boss Sameer Samat recently disclosed that Google will “combine ChromeOS and Android into a single platform.” Twenty‑four hours (after what we suspect was much digital teeth mashing) later, he clarified that ChromeOS will simply run on top of Android internals. Spin aside, the code bases are doing a monster mash.
Officially, Google says it’s doing this to ship Gemini / AI features faster; consolidate kernels, frameworks, and update plumbing; and create a more consistent experience from kiosk to phone.
The Spain business publication Cinco Días, reports that while Google hasn’t committed to a release schedule, “first developments will arrive at the end of 2025 and new devices, possibly from the Pixel line, will accompany this transition in 2026”. Translation for the dedicated device ecosystem: right around the time your next device roadmap locks.
Android 16’s Vanishing Pixel Bits
Arguably, there’s another byproduct of this plan having an immediate impact. Android 16 landed with Pixel device trees, driver blobs, and full kernel history scrubbed from AOSP. In response, here's a statement from a Google representative: “AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google..” One way to interpret this is Chromebooks/Android PCs don’t need Pixel blueprints — and neither should the Android ecosystem.
Google just sent up a clear signal: Going forward, OEMs and ODMs will be expected to ship with the Generic Kernel Image (GKI). GKI is the most straightforward path to Project Treble compliance, since it standardizes the kernel ABI (the Application Binary Interface, which defines how compiled code talks to the kernel at the binary level) and cleanly separates vendor modules from the OS framework. For some silicon vendors, this means the old habit of maintaining deep kernel forks is on borrowed time — upstreaming drivers is now the safest way to ensure compatibility with future Android and ChromeOS releases.
Independent software vendors (ISVs) should start preparing now. Test your apps against a Cuttlefish Generic System Image (GSI) — if it breaks there, it’s likely to break on 2026 hardware. This change isn’t theoretical; while major OEMs have largely moved to GKI on recent devices, many specialized and legacy builds still aren’t there yet. The shift will close that gap fast.
This AOSP pruning demonstrates Google is embarking on welding these two OS hulls into one mega dreadnought.
Why Anyone in the Dedicated‑Device Trenches Should Care…
Let’s tick through the different parts of the end-to-end dedicated device ecosystem and take a look at the potential impact of this OS mashup.
Fleet owners & IT Ops (retail, QSR, healthcare, warehouse, HMI): For now, the Android and ChromeOS worlds remain separate. If you have ChromeOS devices in your fleet, map your ChromeOS-specific policies now to be ready if they jump over to AMAPI sometime in 2026. Starting in 2026 and extending into 2028, one hardened OS baseline could unify the Android and ChromeOS worlds, enabling flexibility to run from Tablet to Chromebook. The combination of Android’s modular updates with ChromeOS verified boot could provide a stronger security posture. A key question to get answered is: “Will Google extend ChromeOS’s 10-year update promise to this new mash up?”
OEMs and ODMs: The impact is more immediate — will 2026 designs need Android CTS and Chromebook PLT? But from 2026 to 2028, there may be the benefit that one BSP can now cover designs from tablets, POS, kiosks, to even clamshell devices (nee Chromebook-like). This translates into less NRE per SKU, and the potential for faster and more engineering-efficient AI enablement. The near-term product planning implication for vertical market device makers regards targeting more traditional PC-like form factors opened up by this mash up, with the implications of investing in desktop-mode window managers, supporting things like trackpads, and addressing thermal design considerations for clamshell designs. If you haven’t gotten an NDA briefing from Google on this, now is the time to ask for it.
Silicon vendors: The Arm camp (think MediaTek and Qualcomm) is sitting pretty. The x86 suppliers have choices to make in light of these changes. Where possible, run a kernel audit against GKI 6.9+ and upstream drivers. Looking toward 2026 – 2028, it’s clear Google is making machine learning acceleration a core building block of the targeted combined OS. Think: NPU firmware reused from phones to laptops. That’s a decision point for silicon vendors, most of whom have invested in proprietary edge AI toolchains. The Android mainline train waits for no one — merge, or be merged.
ISVs and Enterprise Developers: For now, nothing changes — APK is still the target for Android, PWA for ChromeOS. From 2026 to 2028, the game shifts with the promise of write once, run anywhere. Android 16’s desktop mode brings proper windowing — and it’s coming. Try your app in Android 16 desktop mode and watch for layout bugs. Spin up the Cuttlefish GSI and smoke test your app. Test adaptive layouts and pointer input to see how your app behaves, and whether it fits into this new world.
Lastly, what does it mean for MDM? Part of the mash-up is two different device management business models for Google. Google charges to enable basic device management on ChromeOS, adding a third-party MDM provider stack on top of that. In parallel, Google has been pushing AMAPI for GMS devices, where Google controls the agent and MDMs utilize a Cloud interface to reach the GMS devices, creating a bottleneck where customers are dependent on Google for supporting edge use cases frequently encountered in the dedicated device market. That’s why Esper has stuck with providing our own agent for Android, compounded by AMAPI not being available for AOSP.
Note: Esper currently does not support ChromeOS device management. We have remained very focused on Android based on market feedback, while adding iOS and Linux to our control plane. Perhaps that was a good decision based on how things may play out. Will AMAPI absorb Chrome policies? Will Google extend the baseline charge for device management to Android as well, using AMAPI as the mechanism? We shall see. We will be ready for what comes next.
Taking a Step Back
If all this sounds vaguely familiar, we’ve seen this before. Remember Project Andromeda from about a decade ago? Yes, Google tried to merge Android and ChromeOS and ultimately gave up bringing this to market. Is there a risk that this happens again? Yes. But the situation is different in that Android desktop mode already ships, and Gemini AI needs laptop‑class silicon. We’ll likely see a much more pragmatic approach to ChromeOS via a Chrome‑flavored UX skin riding Android plumbing. There is the outstanding question regarding ChromeOS’s 10-year support. With Samsung bantering 7 years for Android, Google will need to at least match that for these “Android PCs.” I wait with baited breath.
Android CTS-Desktop is shaping up to be the new end-game boss. For GMS-licensed device makers, that means beating CTS (the core Android compliance test), GTS (Google Mobile Services integration test), and other xTS test suites — all rolled into one monster challenge. If you’ve never heard of these, it’s because they only matter if you build and ship Google-certified hardware. Picture your current CTS and GTS runs, then throw in Chromebook-class hardware checks… all in one go. That’s more time, more gear, and more budget for xTS — great for the cert labs, not so great for your P&L.
If you are not on the inside, how do you track this? The Android 17 developer preview cycle will be a must-watch and will progress further with the Android 18 developer preview. Include in your build targets the latest Cuttlefish and GSI updates to see if you get sudden failures as they progress.
Here We Go…
Google is plopping ChromeOS’s friendly desktop shell onto Android’s undercarriage while quietly yanking Pixel hardware code from the public repo. For dedicated‑device players, that promises one hardened, update‑friendly platform powering kiosks, tablets, menu boards, even medical carts. It won’t land overnight, and Google still owes the industry answers on lifecycle guarantees and admin tooling. But start aligning roadmaps now, and you might finally kill the “but it works on the phone, why not the Chromebook?” conversation for good.
And wouldn’t that be a beautiful, potentially irreverent thing?
FAQ
Keep Exploring
-25.svg){kind=small}
