They stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP. They also stopped pushing AOSP releases specific to Pixels which is why AOSP now only gets yearly releases, QPR2 releases and security backports to both of those. Other OEMs use the yearly and theoretically also the QPR2 releases. Both the yearly and QPR2 releases get monthly security backports. Since they dropped Pixel support from AOSP, they don't push the releases not shipped by other OEMs anymore.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.
Well, it is only a matter of luck and internal politics, that Linux kernel hasn't yet been replaced by Zircon on AOSP, which is I guess the only GPL piece that is left from the original 1.0 version.
> They need to do it in a reasonable amount of time.
If they did that for years within hours and if we look at the tools available today, I would expect that "reasonable" equates to how they provided it prior: fast.
They did it for many years with 0 delay because they pushed the tags to AOSP. It was moved to Google Drive with a Google Forms setup to request access with manual fulfillment of the request. It was deliberately done to make it into a hassle. The delays are by design through making it a manual system regardless of how much of a delay was intended as part of this change. They could be automatically handling the requests especially from people who have already been given sources for a product. They're deliberately making it take substantially more work on their end to make it into more of a hassle.
I was involved in one of the communities involved in the Block Sidewalk efforts in Toronto Canada, which prevented Sidewalk Labs from moving forward on a multi-billion dollar project to redevelop a chunk of downtown Toronto.
I was at the Data Power 2017 conference in Ottawa where I shared with people (who would become key Block Sidewalk organizers) the clues I had, that Google was about to bid on the as-yet-unknown land development opportunity, closing later that month.
I had previously been in collaboration with secure ROM developers hitting their first adversarial efforts to thwart use of Android for alt app markets. I know that Google's public story of Android openness (which drove people trusting them to build a city platform) was bullshit, and I made sure many many of the key activists and public servants knew it.
While I can't know exactly how my specific actions affected things, I would guarantee that Google's adversarial positions and failed stewardship have already contributed to them losing real opportunities.
A reasonable interpretation would be that they had a previous process that eliminated delivery latency and required no manual manpower for responding, so changing it has been done to induce artificial friction, against the intent of the license.
> They'll sell far fewer Pixels because of these overall changes.
They don't even sell Pixels internationally. Can't tell you how glad I am you're moving to Motorola. I'm really looking forward to having a Motorola GrapheneOS phone!!
- How hard is it for manufacturers to include the option Android/Graphene just like they have memory and storage options?
- Could this be a point where GrapheneOS disconnects from Android and become an independent OS?
> They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels.
Which brand and model is currently best supported by GrapheneOS, if I want to buy an Android device to run GrapheneOS on?
Only Pixels, most other device are ironically locked down a lot more (not allowing custom keys for verified boot) or lack modern security features (like hardware security modules).
So you'll have to wait for the mentioned Motorola Flagship
Well, it's as you wrote: they are making the source available, albeit in a very inconvenient way, and because there is no time limit specified, they're complying with the letter of the GPL (although not with its spirit), so you can't even realistically sue them. And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible, so I don't think they'll see a sales impact from it...
Which is not to say that I'm on Google's side, this is absolutely a dick move from them, and they wouldn't have done it 20 or even 10 years ago, but today's Google is definitely no longer the "don't be evil" company.
Not in the preferred form for modification expected by the build system and not in a reasonable amount of time. It's artificially delayed with no legitimate reason.
> And the number of people who buy new Pixels to immediately install GrapheneOS on them is (no offense) negligible
Nearly all of our current users bought a device specifically to install GrapheneOS. Our current userbase is around 500k and many of those are users had one or more earlier devices with GrapheneOS. Our userbase is rapidly growing. Look up how many Pixels are actually sold in a year. It's not negligible at all.
There are also many large companies wanting GrapheneOS devices with official support from the OEM.
Sorry, I stand corrected: Despite owning a Pixel 9 Pro myself, I didn't realize Google's Android phones market share was so tiny (1.1%! according to https://www.appbrain.com/stats/top-manufacturers). In that case, of course, the number of Pixels bought because of GrapheneOS could be a significant fraction.
That’s 1.1% of ~1.1-1.2B Android phones sold per year. I dont’t know how long the average GrapheneOS user holds on to their device, but if 25% of them per year buy a new phone (rather than upcycling a used one or using their previous phone another year), that would amount to about 1% of Google’s annual sales at best.
No, I'm not (a lawyer might recommend to sue, hoping for a big payout, even if the chances of it happening are small?). I looked at the GPL text, and what Google is doing is really pushing the "If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means", but others have done the same or worse, and so far fines that are really painful for a large company are few and far between...
The main thing here is it used to work faster and google surely can deliver data fast - but now they intentionally changed procedure to make it slower. That could be fined for going against the spirit of the licence contract.
These changes directly led to our Motorola partnership. One of their security people reached out to us after seeing our posts about this with the launch of Android 16. We haven't talked about it much since then since we adapted to it during the several weeks it delayed our Android 16 port. We then continued adapting to it and have fully worked around it. It was an ongoing problem but not a new one and we had accepted we had to deal with it as the new normal.
They were previously responding to our kernel source requests within a day. It was often done without hours. Despite the archaic system, this part wasn't that bad. Recently, they've been taking weeks or longer to get back to us for the requests which is ridiculous. It's the direct result of purposely adding a lot of friction with manual handling of the requests even if the delays weren't directly planned by management.
Weeks or months of delay is not reasonable for one of the largest tech companies in the world. GPL doesn't set a standard time limit for providing the sources, but that doesn't mean they can delay it indefinitely. They need to do it in a reasonable amount of time. What's reasonable for one of the largest tech companies in the world in 2026 with current technology is not the same as what was reasonable 30 years ago. Google chose to come up with a archaic way of distributing the sources involving someone manually going through a list and sharing Google Drive access. It's a deliberate way of making it painful. If they can't keep up with it and it gets delayed for weeks or months then they're not complying with the GPL by not providing it in a reasonable amount of time. Law is not code and a time limit not being explicitly written down doesn't mean there isn't a limit to what's reasonable for compliance.
They'll sell far fewer Pixels because of these overall changes. It pushes GrapheneOS and other projects towards other devices instead. For us, Pixels are being used due to security rather than ease of supporting them. It's now a lot harder to deal with Pixels than it would be for many other devices but they're currently still the most secure option. We're working on changing that and have a lot less reason to contribute to improving Pixels. We helped them fix serious security weaknesses for Pixels including vulnerabilities being exploited in the wild by forensic data extraction companies. Pixel security with the stock OS would be worse without GrapheneOS.