Set up Google Play

An email list names individual tester accounts and is managed in Play Console. A Google Group is a membership list with its own group address, not a new Gmail account. It is optional: you can keep using individual tester emails in Play Console. Google’s publishing API can select existing groups for a testing track, but cannot manage individual email lists.

The group connection grants testing access to current and future group members. Keep the group private and check its membership before approving access. Creating a group, managing members and accepting an invitation are separate steps from publishing a build.

Share the opt-in link with your testers; adding an email to the list is not a TestFlight-style invitation. An active test release still needs an eligible tester to open that link with the listed Google account and install the app. Google may show a temporary package-name label for a new, unreviewed app. Internal testing does not make the app publicly available.

The agent handles the supported steps after you connect the required accounts and approve the proposed actions. Some Google forms still need Play Console. Completing a form there does not mean RNBlocks can submit it through its tools.

Before the first public release, open your app in Play Console → Test and release → Production → Countries / regions. Choose Add countries / regions, select the countries you want, use Edit countries / regions to add them, then save. This configures availability; it does not create or publish a release.

This initial selection is a Play Console step. Google’s public countryavailability API only reads the setting. RNBlocks can continue the supported build, upload and reviewed release actions after you complete it. An internal test does not prove production countries have been selected.

For an organization, match the legal name and address across the payments profile, supporting records and D-U-N-S information. A brand and an authorized person are different identities.

Use reachable organization-controlled contacts for a business. Google also displays verified legal identity information: organization name and address, or personal legal name and country; monetization and regional rules can require more. Review the public Developer profile before release.

An organization can be asked for both business registration evidence and a representative’s government photo ID. The accepted documents depend on the payments-profile country.

For the United States, Google’s examples include IRS-issued documents such as CP575 or 147C and qualifying state incorporation documents. Use the current country-specific list rather than assuming a document accepted elsewhere will work.

Submit unmodified, clear documents directly to Google. If you entered a brand in a legal-name field, correct the relevant legal information during verification; do not create another account and pay again as a first fix.

If Create app is unavailable, read the incomplete Console tasks first. The relevant account owner should resolve the named issue or contact Google support; another app or account will not bypass it.

Google requires identity verification first, plus website verification for organizations or device verification for personal accounts. Submitted documents still awaiting approval do not satisfy that prerequisite.

When the task becomes available, enter the number in international format, choose text message or voice call, and use Verify phone number. Enter the six-digit code directly in Google. If text delivery fails, try the offered call option.

Google’s public Play publishing API does not currently expose ordinary app-record creation. Create the first record in Play Console. The agent can help prepare that browser form, while you review the declarations and agreements. This does not mean every later publishing step must be manual.

Once the record exists and API access is configured, supported tools can upload builds, update listing text and images, manage testing tracks and check release status. Fastlane supply also manages an existing Play app; it does not replace initial app creation.

Google’s Custom App Publishing API creates private enterprise apps that can never become public. Its separate appstoreappsreview creation endpoint is for third-party app stores. Neither is a shortcut for creating a public Google Play app.

Company verification belongs to your developer account. Use that verified account for another app instead of registering again. Each app still needs its own app record, package name, listing and release setup.

A verified Google account, an app record and permission for a publishing service are three separate things. Signing in to Play Console does not automatically give RNBlocks API access.

For the service-account route, each publisher creates or reuses their own connection. You do not need to repeat developer registration or create a new Cloud project for every app. Add access to another app only when you want that connection to manage it.

A project name such as ‘Publishing tools’ is just a label. Confirm the signed-in Google Account and the project’s owner before continuing; an RNBlocks-looking name does not establish ownership.

There are two places to finish setup: Google gives publishing tools access, then RNBlocks saves your private connection. In Google Cloud, enabling the Google Play Android Developer API is a one-time switch for your chosen project. It lets publishing tools communicate with Play; it does not upload or release your app. Google asks you to accept its API terms as part of enabling it.

You can reuse this setup for later builds and other apps you own. For another app, grant the service account access to that app in Play Console, then select the saved connection in RNBlocks. You do not need a new Cloud project, key or paid developer membership each time.

Reuse a suitable service account owned by your publisher. In Google Cloud, select its project, open IAM & Admin → Service Accounts, then choose the account. Use Keys → Add key → Create new key → JSON if you need a new private key. Confirm its app access in Play Console before connecting it.

Publishing credentials and push-notification credentials serve different purposes. Setting up a Play publishing key does not configure notifications. Keep these separate unless you intentionally grant the account both sets of permissions.

Google checks different permissions for uploads, store details and draft apps. For a new draft app, check both Manage store presence and Edit and delete draft apps. The latter also grants deletion of that draft; it does not grant production release access.

Open Play Console → Users and permissions → your publishing service account → App permissions → your app → Manage permissions. After an approved change, select Apply and Save changes. Keep access limited to the intended app.

A permission error alone does not tell you which access is missing. Check which step failed before changing permissions. Text accepted into a temporary Google edit is not saved to the listing until that edit is committed and checked.

A service account is a robot account for publishing software. It belongs to your Google Cloud project; RNBlocks connects to it with your permission. With this setup, create one or reuse a suitable existing account, then grant access only to the apps it should manage. A separate Cloud project or key for every app is not required. Never grant Cloud project Owner or Editor just to enable Play publishing.

Use the service account’s JSON key, not a generic Google Cloud API key. It serves a similar purpose to the Apple API key used for publishing, but Google’s creation and permission steps are different. EAS Submit’s Android route requires this service-account key; Google OAuth support does not automatically make an OAuth connection usable by EAS Submit.

Google supports a service account for server-to-server publishing. Enable the Google Play Developer API in a Google Cloud project, then grant the service account the required app permissions in Play Console → Users and permissions. You no longer need to link the developer account to the Cloud project.

Keep service account keys out of chat and app source. Use a provider’s private credential form, and grant only the access needed for the intended app and actions. RNBlocks can review an existing AAB upload and initial listing details. Check the available tools for later testing, policy and release steps; connecting the account does not complete them.

A Play store build uses an Android App Bundle (AAB). A direct-install APK is a separate testing route. Expo’s current EAS Submit guidance supports the first internal release after the Play app record and service account are configured; it does not require a manual first upload. Check the chosen track and release status before approving an upload.

Prepare a signed store build, complete the listing and App content tasks, choose a testing track and verify the app on real devices. Use Play Console to check that the uploaded build and declarations are ready for review.

An Android APK installed directly on a phone does not satisfy a required Play closed-testing period. See the testing guide for the current personal-account requirement.