Android is on the laptop now.
The hardened one is a hardware list away.

If you want something other than Windows, macOS or ChromeOS on a laptop today, you run a Linux distribution, where an application installed as a traditional package has your access to your files, and a Flatpak gets what its own manifest asks for. On phones, GrapheneOS has shown what a hardened system looks like when it is the whole system: every app in its own sandbox, verified boot with rollback protection, attestation from a second device, memory tagging on by default, updates that install themselves and cannot be rolled backward. This autumn Google brought Android to the laptop, with five Googlebooks from five manufacturers “built on the Android technology stack”. So the obvious question: could GrapheneOS be the hardened laptop, the way it is the hardened phone, if the right hardware existed. That is the case. The answer split in two, and the two halves are not the same size.

What Google actually shipped

Googlebook went on pre-order on 21 September 2026 and ships in October from 899 dollars. Google’s own line is “Built on the Android technology stack and paired with desktop foundations from ChromeOS”. Five laptops from Acer, ASUS, Dell, HP and Lenovo, on Intel Core Ultra Series 3 and Snapdragon X Elite; per press, three Intel and two Snapdragon. Google promises “regular feature drops and updates for up to 10 years”, a “Google Titan hardware root of trust”, and “a first for the laptop category: a Level 5 security-certified pKVM hypervisor” running “an isolated Linux environment with a full terminal access”. Press coverage calls the app drawer “basically the Pixel Launcher” and describes quick settings and notifications, “nearly identical in design to what you’d find on Pixel”, at the top right.

Three things Google did not say. It did not name the Android version; a press photo of the quick settings panel shows a build string beginning with 17. It did not say whether any of Googlebook OS will be published to AOSP. And it did not say ChromeOS is finished; its own support page keeps ChromeOS devices patched “through mid-2034”.

What sits on top of the platform is Google’s: its own Chrome build with extensions, and the Gemini layer called Magic Pointer, Rambler and Create My Widget. The Gemini features have no public source that I found; Chromium does carry a public build switch for desktop Android, and GrapheneOS’s Vanadium browser does not set it. GrapheneOS ships no Google services by default, so none of that layer would come with it. What would come is AOSP’s desktop windowing, which sits in code GrapheneOS already carries; how much of Googlebook’s own desktop is that code, and how much the “desktop foundations from ChromeOS”, Google has not said.

One line in Google’s material does not add up yet. Google says Googlebook features the certified pKVM hypervisor, and some Googlebooks run on Intel. AOSP’s own documentation says the Android Virtualization Framework is “supported only on ARM64 devices”, and that it “is supported for testing purposes on x86_64 (non-protected virtual machines)”. The certificate is real, SESIP Level 5 from TrustCB for “pKVM Hypervisor Version 14-6.1”, and it names no chip. How that lands on an Intel laptop is a question for Google.

The list is longer than a chip

My own premise, before the research, was that a GrapheneOS laptop “probably just needs a security chip and an arm processor”. It does not. GrapheneOS publishes a list of 26 requirements for any future device and calls it non exhaustive. About ten of them are properties of the processor and the secure element, and even those only count if the firmware enables them, as the project found on the Pixel 11 in September, where the silicon keeps at least bare minimum memory tagging and the firmware tells the kernel to switch it off. Most of the rest are firmware behaviour, driver and kernel support, isolated radios and storage, and what the manufacturer commits to: monthly patches within a week, new AOSP releases within months, five years of device support for phones and seven for tablets, and a bootloader that takes the owner’s own verified boot key and shows its fingerprint.

Against that list, a Snapdragon Googlebook is not shown to meet two things, and most of the rest is unpublished. Qualcomm documents the Snapdragon X Elite as “ARMv8.7-A compliant” and does not mention memory tagging, and Android’s own memory tagging page lists only Pixels as known to support it. And Google’s chip is “Titan C”, the Chromebook part. Google’s own sheet describes it guarding keys and slowing brute force in ChromeOS terms, and says its firmware updates “are pushed out by Google”. Nothing Google publishes says it offers StrongBox, Weaver or owner gated updates to Android, and on Weaver the project leaves no room: “GrapheneOS only officially supports devices with Weaver.” For the Intel models I found no shipped x86 memory tagging at all: Intel and AMD announced a specification for it, ChkTag, in 2025, and no Core Ultra document says it is implemented.

