跳到正文 Lab学完总结 · Jimmy Huang's Blog
← Google Firebase and Authentication 学习 › C6001 › 2026 S1 › FIT5046 Mobile and distributed computing systems › Week 11 Guest Lecturer › Google Firebase and Authentication Lab学完总结 Lab学完总结 本页目录· 46 条 1. 一句话总结这个 Lab 这个 Lab 要教会你： 如何把一个 Android App 接入 Firebase，并使用 Google 账号完成登录认证，让 Firebase Authentication 帮 App 判断“这个用户是谁、是否已经登录”。
2. 这个 Lab 实际做了什么 从可见材料看，这个 Lab 的主线不是做一个复杂 App，而是完成一条最小可运行的登录链路：
可以按下面流程理解。
第 1 步：在 Firebase Console 创建 Firebase Project 你先在 Firebase Console 里创建一个 Firebase Project。
这个 Project 可以理解成一个云端“项目空间”。以后这个 App 要用 Firebase 的 Authentication、Firestore、Storage、Analytics 等服务，通常都挂在这个 Project 下面。
在本 Lab 里，它主要负责承载：
如果没有 Firebase Project，Android App 就没有一个对应的 Firebase 后端空间，也就谈不上使用 Firebase Authentication。
第 2 步：在 Firebase Project 里注册 Android App 接着你在 Firebase Project 里注册一个 Android App。
这里不是重新写一个 Android App，而是在 Firebase 里告诉它：
“我有一个 Android 应用，包名是这个，请你把它和这个 Firebase Project 绑定起来。” 这个过程通常需要填写 Android package name，也就是 Android App 的 applicationId / package name。
它的作用是让 Firebase 知道：
本页目录 后续生成的配置文件应该给哪个 App 用
Google 登录、SHA-1、OAuth client 等信息要绑定在哪个 App 身上
如果 package name 填错，Firebase 可能会把配置发给“另一个 App 身份”，你的真实 App 登录时就会出现配置不匹配的问题。
第 3 步：下载并放置 google-services.json注册 Android App 后，Firebase 会让你下载一个 google-services.json 文件，并把它放进 Android Studio 项目的 app/ 目录。
Firebase 给 Android App 的“项目身份证 + 地址簿”。 它里面会包含这个 App 对应的 Firebase Project 信息，例如项目 ID、App ID、API key 等配置。App 运行时，Firebase SDK 需要通过这些配置知道自己应该连接到哪个 Firebase Project。
注意：它不是你的业务代码，也不是数据库文件。它的作用主要是“告诉 App 该连到哪个 Firebase 项目”。
如果没有这个文件，或者文件放错目录，Firebase SDK 很可能初始化失败，App 也就无法正确使用 Firebase Authentication。
第 4 步：配置 Gradle，让 Android 项目能识别 Firebase 仅仅把 google-services.json 放进项目还不够，Android 项目还要通过 Gradle 配置 Firebase 相关插件和依赖。
google-services.json 是配置文件
Gradle plugin 是读取和处理这个配置文件的工具
Firebase SDK dependency 是真正让你的 Kotlin/Java 代码可以调用 Firebase 功能的库
如果 Gradle 没配好，Android Studio 可能会出现：
可见材料没有显示具体 Gradle 代码版本，因此这里不复原具体代码。
第 5 步：在 Firebase Authentication 中启用 Google 登录 然后你需要到 Firebase Console 的 Authentication 区域，启用 Google 作为 Sign-in provider。
“这个项目允许用户使用 Google 账号登录。” 如果没有启用 Google provider，即使 Android App 里写了 Google 登录按钮，Firebase 端也不会接受这种登录方式。
所以 Google 账号系统和 Firebase Auth 是配合关系，不是同一个东西。
第 6 步：获取并添加 SHA-1 fingerprint 材料显示，这个 Lab 还需要获取并添加 SHA-1 fingerprint。
SHA-1 fingerprint 可以理解成 Android App 签名证书的“指纹”。Google Sign-In 需要知道：
“这个请求登录的 App，真的是你注册过的那个 App 吗？” Android App 不是只靠包名来证明身份，因为包名可以被别人写成一样。SHA-1 指纹来自签名证书，更像是 App 的“官方印章”。
开发阶段通常会用 debug keystore 的 SHA-1；正式发布时还需要 release key 或 Play App Signing 对应的 SHA-1。具体本 Lab 使用的是哪一种，页面可见内容没有展开，属于“材料未显示/不确定”。
如果 SHA-1 没配，Google 登录经常会失败，常见表现是：
第 7 步：重新下载更新后的 google-services.json材料特别提到：添加 SHA-1 后，需要重新下载更新后的 google-services.json。
这一步很关键，因为你第一次下载的 google-services.json 可能还没有包含 Google 登录需要的 OAuth client 信息。
如果你忘了重新下载，Android 项目可能仍然拿着旧配置运行，导致 Google 登录配置不完整。
第 8 步：在 Android App 里写 Google 登录 / 登出 Demo 接着在 Android App 里写一个最小版本的 Google 登录 / 登出 Demo。
从可见材料看，这个 Demo 的核心不是复杂 UI，而是验证这条链路是否跑通：
页面没有显示完整代码，因此具体是用 Activity、Fragment、Jetpack Compose、Credential Manager，还是旧版 GoogleSignInClient，材料未显示/不确定。
第 9 步：登录成功后，在 Firebase Console 里看到用户记录 最后，你运行 App，用 Google 账号登录。
如果一切配置正确，你应该能在 Firebase Console 的 Authentication 用户列表中看到该用户记录。
如果 Console 里没有用户记录，通常说明登录链路没有真正到 Firebase Authentication 这一步，可能是 SHA-1、 google-services.json、provider、Gradle 依赖或代码流程的问题。
3. 每个核心组件有什么用
3.1 Android App 它是什么： 你在 Android Studio 里开发的手机应用。
它在 Lab 里负责什么： 提供登录按钮，调用 Google Sign-In，拿到 token 后交给 Firebase Authentication，并根据 FirebaseAuth 判断用户是否已登录。
没有它会发生什么： 没有 Android App，就没有用户端入口，Firebase 也只是一个空的云端配置。
它通过 google-services.json 连接到 Firebase Project
它通过 Google Sign-In 让用户选择 Google 账号
它通过 FirebaseAuth 与 Firebase Authentication 通信
3.2 Firebase Project 它是什么： Firebase Console 里的云端项目容器。
它在 Lab 里负责什么： 存放 Android App 注册信息、Authentication 配置、Google provider 配置和用户登录记录。
没有它会发生什么： App 没有对应的 Firebase 后端环境，无法使用 Firebase Authentication。
一个 Firebase Project 可以注册一个或多个 App
Authentication 是 Project 里的一个服务
Console 是你管理这个 Project 的界面
3.3 Firebase Console 它是什么： 管理 Firebase Project 的网页后台。
它在 Lab 里负责什么： 创建项目、注册 App、下载 google-services.json、启用 Google 登录、添加 SHA-1、查看用户列表。
没有它会发生什么： 你很难配置 Firebase Auth，也看不到用户是否真的登录成功。
和其他组件的关系： 它是管理入口，不是 App 本身，也不是用户登录时直接操作的页面。
3.4 Firebase Authentication 它是什么： Firebase 提供的身份认证服务。
它在 Lab 里负责什么： 接收 Google 登录返回的身份信息，验证用户身份，并在 Firebase 项目中创建/维护用户登录状态。
没有它会发生什么： App 可能能拿到 Google 账号信息，但没有 Firebase 统一管理用户身份，也无法方便地与 Firestore、Storage 等 Firebase 权限规则联动。
3.5 Google Sign-In / Google 账号系统 它是什么： Google 提供的账号登录能力，让用户用自己的 Google 账号证明身份。
它在 Lab 里负责什么： 弹出 Google 账号选择/登录流程，并给 App 返回一个可以证明用户身份的 token。
没有它会发生什么： 用户不能用 Google 账号登录；你可能需要改用邮箱密码、匿名登录或其他 provider。
3.6 google-services.json它是什么： Firebase 为 Android App 生成的配置文件。
它在 Lab 里负责什么： 告诉 Android App 它属于哪个 Firebase Project，以及该用哪些 Firebase 配置信息。
没有它会发生什么： Firebase SDK 可能无法初始化，或者连错项目。
由 Firebase Console 下载
放在 Android Studio 项目的 app/ 目录
被 Gradle 的 Google services plugin 读取
添加 SHA-1 / Google 登录配置后通常需要重新下载最新版
3.7 Gradle 和 Google services plugin 它是什么： Android 项目的构建配置系统和 Firebase 配置处理插件。
它在 Lab 里负责什么： 把 Firebase SDK 加入项目，并让 google-services.json 中的配置能被 App 使用。
没有它会发生什么： 代码里可能无法调用 FirebaseAuth，或者 App 构建/运行时无法正确识别 Firebase 配置。
3.8 SHA-1 fingerprint 它是什么： Android App 签名证书的指纹。
它在 Lab 里负责什么： 帮 Google/Firebase 确认：发起 Google 登录请求的 App 是被允许的那个 App。
没有它会发生什么： Google Sign-In 可能无法正确工作，尤其是在 Firebase 需要创建 OAuth client 信息时。
SHA-1 要添加到 Firebase Console 的 Android App 配置里
添加后通常需要重新下载 google-services.json
debug 和 release 可能有不同的 SHA-1
3.9 idToken / credential 它是什么： Google 登录成功后返回给 App 的身份凭证。
它在 Lab 里负责什么： App 把这个凭证交给 Firebase Authentication，让 Firebase 判断这个 Google 用户是否可信。
没有它会发生什么： Firebase Auth 无法知道这个用户是否真的通过 Google 登录。
3.10 FirebaseAuth currentUser 它是什么： Android 端 FirebaseAuth SDK 提供的当前用户状态。
它在 Lab 里负责什么： 让 App 判断用户现在是否已经登录，以及读取基本用户信息，例如 uid、email、displayName 等。
没有它会发生什么： App 不知道当前用户是否登录，就无法决定显示登录页还是主页面。
和其他组件的关系： Firebase Authentication 登录成功后，Android 端通过 FirebaseAuth 获取登录状态。
4. 用初学者类比解释
类比场景：小区门禁 + 身份证 + 物业系统
用故事串起来 用户来到 Android App 这个“小区前台”。
用户说：“我要用 Google 账号登录。”
App 把用户带到 Google 账号系统那里确认身份。
Google 确认后，给 App 一张“临时身份证明”，也就是 idToken。
App 拿着这张证明去找 Firebase Authentication。
Firebase Authentication 检查： 这个 token 是 Google 发的吗？
这个 App 是我项目里注册过的吗？
这个 App 的包名和 SHA-1 对得上吗？
这个项目是否启用了 Google 登录？
检查通过后，Firebase 说：“可以，这个用户登录成功。”
App 之后就可以通过 FirebaseAuth 知道当前用户是谁。
你在 Firebase Console 的 Authentication 用户列表里能看到这个用户记录。
为什么要这么麻烦？ App 在用户手机上运行，客户端环境不完全可信。更安全的做法是让 Google 和 Firebase 这类可信服务共同完成身份验证。
5. 重点区分容易混淆的概念
5.1 Firebase Project 和 Android App 不是同一个东西 容易误解： 我创建了 Firebase Project，就等于创建了 Android App。
5.2 Google Sign-In 和 Firebase Authentication 不是同一个东西 容易误解： 用 Google 登录了，就不需要 Firebase Authentication。
5.3 google-services.json 不是数据库，也不是密码文件 容易误解： google-services.json 是数据库文件，或者里面有超级机密密码。
正确理解： 它主要是 Firebase 配置文件，告诉 App 连接哪个 Firebase Project。
不过它也不应该随便乱传，因为它能暴露你的项目标识信息。真实项目里通常会配合 Firebase Security Rules、后端校验、API 限制等措施来保护数据。
5.4 Gradle dependency 和 google-services.json 分工不同 容易误解： 我加了 google-services.json，就不用加 Firebase SDK 依赖了。
google-services.json：提供配置
Firebase SDK dependency：提供代码可调用的功能
Google services plugin：让 Gradle 能处理 Firebase 配置
5.5 SHA-1 和 package name 都是身份匹配的一部分 容易误解： 只要 package name 对了，Google 登录就一定能用。
正确理解： package name 只是 App 的名字/标识之一，SHA-1 更像签名证书的指纹。Google 登录常常需要二者一起匹配。
5.6 Authentication 用户列表不是业务数据库 容易误解： Firebase Authentication 里有用户记录，所以它就是数据库。
正确理解： Authentication 主要存认证用户信息，例如 uid、邮箱、登录方式等。它不是用来保存业务数据的地方。
这些通常要放在 Firestore、Realtime Database、Cloud Storage 或自己的后端数据库里。
本 Lab 可见材料没有显示配置 Firestore 或其他业务数据库，因此不要把 Authentication 当成本 Lab 的数据库部分。
5.7 哪个是入口？哪个是权限控制？哪个是数据库？哪个是网络控制？
5.8 登录成功和授权访问不是完全一回事 容易误解： 用户登录成功后，就应该能访问所有数据。
在 Firebase 项目里，后续如果使用 Firestore / Storage，还需要用 Security Rules 规定用户能读写哪些数据。本 Lab 可见材料主要是 Authentication，没有展开数据库规则。
5.9 Debug SHA-1 和 Release SHA-1 可能不一样 容易误解： 我在本地跑通了，正式发布一定也能跑通。
正确理解： 本地调试 App 和正式发布 App 可能使用不同签名证书，所以 SHA-1 也可能不同。
如果只配置了 debug SHA-1，发布版本的 Google 登录可能会失败。
6. 这个 Lab 有什么实际用途 这个 Lab 的实际价值很大，因为“登录认证”是绝大多数真实 App 的基础能力。
6.1 在真实移动 App 里的用途 Google 登录可以降低注册门槛，用户不用重新创建一组账号密码。
6.2 在后端开发里的用途 Firebase Authentication 登录成功后，客户端可以拿到 Firebase ID token。真实后端可以验证这个 token，然后知道：
这个请求来自哪个 uid
用户是否真的登录
是否允许他访问某些 API
所以这个 Lab 是理解“前端登录 + 后端身份验证”的基础。
6.3 在云架构里的用途 Firebase Authentication 是一个托管身份服务。它让你不用自己从零实现：
密码存储
OAuth 集成
Google 登录流程
用户登录状态维护
基础用户管理后台
能用成熟托管服务解决的通用问题，不一定要自己造轮子。
6.4 在安全设计里的用途 App 不能只靠自己声明“用户已登录”
Google 账号系统提供身份来源
Firebase Authentication 验证身份 token
SHA-1 用于确认 Android App 签名身份
后续访问数据库还需要 Security Rules 或后端授权逻辑
6.5 在 DevOps / 发布流程里的用途 真实项目中，登录功能经常在开发环境可用，发布后却坏掉，原因可能是：
debug SHA-1 配了，release SHA-1 没配
更新了 Firebase Console 配置，但忘了重新下载 google-services.json
package name / applicationId 改了，但 Firebase 里还是旧配置
CI/CD 使用了不同签名证书
Google provider 没有启用
所以这个 Lab 也在训练你做移动端云服务集成时的配置意识。
7. 最后画一张生动形象的示意图 下面这张图用 Mermaid 写在 Markdown 里，不生成图片文件。它表达的是本 Lab 的核心认证流程。
图里的核心流程再用一句话说
最重要的记忆点 Google Sign-In 负责证明用户的 Google 身份。
Firebase Authentication 负责把这个 Google 身份变成你的 Firebase App 用户。
google-services.json 负责让 Android App 找到正确的 Firebase Project。
SHA-1 fingerprint 负责证明这个 Android App 是被允许的 App。
Firebase Console 用户列表 只是认证用户记录，不是业务数据库。
本 Lab 的重点是 Authentication 登录链路 ，不是 Firestore 数据库，也不是 VPC / 防火墙网络控制。
最后复习版：这个 Lab 你应该真正掌握什么 完成这个 Lab 后，你不只是会“照着按钮点一遍”，而是应该能解释清楚：
为什么 Android App 要先注册到 Firebase Project。
为什么要把 google-services.json 放到 app/ 目录。
为什么 Gradle 需要 Firebase 插件和 SDK 依赖。
为什么 Google 登录还要启用 Firebase Authentication 的 Google provider。
为什么 SHA-1 是 Google 登录配置里很关键的一步。
为什么添加 SHA-1 后需要重新下载 google-services.json。
为什么登录成功后要去 Firebase Console 的 Authentication 用户列表验证结果。
为什么 Authentication 只解决“你是谁”，不等于自动解决“你能访问什么”。
如果你能把下面这句话讲清楚，这个 Lab 就算真正理解了：
Android App 不能自己随便说用户已经登录，而是要通过 Google Sign-In 拿到用户身份凭证，再交给 Firebase Authentication 验证，Firebase 验证成功后，App 才能通过 FirebaseAuth 可靠地知道当前用户是谁。 Android App → Google Sign-In → Firebase Authentication → Firebase Console 中出现用户记录先注册 App → 下载初版 json
添加 SHA-1 / 启用 Google 登录 → 重新下载新版 json
用新版 json 替换 app/ 目录里的旧文件点击 Google 登录
→ 选择 Google 账号
→ App 拿到 Google 返回的 idToken
→ App 把 idToken 交给 Firebase Authentication
→ Firebase 验证成功
→ App 能通过 FirebaseAuth 判断当前用户已登录
→ 用户可以登出Google 账号系统 → 返回 idToken → Android App → 交给 Firebase AuthenticationFirebase Project：云端后端空间
Android App：手机端应用
注册 Android App：把手机端应用和云端项目绑定Google：证明“你是哪个 Google 用户”
Firebase Auth：证明“你是我这个 App 里的哪个用户”配置文件 + 构建插件 + Firebase SDK = App 能真正使用 Firebasepackage name：这个 App 叫什么
SHA-1：这个 App 是谁签名出来的flowchart TD
Title[Google Firebase Authentication Lab：Android App 使用 Google 登录并交给 Firebase 验证]
U[用户\n想用 Google 账号登录]
A[Android App\n登录按钮 / 登录界面]
G[Google 账号系统\nIdentity Provider]
T[idToken / Google Credential\nGoogle 开出的身份凭证]
FA[Firebase Authentication\n验证身份并维护登录状态]
CU[FirebaseAuth currentUser\nApp 端判断当前用户是谁]
FC[Firebase Console\nAuthentication Users 用户列表]
P[Firebase Project\n云端项目空间]
RA[已注册 Android App\nPackage name + SHA-1]
JSON[google-services.json\n放在 app/ 目录]
GR[Gradle + Google services plugin\n读取配置并接入 Firebase SDK]
DB[Firestore / Storage 等业务数据\n本 Lab 可见内容未配置]
BAD1[❌ 未注册或包名不匹配的 App]
BAD2[❌ 没有 SHA-1 / 没有更新 json]
BAD3[❌ 未登录用户直接访问业务数据]
Remember[你要记住的核心区别：\n1. Google Sign-In 证明“Google 用户是谁”\n2. Firebase Authentication 证明“这个用户在我的 App 里是谁”\n3. google-services.json 是配置，不是数据库\n4. SHA-1 是 App 签名身份证明，不是用户密码]
Title --> U
U -->|点击 Google 登录| A
A -->|发起 Google Sign-In| G
G -->|登录成功，返回| T
T -->|App 把凭证交给 Firebase| FA
FA -->|验证成功| CU
CU -->|App 显示已登录状态| A
FA -->|创建 / 显示用户记录| FC
P -->|包含服务| FA
P -->|注册| RA
RA -->|生成 / 更新配置| JSON
JSON -->|被读取| GR
GR -->|让 App 能使用 FirebaseAuth| A
BAD1 -. 不能冒充已注册 App .-> FA
BAD2 -. Google 登录可能失败 .-> G
BAD3 -. 需要认证和后续 Security Rules .-> DB
FA -. 后续可配合规则控制访问 .-> DB
FC --> Remember
DB --> Remember
classDef normal fill:#eef7ff,stroke:#2f6f9f,stroke-width:1px,color:#111;
classDef firebase fill:#fff4d6,stroke:#d28b00,stroke-width:1px,color:#111;
classDef google fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px,color:#111;
classDef danger fill:#ffe5e5,stroke:#d32f2f,stroke-width:2px,color:#111;
classDef summary fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#111;
class U,A,T,CU,RA,JSON,GR normal;
class P,FA,FC firebase;
class G google;
class BAD1,BAD2,BAD3 danger;
class Remember summary;用户点击登录
→ Android App 请求 Google 登录
→ Google 返回身份凭证
→ App 把凭证交给 Firebase Authentication
→ Firebase 验证成功后记录用户
→ App 再根据 FirebaseAuth 判断用户是否登录