How does the push notifications system work? - is it truly de-Googled?

My main thing for /e/ is to have a private phone so that means that there will be no services from Google or Facebook to spy on my activity.

One of the things I have found from my searching of alternatives to Google services, is that Google is promoting its Firebase platform as the basis for Android app development, which means that almost every app will be using Firebase going forward:

Google started leveraging its de-facto monopoly on Android distributions by forcing all apps to use its proprietary service Firebase for push notifications. Problem: The Firebase Android client library is proprietary, meaning FOSS apps can not use it. Apps that do not comply are reported to the user as “using too much battery”.

So my question is about this: whether there is any residual association with Firebase for notifications in the /e/ platform. My question comes from a place of newbie ignorance of how push notifications work in Android, and the research I have done this week tells me that there are alternatives to Firebase, though all being proprietary and not as widespread.

I am hoping someone can explain to me how the push notifications work and at what point does Firebase get to have access to my device?

I imagine it to be something like this:

My device needs to maintain an active socket connection to a notification server in order to receive push notifications in real time. Therefore Firebase is Google’s attempt to consolidate and funnel all notifications through one active socket so that a user’s device doesn’t use multiple active sockets and therefore limits the drain on the battery.

But my question is this (and it is because I actually haven’t tested it/don’t want to take the risk of letting Google into my /e/ OS in order to find out), : does Firebase have any connection on my /e/ device after a fresh install of the /e/OS? … and then if I am to download an app that uses Firebase for push notifications, how does Firebase then get to come onto my device in order to maintain a socket for push notifications? … is that something to do with the MicroG platform tools?

I just need someone to explain this to me. Thanks :slight_smile:


On /e/, apps will go through microG to use the firebase service. If you install an app which uses Firebase Messenging, you can go to microG settings, Cloud Messenging, and see the list of apps using the service. You can then click on individual apps to disable the registration to the service. Some apps will have the ability to register to the service (they have the firebase framework installed), but did not use it yet, so they will apear in the “Unregistered” section.

Keep in mind that not all messages received from Firebase are visible. This is why we call it Cloud Messaging: The visible messages are notifications, the invisible one are just messages sent by the server to the app, the app then wakes up and handles it. Sometimes, the devs receive the invisible message, and display a local notification on the device, which can be a lot more complex than simple push notifications. Or they might open a specific page in the app, for example a survey.

You can also disable push notifications globally by toggling “Receive Push Notifications”, or even disabling the Google device registration.

As you saw Firebase is not the only system used for push notifications, but a lot of apps use it because it is free compared to most of the alternatives.

I am not part of the /e/ dev team, but I’ve used Firebase when building apps before and I don’t think the OS is making any call to Google servers on a fresh install. The connection should only be created when one app tries to register the device for cloud messaging.

Would love if a dev could confirm!


Not a dev either, anyway I agree with you !

Thanks for your effort and typing this, was an interesting read.

does Firebase have any connection on my /e/ device after a fresh install of the /e/OS?

currently per default yes, as this aligns with /e/ mainstream idea (I concur) - it’s a spoofed device registration, just go to the microg settings and disable the options as @Keplyx suggested.

