Android signing and the Play Store

Every Android build is signed. What differs is what it is signed with, and that decides whether Google Play will take it.

	Signed for testing	Signed for Play
Installs on a phone	Yes	Yes
Can be uploaded to Play	No	Yes
Setup needed	None	An upload key

With nothing set up, your build is signed with the Android testing certificate. That is a real, working app: install it, hand it to testers, use it at full functionality. Google Play refuses it.

Once your own upload key is in place, the same Build press signs with that instead, and the .aab it produces is one Play accepts. You never choose between the two — Memberside checks before each build and uses your key whenever it can.

Your key stays on your site

Your keystore and its password are stored by the Memberside plugin on your WordPress site, under Memberside → API Keys → Android signing. Memberside fetches them only while a build you started is running, never stores them, and deletes them from the build server when the build ends.

Nothing on this page is demanded of you. Until you save a Play listing or open Google Play setup, Memberside says nothing about any of it — an app you only ever sideload is not nagged about a store it will never visit.

Each section below matches one step in the Google Play setup window, in the same order.

Play developer

Google accepts an app only from the developer who owns it, and Memberside never publishes on your behalf. You need a Google account registered as a Play developer, which costs a one-time registration fee.

Sign up in the Play Console. A personal account is quicker; an organisation needs a D-U-N-S number. Google verifies your identity before you can publish.

Tick this step once you have the account.

Play app record

Create the app in Play Console — Create app, then its name, language and whether it is free or paid.

Do this before your first upload rather than after. The package name is permanent once published, and creating the app is how you find out yours is still available.

Tick this step once the app exists in Play Console.

Package name

Your package name is the app’s permanent identity on Google Play, for example com.yourclub.app. Set it under Settings → General.

It can never be changed once you publish: a new package name is a different app, and your members would have to install it fresh.

Android is stricter than it first appears:

• at least two parts, separated by dots;
• every part must start with a letter — com.acme.4you is refused, though it saves without complaint;
• no part may be a word Android reserves, like new, class or native;
• underscores are fine here, though Apple rejects them, so an app that also builds for iPhone is better off without.

The default package name can never be published

An app that has never had an identifier set uses Memberside’s default. Every such app shares it, so Play would refuse the second upload as somebody else’s app. Set your own before you publish.

App icon

Google Play will not accept a submission without one. Upload a square PNG of at least 512×512 under Settings → General.

Site connected

Your upload key lives on your WordPress site, so the site has to be reachable for a build to use it. Connect it under Settings → Connections with your site address and an application password.

Plugin signing support

The Memberside plugin on your site needs to be new enough to store an upload key and hand it to a build. Update it under Plugins on your site.

If your site is already on the newest version and this step is not green, support is on its way and there is nothing for you to do.

Keystore

The keystore holds the key that signs your app as yours.

You do not need keytool

The usual way to make a signing key is a command line, a JDK, and eight prompts whose answers are permanent. Memberside can make one for you instead.

In Google Play setup, open this step and choose Create an upload key. We generate it, store it on your own site, and show you the key and its password once.

Save both when they are shown. That is the only time either appears. They live on your site from then on, and Memberside keeps no copy.

If you already have a keystore, upload it under Memberside → API Keys → Android signing on your site, with its password and the key alias. Both .jks and .p12 files are accepted.

If you lose the key

Under Play App Signing — the default for new apps — Google holds the key that signs what members install, and yours is only the upload key. Losing it is recoverable by asking Google to reset it. That is a support request rather than a button, so keep the copy you were given.

What your site can and cannot check

Your site opens the keystore to check it, and reports a wrong password, a file that is not a keystore, an expired key or one weaker than Play allows.

Two things it cannot check, and says so rather than guessing:

• a .jks file. That is a Java format PHP cannot open at all. It reads as unchecked, and the build server — which has the right tools — checks it instead.
• the key alias, when your keystore holds more than one key. Only a build that tries the alias can settle it, so a wrong alias shows up as a failed build rather than a red step.

Signing fingerprint

Google Maps and native Google sign-in are authorised by your package name and the SHA-1 of the certificate your app is signed with.

The fingerprint belongs to the key, not to a build, so it appears as soon as your site holds your upload key — there is nothing to build first. This step shows it with a button to copy it, next to your package name; the builder shows the same value in the social sign-in and Maps settings.

The fingerprint changes with your first Play-signed build

Testing builds and Play-signed builds have different fingerprints, so Maps and Google sign-in stop working until you register the new one. Until your site holds an upload key, the only fingerprint anything can show is the testing one — which is not the one to register, and both the step and the builder say so rather than offering it as if it were.

Add it to your credential in Google Cloud Console, alongside your package name. Once your app is live, add the Play App Signing fingerprint from Play Console → Setup → App integrity as well, because Google re-signs every upload with a key of its own.

This step only appears if your app uses Maps or Google sign-in.

Push

Notifications on Android need four Firebase values: the API key, app ID, sender ID and project ID. Add your Android app in the Firebase console and copy all four to Memberside → API Keys → Firebase on your site.

All four or none. A partial set compiles, installs, and then closes the moment the app opens.

Maps

A native map on Android needs its own mobile SDK key, compiled into the app. Add it under Memberside → API Keys → Google Maps on your site, and restrict it to your package name and signing fingerprint.

Google sign-in

Native Google sign-in on Android needs its own OAuth client, separate from the one your website uses. Add an Android client ID under Memberside → API Keys → Social login → Google.

In-app purchases

Purchases are checked against a package name. Set the Google package name under Memberside → In-App Purchases on your site to this app’s package name, and map at least one product to a Play product ID.

When it does not work

Symptom	Cause	Fix
Play rejects the bundle as debug-signed	That build was signed for testing	Add your upload key; the next build is signed with it
“The saved password does not open this keystore”	The password on your site does not match the file	Re-enter it under Memberside → API Keys → Android signing
“Enter its password to check it”	The keystore is uploaded but no password is saved yet	Add the password. Nothing is wrong with the file
Your site reports the keystore as unchecked	It is a .jks, which your site’s PHP cannot open	Nothing. The build server checks it instead
A build failed on the upload key	Usually the key alias does not match the one in the keystore	Check the alias against what your keystore holds
Google sign-in or Maps broke after your first Play build	The signing fingerprint changed	Register the new one, shown in Google Play setup
Play refuses your key as expiring too soon	Play needs a key valid past 22 October 2033	Create a new upload key
The package name step will not go green	Often a part starting with a digit, which saves but Android refuses	Read the reason the step gives; it names the rule

Next

APK and AAB, then Preparing your store listing.

For the other store, How iOS builds work and Getting ready for iOS builds.