De-Google your Android app: An incomplete List for Reducing Your Dependency on Firebase

Why Firebase compromises Privacy‑First Design

Google’s Firebase is a great help in app development because it saves time and makes development more convenient. However, this convenience comes at a price: dependency on and data sharing with Google, a price that an increasing number of app users are no longer willing to pay.

The good news is that apps can work without Google if you prepare accordingly. To reduce an app's dependency on Firebase, you first need to understand how closely Firebase is linked to Google Play Services. For iOS apps, Google Play Services are not pre-installed on Apple devices, most of this article is therefore more relevant to Android apps.

What does Google Play Services do on Android?

Because Google Play Services is so widespread, Android apps’ code often assumes that it is available on every device. Without these services, many apps therefore do not function fully, simply because the development team has not given it much thought. Almost every Android phone comes with Google Play Services pre-installed. They are invisible, run in the background and connect a device to a Google account and services such as Gmail, Google Maps or Google Photos. These services are also a powerful bundle of background services and interfaces that deeply integrate with the Android operating system. They often cannot be disabled or uninstalled without rooting/modding the system.

Essentially, this is what Google Play Services does:

• Push notifications: Closely integrated with Google's Firebase Cloud Messaging (FCM).
• Synchronization of personal data: Contacts, calendars, photos and emails are synchronized centrally with Google via Play Services. This makes many things convenient, but it also means that Google can create very detailed profiles.
• Location services: Google Play Services regularly records your location, even when you are not using a navigation app or similar. This allows installed apps to query your location more quickly. Location access is also possible without Google Play Services, but some functions are then restricted or do not work.
• Payment processing: In-app purchases and Google Pay.
• Authentication: Single sign-on enables users to log in with their Google account.
• Security-related functions: Malware checks and verification that apps from the Play Store are correctly licensed. Also includes theft protection: ‘Find My Device’ and the ability to lock or wipe a lost device.

Google Play Services can therefore be very helpful in shortening the time taken to develop apps. However, I like to ask whether a modern app should also be able to function without Google Play Services.

Your Android app without Google Play Services

An Android app that does not rely on Google Play Services is just as useful as apps that assume these services are available on the device. The difference lies in the development hours, maintenance effort, and infrastructure costs to ensure that the app remains usable on any device, independently of Google Play Services. A growing number of Android users no longer have Google Play Services on their devices or want to have less to do with Google for privacy reasons.

Three ideas to prepare your app for ‘De-Googling’:

• Look for alternatives to Firebase that suit your app’s goals, there are very good products that have no interest in personal tracking. See concrete suggestions below.
• Additionally, publish your app in an alternative store such as F-Droid or as a direct download, and then collect feedback from people with Google-free devices.
• Investigate which app functionality requires Google Play Services and build in pragmatic fallbacks, a standard Android emulator without Google Play Services can be helpful in finding weak points.

Does your current app work on Google-free phones?

Some dependencies are obvious: If the app crashes or the main feature doesn't work because there are no Google services on the device. But other dependencies only become apparent over time: for example, when an app needs a tracking ID that is dependent on Google. There can be dependencies on specific apps commonly found on Android devices, such as Google Fit, Google Maps and Gmail.

Are there any Android apps that are completely Google-free?

An increasing number of apps are developed independently of Google services. These can run on alternative Android systems such as /e/OS from Murena or LineageOS. Their characteristics are usually:

• They do not use Google-specific interfaces by default.
• Could be available via alternative app stores (e.g. F-Droid, App Lounge, Aurora Store, etc.) or directly as an APK file.
• Run smoothly on Google-free Android devices.

Reducing Firebase dependencies

Google Firebase is particularly attractive to indie developers and start-ups, as it can be used without complex server infrastructure and without additional costs. Firebase has the advantage of being easy to integrate into apps and offers high scalability without developers having to worry about infrastructure. So from an app development perspective, Google Firebase is undoubtedly of good help. However, when you change your perspective to that of the user, it becomes clear that Google Firebase compromises user privacy. This is because Google collects and processes potentially sensitive data, sometimes without the user's knowledge. During testing, data protection experts often find that immediately after an app is launched, data is transmitted to Google Firebase servers in the United States without the user having been informed or given their consent (Source, in German: https://www.kuketz-blog.de/google-firebase-verlockend-fuer-entwickler-datengrab-fuer-nutzer/). If configured properly, Firebase should actually be GDPR-compliant, but many developers using Firebase seem to struggle to get this right.

Many apps rely on Firebase Cloud Messaging (FCM) for push notifications, which requires Google Play Services. Other common uses of Firebase include crash reporting (Crashlytics), activity tracking (Analytics) and authentication. With the EU's Digital Markets Act and new Android operating system variants, the ecosystem is slowly becoming more diverse.

Breaking down the multiple parts of Firebase, it becomes easier to understand when data flows to US servers when Firebase runs. As of 2025, many Firebase services primarily store and process data in US-based data centers by default, requiring GDPR safeguards for data coming from the European Union for example. Developers must opt into EU locations explicitly in this case.

• Support EU servers: Cloud Firestore and Realtime Database.
• Remain US-bound: Analytics and Crashlytics.

Push notifications

Firebase Cloud Messaging (FCM) is a central component of Firebase. Alternatives have long been available for analytics, crash reporting, maps and authentication. However, when it comes to push notifications, switching away is often the last major hurdle. Currently, FCM excels due to system-level optimization with low battery drain, but there has been ongoing criticism that Google’s control of both Android and FCM creates lock‑in and competitive concerns, I think it is realistic to expect alternatives to FCM to become better through antitrust regulations that will affect Android’s ecosystem.

