undefined

points

[-]

> How slow is "very slow?" The answer can be found two replies after: > Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us. They're the ones who chose to use this archaic system instead of pushing Git tags and it's their responsibility to handle requests promptly.

> What is "certain source code"? The OP seems to be GrapheneOS, which heavy patches AOSP. I guess the context is Android source code and its security patches.

> Why is the OP being so coy about describing the problem? Not sure what you mean, I think they are explicit enough. I guess it's clear enough for developers how an upstream update should go. If people depend on big projects like AOSP, devs should be prompt in delivering source code, especially when it is mandatory by license.

Can you give us more details on how/why you think the OP is being coy?

by grapheneos7 hours ago|

parent|

[-]

It isn't about AOSP but rather the Pixel OS. Android 16 dropped support for Pixels from AOSP but we're still entitled to receiving the subset of the code derived from GPL/LGPL projects. We need the Pixel kernel driver sources for each stable and beta release. We're entitled to getting those in a reasonable amount of time. Weeks of delays is not reasonable for one of the largest tech companies in the world.

They could simply share a folder with us and put all of the releases in that folder so we don't need to request each release. They're going out of the way to make it difficult by requiring us to separately request it for every single release we want. Initially, it was consistently provided in under a business day. Recently, they've regularly been taking weeks or more to provide it. It's likely going to take longer now that more people are aware of it since they're going to receive more requests for it. They could simply push it to a repository on GitHub instead of assigning employees to do this manually. If for some reason they don't want to do that, they could at least automate it. For example, they could give us access to a folder with all the releases. Needing to request every single release tag is ridiculous.

by grapheneos7 hours ago|

prev|

[-]

It applies to anything Google releases based on Android without pushing tags to AOSP for that fork of the code. It isn't a limited set of products but rather everything they make based on it. It applies to Android Wear, Android TV, Pixel phones and anything else not pushed to AOSP. We aren't being specific since we don't know everything they release based on Android. If they release a Beta emulator image for an upcoming version of Android without pushing tags, it applies to that too.

Google used to push all of the Pixel code from AOSP to it every month. They now only push AOSP releases intended to be used by other OEMs. That means they went from pushing each monthly, quarterly and yearly release of Android shipped by Pixels to only pushing 2 major releases per year (yearly release and QPR2) which are the only major releases used by other OEMs. They also provide security backports to those 2 major releases. They're still obligated to give us the GPL/LGPL licensed code for each Pixel OS release.

Google sold the Pixel 6 through Pixel 9a as being AOSP reference devices with 5-7 years of support from launch. They should be pushing the AOSP releases for those devices each month to fulfill their update commitment. GPL compliance is a clear legal requirement, but we think there's more than that too. Pixel 10 and later were not launched as AOSP reference devices since this changed was already made, so sure they have no obligation to provide anything beyond GPL code for those.

We didn't want to explain all this in our thread but we did explain it has to do with Pixels. It isn't only the kernel drivers. It's also the assorted set of stuff within the OS that's GPL/LGPL beyond that. There's more than there used to be since they moved to the OpenJDK libraries during the Oracle lawsuit.