I'm aware of the LineageOS for microG project, however apart from the aforementioned preinstalled set of apps, CalyxOS includes many system patches shared by other projects such as GrapheneOS, which include privacy enhancements on default AOSP DNS fallbacks, connectivity checks, NTP, and more.
I would also like to mention that Signal does not require microG or Google Play Services for auto backup (or notifications). The backup files are stored locally on the device and can be easily synced with Syncthing, Nextcloud, etc.
FreeSignal was a project that aimed to remove this dependency completely but was stopped by the main developer of Signal. It is possible to clone Signal's repo and do this work yourself quite easily if you know Java a bit, but it takes time and it is not convenient.
That exposes client information to Google but not content. Besides, if my understanding is right, The Signal Protocol is non-repudiable, which means there's no way for an external party to conclusively prove if the communication did indeed take place.
Then, it's probably not risky, but it is still proprietary code that you can't inspect and verify. You can't easily know if the library will not silently do something. If you are seeking to avoid running any proprietary code, then it's something you want to avoid.
Now you have several options:
- you trust Google and trust this code not to do anything when the Play Services are not running
- you don't trust Google on this, but you don't care neither
- you don't trust Google and care, but you are willing to take the risk
- you don't trust Google and care, and are worried, or are not willing to run any proprietary code out of principle: you need to adapt Signal's code or dish the app entirely
Right, that's the part I care about. I think there are two possible situations:
- Signal's own open source code can detect the absence of Play Services and not call out to Google's proprietary code in the first place. Great, no problem there.
- Google's proprietary code attempts to use Play Services and doesn't do anything when it's not present. In that case I do indeed trust Google enough that I wouldn't expect it to actually do anything else, i.e. the first option you mention.
The network connectivity, NTP issues and others are the reason why I have Termux installed (to be able to modify the /system/etc/hosts file, as the network core library ignores VPN settings).
Granted, streamlining these apps makes more sense to the end user. I wish Android would have a package manager that would allow creating a meta package for this kind of stuff.
I never used Signal with GServices, so I don't know what you mean with auto backup, nevertheless I simply use the backup function and sync the backup folder with my cloud and it works fine for several years now. For me it seems like a hard constrain to use Telegram which is obviously less secure over Signal only because of an auto backup function. Using Android without GServices always has a compromise part.
I'm all in for android forks, I strongly believe improvements in such forks can be up-streamed for the benefit of the entire ecosystem but I'm yet to see a valid justification for recommending something other than LineageOS for someone new to aftermarket android scene.
As a daily driver, I'd recommend a setup of an official LineageOS device, combined with a set of Apps to increase the level of privacy:
- AppWarden to check for trackers and loggers
- RethinkDNS as a VPN firewall and adblocker
- Privay Browser (f-droid build)
- Permission Manager X to remove permissions from Apps via AppOps
- OsmAnd for Navigation
- Oeffi for Public Transport Navigation (in Germany)
- Element or Telegram FOSS for chat, because Signal still requires microG or other Google Services for their auto backup, which I don't agree with.
I would also recommend to bet on LineageOS because the community is vast, and it's more likely to survive (given the past with Cyanogen and its company) than other forks that are maintained by 1-3 people.
Personally, I hope that phosh and plasma mobile can be feasible app alternatives and I hope that Purism and the Pine movement can change the ecosystem.
But, as of now, developing a GTK4 or QT5 app (compared to making an Android app) is still PITA and seriously lacks better development tools and IDEs.