GrapheneOS used to add support for a new Pixel in under 24 hours. The Pixel 11 could take months. That reversal explains more about the project's Motorola partnership than the prospect of a privacy-focused flip phone: an Android manufacturer is assigning engineers to port and maintain GrapheneOS, while Google's own phones have become harder for the project to support. For developers who maintain an alternate Android distribution, access to hardware is only the start. Timely source, usable build configuration and a route for fixing firmware can decide whether a device is practical at all.
The first Motorola phone with official GrapheneOS support is planned for 2027 and will be a conventional flagship. The project then intends to support successors to the Motorola Razr Fold and Razr Ultra, including its first vertically folding phone, according to a GrapheneOS development thread. Current 2026 models will not qualify. GrapheneOS says they lack mature hardware memory tagging, adequate secure-element integration and other features expected in next year's hardware.
The Verge first reported the expanded device plan, including continued work toward Pixel 11 support. The dates remain targets rather than a product announcement. GrapheneOS has not named the exact 2027 Motorola models, a release day or the countries where they will be sold. It has also said no decision has been made about whether any phone will ship with GrapheneOS preinstalled. Users should still be able to buy regular retail variants and install the operating system themselves.
The porting burden moved
Until the Pixel 9a generation, Pixels were Android Open Source Project reference devices. AOSP included kernel-driver sources and much of the device support code needed to build Android for them. GrapheneOS still had to assemble its own production build setup and make its security features work with each phone, but it started from an official device tree. The project says Android 16 removed Pixel support from AOSP, forcing its developers to reconstruct work that previously arrived upstream.
The new process is much less convenient. GrapheneOS says developers must request Pixel kernel-driver sources through a Google form. Google then supplies tarballs for a specific tag, with code from dozens of Git repositories combined and stripped of commit history. The project says the package is too large for one GitHub repository and has to be split even for GitLab. Google no longer provides the AOSP setup for building Pixel images or the userspace driver and service code that accompanied earlier devices.
That is why the Pixel 11 estimate stretches from hours to possible months. The delay is GrapheneOS's own forecast, not a confirmed release schedule. The project still plans to support the Pixel 11 series, including the Pixel 11 Pro Fold. Its complaint is about the engineering path: a phone sold by Android's steward may now require more reverse integration work than hardware from an OEM actively preparing for an alternate operating system.
Motorola is taking the opposite approach. GrapheneOS says Motorola engineers will do a large share of the initial port, provide firmware and drivers in a usable form, maintain the work, and create a channel for bugs that need attention from Motorola or Qualcomm. The foundation says it is not receiving money from Motorola and would rather see the company assign more engineers. This is a concrete division of labor, though the public thread does not define staffing levels or contractual obligations.
Why the 2026 phones fail the test
GrapheneOS does not grant official support just because Android boots. Its published device requirements include prompt monthly security patches, years of full device-code updates, verified boot with rollback protection, hardware memory tagging, isolated radios and hardware-backed key storage. The project also requires alternate operating systems to retain the phone's hardware security functions. A generic system image cannot meet that bar because GrapheneOS depends on kernel changes and device-specific hardening.
Hardware memory tagging, usually called MTE, is one of the missing pieces in Motorola's current flagships. MTE lets the processor associate tags with memory allocations and check accesses against them, helping catch classes of memory corruption that attackers use in exploits. GrapheneOS says it deploys the feature across the kernel and base userspace on supported hardware, with exceptions when incompatible code produces invalid accesses. The project expects the next Snapdragon generation to have more mature MTE support than current Qualcomm parts.
The secure element presents a different problem. It protects sensitive operations such as hardware-backed keys and throttled credential checks outside the main operating system. GrapheneOS credits Google's Titan M2 and M3 with giving Pixels an advantage here. Motorola's 2027 hardware is expected to include a capable secure element with the current Android rate-limiting design, but GrapheneOS has not claimed that it will match Titan in every respect. The project says matching Titan will be harder than improving resistance to remote attacks.
Software longevity is part of the hardware decision too. GrapheneOS says the Motorola devices it supports will receive seven years of proper updates and start on the Linux 6.18 long-term-support kernel, with a possible move to a newer branch later. Cheaper Motorola phones remain a later goal because lower-tier Qualcomm chips have weaker security features and Motorola would have to buy longer vendor support for them. In an earlier project post, GrapheneOS warned that the initial flagships would cost more than Pixels.
Those conditions rule out the Motorola Signature, Razr Fold and Razr Ultra sold in 2026. GrapheneOS describes them as previews of the product lines it expects to support, not compatible devices awaiting an installer. Buying one now on the assumption that support will arrive later would be a mistake. The planned ports apply to a subset of next-generation models whose hardware and update commitments still have to meet the project's requirements.
A foldable expands the test matrix
GrapheneOS already supports Google's book-style Pixel Fold, Pixel 9 Pro Fold and Pixel 10 Pro Fold. A successor to the Razr Fold would therefore add another manufacturer without introducing an entirely new shape. The Razr Ultra successor is different. Its vertical fold creates a compact outer mode and a second display arrangement that GrapheneOS has never officially shipped. Display state, rotation, camera behavior, power management and updates all have to work without weakening the locked boot chain.
The project plans to begin with a non-folding Motorola flagship before moving to both foldable lines. That order gives the teams a simpler device on which to establish the build, update and security pipeline. Because the foldables are expected to share similar core hardware with the slab phone, later ports may reuse low-level work. GrapheneOS has not promised that each model will arrive at the same time, so the 2027 target should not be read as a simultaneous three-phone launch.
There is also a practical distribution question. Motorola sold its 2026 Fold and Ultra in some markets where the Signature was absent, and next year's availability may differ again. GrapheneOS users often import Pixels, but imported phones can run into carrier allowlists or missing radio bands. The project's FAQ separately warns that carrier-sold devices may have locked bootloaders, which prevents installation. A supported model name will therefore be only one part of the buying decision; the exact regional variant and unlock policy will matter.
Pixels remain supported, with a warning attached
The Motorola work does not mean GrapheneOS is abandoning Google hardware. Its current support list remains entirely Pixel-based, from the Pixel 6 generation through the Pixel 10 family, and the project explicitly plans Pixel 11 builds. Existing users still receive official releases and updates. Motorola support is an expansion of the hardware base and a hedge against one increasingly expensive maintenance path.
That distinction matters because GrapheneOS's Pixel comments are claims from the project doing the porting. Google has not provided a response in the cited reporting, and the public material does not establish why Pixel device support left AOSP. The observable change is narrower: GrapheneOS says the source and build inputs it relied on are no longer delivered in the old form, and its estimated integration time has increased sharply.
For alternate Android projects, the Motorola arrangement offers a useful test of OEM cooperation. A long update promise has limited value if firmware arrives late, driver code cannot be built in the required form or security bugs have no escalation path. Motorola is promising engineering participation through the partnership; GrapheneOS is setting measurable entry conditions. The first proof will be a production build on retail hardware, followed by monthly updates that arrive without special pleading.
Watch the ordinary flagship first. Its release will show whether the 2027 Snapdragon platform delivers working MTE, whether the secure-element integration meets GrapheneOS's stated bar and whether Motorola sustains the port after launch. Pixel 11 timing will provide the comparison. If Motorola support lands faster while preserving locked-boot security and seven years of updates, the foldable will be the eye-catching device, but the durable result will be a better maintenance relationship for an open-source operating system.