Thanks for your detailed reply.
So I still presume that apps are not capable of sending any tracking data as long as neither of these apis is installed. And I doubt that microg, as a replacement for the google services would forward those requests at all.
1 Like
Those APIs are either preinstalled (e.g. the GMS stuff) or their components get installed by the APK that uses them. And this is where we get back to the beginning of the discussion, i.e. how important it is to carefully check each Android app for this kind of hidden functionality prior to installing it. Of which probably the best way is to view its AndroidManifest.xml file, where everything is clearly visible.
First of all, youâre mixing up Play Services (GSF - Google Services Framework) with GMS (Google Mobile Services), which are different things. MicroG is a replacement for GSF, not GMS. Secondly, GMS is just one of many tracking APIs. So even if MicroG was a replacement of GMS (which it ISNâT) then it would still mean nothing when it comes to Firebase, Google Ads, Facebook, Amazon, and the whole rest.
1 Like
Ah I see. Thanks.
Are there tools to determine if any of these apis has been installed unintentionally?
I didnât install any Google stuff except for Waze, but of course I installed chromium and maybe even Edge (for testing, not sure atm).
I installed all package either through the Aurora store or by hand. I didnât recognize any dependencies being installed but I wouldnât bet there werenât if this is really done in the background.
Iâve microg installed.
I donât know, actually. As I always manually remove references to such tracking functionality from the AndroidManifest.xml file prior to installing an APK (or if I donât succeed in doing it then I just donât install it), I donât really pay attention to it past that, maybe except for then checking a few times the list of running processes/services to verify that no process/service from that app gets autostarted and working in the background.
Those APIs themselves are actually legal stuff, parts of official SDKs from Google, Firebase, etc. So I guess that themselves they do nothing unless triggered/invoked by an app using them. So even if they remain on the device, without any app utilizing them being installed I guess they donât do any tracking just by themselves. I think that it takes an app with the tracking functionality to pass data to them so that they forward it to their corresponding servers. Thatâs why in the AndroidManifest.xml file of so many Android apps there are so many events defined to trigger such telemetry/analytics/tracking functions upon connecting/disconnecting a charger, switching on WiFi, changing profile, and things like that. If those APIs were doing any tracking/analytics just by themselves, I guess there would have been no need to define such events triggering them in all those apps.
In the article I quoted earlier, they mention DuckDuckGo as the most trusted app being able to discover, report and even block trackers in an app. So maybe give it a test and see if it reports anything on your device.
wait for the moment when your govs will make decision that someone thoughts are not in line with the party and will be just banned from using that app. Ooopsie no founds for live.
4 Likes
IIRC this happened in Canada already, without even having centralised access ID ⌠yes, itâs a BIG problem for our futures. I hope I will be dead before it gets out of hand
1 Like
Wow, you can actually do that? Could you describe how you do that? Because I would like to do that too, I looked into an AndroidManifes.xml file, but I was really confused and didnât understand anything 
3 Likes
Well, itâs not that easy to shortly describe it. Youâd need to learn some basics about the structure of AndroidManifest.xml file, so that you know which tags are responsible for enabling permissions, starting services, or setting up receivers to listen to events and trigger certain actions. There are lots of articles and guides about it. And then it simply takes some practice, youâll simply need to experiment with it a little bit, by trial and error. You wonât risk anything but that the app just wonât work.
It is actually about removing three types of tags: the tags enabling permissions that the app doesnât really need (e.g. autostarting on boot, or Internet access if it doesnât really need it, or your precise/coarse location, or creating/modifying accounts on the device, or using the phone or messaging, etc.), then tags responsible for setting up receivers which trigger undesired actions (like e.g. those telemetry/app measurement data collection starting when charger is connected, or when battery level gets low, etc.), and finally you can also try to remove lines responsible for starting services that do such things (e.g. service referring to âapp measurementâ or âFacebook adsâ, etc).
To remove a permission you basically delete the line starting with <uses-permission> and then the name of the permission you want to remove (e.g. android.permission.INTERNET or android.permission.BOOT_COMPLETED). To remove a service you delete a line starting with <service> or multiple lines between <service> and </service> tags. Similarly, to remove a receiver triggering certain actions upon certain events (e.g. BOOT_COMPLETED or CHARGER_CONNECTED, etc), you remove lines between <receiver> and </receiver>.
There is no simple rule or recipe, it always takes experimenting with each APK and seeing what can be removed while the app still works OK. Removing receivers and unneeded/undesired permissions mostly (like 98% of times) doesnât affect the intended app functionality at all (it just stops hidden, undesired activity), while removing services needs more care and attention not to remove what the app needs to keep working.
When you make all the modifications, you let the APK Editor Studio repackage and re-sign the APK and you need to test if it still works OK.
In case of some APKs it is completely trivial, while in case of others it takes more work.
Well, thatâs all I can say. All the rest is practicingâŚ
2 Likes
Thank you, I will try that