/

• English
• Deutsch
• Español – América Latina
• Français
• Indonesia
• Italiano
• Polski
• Português – Brasil
• Tiếng Việt
• Türkçe
• Русский
• עברית
• العربيّة
• فارسی
• हिंदी
• বাংলা
• ภาษาไทย
• 中文 – 简体
• 中文 – 繁體
• 日本語
• 한국어

Android Studio Sign in

• Games dev center

Migration overview

Google Play Games Services, games v1 SDK relies on Google Sign-In for Android which is deprecated and will be removed from the Google Play services Auth SDK (com.google.android.gms:play-services-auth) in 2025. New games apps can use games v1 until 2025. The Google Sign-In removal introduces dependency issues for existing games apps. Migrate existing games apps from the games v1 SDK to the games v2 SDK resolves dependency issues introduced by the Google Sign-In removal.

Google Play Games Services v1 to v2 migration is a significant update that simplifies development and supports cross-platform gaming. Google Play Games Services v2 decouples platform and in-game identity, acting as a platform-level identity system that automatically authenticates players at launch. Platform identity is now separate from the primary in-game account system, which you must manage independently using tools like Sign in with Google or proprietary backends. The Play Games Services v2 SDK integration uses the player ID for platform features like achievements and leaderboards without altering existing onboarding or login flows.

This document helps you understand the interactions between the games application and various SDKs. Because of the official deprecation timeline, you must follow this migration guide's architectural principles, pathways, and player communication strategies to ensure player continuity.

SDK interactions

The diagrams illustrate the interaction between a games application on Android, Google Mobile Services (GMS) Core, Play Games Services, and a third-party (3P) games server. It highlights how the application uses Google's services for authentication and game features, while also interacting with a separate third-party system.

games v2 (Current)

games v1 (Legacy)

The following is a brief overview of the components and SDKs:

• This is the Google-proprietary layer on Android.
• The games application uses two GMS Core modules:
  • Games Module. provides game-specific features, such as leaderboards, achievements, and game state management.
  • Auth Module. Handles user authentication and authorization operations.
• The Games and Auth SDKs in the games application communicate with the corresponding modules using AIDL interfaces, indicating inter-process communication (IPC).

Why migrate your title to Play Games Services v2

The transition from Play Games Services v1 to v2 is a major architectural modernization that simplifies development and supports cross-platform gaming.

Unlike v1, which served as a primary in-game identity system, Play Games Services v2 decouples platform and in-game identity. It acts as a platform-level identity system that automatically authenticates players at launch to manage features like achievements and leaderboards.

You must now manage your game's primary in-game account system independently using tools such as Sign in with Google or proprietary backends. The Play Games Services v2 SDK lets games use the Play Games Services player ID to access platform features without changing existing onboarding or login flows. This document guides you through the migration, covering architectural principles, pathways, and player communication strategies. Adherence is critical for player continuity given the official deprecation timeline.

Compare platform authentication and in-game authentication

In Play Games Services v2, the concept of "logging in" is decoupled into two distinct layers:

• Platform identity. SDK handles platform authentication.
• In-game identity.

Platform authentication

Play Games Services functions strictly as a platform engagement layer. It manages the player's relationship with the Google Play Games ecosystem (Achievements, Leaderboards, and Events) rather than with authenticating into a specific game account or inventory.

• Silent & Automatic: Authentication happens automatically in the background when the game launches. There is no manual "Sign in" button required for Play Games Services itself.
• The Player ID: Upon successful platform authentication, Play Games Services provides a stable Player ID. This ID is consistent across devices for the same game but should be used primarily to track platform stats (like Achievement progress).
• Decoupled: Play Games Services v2 must not be used as your game's primary identity system for managing player's in-game account with their game progress or inventory. Play Games Services v2 acts strictly as a secondary, persistent platform identifier.

In-game authentication

Developers are responsible for managing the "In-Game Account" (IGA). This is the identity system that binds a player's progress, inventory, and currency within your game.

• Primary Identity: You may use your own backend, Sign in with Google (SiWG), or other providers as the primary login method.
• Independence: A player can be signed into Play Games Services (Platform Identity) to earn achievements while being logged into any specific In-Game Account. For example, a guest account, or a specific SiWG account.
• Management of Multiple In-Game Accounts: Play Games Services is responsible for only the platform authentication with your game managing the primary authentication of players into their in-game accounts (IGAs). This means that there would be no change to your game's existing flows about how players switch between their in-game accounts. While the players do so, they would still remain authenticated to the Play Games platform using Play Games Services and you would continue sending their data related to achievements and other Play Games Services features against the persistent Player ID.

Migration requirement: Bind in-game accounts with Google Open ID instead of Play Games Services Player ID

In Play Games Services v1, developers used Play Games Services as the primary identity provider. A "Google Play" button would link a player's In-Game Account (IGA) directly to their Player ID.

Play Games Services v2 shifts this by providing automatic, silent platform authentication at launch. The resulting Player ID is now used exclusively for platform features like leaderboards and achievements, separate from the main account login.

Games must now manage primary identity independently through a dedicated login screen offering methods like "Sign in with Google" (SiWG) or other social accounts. Crucially, Play Games Services v2 must not be used as a primary identity system.

This architectural shift requires a corresponding change in how developers structure their account data. The In-Game Account (IGA) must be decoupled from being primarily bound to the Player ID.

Instead, the IGA must now be bound to a stable, primary identifier that is independent of Play Games Services. The recommended identifier is the Open ID provided by the Sign in with Google (SiWG) flow. This Open ID serves as the unique, persistent key for the player's primary account within your system.

However, the IGA could still be linked to the Player ID as a secondary binding. This secondary link serves two critical functions:

1. It allows the game to continue tracking and updating progress for Play Games features (achievements, etc.) associated with that specific player.
2. It enables the "Seamless Restore" functionality, allowing the game to automatically log a player into their most recently used IGA only on a new device or after a reinstall.

Understanding this decoupled identity model is the key to unlocking the correct technical migration path for your game.

Feature comparison

This table gives you a feature comparison between the games v1 and games v2 SDKs: