Silent google sign in login

[Leinnan]

Ticket

Implements #4750

Brief Description

Refactor the Google SignIn plugin and add the silent login functionality.

[github-actions]

Lightbeam link

[mhijaziB]

Due to importance of this and what it touches, i had Codex/Sol-high go through it. Please take these with a grain of salt.

Findings

1. [P1] Overlapping requests can apply the wrong Google token
   GoogleSignInBehavior.AdoptPromise() completes the previous promise but does not cancel its native request. Both requests still callback through the same GameObject and GoogleAuthResponse. A startup silent request followed by an interactive login can therefore let the old callback complete the new promise with the previously signed-in account’s token. That can offer or switch to the wrong Beamable account.
   Use GoogleSignInService’s unique per-request receivers, or serialize/reject overlapping requests and ignore callbacks from superseded generations.

2. [P2] Account Management silent login can remain pending forever
   StartGoogleSilentLogin() uses the low-level GoogleSignIn.LoginSilently() wrapper, which has no timeout. If UnitySendMessage drops the response, the promise never completes. The new GoogleSignInService explicitly implements a timeout for this exact failure boundary; this integration bypasses it.

3. [P2] The Android plugin loses CI coverage
   The PR deletes the old Jenkins pipeline and comments that .github/workflows/androidPluginPR.yml validates the artifact, but that workflow does not exist. Current PR checks compile Unity against the already-committed .aar; they do not rebuild Java source.
   Additionally, --verify-only validates a newly built temporary AAR and exits before comparing it with the AAR shipped in com.beamable. A stale source/binary pairing could pass CI. Add a path-filtered workflow that rebuilds, verifies, installs, and fails if the tracked artifact differs.

4. [P2] The installer accepts an unsupported JDK
   ResolveJavaHome() returns any existing JAVA_HOME. On my local machine’s JDK 8 it failed because AGP 7.4.2 requires Java 11+. Unsetting JAVA_HOME let it find Unity’s supported JDK and pass. Validate the major version and either fall back to the paired Unity JDK or fail immediately with a clear 11/17 requirement.

What aligns correctly

Legacy Google silentSignIn() is the documented UI-free path for refreshing an ID token before backend calls, and requestIdToken(webClientId) is correct. The Java implementation does not launch an Activity during silent login and correctly treats SIGN_IN_REQUIRED as a benign miss. GoogleSignInClient, Google backend authentication.

The unique receiver names, asynchronous string callback, [Preserve], DontDestroyOnLoad, and disposal of AndroidJavaClass generally align with Unity guidance. Unity Android callbacks, PreserveAttribute.

One strategic caveat: this entire Google Sign-In API is deprecated. Credential Manager is the supported replacement, but its automatic flow may briefly display a bottom sheet, so it does not preserve the strict zero-UI requirement. Treat this PR as a compatibility bridge and create a migration follow-up. Google migration guide.

[github-actions]

Lightbeam link

[allister-beamable]

We can disregard the Jenkins issue: for this plugin, Jenkins was never a test harness for continuous integration; rather, it was a glorified build box. We should translate that build to GitHub Actions so that rebuilding the AAR does not depend on any individual developer's laptop, but the GHA we create really just needs to have the right Java version and be capable of running a Gradle build.

For all practical purposes, game developers will just use the AAR file we ship with the SDK, right, @Leinnan ? That is, nobody using the Beamable Unity SDK should need to rebuild the plugin on their own (but they may do so if they wish, by following instructions in the README), right?

[Leinnan]

For all practical purposes, game developers will just use the AAR file we ship with the SDK, right, @Leinnan ? That is, nobody using the Beamable Unity SDK should need to rebuild the plugin on their own (but they may do so if they wish, by following instructions in the README), right?

Correct.

The PR s ready for review, I was able to build it and test the login and silent login.

[github-actions]

Lightbeam link

[mhijaziB]

@Leinnan Did another codex pass, all previous stuff have been addressed which gr8. A couple according to it remain. Again take this with a grain of salt:

#Remaining findings

1. [P1] The generated ProGuard rule is invalid
   BuildPreProcessor writes:

com.beamable.googlesignin.** { *; }

The newly committed proguard-user.txt contains the same malformed rule. R8 requires an option and class specification, for example:

-keep class com.beamable.googlesignin.** { *; }

When Unity minification uses this file, the release build can fail while parsing the configuration. This path now applies to ordinary Google Sign-In projects, not only GPGS. Android keep-rule syntax, Unity ProGuard behavior.

Fix the generator with something equivalent to:

string.Join("\n", missingRules.Select(rule => $"-keep class {rule} {{ *; }}"));

Also correct or remove the committed proguard-user.txt. The AAR already contains the correct consumer rule.

2. [P2] Backgrounding during the pre-login sign-out can hang interactive login
   client.signOut().addOnCompleteListener(this, ...) creates an Activity-scoped listener. Google documents that this listener is removed in onStop. If the app backgrounds before signOut() completes, the account chooser is never launched and no response is returned to Unity. Google Task documentation.

This matters because GoogleSignInService.SignIn() deliberately has no timeout. The pending promise—and Account Management loading flow—can therefore remain stuck indefinitely. The Java side needs exactly-once lifecycle settlement, or a non-Activity-scoped listener that checks whether the Activity is still usable and returns a terminal response when it is not.

3. [P2] The replacement Gradle template conflicts with declared Unity support
   The package declares Unity 2021.3 support, but mainTemplate.gradle is explicitly copied from Unity 2022.3 and uses:

namespace "com.unity3d.player"
sourceCompatibility JavaVersion.VERSION_11

Unity 2021.3.29 uses AGP 4.0.1, while Android documents that the namespace DSL begins with AGP 7.3. Unity 2021.3 compatibility table, Android AGP namespace requirement.
The repository currently has useCustomMainGradleTemplate: 0, so CI does not exercise this file. The passing Android check uses Unity 6 and therefore does not establish Unity 2021.3 Android compatibility. Keep the shared template compatible with the declared minimum, or use version-aware dependency injection rather than one version-specific template.

[github-actions]

Lightbeam link

[github-actions]

Lightbeam link

[allister-beamable]

I like the improvements on the error case handling.

Needs some developer-facing docs, but that might be as simple as adding a section to the Google Sign-In page saying "use .signInSilent to perform a silent, automatic login", right?

Good to merge to main from my perspective, though we will want to do as much thorough on-device testing as we can.

[github-actions]

Lightbeam link

[github-actions]

Lightbeam link

[github-actions]

Lightbeam link