← 资料库索引 ← 媒体报道 原始链接 ↗ 🔍
媒体报道

Firebase Cloud Messaging 弃用 Registration Token,官方文档却未跟上 原文标题:Firebase Cloud Messaging Retires the Registration Token, Docs Lag — Firerun

发表时间:2026-07-10采集时间:2026-10-09 10:35:00来源:firerun.io原文语言:en状态:完整

内容概要总结

本文报道 Firebase Cloud Messaging(FCM)服务端 Admin SDK 的一次标识符迁移:Node.js、Java、Python 三套服务端 Admin SDK 在同样的 10 天内相继发布了同一项变更——Send API 上的 token 字段被弃用,改用 fid(Firebase Installation ID)。Node.js 在 6 月 24 日随 v14.1.0 落地,Java 的 v9.10.0 与 Python 的 v7.5.0 在 7 月 2 日跟进,三份发行说明几乎一字不差:「Enable fid and deprecate token for Send API」。

文章指出客户端先动:Android SDK 25.1.0 已弃用 FirebaseMessaging.getToken()、deleteToken() 和 onNewToken(),改用基于 FID 的注册(该变更在 GitHub 上可追溯到 pull request #8087)。服务端 Admin SDK 的更新是这场迁移的后半程。文章援引 firebase-android-sdk 的 issue #8316(6 月 17 日提交)指出:getToken() 自 SDK 25.1.0 起已弃用,但 Firebase「发送到特定设备」的官方文档仍只展示旧的基于 token 的示例,也没有配套的 FID 迁移指南。文章给出的要点:过渡期内 token 与 FID 两条路径都仍受支持,这不是破坏性变更,但 Google 已表示 token 会在未来版本中「被移除」;建议新建 FCM 集成代码时用 FID 注册应用实例,而维护现有集成的团队暂不必迁移,因为 token 路径尚未失效,且官方尚未发布 FID 的定向发送示例。

翻译内容

原文内容(English)

⚠ 说明:为与原文结构对齐,已将 9 处小标题还原为 Markdown 标题(5 个 # + 3 个 ## 文章卡 + 1 个 #),并补回 4 个图片占位符。 为与原文结构对齐,已将 9 处小标题还原为 Markdown 标题(5 个 # + 3 个 ## 文章卡 + 1 个 #),并补回 4 个图片占位符。
Abstract flat-vector editorial illustration for "Firebase Cloud Messaging Retires the Registration Token, Docs Lag"
Abstract flat-vector editorial illustration for "Firebase Cloud Messaging Retires the Registration Token, Docs Lag"

Firebase Cloud Messaging 面向 Node.js、Java 和 Python 的服务端 Admin SDK 都在同样的 10 天内发布了同一项变更:Send API 上的 token 字段被弃用,改用 fid,即 Firebase Installation ID。Node.js 在 6 月 24 日随 v14.1.0 落地,Java 的 v9.10.0 和 Python 的 v7.5.0 在 7 月 2 日跟进。各条发行说明读起来几乎一模一样:「Enable fid and deprecate token for Send API」(Node.js v14.1.0、Java v9.10.0、Python v7.5.0)。如今每个通过 Admin SDK 发送推送通知的后端,都会在它自 FCM 发布以来一直使用的那个字段上收到一条弃用警告。

实际在变的是什么

FCM 一直用 registration token 来标识某个具体的应用实例,该 token 由客户端 SDK 生成、传给服务端用于定向发送。这个 token 正被 FID 取代,FID 是 Firebase 的 Installations 服务早已分配给每个应用实例的标识符,如今由 FCM 直接签发。在 Admin SDK 上,Message.token 在过渡期间仍然可用,但根据 Firebase 关于管理 FCM 注册的指引,Message.fid(批量发送时用 MulticastMessage.fids)才是 Google 希望开发者迁移过去的字段。

客户端先行了一步。Android SDK 25.1.0 弃用了 FirebaseMessaging.getToken()、deleteToken() 和 onNewToken(),改用基于 FID 的注册——这一变更在该版本的发行说明中有所标注,并在 GitHub 上可追溯到 pull request #8087。Admin SDK 的更新则是同一场迁移中服务端那一半的最终落地。

文档还没有跟上

正是 Google 自己的开发者在指出这一缺口。firebase-android-sdk 上的 issue #8316(6 月 17 日提交)指出:getToken() 自 SDK 25.1.0 起就已弃用,然而 Firebase 关于「发送到特定设备」的文档仍然只展示旧的基于 token 的示例。旁边也没有一份 FID 迁移指南。今天照着官方「发送到特定设备」文档做开发的开发者,仍会针对一个已被三套 SDK 标记为待移除的字段编写代码。

这是一个缺口,而不是吹毛求疵。在过渡期间两种模式都完全受支持,所以团队不必今天就迁移。但一项没有配套迁移文档的弃用,会让开发者靠猜来写替代代码,而不是照抄。

要点

Node.js Admin SDK v14.1.0(6 月 24 日)以及 Java v9.10.0 / Python v7.5.0(7 月 2 日)都在 FCM Send API 上弃用了 token/tokens,改用 fid/fids。

该变更与 Android SDK 25.1.0 在客户端弃用 getToken()、deleteToken() 和 onNewToken() 相呼应。

过渡期间 registration token 仍可继续工作——这还不是破坏性变更,但 Google 已表示 token「将被移除」于未来的某个版本。

根据 6 月 17 日来自 Android SDK 仓库的一条 GitHub issue,Firebase 自己的「发送到特定设备」文档尚未更新加入 FID 示例。

该怎么办

目前没有截止期限强制要求重写,token 与 FID 两条路径在本次过渡期间都能工作。但如果你现在正在搭建全新的 FCM 集成代码,请用 FID 而不是 token 来注册应用实例。写入 Google 已经表示会保留的字段,可以省下以后的一次迁移。如果你在维护一套现有集成,那现在还不必追这件事:token 路径并没有坏,而且在 Firebase 真正为定向发送发布 FID 示例之前,迁移意味着针对未记录的行为编写代码,而不是遵循一种受支持的模式。

继续阅读

Abstract flat-vector editorial illustration for "Firebase App Check Brings reCAPTCHA Enterprise to Mobile Apps"
Abstract flat-vector editorial illustration for "Firebase App Check Brings reCAPTCHA Enterprise to Mobile Apps"

Firebase App Check 将 reCAPTCHA Enterprise 带到移动应用

Firebase App Check 新增 reCAPTCHA Enterprise 作为面向 Android、Apple 平台和 Flutter 的证明(attestation)选项,与 Web 应用早已拥有的选项保持一致。

Abstract flat-vector editorial illustration for "Firebase Crashlytics Splits System Kills From Memory Errors"
Abstract flat-vector editorial illustration for "Firebase Crashlytics Splits System Kills From Memory Errors"

Firebase Crashlytics 将系统杀进程与内存错误分离

在 Android 17 及更高版本上,Crashlytics 现在把 Low Memory Kills 和 OutOfMemoryErrors 分到各自独立的问题中,而不再共用一个桶。

Abstract flat-vector editorial illustration for "Firebase Crashlytics Now Separates Android 17's Memory Kills"
Abstract flat-vector editorial illustration for "Firebase Crashlytics Now Separates Android 17's Memory Kills"

Firebase Crashlytics 现在分离 Android 17 的内存杀进程

Crashlytics 现在在 Android 17 设备上把 Low Memory Kills 与 Out of Memory 异常分开,让 Android 新的内存限制所造成的影响得以显现。

获取新文章到你的收件箱

我们只会在有新文章发布时给你发邮件。随时可退订。

Abstract flat-vector editorial illustration for "Firebase Cloud Messaging Retires the Registration Token, Docs Lag"
Abstract flat-vector editorial illustration for "Firebase Cloud Messaging Retires the Registration Token, Docs Lag"

Firebase Cloud Messaging’s server-side Admin SDKs for Node.js, Java and Python all shipped the same change within the same 10 days: the token field on the Send API is deprecated in favor of fid, the Firebase Installation ID. Node.js hit this in v14.1.0 on June 24, and Java’s v9.10.0 and Python’s v7.5.0 followed July 2. Each release note reads almost identically: “Enable fid and deprecate token for Send API” (Node.js v14.1.0, Java v9.10.0, Python v7.5.0). Every backend sending push notifications through the Admin SDK now gets a deprecation warning on the field it has used since FCM launched.

What’s actually changing

FCM has always identified a specific app instance with a registration token, minted by the client SDK and passed to the server for a targeted send. That token is being replaced by the FID, the identifier Firebase’s Installations service already assigns every app instance and that FCM now issues directly. On the Admin SDK, Message.token still works during the transition, but Message.fid (and MulticastMessage.fids for batch sends) is the field Google wants developers to move to, according to Firebase’s guidance on managing FCM registrations.

The client side moved first. Android SDK 25.1.0 deprecated FirebaseMessaging.getToken(), deleteToken() and onNewToken() in favor of FID-based registration, a change flagged in that release’s notes and tracked on GitHub as far back as pull request #8087. The Admin SDK updates are the server-side half of that same migration finally landing.

The docs haven’t caught up

Google’s own developers are the ones flagging the gap. Issue #8316 on firebase-android-sdk, opened June 17, points out that getToken() has been deprecated since SDK 25.1.0, yet Firebase’s documentation for sending to a specific device still shows only the old token-based example. There’s no FID migration guide sitting next to it. A developer following the official “send to a specific device” doc today would still write code against a field three SDKs have now marked for removal.

That’s a gap, not a nitpick. Both patterns are fully supported during the transition, so teams don’t have to migrate today. But a deprecation with no paired migration doc leaves developers guessing at replacement code instead of copying it.

Key Takeaways

  • Node.js Admin SDK v14.1.0 (June 24) and Java v9.10.0 / Python v7.5.0 (July 2) all deprecate token/tokens on the FCM Send API in favor of fid/fids.
  • The change mirrors Android SDK 25.1.0 deprecating getToken(), deleteToken() and onNewToken() on the client.
  • Registration tokens keep working during the transition — this isn’t a breaking change yet, but Google has said token “will be removed” in a future release.
  • Firebase’s own “send to a specific device” documentation hasn’t been updated with FID examples, per a June 17 GitHub issue from the Android SDK repo.

What to do

There’s no deadline forcing a rewrite today, and both the token and FID paths work through this transition. But if you’re standing up new FCM integration code now, register app instances against FIDs rather than tokens. Writing to the field Google has already said it’s keeping saves a second migration later. If you’re maintaining an existing integration, don’t chase this yet: the token path isn’t broken, and until Firebase actually publishes FID examples for targeted sends, migrating means writing against undocumented behavior rather than a supported pattern.

Keep reading

Abstract flat-vector editorial illustration for "Firebase App Check Brings reCAPTCHA Enterprise to Mobile Apps"
Abstract flat-vector editorial illustration for "Firebase App Check Brings reCAPTCHA Enterprise to Mobile Apps"

Firebase App Check Brings reCAPTCHA Enterprise to Mobile Apps

Firebase App Check added reCAPTCHA Enterprise as an attestation option for Android, Apple platforms and Flutter, matching the option web apps already had.

Abstract flat-vector editorial illustration for "Firebase Crashlytics Splits System Kills From Memory Errors"
Abstract flat-vector editorial illustration for "Firebase Crashlytics Splits System Kills From Memory Errors"

Firebase Crashlytics Splits System Kills From Memory Errors

On Android 17 and up, Crashlytics now gives Low Memory Kills and OutOfMemoryErrors their own separate issues instead of one shared bucket.

Abstract flat-vector editorial illustration for "Firebase Crashlytics Now Separates Android 17's Memory Kills"
Abstract flat-vector editorial illustration for "Firebase Crashlytics Now Separates Android 17's Memory Kills"

Firebase Crashlytics Now Separates Android 17's Memory Kills

Crashlytics now separates Low Memory Kills from Out of Memory exceptions on Android 17 devices, surfacing what Android's new memory limits are doing.

Get new articles in your inbox

We'll only email you when a new article drops. Unsubscribe anytime.

放大预览