Another Google Service in a DeGoogled System? Now It’s Health Analytics!
In my previous post “Work Mode Causes Recovery Reboot on /e/OS v2.9 & v3.0”, I discovered that Google Assistant had made its way into /e/OS—carried over from LineageOS (surprisingly, /e/ Foundation doesn’t seem to audit the Lineage source code but trusts it blindly). Now, I’ve spotted “Health Connect” in the list of system apps. I tried to find its code on /e/OS’s GitLab, and guess what? It’s not there. I searched online and found out it’s actually a Google app!
You can’t disable it, and you can’t revoke its internet access—yet another ticking time bomb that hasn’t exploded yet. It feels like all /e/OS users are playing Minesweeper, except instead of a lost game, we might end up with a data leak or a security breach.
Here is my build information:
e_alioth-user 14 AP2A.240905.003 eng.root.20250322.060729
The device is not rooted.
/e/os: 2.9-a14-20250322478432-community-alioth
Phone model: M2012K11AG / alioth/ poco f3
I feel like in a conspiracy forum, everbody got their tinfoil hats pulled way down.
The appid you’re referring is part of AOSP, agpl’d and mostly does permissions around tracked health data. That is: on-device and something people want?
it’s even namespaced to android instead of google - com.android.healthconnect.controller… there’s dozens to a hundred of those libraries in your Android. You can assume it’s not connected to play-service if namespaced that way.
Thanks for the clarification about Health Connect and its relation to AOSP. However, in practice, Health Connect is not truly open source in the usual sense. If /e/OS is going to include such a system to handle sensitive health data, it would make more sense to use a solution that is genuinely transparent and fully open source , so users can trust that their data is safe and private.
nah man, you’re wrong (on the internet!). That system component is truly open source. You can hook it up to something online (installing an app that connects to that data store that will upload) - but not by default.
That is what degoogling is kind of about? user agency / network silence by choice. Not getting rid of google code in a google OS. You can decide to remove that component, but then people who are into fitness tracking or this system service is helpful for miss out (device internal). /e/OS has it in its manifest somehwere that they want to strike a balance - that is why microg is included and on by default (repeatedly up to debate).
If that rubs you all the wrong way, foss alternatives to Android are shaping up pretty well without all that Google product direction
Really? The number of /e/OS users who actually need Health Connect is much smaller than the number of people who are against having pre-installed Google apps on a de-googled system—especially when those apps can’t even be removed.
I don’t agree with your idea of de-googled. To me it’s just another AOSP system component that is benign, has a minimal install footprint and people who already saw a cardiologist in their life can be useful to. There’s no privacy angle upfront. Depends on the Apps that make use of that API.
As long as it is based on Android, deGoogled is mostly related to removal of communication towards Google servers and third party (bloatware) servers, together with removal of applications which are “set on top”.
Not necessarily meant as a removal of relevant core functions of Android (I wouldn’t be happy if my “deGoogled” phone couldn’t connect to Android Auto devices anymore, as well).
/e/ doesn’t need to be a 100% self-coded alternative, where all traces of Googles Android would be missing.
Same goes for microG LineageOS and others, they all bring a bunchload of necessary “Google” system packages.
GrapheneOS seems more strict in terms of removal (and avoidance of microG etc.), but it is only available to very few devices due to the focused development on those. Advantages and disadvantages of choices…
I guess it is impossible to “do it right” for everyone. For me as engineer and technician but not (Android) programmer, /e/ OS looks very well-thought cleaned from Google dependencies.
Some aspects like MGM / Find my device should in the future maybe be a matter of choice via first-boot assistant or image selection aka “I want this, but not that”, if this doesn’t generate too much hassle by the apps removal (system integration).
But regarding Health Analytics which doesn’t seem to communicate to Google servers on itself (acts as a handler between data and other local apps, which can be installed), that’s none of my concern.
Yes, of course, some people need Android Auto, Health Connect, and other bloatware that I wanted to get rid of when switching from MIUI—then from stock Android to /e/OS. In the early versions, there was no such pre-installed bloatware that I couldn’t disable and that used up data by updating automatically, since they are system apps. I disabled all of MicroG and other system apps I didn’t need, but as a result, some features stopped working: I can’t adjust the volume with the keys, I can’t use picture-in-picture mode, because /e/OS relies heavily on third-party components instead of doing everything itself. Personally, I don’t use synchronization or transfer any data to Murena’s servers or other services. Security and privacy mean that you control your own data.
What would I suggest to please everyone? When building your own custom build, you can choose a minimal system where some services are absent. Why not do the same with the .img files—so you could choose which services you want on your phone before downloading, or download a clean system and install only what you need afterwards? As an Arch Linux user, I would be very happy if Murena did something similar: a bare system with SELinux protection, encryption, and advanced privacy, and then you install whatever else you need after the system is set up.
So, tell me, which systems offer a degoogled, secure OS that can be installed on the POCO F3? I’ll say right away: there aren’t any. Either you have to build your own custom ROM, which could turn your phone into a brick, or use something like GrapheneOS, which only installs on Google phones. So, either you build your own ROM or you buy a Google Pixel—but I’m not going to buy a Google Pixel. I’d rather buy a Pine64 and set up ArchARM on it, not an AOSP-based system, which is actually what I plan to do after the latest /e/OS updates.
Your pattern to beat on /e/OS to make it what you want seems pointless to me. Murena is a business, thus mainstream features to get people buy their phones and sustain their people. The AOSP component discussed in this thread is in line with their slogan.
There’s a ROM scene still, even for the alioth, Divest would’ve been a good fit for you. Then you can also look for unofficial GSIs at xda where projects only build for a subgroup of devices. Building AOSP isn’t that hard too, just an initial investment.
Normal userland Linux has a worse security posture, but more agency and more of what you mean by “truly opensource”? Your alioth came far but needs more time to get all hardware working, I’d be optimistic on that.
Android is a difficult base to build an independent OS up on, constant turmoil. What component or package is on by default or included should be debated, but I can’t get behind outrage when there is no ill intent.
