Repository files navigation

This repository contains the source code for all Android Firebase SDKs exceptAnalytics and Auth.

Firebase is an app development platform with tools to help you build, grow andmonetize your app. More information about Firebase can be found athttps://firebase.google.com.

1. Getting Started
2. Testing
   1. Unit Testing
   2. Integration Testing
3. Proguarding
   1. APIs used via reflection
   2. APIs intended for developerconsumption
   3. APIs intended for other FirebaseSDKs
4. Publishing
   1. Dependencies
   2. Commands
5. Code Formatting
6. Contributing

• Install the latest Android Studio (should be 3.0.1 or later)
• Clone the repo (git clone --recurse-submodules git@github.com:firebase/firebase-android-sdk.git)
  • When cloning the repo, it is important to get the submodules as well. Ifyou have already cloned the repo without the submodules, you can update thesubmodules by runninggit submodule update --init --recursive.
• Import the firebase-android-sdk gradle project into Android Studio using theImport project(Gradle, Eclipse ADT, etc.) option.
• firebase-crashlytics-ndk must be built with NDK 21. Seefirebase-crashlytics-ndk for moredetails.

Firebase Android libraries exercise all three types of tests recommended by theAndroid Testing Pyramid.Depending on the requirements of the specific project, some or all of thesetests may be used to support changes.

⚠️Running tests with errorprone

To run with errorprone addwithErrorProne to the command line, e.g.

./gradlew :<firebase-project>:check withErrorProne.

These are tests that run on your machine's local Java Virtual Machine (JVM). Atruntime, these tests are executed against a modified version of android.jarwhere all final modifiers have been stripped off. This lets us sandbox behaviorsat desired places and use popular mocking libraries.

Unit tests can be executed on the command line by running

./gradlew :<firebase-project>:check

These are tests that run on a hardware device or emulator. These tests haveaccess to Instrumentation APIs, give you access to information such as theAndroid Context.In Firebase, instrumentation tests are used at different capacities by differentprojects. Some tests may exercise device capabilities, while stubbing any callsto the backend, while some others may call out to nightly backend builds toensure distributed API compatibility.

Along with Espresso, they are also used to test projects that have UIcomponents.

Before you can run integration tests, you need to add agoogle-services.jsonfile to the root of your checkout. You can use thegoogle-services.json fromany project that includes an Android App, though you'll likely want one that'sseparate from any production data you have because our tests write random data.

If you don't have a suitable testing project already:

• Open theFirebase console
• If you don't yet have a project you want to use for testing, create one.
• Add an Android app to the project
• Give the app any package name you like.
• Download the resultinggoogle-services.json file and put it in the root ofyour checkout.

Integration tests can be executed on the command line by running

./gradlew :<firebase-project>:connectedCheck

You need additional setup for this to work:

• gcloud needs to beinstalled on local machine
• gcloud needs to be configured with a project that has billing enabled
• gcloud needs to be authenticated with credentials that have 'Firebase Test Lab Admin' role

Integration tests can be executed on the command line by running

./gradlew :<firebase-project>:deviceCheck

This will execute tests on devices that are configured per project, if nothing is configured for theproject, the tests will run onmodel=panther,version=33,locale=en,orientation=portrait.

Projects can be configured in the following way:

firebaseTestLab {  // to get a list of available devices execute `gcloud firebase test android models list`  devices = [    '<device1>',    '<device2>',  ]}

Firebase SDKs use some special annotations for tooling purposes.

APIs that need to be preserved up until the app's runtime can be annotated with@Keep.The@Keepannotation isblessed to be honored by android'sdefault proguardconfiguration. A common use forthis annotation is because of reflection. These APIs should be generallydiscouraged, becausethey can't be proguarded.

APIs that are intended to be used by Firebase SDKs should be annotated with@KeepForSdk. The key benefit here is that the annotation isblessed to throwlinter errors on Android Studio if used by the developer from a non firebasepackage, thereby providing a valuable guard rail.

We annotate APIs that meant to be used by developers with@PublicAPI. Thisannotation will be used by tooling to help inform the version bump (major, minor, patch) that isrequired for the next release.

Firebase SDKs do not proguard themselves, but support proguarding. Firebase SDKs themselves areproguard friendly, but the dependencies of Firebase SDKs may not be.

In addition to preguard.txt, projects declare an additional set of proguardrules in a proguard.txt that are honored by the developer's app while buildingthe app's proguarded apk. This file typically contains the keep rules that needto be honored during the app' s proguarding phase.

As a best practice, these explicit rules should be scoped to only librarieswhose source code is outside the firebase-android-sdk codebase making annotationbased approaches insufficient.The combination of keep rules resulting from theannotations, the preguard.txt and the proguard.txt collectively determine theAPIs that are preserved atruntime.

Firebase is published as a collection of libraries each of which eitherrepresents a top level product, or contains shared functionality used by one ormore projects. The projects are published as managed maven artifacts availableatGoogle's Maven Repository. This section helpsreason about how developers may make changes to firebase projects and have theirapps depend on the modified versions of Firebase.

Any dependencies, within the projects, or outside of Firebase are encoded asmaven dependenciesinto thepom file that accompanies the published artifact. This allows thedeveloper's build system (typically Gradle) to build a dependency graph andselect the dependencies using its ownresolutionstrategy

For more advanced use cases where developers wish to make changes to a project,but have transitive dependencies point to publicly released versions, individualprojects may be published as follows.

# e.g. to publish Firestore and Functions./gradlew -PprojectsToPublish="firebase-firestore,firebase-functions" \    publishReleasingLibrariesToMavenLocal

Developers may take a dependency on these locally published versions by addingthemavenLocal() repository to yourrepositoriesblock inyour app module's build.gradle.

N/A for now

Kotlin code in this repo is formatted with thektfmt tool. You can enablethis formatting in Android Studio by downloading and installing thektfmt plugin.Enable the plugin in Preferences | Editor | ktfmt Settings. and set code style to Google (internal).

To run formatting on your entire project you can run

./gradlew :<firebase-project>:ktfmtFormat

We love contributions! Please read ourcontribution guidelines to get started.