luca020400

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.

I don't think that's a fair comparison.

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 isn't cell networks, no one ever on that side ever blocked Android forks.

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.

What stops you from uploading a fix? Now that I know about the issue I can do it myself, but...

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

Thanks for digging it up.

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

Pressure from Google?

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

There's many of us :)

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.

Supported => Supported by Google yes.

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 :)

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...