So no laptop that runs Android meets the list today, and the only laptops the project says meet similar requirements are Apple’s. The parts that would meet it are announced, in the project’s own words, for its 2027 Motorola phone: a flagship Snapdragon with memory tagging and “a very high quality dedicated secure element rather than relying on the Snapdragon SPU”, which GrapheneOS says “will meet or exceed” its requirements. The same silicon and the same secure element in a laptop or a desktop computer is a thing a partner could build, and no GrapheneOS statement announces it.

The machine

Taken literally, the list describes most of a machine. An arm64 processor with memory tagging implemented in silicon and enabled in the firmware, pointer authentication, branch target identification, PXN and PAN, and virtualization that pKVM can use for both protected and ordinary virtual machines. A discrete secure element that provides StrongBox with attestation, Weaver, and owner gated firmware updates; the Titan in a Pixel is the reference, “Titan M2/M3” in the project’s words. Firmware with two slots and automatic rollback, verified boot with rollback protection for firmware and OS, a bootloader that takes the owner’s key and shows its fingerprint, memory zeroed in firmware boot modes, debug ports locked. A USB controller that can be cut in hardware, inline storage encryption with wrapped keys, isolated radios, GPU, storage and media blocks. A manufacturer that ships a kernel on a supported GKI branch, monthly device patches within a week, new AOSP releases within months, and at least five years of device support, the phone figure, since the list names none for laptops, and that lets the project use all of it. And the image on it: the project’s FAQ hopes for partner devices “ideally shipping with GrapheneOS”.

There are two ways that machine gets built, and neither is announced. Google already makes devices that meet the list: the Pixel 10, Tensor G5 paired with a Titan secure element, is on GrapheneOS’s recommended list. A Google laptop built the way that phone is built would be the first candidate; Google instead built Googlebook on Intel and Snapdragon with the Chromebook’s Titan C. The other way is GrapheneOS’s own: “We plan to partner with OEMs to have devices produced meeting all our requirements”, and the project already has a long term partner in Motorola, building a phone to that list for 2027 on a flagship Snapdragon with memory tagging and a dedicated secure element.

The shell is already upstream

Desktop windowing is not something Google built for Googlebook. The Android Open Source Project now ships desktop windowing: a taskbar with pinned and running apps, freeform windows with a caption bar on each, snapping to the edges, keyboard shortcuts and a touchpad stack. Android 16 shipped it and Android 17 extends it.

The code sits in three repositories, and each path is on the android-17.0.0_r1 tag on Google’s source host and on GrapheneOS’s fork of it. The window manager and the caption bars are in frameworks/base, under libs/WindowManager/Shell, in packages called desktopmode and windowdecor. The taskbar is in Launcher3. The touchpad gesture mapper is in frameworks/native. The keyboard shortcut helper is in SystemUI, which also lives inside frameworks/base. Most of the window manager’s desktop flags sit in one file, lse_desktop_experience.aconfig, 148 of them on the tag, the same file on the fork, and two bugfix flags refer to a laptop directly: one to desktop-first mode “triggered by laptop state”, the other to a “close lid feature”.

GrapheneOS forks all three repositories already. It maintains its changes “as a clean patch set on top of the latest stable release of AOSP” and re-ports them onto each new AOSP release, which is the constraint the Bone case was built around. The desktop code sits underneath that patch set and arrives with each rebase.

The project has also said what it wants. In November 2024: “If it runs Android and meets our hardware requirements [...], it can be supported and we would want to support it. That doesn’t mean it would be a particular good experience unless everything required for the form factor is available in the Android Open Source Project.” In March 2025: “we want to eventually have support for GrapheneOS on laptops. There’s currently no laptop close to meeting the hardware requirements we cover at [the FAQ].” In July 2026: “It will likely eventually run on a small number of laptops meeting the hardware security requirements.”

So the shell of a GrapheneOS desktop OS is upstream, it lands in repositories the project already carries, and the project wants the laptop. What is missing is the machine and the device support code that comes with it.

So I extended Bone to the screen that has room

If the shell’s structure is inherited, then inventing a new one would be dishonest, and expensive in exactly the way the first case priced. So the structure here is AOSP’s: the taskbar, the caption bar on every window, freeform windows that snap, a list detail Settings, the layout Google documents for wide windows. The visual system is Bone, the interface from the first case, carried to a 1440 by 900 screen. Bone’s three positions carry unchanged: a fixed palette that never comes from the wallpaper, one typeface across every register with mono only where a value is a fact, and light as a deliberate ground. And Bone’s elements carry too: the capability strip, the smartspace line with the patch date, and a consequence line under every control. On a desktop they get new places and more room.

