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!

What stops me is that I'm afraid of testing it on my phone and breaking it.

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.

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

> A lot of people still don't see how the operating system as a whole is open source

What? Just checkout the sources and go through them, maybe?

> not having properly supported open source apps is not the best

If your definition of "properly supported" means "supported by Google", I guess...

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

Oh, maybe I did misunderstand it, indeed. Sorry :)

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.

I think the big question is whether they “improve” the APIs these apps require at the same time.

That would break the alternative implementations.

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.

Yes. That is the problem I am referring to. They can bump the api version, removing the non-privileged APIs the AOSP stuff used, and move the implementation of the new privileged API into a proprietary blob.

This is how location services work. Location has an obvious local-only fallback, but it is broken in practice. I imagine they can break phone calls/sms/rcs equally badly using the same technique.

Actually there are a few APIs you can't use when the app isn't signed by a system key.

All oems or rom makers are able to make whatever apps they want system apps. So even if this is being done, Google dialer isn't getting access to something others cannot.

Oh wow, you're one of the guys from LineageOS right?

There's many of us :)