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