Ah, the fraud of Android: the great "open-source" OS that was going to free us all from vendor and telco tyranny.
Instead, users wait months, years, or forever their telco to dribble out a hacked, proprietary version of Android for every model of phone, one at a time.
It's incredible that an OS created in modern times lacks a proper hardware-abstraction layer and driver model, which would allow users to install an updated version of it on they day of release... without breaking all the crapware that vendors have laden it with.
As far as I ever understood, the point of Android wasn't to help users as much as developers: it took a fragmented ecosystem of custom platforms and united them behind a single development SDK; which, post-iPhone App Store, became an easy sell to manufacturers for adoption as the iPhone started getting all of these new sort-of-features while their platforms stagnated due to their small-percentage marketshare making it not worth writing an app for them at all. Remember: the original Android G-1 was a locked-down device that we were only able to install custom core software on due to jailbreaks.
What do telcos have to do with any of this? The only piece of software that has anything to do with my telco is running on the SIM. They do not and, as far as I know, can not load software on my device, let alone control something OS-level like software updates
People have started realizing that when people say "AOSP Android" they actually mean "Google Android" because the discussion is never about how to get rid of google bloat, only how to get rid of manufacturer or telco bloat.
Meanwhile I actually think that the OEMs have driven innovation and usability in the Android smartphone space as much as or more so than Google. Sure, some of the UI was over the top but it was a learning experience for consumers as well as for manufacturers.
> People have started realizing that when people say "AOSP Android" they actually mean "Google Android" because the discussion is never about how to get rid of google bloat, only how to get rid of manufacturer or telco bloat.
That's definitely your own bubble :-)
I have bubbles where they say "stock android" to mean "AOSP + google apps", I have bubbles where "AOSP" mean "*without* google apps" (notably professionally), and I have bubbles where AOSP just means without major changes to AOSP but doesn't imply anything about whether it's using google apps or not.
Notably, I make an "AOSP" ROM which has three variants, one with Google apps, one with microg, one with nothing, and sure I have more users using the Google apps one, but that's maybe 2/3 for google apps, 1/3 for non-google apps.
> Meanwhile I actually think that the OEMs have driven innovation and usability in the Android smartphone space as much as or more so than Google. Sure, some of the UI was over the top but it was a learning experience for consumers as well as for manufacturers.
Yeah that's a pretty hard compromise to make. Nowadays, the compromise is moving hard towards "use Google-provided UX with very minimal changes", which imo reduces innovation, but most devices have pretty close UX from each other (I have a friend who moved from a OnePlus 5 Android 10 to a Samsung Galaxy A53 running Anddroid 12, the vast majority of their annoyances are because of Android 10 => Android 12 changes). A decade ago, going from one OEM to another you had very different UX (and very slow OEM UX...)
And there is an entire vendor partition (On the Pixel 3a, it was >400 MB). However, even if a user built AOSP with those drivers, VoLTE, SMS on LTE, Wi-Fi Calling, eSIM, and a few other things (Sorry I don't remember) do not work.
To get those features, one has to extract them from a stock image:
> This is where yet another amazing open-source project comes in. It’s called MicroG. It’s basically an open source reimplementation of Google’s Play Services, APIs, and some of those services. We were talking about this before, that AOSP has APIs for everything. What MicroG does is it provides the implementation or everything that an app would expect from Google Play Services.
> But they implement push notifications. The way push notifications work is, say you are using WhatsApp. WhatsApp will send a notification to the Google servers, so MicroG has to talk to Google servers to get that notification, because that’s where WhatsApp sent it.
They address the privacy aspects of this, but I've been wondering what implications this has for control and stability of open-source android distributions.
With enough time and effort, you can certainly reimplement proprietary on-device APIs that commercial apps expect to be present - but Push is in a sense an "off-device" API: To send a push notification, an app's backend-server talks directly to Google's backend and submits a push request. Then, at a later time, some Google Play Services component on the device calls an internal API on Google's backend end fetches the enqueued push notifications for that device.
To get Google fully out of the loop here, MicroG would have to run its own backend server and convince the developers of every single app that uses Push to also send their push requests to MicroG's server in addition to Google's. That's of course practically impossible.
So what MicroG does instead is to call Google's internal API and fetch the enqueued messages from Google's backend like the original Play Services component would do. However, by doing that, they depend on Google's goodwill to let them use their internal API.
If Google some day decides that they won't let anyone else use their internal APIs anymore (either by doing some ML on the API server to distingish "genuine" Play Service clients from MicroG clients - or by threatening to sue MicroG), then all the alternative Android distributions would be instantly left without working push notifications.
If Google wanted to be insidious, they could even purposefully degrade service for MicroG clients - e.g. randomly hold back queued push notifications - to make alternative distributions appear unreliable.
I don't know if there are any other APIs besides Push which follow that same pattern.
That always seemed like a huge achilles heel to me.
> I don't know if there are any other APIs besides Push which follow that same pattern.
According to microg.org, the main components are Google's push notification API, the Google Maps API (embedding maps in apps), and Unified Network Location Provider (WiFI/cellular tower based location, provides fast initial loaction).
The maps API replaces Google maps with mapbox, so no requests are sent to Google (?).
MicroG uses Google for push and they need a device ID, but it is not connected to an account (and can be disabled).
Network location does not use Google's services but instead use local location modules (e.g. from F-Droid). One of the default ones uses Mozilla's database of WiFi & cellular tower.
So if I didn't miss anything the only component that Google can deactivate is Push. For apps like WhatsApp & Signal that's not a big problem as they are able to use WebSockets for push instead.
Other Apps won't push which is inconvenient, e.g. Stem wouldn't push the 2FA code, so I'd have to open the app manually.
But that is something I'll worry about if Google actually shuts push down. Over the last 2 or so years I watched unifiedpush.org and they make steady progress. They define how push components work together and now there are multiple push (hosted and self-hostable) "providers". Anyway, Element Android will support it & FluffyChat has support already (Matrix clients).
MicroG could integrate https://github.com/UnifiedPush. Developers should prefer an API that is push provider agnostic, so they can deploy on Amazon FireOS and Chinese devices with the same code.
Yeah I agree, and the biggest issue is that making it a commercial product is extremely dangerous (though some company try it anyway). IMO this is one of the major competition issue in the Android world.
Thankfully there is China (so both mainland, and Huawei overseas) to have app makers understand that google push isn't everything. Notably the China market has no interior monopoly on the matter, so the 4 big China OEMs made a generic API that is independent of server side under Unified Push Alliance. (Also opensource-world did the same - without knowing the China side- under UnifiedPush). Hopefully we'll be able to switch to something like that, I just don't know how many apps support it, and whether it's possible to push them into supporting it.
[+] [-] NonNefarious|3 years ago|reply
Instead, users wait months, years, or forever their telco to dribble out a hacked, proprietary version of Android for every model of phone, one at a time.
It's incredible that an OS created in modern times lacks a proper hardware-abstraction layer and driver model, which would allow users to install an updated version of it on they day of release... without breaking all the crapware that vendors have laden it with.
[+] [-] saurik|3 years ago|reply
[+] [-] franga2000|3 years ago|reply
[+] [-] llampx|3 years ago|reply
Meanwhile I actually think that the OEMs have driven innovation and usability in the Android smartphone space as much as or more so than Google. Sure, some of the UI was over the top but it was a learning experience for consumers as well as for manufacturers.
[+] [-] phh|3 years ago|reply
That's definitely your own bubble :-)
I have bubbles where they say "stock android" to mean "AOSP + google apps", I have bubbles where "AOSP" mean "*without* google apps" (notably professionally), and I have bubbles where AOSP just means without major changes to AOSP but doesn't imply anything about whether it's using google apps or not.
Notably, I make an "AOSP" ROM which has three variants, one with Google apps, one with microg, one with nothing, and sure I have more users using the Google apps one, but that's maybe 2/3 for google apps, 1/3 for non-google apps.
> Meanwhile I actually think that the OEMs have driven innovation and usability in the Android smartphone space as much as or more so than Google. Sure, some of the UI was over the top but it was a learning experience for consumers as well as for manufacturers.
Yeah that's a pretty hard compromise to make. Nowadays, the compromise is moving hard towards "use Google-provided UX with very minimal changes", which imo reduces innovation, but most devices have pretty close UX from each other (I have a friend who moved from a OnePlus 5 Android 10 to a Samsung Galaxy A53 running Anddroid 12, the vast majority of their annoyances are because of Android 10 => Android 12 changes). A decade ago, going from one OEM to another you had very different UX (and very slow OEM UX...)
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] kop316|3 years ago|reply
https://source.android.com/setup/build/downloading#downloadi...
https://developers.google.com/android/drivers
And there is an entire vendor partition (On the Pixel 3a, it was >400 MB). However, even if a user built AOSP with those drivers, VoLTE, SMS on LTE, Wi-Fi Calling, eSIM, and a few other things (Sorry I don't remember) do not work.
To get those features, one has to extract them from a stock image:
https://wiki.lineageos.org/extracting_blobs_from_zips
I can't imagine this is any better for newer Pixel phones, nor for any non-pixel phones. This will be true for compiling AOSP or any Android ROM.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] aaaaaaaaata|3 years ago|reply
[+] [-] xg15|3 years ago|reply
> But they implement push notifications. The way push notifications work is, say you are using WhatsApp. WhatsApp will send a notification to the Google servers, so MicroG has to talk to Google servers to get that notification, because that’s where WhatsApp sent it.
They address the privacy aspects of this, but I've been wondering what implications this has for control and stability of open-source android distributions.
With enough time and effort, you can certainly reimplement proprietary on-device APIs that commercial apps expect to be present - but Push is in a sense an "off-device" API: To send a push notification, an app's backend-server talks directly to Google's backend and submits a push request. Then, at a later time, some Google Play Services component on the device calls an internal API on Google's backend end fetches the enqueued push notifications for that device.
To get Google fully out of the loop here, MicroG would have to run its own backend server and convince the developers of every single app that uses Push to also send their push requests to MicroG's server in addition to Google's. That's of course practically impossible.
So what MicroG does instead is to call Google's internal API and fetch the enqueued messages from Google's backend like the original Play Services component would do. However, by doing that, they depend on Google's goodwill to let them use their internal API.
If Google some day decides that they won't let anyone else use their internal APIs anymore (either by doing some ML on the API server to distingish "genuine" Play Service clients from MicroG clients - or by threatening to sue MicroG), then all the alternative Android distributions would be instantly left without working push notifications.
If Google wanted to be insidious, they could even purposefully degrade service for MicroG clients - e.g. randomly hold back queued push notifications - to make alternative distributions appear unreliable.
I don't know if there are any other APIs besides Push which follow that same pattern.
That always seemed like a huge achilles heel to me.
[+] [-] nani8ot|3 years ago|reply
According to microg.org, the main components are Google's push notification API, the Google Maps API (embedding maps in apps), and Unified Network Location Provider (WiFI/cellular tower based location, provides fast initial loaction).
The maps API replaces Google maps with mapbox, so no requests are sent to Google (?).
MicroG uses Google for push and they need a device ID, but it is not connected to an account (and can be disabled).
Network location does not use Google's services but instead use local location modules (e.g. from F-Droid). One of the default ones uses Mozilla's database of WiFi & cellular tower.
So if I didn't miss anything the only component that Google can deactivate is Push. For apps like WhatsApp & Signal that's not a big problem as they are able to use WebSockets for push instead.
Other Apps won't push which is inconvenient, e.g. Stem wouldn't push the 2FA code, so I'd have to open the app manually.
But that is something I'll worry about if Google actually shuts push down. Over the last 2 or so years I watched unifiedpush.org and they make steady progress. They define how push components work together and now there are multiple push (hosted and self-hostable) "providers". Anyway, Element Android will support it & FluffyChat has support already (Matrix clients).
[+] [-] lern_too_spel|3 years ago|reply
[+] [-] phh|3 years ago|reply
Thankfully there is China (so both mainland, and Huawei overseas) to have app makers understand that google push isn't everything. Notably the China market has no interior monopoly on the matter, so the 4 big China OEMs made a generic API that is independent of server side under Unified Push Alliance. (Also opensource-world did the same - without knowing the China side- under UnifiedPush). Hopefully we'll be able to switch to something like that, I just don't know how many apps support it, and whether it's possible to push them into supporting it.