What does “AOSP Android” mean? Can you use it?
blog.esper.io
blog.esper.io
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.
> Update schedules vary by device, manufacturer, and mobile carrier.
> If you have a Pixel phone, learn when you’ll get updates.
> If you have another Android device, contact your manufacturer or carrier for info.[1]
Also for others concerned about privacy, your carrier can push applets onto the SIM card itself which can do a lot. Malicious actors in the past have exploited devices via applets such as Simjacker and WIBattack
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.
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...)
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.
> 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.
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).
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.