I suppose the alternative AOSP rom wouldn't even have "Nearby Share" as a feature? I suppose in that case you could use some other protocol/service that wasn't bound to Google (maybe Briar?).
The article is correct, you're mistaken. While AOSP is licensed under Apache 2.0, in order to bundle the Play Store and associated Google services you have to agree to MADA[0]. No major manufacturer, except Amazon, ships an AOSP variant without Google's Services.
Arguably many of Android's core APIs now flow through Play Store Services (e.g. Location Services).
I think you're mixing up AOSP and Google Apps / Play Services.
AOSP is available under a standard open source license, and can be used by anyone under those terms. It's the use of Play Services and Google's Apps that requires specific permission and has relatively onerous terms. CyanogenMod can use Play Services, but it doesn't have to, and seems to be moving away from it entirely.
I’m pretty sure it would be somewhere within the Google Play Services blob. You should be good if you build your own AOSP, although binary hardware drivers might have the ability to do shady things.
>fused location system ... which can't exist without Googles involvement
That's kind of a cop-out though. It certainly could exist without Google's involvement if the location provider were a pluggable module within AOSP. microG does this - my phone supports the fused location API using Mozilla's location database instead of Google's. (There are other modules too, like a local database of cell towers if you're willing to dedicate some storage to it.)
Push notifications and Google login sure, but some of what's in the Play Services APIs should really be in AOSP, IMO.
EDIT: For that matter, you could even have the push provider available as a module too, even though Google's push service is the only one currently available.
For now, at least. AOSP and Android "share the same engine", supposedly, but API footprint standardized in AOSP is getting drastically distanced from the API footprint moved behind Google Play Services and other proprietary bulkheads. The number of APKs that run on non-Google Play enabled AOSP builds has dwindled fast in the last few years. (Just ask Amazon.)
What's to stop "YouTube needs Genuine Chrome™ with Google Play® Support Services Installed"?
Interesting and disappointingly. In this case I was testing it with play services, using the nextcloud app. I believe they are using something slightly custom from an open SDK, and suspect the outdoor was at their end.
It seems strange Google put fido2 into play services, but that's certainly what they seem to "need" to do to get things shipped, given the lack of prompt Android release updates (don't even start me on longevity...)
Still unfortunate every time this happens, as AOSP just loses more and more functionality.
Google is constantly pushing their proprietary APIs so a lot apps in practice only work with play services, if you even can get hold of them without the Play store app. they also abandon more and more of the AOSP builtin Apps, new features and are added mostly only to the proprietary counterparts. So a lot of things people might attribute to Android are in fact part of the Google Apps. The direction is clear and AOSP is entirely controlled by google, they could simply decide to not open the next Version or parts of it.
That is completely unrelated. This is about propriety Google play services. Not about android or aosp. You can anyway run aosp on any number of devices.
You are missing the distinction between AOSP's license and google play services' license. You can do as you wish with AOSP. If you want google play services (which all OEMs do), a whole new set of things kick in.
This has a few interesting potential repercussions that nobody is talking about. Since this is a lose-lose situation for both, here are a some possible outcomes:
a) Google moves enough play services code into AOSP to make AOSP more functional than it is now.
b) Webapps become more of a thing
c) Play services become "downloadable" when you visit google.com
d) Play services become standardised and/or federated
That is just an illusion ultimately, which you see crack in instances like these. Google play services have system level privileges. If you don't want such surprises, run AOSP.
> Most of those DEPEND on some proprietary google app that's not part of AOSP.
Do you have something to support this ?
Many apps use Play Services (I guess that's what you are referring to but can usually also work fine without it.
For example on the app I work on, we are integrated with chromecast if you have play services available, if not, we just never display the icon.
Regarding support on Android, if you are using a custom rom like LineageOS without Google Play Services then it won't work currently. Unfortunately, Google implemented FIDO2 in the play services, not in AOSP: https://bugs.chromium.org/p/chromium/issues/detail?id=997538
There are third-party clients for the Play Store (Aurora store being a good example). Aurora store uses anonymous accounts to download the APKs directly from Google. That being said, just because you can install the application doesn't mean it will actually work without Play Services installed. I've had quite a bit of luck with random applications I've installed (interestingly most Google apps like Gboard, Photos and GCam work fine offline and without Play Services), however YMMV.
I suppose the alternative AOSP rom wouldn't even have "Nearby Share" as a feature? I suppose in that case you could use some other protocol/service that wasn't bound to Google (maybe Briar?).
reply