4

I've been running Android for maybe 2 years without Gapps or a Google account, and like the experience, but I'd also like to do it better because some apps I used to use, now don't run without some Google services. I researched NoGapps but don't quite understand the information well enough, and the different packages available, to know what I need.

It looks like these are packages that simulate the Google play store and main services APIs but return either null data, minimal responses, or data from other open source providers? But I can't find a clear explanation what options there are, and the main differences between them, to help me choose what to install.

My current phone is lineage 14.1 + SuperSU 2.79 on a Samsung S7 G930F, and I don't use the Play Store (I use FDroid and sideloading).

Update

Just to clarify (following @Izzy's excellent "basics" reply so far), the main issue thinking about it isn't so much "which of these packages can I use to replace a Google library".

The real issue is, to what extent do these No Gapps alternatives meet the presumed goal of allowing software to still work (by faking a playstore/location provider/other service that they expect GApps to have provided), but also in reality sanitising or avoiding actually using Google for these, or reducing and making clear what data is sent to Google if it's used.

So for example, Fakestore sends nothing to Google, period, its job is to fake that Google Play Store is installed and its Android API working, but unfortunately unreachable/empty. But for the rest, it's really hard to know what's still sent and what's sanitised or not sent. If all there is, is a FOSS reimplementation of a Google Library, same data, same auth, mostly same logging/datamining, that's a bit weak and unfortunate, even if unavoidable. If Nlp can fully avoid Google and use more trustworthy sources, that's better. But this is the kind of information and discussion I can't find details about.

I'm realistic here - a person who wants an app that needs Google Push Notifications, has to either fake that functionality as installed but not responsive, or use code that cleans the data and does data leak avoidance as best possible, or must accept they can't use that app. But the information needed for that decision is clarity as to what these NoGapps softwares can do, to minimise or avoid data leaks, and how far they can go to distangling from Google.

That's pretty central to "why I want to use them". I'd like to be clearer what their compromises are and what's possible or not, in terms of data and info passed to Google, and I'm not, which is all that stops me enjoying them ATM.

10

Some basics first:

  • NoGAPPS is deprecated and got replaced by its successor, µG (read: microG).
  • µG includes the core (basically, GServices) and also UnifiedNlp.
  • No GService replacements will support the Google License API. That's much too hot an area. While we all love dentists, we better not see them working on us (replace "dentists" by "lawyers" in this context).
  • there are ways to access PlayStore, though, and you've mentioned some candidates:
    • BlankStore: Deprecated, no longer maintained except for bugfixes, but its successor not yet ready. Supports only free apps.
    • FakeStore: As the name suggests, only a "fake" – i.e. it fakes the presence of Playstore to apps not working otherwise.
    • Yalp: Like BlankStore but still maintained, plus supporting apps you've already bought (but not the process of buying and not the license check some paid apps perform).
    • More candidates in my corresponding app list.

I'm running that combination (CyanogenMod + µG with UnifiedNlp + BlankStore/Yalp) for about 2 years now. The only thing I found not working was paid apps that wished to verify their license against GPlay – apart from that, everything runs smoothly. For details, you might wish to see my article series on Android without Google. Note that, however, there seem to be some issues concerning LOS 14.x and UnifiedNlp currently; for details, please check with the issue tracker on µG's Github presence.

You can find the implementation status in the project's wiki, as well as a short introduction. In terms of privacy, you can derive from those two:

Acting as a replacement for the closed-source Google Apps (GAPPS), it is a powerful tool to reclaim your privacy while enjoying Android core features.

(from the introduction; emphasis mine). In the implementation status, take a closer look at two columns: Functionality and Crashing. If both are "No", we have a dummy: Apps think it's there, but absolutely nothing is happening in there (especially no data transmission); this is and always will be the case for Analytics and Ads, for example. No functionality and crashing means there's nothing implemented (not even a dummy) – so apps accessing that might crash, but again nothing is transmitted (currently e.g. Auto and Cast).

If data is transmitted, to my knowledge this is limited to the absolute minimum for the functionality to be achieved. This e.g. includes Google Cloud Messaging (token, id and obviously the message must be exchanged, where the latter is usually incoming only), Account Authentication (guess what: account name and token/password must be sent for that, or there can't be an authentication), Maps API (must obviously send the desired position for the tiles to be retrieved – but this doesn't go to Google, as it uses OpenStreetMap/OpenScienceMap instead). Fused Locations doesn't run via Google either, as it uses the UnifiedNlp backends instead.

  • 1
    That's really helpful basics, thanks. Thinking about it, what's not clear to me (and matters) is, how much each of these just re-implements as FOSS the same Google API calls (and hence still raises the same basic issues just via different middleware), or needs a Google login, etc), and how much they do detach you from Google. I'm realistic, if you want Google notifications/email/search/voice/calendar, it's realistic that Google will datamine it en route. But there's no clear information for most of these about what's been detached from Google vs what's relayed to them, which would help loads – Stilez May 11 '17 at 22:06
  • See my update, hope it's clear now. Speaking of "clear": I will clear out the now redundant comments which I integrated with the answer already :) – Izzy May 12 '17 at 7:06
  • Thanks - that really is clear! One last question (optional) - is there anywhere a list of exactly what data and/or tracking capability is inevitable, for each Google library function, to get a sense of "Using feature/API X, isn't possible unless one lets Google have data Y; however you can randomise the tokens or wipe them each time for at least data Z"? That would be very wonderful, but if it exists, I can't find it – Stilez May 12 '17 at 15:23
  • I'm not aware of that, and rather deal with it "by my guts" (e.g. with Xprivacy, randomizing things like location, device IDs etc.). But what data exactly is sent in which context is beyond my knowledge. If you really want to investigate that, you'd have to "snoop" the network packets I'm afraid – unless someone had already done exactly that, and you can turn up the results. Though even that might change with new versions of the services/apps… – Izzy May 12 '17 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.