Play Games Services v1 迁移到 v2 后，游戏 APP 加固应该重新验证哪些登录与账号链？

如果 PGS v2 原始 Release 已经登录失败，就不应先把问题归因于 APP 加固。正确顺序是先固定旧稳定版本和服务端基线，再验证 PGS v2 原始包，随后逐级比较御盾基础保护、目标保护和最终签名 Play Release；同时把平台认证、游戏自己的账号、Player ID、Server Auth Code、存档与权益恢复分别记录。御盾负责候选包保护和发布兼容证据，不替代 Google 认证服务或游戏后端的身份裁决。

摘要

Google 官方弃用时间表说明，从 2026 年 9 月起 Google Sign-In for Android API 不再受支持，Play Games Services v1 也进入退出阶段；play-services-games:25.0.0 已移除 v1 API，仍依赖旧接口的项目在升级认证或相关第三方 SDK 后可能遇到编译和登录链故障。Play Games Services 弃用时间表

PGS v2 不是简单替换一个依赖。Play Games 平台认证与游戏自己的 In-Game Account（IGA）需要拆开：PGS Player ID 服务于 Play Games 平台能力，游戏的账号、进度、库存、货币和权益仍应由游戏自己的身份系统与后端管理。PGS v2 登录模型 如果旧项目把 Player ID 直接当成 IGA 主键，迁移时必须建立旧身份到新账号模型的关联；如果原本已经使用 OpenID 或独立账号体系，迁移路径通常不同。Android 迁移指南

本文不声称任何具体游戏已经完成迁移，也没有执行真实 Google 账号、服务器 Auth Code 交换、成就、排行榜或存档测试。所有候选包、账号迁移、签名与业务结果均为 NOT_TESTED。文章提供的是公开的 Game Authentication Release Gate 方法，实际发布仍需在客户受控环境完成。

读者对象

本文面向 Unity、Android、IL2CPP 游戏研发，发行与 QA 团队，以及负责登录、账号迁移、支付资产和 APP 加固验收的安全负责人。需要先了解 Unity 原生与 Native 交付门禁，可阅读Unity IL2CPP App 加固发布门禁；需要了解游戏数据可信度，可阅读Google Play Game Stats 数据可信度责任矩阵；客户端保护与服务端验收边界可参考御盾 APP 加固产品说明。

核心结论

1. PGS v1 → v2 迁移属于认证链、平台身份和游戏账号模型的联合变更，不是只改 Gradle 依赖。
2. 从 2026 年 9 月起 Google Sign-In for Android API 不再受支持，PGS v1 已进入明确退出路线；项目应按官方迁移文档检查依赖和插件版本。
3. PGS Player ID 是 Play Games 平台身份，不应未经设计直接等同于游戏的唯一 IGA。
4. 旧玩家迁移的关键不是弹窗是否出现，而是旧 Player ID、OpenID、IGA、进度、货币、库存和付费权益能否在服务端连续关联。
5. PGS v2 的 Server Auth Code 应由客户端获取后交给游戏后端交换和验证，不能把长期 OAuth 秘密放进 APK。Android 服务端访问
6. APP 加固验收要从 PGS v2 原始 Release 开始，再比较基础保护、目标保护和最终签名包；原始包已失败时，不应直接归因御盾。
7. 自动静默认证、手动登录、老玩家、Guest、换设备、覆盖升级、成就、排行榜、存档和账号恢复都属于不同路径，不能用一次启动成功代表全部通过。

事实依据与脱敏证据

公开事实映射：PGS 变化与工程影响（Report Fact Mapping）

本节把本日公开政策变化转成发布工程问题，不把政策资料写成某个客户已经完成的测试结果。

report_evidence:
  report_date: 2026-09-17
  pgs_v1_status: DEPRECATED_OR_EXITING
  google_sign_in_android_status: NOT_SUPPORTED_FROM_2026_09
  games_dependency_v1_api: REMOVED_IN_25_0_0
  unity_plugin_migration: NOT_TESTED
  pgs_v2_original_release: NOT_TESTED
  yudun_basic_candidate: NOT_TESTED
  yudun_target_candidate: NOT_TESTED
  server_auth_code_exchange: NOT_TESTED
  legacy_player_id_binding: NOT_TESTED
  openid_or_google_identity_binding: NOT_TESTED
  progress_entitlement_restore: NOT_TESTED
  final_signed_play_release: NOT_TESTED
  production_credentials: CUSTOMER_CONTROLLED_NOT_SHARED

动态时间线与字段时间线

认证迁移不是一次编译任务。建议按版本、账号状态和候选包维护动态时间线，记录依赖升级、身份迁移、服务端回执和最终签名之间的关系。

技术拆解：PGS 平台身份、IGA 与加固候选

PGS Player ID 不是游戏账号数据库

