GrapheneOS is the only Android OS providing full security patches

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

Fair?

> OEMs have quite a lot of extra steps before releasing any build to the public.

AIUI updates are less stringent and burdensome than initial certification. Regardless much of the process is automated. Graphene has CI too. 3PL's taking 4 weeks to run automated tests is also absurd. There are some "manual steps" to run CTS-V but they shouldn't be weeks level burdensome either. This is the point, this is an industry problem.

The reason that the OEMs even have to deal with this 3PL test mess is for GMS certification, so again this is a policy decision that enforces a poor process. The bad properties of the process are not inherent to the problem space of validating builds against requirements. An industry problem.

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

Seems like a decision that is not user-centric.

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

Private test suites for software are a toxic idea, it's in the same box as "SSO tax", and other such "pay for security" models. Given the software industry can't be trusted not to do this, I'm almost keen to see legislation to explicitly ban this practice.

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

Android CTS and VTS are open source so we can and do use those. They're filled with flaky and badly made tests along with enforcing anti-privacy and anti-security design decisions though, so not everything is supposed to pass. Google likes to enforce that OEMs aren't allowed to make certain kinds of privacy and security improvements which could impact app compatibility until Google decides to do it themselves in new major Android versions with new API levels forcing app developers to deal with it.

They don't allow adding our Network and Sensors toggles which are detected as modifications to the permission model. They don't detect Contact Scopes and Storage Scopes but they might be considered Compatibility Definition Document violations. We don't worry about this, our focus is passing the tests which are actually relevant including the ones we've added for duress PIN, hardened_malloc, our more advanced hardware memory tagging integration that's always on, etc.

If we wanted to get access to the proprietary GTS for Google Mobile Services to see how much sandboxed Google Play passes, we could, but we focus on real world app compatibility.