018b - Firebase Project + RTDB + Authentication Setup

Shared classroom backend setup (Email/Password, no Google OAuth)

This lesson is based on the tested flow in video CMvpeYQm5xo and its local captions file captions/captions.CMvpeYQm5xo.sbv.

Goal of this lesson:

  1. Connect the Android app to Firebase.
  2. Create a Realtime Database.
  3. Enable Firebase Authentication (Email/Password only).
  4. End with a setup that can be switched to another shared backend by replacing google-services.json in a separate commit.

Important scope for this lesson:

  • We do not enable Google OAuth provider here.
  • We do not configure production security rules yet.
  • We focus on a classroom-ready setup that works fast.

This is a NO-CODE lesson:

  • No manual Java/Kotlin edits
  • No manual XML edits
  • No manual Gradle text editing
  • Only Android Studio GUI actions and Firebase Console actions

Video + Time Points

Suggested checkpoints:

  • Open Firebase Assistant in Android Studio: 00:10
  • Connect app to Firebase + create project: 00:52, 01:10
  • Disable Google Analytics during project creation: 01:31
  • Confirm connected + google-services.json appears: 02:28, 02:39
  • Create RTDB in this project: 03:12
  • Region and test mode: 03:35, 03:42
  • Update Rules for learning mode: 04:06
  • Add Authentication SDK (Accept changes): 04:50
  • Fix “user create failed” by enabling Email/Password provider: 06:47, 07:02
  • Validate register/login success: 07:45, 08:10
  • Validate in Firebase console (Auth user + RTDB activity): 08:39

Prerequisites

  • Start from the project state after step 018a.LoginActivityFromGui.md (or at least after 017DuplicateAndAddActivityToMenu.md).
  • Project builds and runs before Firebase setup.
  • You are signed into Android Studio with a Google account.

Classroom onboarding modes (decide before class)

Mode A - Connect to teacher/shared backend first

  • Teacher or student-lead prepares one Firebase project in advance.
  • Students start by plugging in the provided google-services.json.
  • This gives fast classroom start and immediate interoperability.
  • Later, students can still create their own Firebase project as a separate exercise.

Mode B - Each group creates its own shared backend in lesson

  • Follow all lesson steps as written.
  • Each group ends with one shared Firebase project.
  • Inter-group switching remains possible via the separate JSON-switch commit.

Step 1 - Open Firebase Assistant and start connection

In Android Studio:

  1. Open Tools -> Firebase.
  2. Select setup flow for Authentication first (as shown in video).
  3. Choose the Java app path and click Connect to Firebase.

The video starts with Auth side first, then RTDB creation in console.

Step 2 - Create Firebase project from Assistant flow

During Connect to Firebase:

  1. Click Create a Firebase project.
  2. Give the project a clear name.
  3. Click Continue.
  4. Disable Google Analytics for this lesson.
  5. Click Create project.

Expected result:

  • Android Studio shows the project as connected.

Step 3 - Confirm Android-side artifacts

After connection, verify:

  1. google-services.json exists in the app module.
  2. Assistant status changes from not connected to connected.
  3. Gradle sync completes successfully.
  4. The app package (applicationId) matches an Android client inside google-services.json.

If sync fails, stop and fix this before moving on.

3.1 Common clone/switch error: No matching client found for package name ...

Typical error:

Execution failed for task ':app:processDebugGoogleServices'

No matching client found for package name 'com.example.tictactoe' in .../app/google-services.json

What this means:

  • google-services.json is not just “for Firebase project X”
  • It is also tied to a specific Android app registration inside that Firebase project
  • The Gradle Google Services plugin checks your app package (usually defaultConfig.applicationId)
  • If no matching package exists in the JSON, build fails

This is very common when:

  • You clone/duplicate a project and change package name
  • You copy google-services.json from a sibling project with a different package
  • Students reuse a shared backend but each app uses a different package name

Copying google-services.json from an existing project is fine only if the package matches.

You do not need to create a new Firebase project to fix this. Usually you only need to add another Android app to the same Firebase project.

If your app package is com.example.tictactoe but the copied JSON belongs to another package (for example com.example.tictacmenu):

  1. Open the existing Firebase project (the one you want to reuse).
  2. Go to Project settings -> General.
  3. In Your apps, click Add app -> Android.
  4. Enter the exact package name from your Android app (applicationId), e.g. com.example.tictactoe.
  5. Register app.
  6. Download the new google-services.json.
  7. Replace app/google-services.json with this new file.
  8. Sync Gradle and rebuild.

This reuses the same Firebase project / RTDB / Auth backend. You are adding a new Android client registration, not creating a new Firebase project.