PGS Player ID 是 Play Games 平台的一类身份。游戏可以用它关联平台能力，但玩家的角色、进度、库存、货币和权益应当由游戏自己的身份系统与后端维护。若旧项目把 Player ID 直接写入 IGA 主键，迁移时必须制定兼容映射、冲突处理、账号合并和回滚方案。

OpenID、Google 身份与 IGA 要分层

Google 身份、OpenID、PGS Player ID 和游戏 IGA 不是同一个字段。一个玩家可能先以 Guest 游玩，再绑定 Google；也可能换设备后通过新的认证路径恢复旧 IGA。服务端应保留不可变的内部账号标识，再把外部身份作为可撤销、可审计的关联记录。不要让客户端用一次回调结果直接决定资产归属。

v2 静默认证不等于账号迁移完成

PGS v2 的自动平台认证改善了启动体验，但登录回调成功只代表平台层完成了一步。游戏还要继续验证当前玩家映射、服务端会话、历史进度、库存和权益。对于老玩家，账号映射缺失、多个外部身份指向同一个 IGA、绑定已撤销和跨设备恢复失败都需要单独记录。

Server Auth Code 必须走后端闭环

客户端获取单次 Server Auth Code 后，应通过受保护的会话交给游戏服务器，由服务器完成交换、验证和内部账号绑定。客户端不应内置长期 OAuth 密钥，也不应把“拿到 code”当作支付、资产或存档恢复的最终凭证。服务端要记录 code 的一次性使用、过期、重放和绑定失败原因。

Unity 与 IL2CPP 的边界

Unity 项目迁移时，插件版本、Gradle 依赖、Android 原生回调、IL2CPP 生成代码、ABI、Manifest 和 Play 配置可能同时变化。APP 加固会进一步影响反射、JNI、Native Bridge、初始化时序和最终签名，因此应先让 v2 原始包建立基线，再比较基础候选与目标候选。任何“原包已失败”的场景都优先归入 SDK、插件、账号模型、后端或平台环境排查。

攻防视角：只保留发布与防守方法

认证链的风险不只来自恶意改包，也来自旧插件、旧账号模型、重复提交 code、错误缓存、渠道签名差异和服务端过度信任客户端。防守的重点是让身份关联和发布候选可追踪，让高价值动作需要服务端确认，让迁移失败能够回滚而不是生成第二个玩家账号。

不公开登录绕过、Auth Code 重放、账户合并利用、改包或 Hook 的操作细节。内部授权测试可以记录失败类型和安全回执，对外仅公开字段、状态、责任层和非目标。加固的价值是保护客户端逻辑、完整性、关键回调和候选身份；它不能替代 Google 认证、服务器账号模型或平台 API 的生命周期管理。

工程落地：Game Authentication Release Gate

编译与依赖门

• Unity、Plugin、PGS SDK、Gradle 和 AndroidX 版本固定并可追踪。
• 删除或隔离仍依赖 v1 的接口、适配层和过期调用。
• PGS v2 原始 Release 必须先完成编译、安装和基础认证。
• Google 登录、PGS 平台认证和游戏 IGA 的责任边界写入设计记录。

账号与服务端门

• 新用户、老玩家、Guest、已绑定 Google 和多身份冲突分别测试。
• Player ID、OpenID、IGA、内部账号、进度、货币、库存和权益有明确映射。
• Server Auth Code 一次性使用、交换、过期、重放和失败回执可审计。
• 换设备、覆盖升级、卸载重装和断网恢复不产生无法解释的新账号。

加固与最终发布门

• v2 Original、Yudun Basic、Yudun Target 和 Final Signed Play Release 使用同一业务版本对照。
• 自动认证、手动登录、回调、JNI/Native Bridge、IL2CPP 启动和账号恢复分别验收。
• 最终签名由客户或受控签名系统完成；候选摘要、证书摘要和 Play 上传产物关联可追踪。
• 成就、排行榜、Saved Games、账号恢复和高价值权益路径必须有回滚对象。

风险边界

• 御盾不维护 Google Play Games 平台账号，也不替代 Google 的认证、弃用和 API 生命周期规则。
• 御盾不把 PGS Player ID、OpenID 或 Server Auth Code 直接升级为游戏账号最终结论。
• 御盾不保存客户长期 OAuth 密钥、真实账号、Auth Code、Player ID、支付资产或生产日志。
• APP 加固不能修复 PGS v1 API 删除、Unity Plugin 版本不兼容、服务端映射错误或 Google 平台故障。
• NOT_TESTED 不等于失败，也不等于通过；它表示需要在客户授权环境继续验证。
• 本页不证明任何 Unity、IL2CPP、PGS SDK 或渠道组合都能兼容，具体结果必须绑定版本、签名、设备、账号和服务端配置。

测评目标与非目标

本轮主目标是建立 PGS v1 → v2 迁移下的认证与加固发布门禁；不以文章替代真实账号测试，也不尝试复现登录绕过。

常见误区

升级 play-services-games 就算迁移完成了吗？

