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.

As Lineage is concerned I found that a while ago and made https://review.lineageos.org/c/LineageOS/android_packages_mo... But no one bothered to test, and I had no way to verify so it's in a limbo for now :)

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

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!

Not entirely sure what configuration you're looking for, but the one supported in Android can be found here https://android.googlesource.com/platform/packages/modules/B... https://android.googlesource.com/platform/packages/modules/B...

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

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

Their plan is to remove them altogether. Still those apps have not been maintained in years, that's the normal course of action for apps in AOSP.

Yep, everything you said is correct.

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.

This operating system, know as firmware running in the DSP.

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.

The download is done from the Android side.

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.

Leaving aside the opt-in/opt-out possibility.

You can remove the services that download the extra GPS data, nothing stops you from doing that, aside making GPS unusable :)

Indeed, everyone works in its own way. Most on this scene started because people had obscene support by some OEM, so just for personal interest. But after a while you see the whole community behind it and you don't have much of a choice to start sharing your work and goals with other people.

I've been doing CyanogenMod for years, and since become a director at LineageOS.

I've never heard anything akin to " malicious organization/project that's involved in spreading misinformation about GrapheneOS and harassing our developers" and if I were I'd have no problem with going around smacking some of my friends ( some I've known since ~2014 ) that work on the project.

Nowadays most of custom ROM developers are chill and there's really nothing like the old "wars", everyone is "friend" with other projects. The issues arise with these people that you called "evangelists", and I couldn't agree more. It seems like a cult. And it's always on these "super" security/privacy oriented projects.

1) You can still block network via a native firewall ( it's in app settings ), currently the only issue is that network via VPN bypass the toggle.

3) Never heard of this happening, and I've heard a lot of stuff.

If you're rooted your security is way lower. Simple as that. Rooting can be used against you, it can lead to exploitation, and likely has been.

Note: you can have secure boot without root and using your own Android build, such as CalyxOS. Not rooting doesn't imply using the stock firmware, never has been.

We cater the normal user.

And what the hell? Root with verified boot? That's like having the most secure castle while leaving the door open for anyone, you can't have both worlds.

Note: our root implementation was apparently affected by some vulnerabilities ( never disclosed to us ), meaning I tried to lower the attack surface to minimum, but not knowing I did anything helpful we just couldn't leave it there.

Privacy Guard) I was the one who purposely removed it. I spent days ( if not weeks ) trying to get it working properly ( read, it never worked properly and causes many issues we still have tickets for ) futhermore Google basically rewrote the full stack once again, while introducing the, now publicly available in 12, permission hub that somehow gave a better view of permissions and easy access to remove them. We know it removed some more granular ops, but it wasn't worth the effort.

SafetyNet) Nothing can legally pass it unless Google certifies it, we can't do much, only Google can enforce it to be used only for security related reasons

Bribing) I wish I got a single cent from any of the OEM I worked on, name it, Motorola, Asus, Huawei, OnePlus, Xiaomi. Not once they threatened us to stop working on their devices, and at the same time didn't help at all ( the only outsider is Asus that is willingly to help ) We simply can't continue supporting every device that enters the door, we don't have any real way to improve it, everyone is doing it voluntarily with no expectation, and so do we as project directors.

PS: I'm one of the directors.

Guess I'll play a bit more on CalyxOS then. Feel free to hire me I guess.

We are the base of course.

Director/Head Developer @ LinaegeOs here.

Hi, sharing codebase when? :P