Here are three examples of how push notifications can work without FCM:

• Your own solution with WebSockets: The app maintains a permanent connection to your own server. As soon as an event occurs, a notification is triggered immediately. Examples: Signal Messenger and the email app Tutanota are open source and use WebSockets for this purpose.
• Alternative push services such as Pushy or Airship: These services work without Google, but often have their own limitations and costs. They are usually not open source and may also collect data.
• Open source with Server Sent Events (SSE): Some projects rely on SSE or their own protocols to implement push notifications.

Some apps use these alternatives as a fallback to FCM. However, if Google Play Services are available, they prioritise FCM for more energy-efficient notifications.

Crash reporting

I remember well when I first integrated Crashlytics into a live app in 2014: suddenly, error analysis became much easier and faster. Live use always brings surprises. Without crash reporting, debugging often feels blind, with fixes taking weeks. In 2017, Crashlytics became part of Google, and one of the goals of the acquisition was to attract more developers to Google's Firebase development platform. Today, there are many tools that do not send anything to Google and provide much better anonymisation.

Which crash reporting tools only collect the data necessary for error analysis? There are powerful alternatives that provide accurate error reports without data hunger:

• Sentry: Open source, runs on your own servers or as a cloud service. Anonymises data by default and offers full control over the information collected. In my experience, Sentry meets crash-analysis needs better than Crashlytics.
• Bugsnag: Strong alternative, supports many platforms, offers granular control over data.
• ACRA: For Android, open source and completely self-hostable. You decide where the data goes and how much you collect.

Privacy-friendly crash reporting is particularly worthwhile for projects with sensitive user groups. Integration is usually straightforward, and the range of functions allows for effective crash analysis.

App tracking

Many tracking SDKs do not truly anonymise data, and their business models incentivise data collection. But there are analytics tools that think differently from the ground up: they don't want personal data, just the insights you really need from your app. Firebase Analytics is Firebase's main product because it's the most interesting for Google's business model. But there's no longer any reason to settle for the old tools. Try this test with your current analytics SDK: Install and open your app, and see which network connections are made from the SDK without your consent as a user. If you are on a Mac using an Emulator/Simulator, I’ve found “Little Snitch” to be very helpful (https://obdev.at/products/littlesnitch/index.html).

Here are some examples of useful app tracking products without Google:

• TelemetryDeck from Germany has focused on data protection and anonymisation from the outset. It does not process any personal data, but aggregates usage data in such a way that conclusions about individual persons are impossible. The business model is based on subscriptions, not data trading.
• Plausible Analytics from Estonia: Open source, no persistent identifiers, also subscription-based.
• Piwik Pro from Poland: focus on privacy and data security, GDPR-compliant.
• Matomo from New Zealand: Open‑source, can be self‑hosted or run in an EU cloud, offers IP anonymization, and no Personally Identifiable Information by default

Many of these solutions do not use aggressive user identification and focus on transparency. They provide you with the necessary metrics without your users having to sacrifice their privacy. Furthermore, the General Data Protection Regulation (GDPR) does not apply to anonymised data. Anonymised analytics tools thus reduce one compliance worry. Keep in mind that self-hosting requires developer configuration efforts to avoid leaking personally identifiable information.

App authentication, data and storage

If you'd rather not use a platform that prefers to keep data to itself, you can check out these alternatives:

• Supabase is one of the best-known open source solutions. It offers authentication, a powerful PostgreSQL database and file storage, all integrated directly. Supabase is GDPR-compliant, can be self-hosted, and gives you full control over all data. You can use role-based access rights, which is not possible with Firebase at such a granular level.
• Appwrite is another powerful tool that offers authentication, databases, and storage out-of-the-box. It is completely open source, supports various database types, and runs on your own infrastructure.
• Back4App is based on the Parse platform and is particularly exciting for no-code and low-code projects. It offers an intuitive interface, real-time synchronization and flexible hosting options. The platform supports both SQL and NoSQL and offers you more database freedom than Firebase.

All three solutions refrain from hidden data collection and allow you to keep user data anonymous.

Constantly weighing up

There are many reasons to avoid Google services. Data protection and compliance are at the forefront: by not passing on user data to third parties, you minimise the risk of data leaks and retain control over sensitive data. Independence from large tech companies is also becoming increasingly important, especially when it comes to critical infrastructure.
But there are also arguments against it: Google services often offer a smooth user experience, are cost-effective and easy to integrate. Developers save time because they can fall back on widely used solutions. Independence means more short-term effort: you have to develop your own alternatives or rely more on open source solutions, which sometimes involves higher costs and longer development cycles.

What are you willing to accept when you ‘De-Google’ your app?
You gain sovereignty and data protection, but you may lose convenience in app development in the short term and have to live with technical hurdles at the beginning. Striking the right balance remains a challenge.
Those who act now will remain independent and gain credibility for the future. Just start with a pragmatic fallback.

About the author

Sebastian began his career as an app developer in 2011 by building an Android Sudoku app and playing it on a modified iPhone 3G running Android Gingerbread. Over a decade later, he still loves the 'open' Android ecosystem, although he is quick to point out that, based on his experience, this openness tends to end where Google's data pipeline begins. These days, he explores how apps can benefit from open-source to perform better on de-Googled phones and offers this as a service to his clients. You can reach Sebastian via LinkedIn.