不是。还要处理插件、认证回调、账号模型、Player ID 映射、Auth Code 后端交换和老玩家恢复。

PGS Player ID 能继续作为游戏唯一账号吗？

不能直接假设。应按官方 v2 模型和项目历史判断，并由游戏后端维护稳定的内部 IGA。

v2 自动认证成功就说明老玩家数据没问题吗？

不说明。平台认证、IGA 映射、进度、货币、库存和权益恢复是不同验收项。

游戏登录失败应该先找加固厂商吗？

如果 v2 原始 Release 已失败，应先排查 SDK、插件、账号模型、服务端、签名和平台配置；只有原包通过而保护候选首次失败时，才进入加固归因。

Auth Code 可以放在客户端长期保存吗？

不应。客户端只处理短期、单次使用的 code，交换和验证应在服务端完成，长期秘密不能依赖 APK 保密。

成就、排行榜和 Saved Games 是否属于认证验收？

是。它们依赖账号和平台能力，登录弹窗成功不能覆盖这些路径。

加固后出现老玩家变新号怎么办？

先比较同一账号、同一服务端、同一 v2 原始包与候选包，检查身份映射和回调参数，再按迁移记录和策略版本回滚；不要直接删除或覆盖旧 IGA。

FAQ

Google Sign-In 停止支持后，PGS v2 还能使用吗？

应按 Google 当前弃用和迁移文档使用受支持的 PGS v2 方案，不再依赖被弃用的旧 Google Sign-In 或 PGS v1 调用。具体可用版本和地区要求应在发布时重新核对官方文档。

Unity 游戏迁移 PGS v2 最先要固定什么？

先固定 Unity、Google Play Games Plugin、PGS SDK、Gradle、Android 依赖和服务端认证协议，然后建立 v2 原始 Release 基线，再进入加固。

御盾负责账号迁移吗？

不负责替代游戏后端的账号真相源。御盾可以保护客户端代码、回调、Native/IL2CPP 关键路径并协助建立候选与最终发布证据；IGA、进度、库存和权益由客户后端管理。

如何判断问题是不是加固导致？

相同账号、服务端、签名、设备和依赖下，先让 v2 原始包通过，再比较 Basic 与 Target 候选。只有原包通过而某一保护级别首次失败，才进入加固模块定位。

为什么要做覆盖升级和换设备测试？

认证迁移可能改变本地凭证、账号关联和服务端会话。新安装通过不代表旧玩家、覆盖升级和跨设备恢复没有断链。

可以把 Player ID、Auth Code 和完整账号记录公开吗？

不可以。公开资料只保留脱敏字段、状态和责任边界；真实身份、code、token、账号和生产日志应留在客户受控系统。

迁移失败的工程归因

认证迁移失败时，建议先把错误拆成四类，而不是统一显示“登录失败”。第一类是构建与依赖错误，例如旧接口在新版本库中被移除、Unity Plugin 与 Gradle 依赖不一致、Manifest 或服务端配置缺失；第二类是平台认证错误，例如 Play Games 服务不可用、账号未授权、平台回调未返回或 Player ID 获取失败；第三类是账号映射错误，例如新身份没有关联旧 IGA、Guest 与 Google 账号绑定冲突、多个外部身份指向不同内部账号；第四类是候选包或签名差异，例如原始包能完成回调而加固候选丢失 JNI/反射入口，或最终签名与测试包不一致。

每一类错误都应保留版本、账号状态、服务端回执、候选摘要和时间，而不是只保存截图。对老玩家尤其要记录迁移前后的内部账号是否相同、存档读取是否来自同一个后端对象、货币和权益是否重新计算、失败后能否回到旧版本。任何涉及资产合并、账号解绑或人工恢复的动作，都要有审批和回滚，不应由客户端直接覆盖。

发布时还要区分“认证通过”和“游戏可运营”。认证通过只能说明某一步身份链可用；成就、排行榜、Saved Games、好友、云存档、支付权益和客服找回仍然需要各自的服务端校验。加固候选应在这些关键路径中逐项回归，保留未覆盖范围。这样，当 Google SDK、Unity 插件、Android 系统或御盾策略再次更新时，团队可以准确知道是哪一层发生变化，而不是重新猜测问题来自哪里。

参考与下一步

建议先选择一个无敏感数据的 Unity Demo，建立 v2 原始包、基础保护候选、目标保护候选和最终签名包四组对象。记录插件、SDK、Unity、IL2CPP、ABI、签名摘要、账号模型、Server Auth Code 回执、Player ID 映射、进度与权益恢复结果，并把每一项未执行内容标为 NOT_TESTED。当基础认证链稳定后，再接入成就、排行榜、Saved Games、换设备和覆盖升级。

如需把游戏认证、IL2CPP、APP 加固和发布验收放入同一条流程，可从Unity IL2CPP 加固发布门禁、游戏数据可信度责任矩阵、Android 设备完整性与 APP 加固和御盾产品页开始。