a mechanism like Firebase makes sense from a network/battery conserving viewpoint, the more Apps you install that use notifications… this is something that longterm can get a solution, subscribe to ungoogled push messaging solution (#168) · Issues · e / Backlog · GitLab ?

I cite this often, good high level explanation on which requests occur if you use microg by marvin himself:

1 Like

Wow, what is this:

  • is used for device registration, which is a requirement for various other services and push notifications. This happens once per day in the background

Is this the truth, that microG is making a connection once per day to a server? How could it not be the truth, when that is what it says?

It means that any phone that uses microG is not a truly de-Googled phone. How important is microG in /e/OS? Is it possible to compile and run /e/OS without microG?

1 Like

It’s true that it does make sense, but it should be a user’s personal choice to decide who is providing that service. If I want to host my own notification server and have all notifications proxied through it, any app should be able to interface with it. Is there no official protocol standard for mobile notifications that makes it possible?

How can the world simply say “OK Google, I want you to be the only way that anyone can send me realtime notifications”?

The linked document also states that

For all of them, we strip device identifier (MAC addresses, IMEI, etc) from requests where they normally would be (and if required use random but valid identifiers instead).

So using these connections to Google servers has no privacy implications for e/OS/ users.

Any phone that uses the AOSP code as a basis for their OS is not a truly de-Googled phone, since the bulk of that code was written (and copyrighted with an open source licence) by Google.

It is possible to build and run it, but

  1. Behaviour of some apps which rely on microG would be affected, in ways that are hard to predict
  2. It would not be official or unofficial /e/OS, and would have to be a custom build and clearly identified as such.

For a phone OS that does not have microG, take a look at LeOS, created by a guy who was involved with /e/ OS (as a volunteer, not an employee), and contributed a lot to this forum and the /e/ Telegram support channels. The ‘Mini’ and ‘Full’ versions do have microG, but the ‘Nano’ version does not.


WOW! … hopefully you will be the only one who believes that.

I will have to look into that. I have been running my phone for a few days after having disabled the microG as much as possible in e/OS and I can still take photos, record audio, browse internet etc. Maybe it’s just the maps that wouldn’t work, but frankly I have disabled the MagicEarth too because I am against closed-source software on this installation.

That’s useful, thanks I will look into it. BTW, here is the LeOS definition of “de-Googled”:

- All versions are ‘de-googled’. This means that the OS itself does not send unwanted data to Google Server

I wonder what his reason is for having split from /e/OS…

I’m happy to be corrected - seriously - if I’m wrong. The AOSP home page says

Android is an open source operating system for mobile devices and a corresponding open source project led by Google

If Google did not write most of the Android code, who did? Genuine question.

Looking at some of the AOSP Github repos, the few code files I have looked at contain the following

/ Copyright (C) 2016 The Android Open Source Project
// Licensed under the Apache License, Version 2.0 (the "License");

So the copyright is held by AOSP, a project ‘led by Google’, and licensed under the Apache Open Source License. If you’re using any Android-based device OS, you are using code created by Google. Or is it OK to use code created by Googles, and the work of a project led by Google, but not OK to use APIs provided by Google, even with spoofed, stripped or random data? Where you choose to draw the line is up to individuals users, developers, ROM creators.

I don’t think that open source map software (e.g. OSMAnd+, Organic maps) would run too well without microG providing location services.

And the microG author himself states (in the linked github post):

In general, we obviously try to minimize the connections to Google, but some services strictly rely on them and would just not work without. Blocking any network requests of microG will thus result in something not working as expected.

But two of the three LeOS versions include microG - in the same way as /e/ OS includes it. I suppose you can argue that it is microG, not the OS that does the sending, but if that is true for LeOS, then it is also true for /e/ OS. Or you could accept that microG doesn’t in fact send any useful (or “unwanted”) data to Google: it connects to the Google APIs in order to provide services to make the phone work for most users, and, where it does send data, that data is stripped of useful information, or contains ‘valid but random data’.

As I recall, he didn’t like /e/'s selection of default apps - he used the Simple Mobile Apps suite in his own devices - and he particularly objected to the inclusion of microG’s Exposure Notification Framework, which he felt was incompatible with user privacy. His forum user name was harvey186 - search for that and you will find some of his posts.


Having code written by Google on your device is not the same as having Google on your device. To have Google on your device implies that the entity we know as being Google (ie: the corporation) is literally present and operating within the system.

If an Operating System is only operating in such a way so as to not be interacting with the entity known as Google, then it really cannot be said that the entity is operating on the device. It can be said that the Operating System is mostly developed by the entity of Google, but if all activity of the Operating System is interacting with services that are not informing Google, then it cannot be said that Google is in any way receiving (ie: “being sustained by”) my device.

It isn’t really a subjective definition as such. Any time that Google is receiving information from my device or my device is relying upon Google, there is the fact that my device is interacting with Google.

If on the other hand, all information sent by my device and all incoming push notifications are proxied through my own notification server, then in fact Google has become a client rather than a component of my device. In such a model, Google’s Firebase Push Notifications would be an option for app developers to select alongside other existing options such as Amazon SNS, OpenPush, parseplatform . org, Pusher . com etc,

… or if the situation was as good as it ideally should be, then there would be a global registry of sorts so that every device user can register their preferred delivery service in a similar way that domain names are registered and propagated. As it is in the present form however, an app developer decides on which push notification service to use and the user of an app has to decide whether they are comfortable with committing themselves to that service.

In addition to that, Google seems to have taken a somewhat unethical approach by coercing users through fear that an app is untrustworthy when it uses a service in order to bypass Google’s own Firebase service. I think this corresponds quite succinctly with the shift in culture at the corporation in recent times.

Just accepting that running Google code on my phone means having Google on my phone in some way, shape or form is conceptually way more clear than drawing an arbitrary line between Google code running on my phone and Google code running on my phone and having to explain how I have no problem with the one but a problem with the other.

I’m not saying one view on the matter is more legitimate than the other here, I’m just wondering what would be so surprising about there being a different view on the matter.

1 Like

The difference is that you aren’t running Google on your phone if you are only running code that Google has written. The code itself isn’t Google in any way, it is mostly Java and C (compiled to binary).

The company being Google is an entity, which means that it has a legal status similar to personhood (except that it cannot be jailed), and as such it has a living presence in the world among the ranks of gods (the ones potentially immortal and powerful, reigning over humans).

I suppose that is fair.

From what you’ve written, it seems that you draw your line in a different place from me which is fine. Enjoy using /e/ OS in a way that works for you :slight_smile:


It’s actually that we are using language differently, because while you say that using Google’s products is the same as having Google on your device, I say that it doesn’t necessarily mean that Google is operating on my device.

It would be similar to saying that if I use an Operating System developed by Linus Torvalds then I have Linus on my device. But I think we can all agree that using Linux does not mean that the developers of Linux are actually operating on our devices.

Where we draw the line differently is as to the benefit of identity spoofing when it interfaces with Google’s services. While you believe that it is sufficient to guard the identity of the user and therefore make him appear as an anonymous user, I do not make the same assumption. I believe that Google itself is much better equipped to draw useful conclusions by making assumptions of its own so that the only real way to be sure that Google is truly decoupled from the device is to remove all connections that the device is making to it.

Thanks! :slight_smile: I have found the /e/ OS has been incredibly good for battery and stability, and only three things are what I would want to be doing differently, of which one I am already working on and 80% to a working prototype. I do like the /e/ OS!

This topic was automatically closed after 19 days. New replies are no longer allowed.