First, your question — what is actually verified?

You asked how we can fully test the pipeline when the consoles are not configured. Fair challenge. Here is the precise answer.

What you are setting up, in order

A and B are independent — either order. C must come after B (the service account is granted access to an app that has to exist first). One step inside A can only be done after B; it is flagged where it appears.

AGoogle Cloud Console — make Google sign-in work

Android sign-in fails today with ApiException: 10 (DEVELOPER_ERROR). Google identifies an Android app by the pair package name + signing certificate SHA-1, and that pair has never been registered. There is no code to change — the app's sign-in code already works on Android.

A1 · Get into the right project

Go to console.cloud.google.com and select project number 584364169898.

A2 · OAuth consent screen

It should already be configured — you cannot create OAuth clients without it, and two already exist. Check APIs & Services → OAuth consent screen.

A3 · Create the Android OAuth client

APIs & Services → Credentials → + Create Credentials → OAuth client ID → Android.

Click Create. Nothing needs copying back — no client ID goes into our code. Android finds it by package and fingerprint.

A4 · You will need up to three of these, one per signing key

This is the part that catches people. Re-signing an app changes its SHA-1, so as far as Google is concerned each differently-signed build is a different app.

✅ Verifying part A

There is no "configured" indicator in the console. The only real test is signing in on a phone, with the log open:

~/Library/Android/sdk/platform-tools/adb logcat | grep google_signin

Allow a few minutes after creating the client, and force-stop the app before retrying.

BPlay Console — get the app to testers

B1 · Create the app

play.google.com/console → Create app. Name (what users see in the store), default language, App not Game, and Free.

B2 · Play App Signing — the one permanent choice

B3 · The declarations Play requires

Under Policy → App content. Internal testing does not require these — you can get a build to testers first. They are required before any public track, and some take review time, so start them early.

B4 · Upload to internal testing

Test and release → Testing → Internal testing → Create new release.

Upload the .aab. One already exists from this morning's build:

~/.hoop/wt-android-verify/app/build/app/outputs/bundle/release/app-release.aab
# versionCode 1, signed with our upload key, 531M

Or have NOVA cut a fresh one — either works, the pipeline is the same.

Then release notes → Save → Review release → Start rollout to Internal testing.

B5 · Add testers

Testers tab → create an email list → add each tester's Google account address (up to 100) → copy the opt-in link Play generates.

B6 · Go back and finish part A

Now that Play App Signing is on, Google has generated its own key. Get its SHA-1 from Test and release → Setup → App signing and repeat A3 with it. Sign-in will fail for everyone installing from Play until you do.

✅ Verifying part B

• The release shows as Available to internal testers, not stuck in review or draft.
• Play's App signing page shows both an app signing certificate and an upload certificate — the upload one must match our SHA-1 7A:03:…:91:CA. If it does not, the package was signed with the wrong key.
• A tester on the list can find and install the app from Play.

CService account — uploads without a human

Optional, and do it last. Nothing above depends on it. It lets the build pipeline push to Play automatically instead of someone dragging a file into a browser.

C1 · Enable the API

Cloud Console, project 584364169898 → APIs & Services → Library → find Google Play Android Developer API → Enable.

C2 · Create the service account and its key

IAM & Admin → Service Accounts → Create service account. Name it something obvious like hoop-play-publisher. No project roles are needed — the permissions that matter are granted in Play, not here.

Then open it → Keys → Add key → Create new key → JSON. It downloads once.

mv ~/Downloads/<whatever>.json ~/.hoop-keys/play-service-account.json
chmod 600 ~/.hoop-keys/play-service-account.json

C3 · Grant it access in Play

Play Console → Users and permissions → Invite new users → paste the service account's email (it looks like hoop-play-publisher@<project>.iam.gserviceaccount.com, and is the client_email field inside the JSON) → grant release permissions for this app → Invite user.

✅ Verifying part C — an actual command, not an inspection

Nothing in either console tells you the three pieces fit together. This does:

cd <a checkout of the repo>
python3 tools/tf-build/verify_play_credentials.py \
  ~/.hoop-keys/play-service-account.json com.hooptech.hoop

It uses the credential to open a Play "edit" and then abandons it — the only action that proves genuine release permission, and it changes nothing (an uncommitted edit simply expires). Read-only calls cannot prove this, because read access does not imply publish access.

DThe end-to-end test — this is the moment it is proven

Do these in order. Each step depends on the one before, so the first failure tells you exactly which part is wrong.

Step 5 or 6 failing is expected the first time if part A's third fingerprint was skipped. That is the single most likely failure, and A4 is the fix.

Checklist

What I verified, and what I did not

Verified on this machine today: both fingerprints, read out of the keystores with keytool. The package name and the Web client ID, cross-checked between build.gradle.kts, google_signin.dart and the backend config. The privacy URL returning 200. The signed AAB and APK referenced here — they exist, at those paths, with those sizes. The failure paths of the verification script.

Not verified — instructions, not observations: every console screen in parts A, B and C. I have no access to either console, so menu names and layouts come from Google's documentation and may have moved. The values to enter are verified from our own code and keys; the clicks are not. Also unverified: the success path of the credential script, whether Play accepts our size, and whether sign-in works once the client exists — that is exactly what part D is for.

Companion: the build pipeline (verified working) · the original wireframe.