Almost all device run on the initial android release (QPR0), and never shipped any of quarterly updates. Even less so using _main_ as a baseline so that point is moot.
With android 16 introducing "mid releases" (QPR2), they expect OEMs to start shipping those as well, QCOM already has a QPR2 BSP release, and Samsung is expected to release QPR2 based builds soon.
As far as contributions go, google usually wanted patches to apply to main, I don't think that ever changed.
And even there now that AOSP development is fully closed, it's even easier as partners will likely just upload patches against internal main instead. Less integration work there as well.
There really isn't a good explanation as to why they want to do move code drop cadence, other than they can and want to avoid wasting time releasing QPR1/3 that no OEM ever shipped (expect Pixels that is)
> AIUI updates are less stringent and burdensome than initial certification
That's true having dealt with some of it, nonetheless I haven't found that much of a difference due to having to use 3PL.
There's more manual steps on top of CTSV for camera and GMS, but that's all there is to it.
The only real difference I've seen is on Google's side to actually say "ok" before it getting approved.
Carriers and regulations are better on that side, but assume you have a security fix in the modem, for some carriers you're supposed (emphasis here) to redo it...
> Seems like a decision that is not user-centric.
I can see how having two release channels one solely for security and a bigger one might be a burden on some.
But you hardly want to only fix security issues when you have a real bugfix you want to also release, so it makes sense to me the channels have to be merged.
> Private test suites for software are a toxic idea
To be fair on android side they're quite fine.
One is specifically for GMS compliance, one for camera verification, and one for security patches verification.
The latter is janky and not as updated as you'd think, so unless you really forget to apply patches it'll pass.
With that said, the amount of people running those test suites not for certification can probably be counted on a single hand, I think that's the least of the problems.
OEMs have quite a lot of extra steps before releasing any build to the public.
They have to pass xTS, the set of test suites required before getting certified by Google, possibly carrier certification, regulatory requirements and more depending on where the build will be released.
There are "quicker" release channels for security fixes, but I don't think it's common for OEMs to only ship those without any other change to the system.
I don't think Graphene does anything of sort, they take what's already certified in the Pixel builds and uses it.
Not like they could do much aside testing on the public part of xTS.
Android APIs are stable and an app will keep working until Google decides to bump the min SDK version in Android itself.
The APIs a Google app uses are the same as any other app.
Unless the app is privileged ( = can use system APIs ) there's no difference in capabilities.
A lot of people still don't see how the operating system as a whole is open source, not having properly supported open source apps is not the best, but while we can make apps and/or update the aosp versions, we can't make an operating system...
You'll hear that it's been happening since years, and while a lot of us tried to upstream some of our enhancements/changes hardly any of them got accepted ( or anyone is actively working on those apps to review them properly ).
This changes nothing, we'll keep using our forks that didn't see a single change from Google in years at this point :)
The AMSS has control of the hardware, but there's different components, each implementing different functionality, they may be able to talk with each other using various IPC mechanism, and they do, but mostly using Android as a middleman ( Linux )
WiFi ( known as cnss on QCOM ) is implemented in a different block than GPS, they don't have direct communication in place. It's routed via the Linux kernel ( and userspace processes )
You have to manually strip the QCOM additions in the vendor side.
It's just a matter of removing files, but I wouldn't expect to do it without some knowledge how the whole thing works in Android, without breaking GPS as a whole.
It's a privileged app ( a service in Android lang ) that once fetched sends the data to the modem, where GPS is actively implemented, and augmented by such extra data.
With android 16 introducing "mid releases" (QPR2), they expect OEMs to start shipping those as well, QCOM already has a QPR2 BSP release, and Samsung is expected to release QPR2 based builds soon.
As far as contributions go, google usually wanted patches to apply to main, I don't think that ever changed. And even there now that AOSP development is fully closed, it's even easier as partners will likely just upload patches against internal main instead. Less integration work there as well.
There really isn't a good explanation as to why they want to do move code drop cadence, other than they can and want to avoid wasting time releasing QPR1/3 that no OEM ever shipped (expect Pixels that is)