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)

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.

It's the implementation that OEMs used to support VoLTE isn't compatible with AOSP APIs.

If it wasn't for Google here you'd never have VoLTE on custom ROMs, if it exists in any shape or form it's thanks to them.

It's always a mix of things people report to us, things someone randomly pick up, but then we need real users testing them out lol

Regardless let me tell you that: AOSP fixed it for Android V!

Sometimes I can't comprehend how people come up with that stuff when it was already publicly explained how/why it happened :/

I myself removed that feature because the effort to have it was more of an hassle than anything else.

I think you misread my comment, or I wasn't clear enough, I work on AOSP daily so I know very well what's in there :)

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 )

That's the only sane way to have a working device that needs to handle signals.

It's not hidden in any way, and the kernel/Android actively talks with it, configures it, turns it on/off.

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.