You can also make the Android app package match the copied JSON (for example by changing applicationId back).

Use this only if you intentionally want the cloned project to keep the original package identity.

Risks:

  • Can break manifests/imports/package declarations if done partially
  • Creates confusion later when multiple projects look different but share the same package

For classroom cloning, it is usually cleaner to keep each project package as-is and register that package in Firebase.

3.4 Quick check before blaming Firebase

Compare:

  • Android app package: app/build.gradle -> defaultConfig.applicationId
  • Firebase JSON package: google-services.json -> client[] -> client_info -> android_client_info -> package_name

They must match for the variant you are building.

Step 4 - Create Realtime Database in the same Firebase project

In Firebase console for the project you just created:

  1. Open Realtime Database.
  2. Click Create database.
  3. Choose the region shown in the video (US region).
  4. Start in test mode.

Test mode is for classroom development only.

Step 5 - Rules for classroom development

In RTDB Rules, keep classroom-open rules for this stage:

  • read: true
  • write: true

Publish rules.

These rules are intentionally insecure and must not be used in production. Security rules will be taught in a later step lesson.

Step 6 - Add Authentication SDK changes from Assistant

Back in Android Studio Assistant:

  1. Add Authentication dependency changes.
  2. Click Accept changes.
  3. Sync project.

Expected result:

  • App compiles with Firebase Auth + RTDB SDK setup.
  • All changes are assistant-generated; no hand-written code is required in this step.

Step 7 - Enable Email/Password sign-in provider

If registration fails with “user create failed”, check Firebase Console:

  1. Go to Authentication -> Sign-in method.
  2. Enable Email/Password provider.
  3. Do not enable Google provider in this lesson.
  4. Do not configure MFA in this lesson.
  5. Save.

This is the key fix shown in the video after the first failed registration test.

Step 8 - Validation checklist

Run app and verify:

  1. Register succeeds.
  2. Login succeeds.
  3. Firebase Console -> Authentication shows created user.
  4. Firebase Console -> RTDB shows activity/data for your app flow.

When all four pass, setup lesson is complete.

Git Commit Strategy (Mandatory Split)

Commit A - Firebase setup baseline

Include all setup work from this lesson:

  • Assistant connection changes
  • SDK/Gradle changes
  • Added google-services.json
  • Console setup validated (Auth + RTDB)

Commit message example:

018b: connect app to Firebase, create RTDB, enable Email/Password auth

Commit B - Backend switch only (for another shared group)

If moving to another shared backend:

  1. Replace only google-services.json (and only related config files if truly required).
  2. Keep app code unchanged.
  3. Re-sync and run smoke test.

Important precondition for Commit B:

  • The replacement google-services.json must contain a client entry matching your app package (applicationId)
  • If it does not match, add your package as an Android app in that Firebase project and download the correct JSON first

google-services.json switching is a backend switch, not a package migration. If package identity changed (for example cloned app with a new package), register that package in Firebase before switching.

Commit message example:

018b: switch Firebase backend (group shared project)

This split lets each group share one Firebase project while keeping app logic identical.

Classroom Shared-Project Policy

Default policy for this course phase:

  • One shared project per student lead (or per group).
  • App data root remains /tictac/... in RTDB.
  • Different groups can work in parallel by using different Firebase projects and switching google-services.json via Commit B.
  • A single shared Firebase project can serve multiple Android app packages, but each package must be registered as its own Android app in Firebase.

Out of Scope (next lessons)

  • Google OAuth provider setup
  • UID-based security rules
  • FBRef utility design and usage (planned for 018c, then expanded in 018e)
  • Lobby and room lifecycle implementation
  • Realtime subscriptions for board updates

Note on including google-services.json in the repo

For this course flow (including shared classroom backends), we explicitly allow committing google-services.json and sharing it between students in the same team/group.

Quoted guidance (Samuel Stern):

“The general answer is yes, the google-services.json is safe to check in to your repo and is something that should be shared among engineers on your team. The JSON file does not contain any super-sensitive information (like a server API key). It does contain some information like your database URL, Android API key, and storage bucket. These are not secrets, but if your security rules are not set up correctly an attacker could use them against you. However since these values are also compiled into your APK as resources, the theoretical attacker would not need your JSON file to get these values anyway.”

Source:

  • https://groups.google.com/g/firebase-talk/c/bamCgTDajkw/m/uVEJXjtiBwAJ

Teaching implication for this series:

  • Committing google-services.json is acceptable for class workflows and backend switching.
  • This does not reduce the importance of correct Firebase Authentication setup and RTDB security rules (security rules are covered later as a bonus lesson).