upvote
Yes, and we do mirror their source code on GitLab. We put the upstream 17 code in the 17-base branch and our code on top of it in the 17 branch:

https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base

https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...

We also have mirrors of the QPR1 Beta and QPR2 Beta code there too.

It's not meant to be distributed as a tarball or a single Git repository. The build system runs Git commands to determine the revisions of each component. It's supposed to be in dozens of Git repositories. They provide repo metadata as part of the tarballs on Google Drive which you can see there but it's not a full replacement for the Git repository layout expected by builds. It's somewhat convenient having it in a monorepo but it's not the way it's meant to be and the build system makes it clear that it isn't happy about it despite running.

It would be nice if Google would simply push it to the Git repositories still available on AOSP again. The repositories still exist both internally and publicly but they're making it a hassle instead of simply pushing tags.

We publicly complained about these and other Pixel changes as they were ongoing and that directly led to our Motorola partnership. It was in Google's financial interest to work with us so we continue using Pixels and that's still the case. They're welcome to reach out to us and start collaborating again. We made a lot of upstream contributions and aren't their enemy.

Google should want more people to use their devices, apps and services. It shows how heavily they're violating antitrust laws by using monopolies to protect other monopolies when they sacrifice revenue for their devices and apps/services for it.

reply
Maybe a naiive question, but couldn't you request the source code from phone companies? Say you request it from Xiaomi - sure they're not the original writers of the code, but they too "distributing GPL code" and therefore must release the code on request. They may be more amenable to your request since they have leverage with Google and are in an adversarial relationship
reply
“Couldn’t you just” couldn’t fucking GOOGLE, the don’t do evil corporation, support one of the few alternative mobile phone OSs use standard development tools, instead of being little shits?
reply
You can request anything from anyone, but compelling a company to follow their GPL obligations requires cooperation from the copyright holders + infinite funds for legal fees
reply
Doesn't their change break supply chain security on Google's end?

With git tags, presumably people spoke in terms of cryptographic hashes. Now what prevents them from serving different Google drive contents to different accounts?

reply
deleted
reply
It doesn't break supply chain security for anybody with power to change the situation.
reply
It is an easy to overlook this, but even for someone in position of power to change, creating different code with the same hash is borderline impossible.
reply
Non-sequitor? They're not providing a (sha-1) hash, they're providing source code to integration partners using their business channels, not public git providers. Those business channels include contracts etc to "secure their supply chain".

You and I aren't in those business channels, and we're not being given anything with a hash. There's simply no hash to collide with?

reply
A git hash is cryptographically secure. It doesn't matter how you distribute it. That is the entire point you're missing.
reply
Yes, but that person still needs to file a request and wait several days
reply
It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it.

This is the relevant code for Android 17:

https://gitlab.com/grapheneos/kernel_pixel/-/tree/17-base

https://gitlab.com/grapheneos/kernel_pixel_muzel/-/tree/17-b...

There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta.

Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world.

It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.

reply
I wholeheartedly agree. Making it more difficult to obtain GPLed source code than it was before is fundamentally a dick move.
reply
It also isn't only them pushing the boundaries of the GPL.

Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.

reply
But after one person does this, the source code access is a solved problem.
reply
No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.
reply
Maybe we colld getan AI agent to pester them with forms?
reply
What consequences do you imagine if they (rightfully) choose to ignore it?
reply
But nobody has done this, which is why it's a problem for Graphene
reply
Maybe should someone should do it then?
reply
Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).
reply
They are, which is how they know how long it's taking.
reply