The capability strip moves into the caption bar. Android’s desktop caption bar is system chrome: the system draws the window controls, and an app may fill the rest of the bar with its own header, as Chrome does with its tabs. Bone reserves a region beside the window controls for the app’s capabilities, shown on each of its windows: network on or off, sensors, live microphone or camera, the storage scope it has been granted. Reserving it is a Shell patch, and an app with a custom header gives up that width. Qubes marks each window with a border in its domain’s colour that the app cannot forge. macOS shows a dot in the menu bar when any app is using the microphone or camera. Neither shows, per window, what that app can reach, and in the Windows, ChromeOS and GNOME pages I read nothing does; the closest thing is a third party network monitor.

The smartspace line sits where the clock is. The patch date and the age of the last update sit beside the clock on the lock screen, in the status bar and at the top of quick settings. They are the updater’s own report, not proof, and a compromised OS could draw them too. What is deliberately not there is any claim the machine makes about its own integrity. The first case put a “Verified boot passed” line in that same smartspace and priced it; on reflection that line is self reported, and the laptop does not carry it. A compromised OS can draw it as easily as an honest one, which is why GrapheneOS’s Auditor verifies a device from a second, paired one. So the quick settings header offers “Verify with Auditor” as an action and claims nothing about the machine’s own state.

The consequence line gets a full sentence. A two pane Settings at 1440 wide has room to say what a control protects against and what stops working, in plain words. Windows Security names its toggles by capability and leaves the threat unsaid; macOS’s Lockdown Mode names its threat once, “a highly sophisticated cyberattack”, for a single switch, and lists what it limits on its support page, feature by feature, not control by control.

No new typeface beyond Geist, which Bone’s file is built in and the first case priced as a font overlay; AOSP’s own monospace family is Droid Sans Mono, and whether an overlay can replace it I did not research or price. No theme argument reopened. No score, ring, shield, padlock or tick. And no new shell. Taskbar, caption bar and window behaviour follow AOSP’s desktop windowing as Google documents it; the quick settings panel follows the one photographed on a Googlebook. Google publishes a minimum window size and its breakpoints, and no caption bar or taskbar height that I found, so those are the case’s own.

What it would take to ship

The shell costs the normal re-port, plus a device overlay for the laptop that sets config_isDesktopModeSupported and its siblings. Bone’s palette and typeface are the overlay packages the first case priced, with the same SystemUI decision to stop the wallpaper colour path, so not free, but not a fork either. The consequence lines are strings and preference XML in files the project already owns, with a little Kotlin where a control moves.

The expensive part is the patches: the reserved caption zone in the Shell’s windowdecor package, the smartspace line in SystemUI and Bone’s card geometry on the desktop, all re-ported with each release. That is the part I would drop first. “Verify with Auditor” also needs Auditor to support the model, which today means Pixel 6 to 10a. A desktop class browser is a build switch, is_desktop_android, that Vanadium does not set, and I did not price what follows from setting it.

Then there is the laptop itself: a device tree, a kernel, firmware, vendor code, a secure element, and a manufacturer prepared to commit to the list. No amount of interface work moves that.

Reasons to say no

No Android laptop meets the list, and the project has said so more plainly than I have. This is a design for a machine with no date.

The project’s own laptop recommendation today is a MacBook: “Macbooks remain the serious security option for a laptop.” The design does not argue with it.

Linux desktops give things this cannot: root, any window manager, native packages, and the whole desktop software catalogue running natively rather than in a virtual machine, which GrapheneOS today offers only on Tensor Pixels. GrapheneOS describes itself as a Linux distribution and calls the kernel one of its biggest security problems. It is a different security model on the same kernel, and a person who needs root should not be sold it.

A caption strip that reports live sensor use is instrumentation as much as layout. Surfacing it per window in system chrome has a cost the case does not measure. And an app with a custom header can paint a lookalike strip beside the reserved zone; Qubes’ border frames the whole window, which is a stronger position than a zone in the caption. I have not resolved that, and it is the first thing to test.

And a maintainer could accept every fact here and still decline the design. That would be coherent.

Why now

Laptops with a Google security chip and an Android desktop are now a product line from five manufacturers, two of them on ARM per press. The requirements list GrapheneOS publishes has something concrete to be measured against. And the desktop shell a laptop needs is already in AOSP, in repositories GrapheneOS already carries.

The whole file is open.

The finding, Googlebook, the hardware list, the Linux comparison, the approach, twenty four Bone screens, how it ships, the Bone library and the foundations.

Open the Figma file →