Publishing an app to the Play Store involves the following steps detailed in the publishing overview (Android docs):

1. Preparing for release
2. Generating an unsigned release version
3. Signing the application
4. Publishing

Note: Gradle can automate generating a signed release version of the app, but the manual method of doing this is explained to familiarize you with the app signing process.

For details on how to configure Gradle for automated app signing see here

• Remove any Log calls.
• Configure build settings.
  • Build settings are modified in <root>/app/build.gradle:
  • See the section on Build Settings for details.
• Configure application.
  • Application settings are found in the AndroidManifest.xml file.
  • See the section on the Android Manifest File for details.

An unsigned release .apk can be generated using the gradlew gradle wrapper script.

To get a list of build tasks, enter ./gradlew tasks from the project root directory. The following output should be displayed:

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------
...
Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleDebugAndroidTest - Assembles the android (on device) tests for the Debug build.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
...

To build an unsigned release version:

1. Navigate to the project root.
2. Run ./gradlew assembleRelease.
3. If the build is successful, app/build/outputs/apk/app-release-unsigned.apk will be created. An unsigned version is generated if the build process was not able to access the public key within the keystore.
4. Check the build badging information (e.g., version code/name) via aapt dump badging app-release.apk

For more details, see the Android developer docs on building in release mode

This section describes how to sign an app via the command line, as detailed in signing an app manually in the Android developer docs.

1. Generate a keystore and key pair if necessary. Uses keytool.
   • keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
     • This command generates a keystore with a single key pair. Description of the keytool options used above:
       • genkey: generates a new private/public key pair.
       • -v: use verbose mode. keytool will display all logging.
       • -keystore: the location of the keystore file.
       • -alias: attaches a name to the key pair being generated that allows the key pair to be retrieved.
       • -keyalg: the algorithm used to generate the key pair. Use RSA.
       • -keysize: size of the each key to be generated, in bits. Use 2048.
       • -validity: lifetime of this key pair in days, after which the key pair will expire. A validity period of greater than 25 years (9,125 days) is recommended.
   • A keystore is a container that stores pairs of public and private keys.
     • These pairs of keys are identified via an alias.
     • In Android, signing an app involves encrypting it with the private key and embedding the public key in the .apk.
     • Signing multiple apps with the same key pair has advantages and disadvantages
       • Advantages: apps can run in the same process and can share code and data.
       • Disadvantages: transferrring ownership of applications can become complicated.
     • This StackOverflow answer contains a good description of keystores and aliases.
2. Sign the release version of the app. Uses jarsigner.
   • `jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name
     • This command signs the .apk file with the supplied keystore. Description of a few options used above:
       • -sigalg: name of the algorithm used to sign the .apk. Must be compatible with the private key used to sign the .apk with. Use SHA1withRSA.
       • -digestalg: the algorithm used to digest entries in the .apk. Use SHA1.
3. Check to ensure the apk was signed successfully. Uses jarsigner.
   • jarsigner -verify -verbose -keystore my-release-key.keystore my_application.apk
     • The keystore option is optional.
   • The following message indicates a successfully signed .apk file:
     • jar verified
   • The following warning can be ignored:
     • This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2043-01-22) or after any future revocation date.
     • If a Timestamp Authority URL can be supplied during signing then users will be able to use the app past its validity date. See this Stack Overflow answer for more details on this warning.
4. Align the compressed app. Uses zipalign.
   • zipalign -f -v 4 unaligned-source.apk aligned-destination.apk
     • -f: overwrite destination file
     • -v: verbose output
     • 4 specifies alignment of files on 4-byte boundaries.
   • zipalign helps reduce the memory footprint of the application by aligning assets and other uncompressed data on 4-byte boundaries.
   • If alignment was successful, Verification Successful will be displayed at the end of the output.
   • To verify that an .apk has been aligned properly: zipalign -c -v aligned-destination.apk
   • Note: zipalign should only be performed AFTER signing the .apk file, since signing will change the alignment of bytes.

The Gradle build system can create a signed release version of the app.

See how to configure Gradle to build a signed release version

Publishing is done through the Google Developer Console. A Google developer account is required.

• Select or create the appropriate application.
• Upload a signed release version .apk.
• Provide all necessary information.
• Publish app.

• Publishing overview - Android docs