firebase/quickstart-android: what the samples actually demonstrate

Fifteen samples, one per Firebase API, and no shared library

The repository is a collection of quickstart samples demonstrating the Firebase APIs on Android. Each entry in the top-level list is its own Android Studio project: admob, firebase-ai, analytics, appdistribution, auth, config, crash, database, dataconnect, firestore, functions, inappmessaging, messaging, perf, storage. The README states that you open each one as an Android Studio project and run it on a mobile device or a virtual device.

That structure answers a narrow question well. If you want to see how Cloud Messaging is registered in a manifest, or where an Analytics call sits relative to an Activity lifecycle, the sample is right there with the surrounding Gradle files intact. The audience is an Android developer who already knows the platform and needs the Firebase-specific glue. It is not a tutorial for someone learning Android, and it is not a starter template you fork and keep building on. Nothing in the repository layout suggests a published Maven artifact; the top level holds build.gradle.kts, settings.gradle.kts, gradlew, and the sample directories, which is the shape of a multi-project Gradle build used for building and testing the samples themselves.

The applicationId is the hinge between the sample and your Firebase project

Every sample needs a google-services.json file, and that file is generated per Android package name. The README is explicit about the sequence: add each sample app you wish to try to a Firebase project in the Firebase console, and use the applicationId value specified in the app/build.gradle file of that app as the Android package name. You then download the generated google-services.json and copy it into the app/ directory of the sample you want to run.

Two consequences follow. First, the top-level README does not print the applicationId values; it tells you to go read app/build.gradle. Second, you can add multiple sample apps to the same Firebase project, so there is no need to create a separate project for each one. That is the main operational detail in the whole document, and it is the step people get wrong: a google-services.json generated for one package name will not authenticate a sample whose applicationId differs.

The repository also carries mock-google-services.json at the top level and a copy_mock_google_services_json.sh script, plus a scripts/ directory. Those exist so the samples can build in CI without real credentials. If you are reading the build configuration to understand how a sample is wired, expect to meet the mock path rather than a real project file.

Opening a sample in Android Studio and running it for the first time

There is no package to install. You clone the repository, pick a sample directory, and open it in Android Studio. Before the app will talk to Firebase you need the applicationId from that sample's app/build.gradle and a matching google-services.json.

The README points at app/build.gradle as the source of the package name, so open that file in the sample you want and read the applicationId value it declares. Take that value, register it in the Firebase console as the Android package name, and download the generated file. The README then says to copy that file into the app/ directory of the sample you wish to run, so it goes next to the module's build file, not at the repository root.

From there, open the sample as an Android Studio project and run it on a device or an AVD, which is the workflow the README describes. If you would rather build from the command line, the repository ships a Gradle wrapper at the top level. What you should see is the sample's own UI, and the individual sample READMEs (for example auth/README.md) are where the per-API setup beyond this is documented.

Where the samples stop being useful

These are demonstrations, and the README frames them that way. A sample shows one API doing one thing on a screen. It does not ship error handling for the cases you will hit in production, and it does not present an architecture you would want to copy into a large app. Treating the auth sample as a starting point for a real sign-in flow means you inherit its shape and then rewrite most of it.

The bigger friction is the credential model. The README's instructions assume you are running the sample yourself against your own Firebase project, and the repository's own CI works around this with mock-google-services.json and copy_mock_google_services_json.sh. There is no documented path in the top-level README for running the samples against a shared or preconfigured backend, so anyone expecting to clone and immediately see data flowing will be stopped at the console step.

Finally, the samples are independent projects. There is no umbrella app that launches all fifteen, and the top-level README does not describe a combined build. If your goal is a single demo APK covering several Firebase products, this repository does not give you one.

How this differs from Firebase documentation and from a starter template

Firebase's own product documentation explains each API in prose and isolated snippets. This repository is the opposite trade: complete, compilable Android projects where the snippet is surrounded by a real manifest, real Gradle configuration, and a real Activity. When a doc snippet fails to compile because a plugin or a dependency is missing, the sample is where you find what was omitted.

It also differs from a starter template in intent. A template is meant to be forked and extended; the README here describes opening samples and adding them to a Firebase project, which is a read-and-run loop. The repository carries CONTRIBUTING.md and an Actions workflow, so contributions flow back into the samples rather than into forks, and the .editorconfig and .github/ entries reinforce that this is a maintained upstream collection rather than a scaffold handed to you.

The practical difference: use the official docs to understand an API, and use this repository to see that API assembled into a working Android project.

Maintenance, licensing and what an upgrade costs you

The repository is not archived, and its last push was on 2026-09-20. The default branch is master. There are no retrieved releases, which fits a samples repository: the unit of change is a commit to a sample, not a versioned artifact, so there is no changelog to read and no version to pin.

That shapes the upgrade cost. You are not upgrading a dependency; you are re-reading a sample after it changes. If you copied code out of one, the cost of keeping up is noticing when the sample's Gradle files or API calls move, and there is no release note telling you. The repository's Actions workflow is the signal that the samples are built on every push, which is the closest thing to a compatibility guarantee the material offers.

Licensing is Apache-2.0, stated in the LICENSE file at the top level. That is a permissive licence, and the practical implication for a reader is that copying sample code into your own project is contemplated by the licence. This is not legal advice, and the samples also depend on Firebase SDKs that carry their own terms, which the repository does not restate.

Editorial conclusion

Adopt it when you need a working reference for one Firebase API and want to see the Gradle wiring, the applicationId, and the google-services.json placement in context. Do not adopt it as a dependency or as a production codebase: nothing here is published as an artifact, and each sample is a standalone Android Studio project. Before you start, open the sample's own README and its app/build.gradle to confirm the applicationId you must register, because the top-level README only points you at that file rather than listing the values.

Frequently asked questions

Official sources

1. firebase/quickstart-android on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README