30. Preparing for Release

Written by Fuad Kamal

So you finally built that app you’ve been dreaming about. Now it’s time to share it with the world! But where do you start?

By the end of this chapter, you’ll have the essentials you need to deploy your app to the Google Play Store. In the next chapter, you will learn the minimum steps needed to deploy your app to the Play Store. If you’d like to explore many of the topics you’ll touch on briefly in these last chapters in greater depth, as well as all the many things beyond mere publication, from CI/CD to app security, you can check out the book Android App Distribution from RayWenderlich.com. Although this chapter focuses primarily on preparing the app for the Google Play Store, most of the steps apply regardless of the publishing platform.

Here’s a quick overview of each step:

• Clean up any debugging code you may have in the source.
• Check the app version information.
• Create a release version of the app with the correct signing key.
• Test the release version on as many devices as possible.
• Create a Google Play Console developer account.
• Create screenshots, promotional graphics, and videos.
• Fill out the app details on the Google Play Console.

Now you’re ready to walk through these items in detail.

Code cleanup

First, make sure your project and code are ready for release. Here are a few items to consider.

Choosing a good package name

Once you submit an app to the store, you can’t change the package name. The package name is embedded in AndroidManifest.xml, but you can set it in the app’s build.gradle.

The package name must be unique from all other apps in the Play Store. One of the best ways to ensure your name is unique is to use a reverse naming convention based on your own domain name. For example, PodPlay published by raywenderlich.com has the package name com.raywenderlich.podplay. You can view your app’s package name in your app-level build.gradle as shown below:

defaultConfig {
  applicationId "com.raywenderlich.podplay"
  ...
}

Note: For more information on how to use the package name and how it differs from the application ID, see the Android developer documentation: https://developer.android.com/studio/build/application-id .

Turning off debugging for release builds

By default, Android Studio creates debug and release build types for new projects.

For the release build type, Android Studio disables debugging by default. You can verify this by looking at the buildTypes section in the app build.gradle. If you have a debuggable true line in the release build type, remove it.

In the starter project for this chapter, open the app build.gradle. Notice the buildTypes section:

buildTypes {
  release {
    minifyEnabled false
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
  }
}

There are two things of note here. First, when you make a new Android project in Android Studio, it sets minifyEnabled for the release build type to false. Generally, you want to set minifyEnabled to true. However, setting it to true can have consequences, especially in more complex apps, so test your release build to make sure it works properly.

minifyEnabled allows code shrinking, obfuscation, and optimization for your project’s release build type, but also increases build times. If you’re unfamiliar with minifyEnabled, it can be a source of hard to track down bugs, which is another reason to test your release build thoroughly.

The second thing of note is the name of the Proguard file: proguard-android.txt. You’ll learn more about Proguard rules later. For now, know that the above reference is there because the sample app was made with an earlier version of Android Studio. As of Android Studio version 4.0.1, new projects reference proguard-android-optimize.txt by default. This change provides additional optimizations for your release build.

Change the buildTypes section to:

buildTypes {
  release {
    // Enables code shrinking, obfuscation, and optimization for
    // only your project's release build type.
    minifyEnabled true
  
    // Enables resource shrinking, which is performed by the
    // Android Gradle plugin.
    shrinkResources true
  
    // Includes the default ProGuard rules files that are
    // packaged with the Android Gradle plugin.
    proguardFiles getDefaultProguardFile(
      'proguard-android-optimize.txt'),
      'proguard-rules.pro'
  }
}

Removing logging

For your app’s security, you should remove debugging log messages from your app’s published version. Remove logging by deleting Log calls in the code.

Alternatively, you can let something called R8 remove the calls during the release build. R8 is a compiler that tackles the following:

• Code shrinking. It removes unused code from your app and its library dependencies.
• Resource shrinking. After code shrinking, R8 then removes unused resources from your app and its library dependencies.
• Obfuscation. It shortens the names of classes and members, reducing DEX file sizes. This is also one of the areas which can lead to bugs if you’re not careful. You can help guide this by adding rules to the file proguard-rules.pro in your app. This is one of the R8 configuration files which you can edit to add your own rules.
• Optimization. Finally, R8 inspects and rewrites your code to further reduce your app’s DEX files. DEX is a special executable file (Dalvik Executable) that was developed specifically for Android, rather than using standard Java byte code instructions. To learn more and gain some interesting insight on the origins and evolution of Android itself and Dalvik, check out episode 156: Android Runtime Classic (Dalvik) on the Android Developers Backstage Podcast. Now, if only you had an app with which to search for and listen to podcasts… :]

To have R8 remove the logs, you need to add the following lines to proguard-rules.pro in the root of your project:

-assumenosideeffects class android.util.Log {
  public static boolean isLoggable(java.lang.String, int);
  public static int v(...);
  public static int d(...);
  public static int i(...);
}

This code removes verbose, debug, and information log calls but leaves warnings and errors. Make sure any remaining warning or error messages don’t log personal data.

Verifying production settings

If your app communicates with external services, has update URLs, API keys, or other configuration items that are different during development, change them to the proper production settings.

Removing unused Resources

In Android Studio, run the Remove unused Resources command in the Refactor menu. Then check for stray files in your project. Look inside src to make sure it contains only source files. Check assets and res for outdated raw files, drawables, layouts, and other items. If found, remove them from the project.

Localizing

Perform any final localization tasks, such as translating your string files to other languages. You can broaden your app’s appeal with this simple yet often overlooked step.

Versioning

Before releasing the app, make sure you have a strong versioning strategy. It’s critical to maintaining the app and keeping a handle on support issues that may arise.

Users should be able to identify the version number and trace it back to a specific source code snapshot. This ability to trace helps with debugging.

The app build.gradle file is the best place to specify your app version. Two primary settings control versioning: versionCode and versionName.

Typically, you’ll find these settings in the defaultConfig section, as show here:

defaultConfig {
  applicationId "com.raywenderlich.podplay"
  minSdkVersion 23
  targetSdkVersion 30
  versionCode 1
  versionName "1.0"
  testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}

• versionCode: this is the internal version number, which the user can’t see. It’s an integer value and you should increase it with each new build you upload to the Play Store. The Play Store uses this number to determine if one build is older than another. It won’t allow installs that downgrade to an older version.

• versionName: this is the external version number visible to the user. You have full control over how it’s formatted. Most apps use a major.minor.point release format for versionName. The key is to have a consistent formatting convention. Remember to update the string with each new release.

Note: Developers often refer to the major.minor.point release scheme as Semantic Versioning. For more information on this scheme, check out https://semver.org/.

Building a release version

Each time you build and run your app during development, Android Studio produces an APK file and installs it on the emulator or device. This APK file contains your app’s executable code as well as all of its resources.

When using the default debug build type, Android Studio automatically generates an APK and signs it with a debug key. This debug APK also has a special debuggable flag set and includes extra information to make debugging easier.

Google won’t let you submit an APK built for debugging to the Play Store. You also shouldn’t distribute it directly to users.

To make sure the debuggable flag isn’t set, and to have Android Studio build an optimized release version of the APK, use the release build type. Like the debug version, you must sign the release APK. But in this case, you should sign it with your private signing key.

Creating a signing key

To build a release version you first need to generate the signing key you’ll use to sign the app. The key stores in a keystore file. You must sign any future versions of the same app with the same key.

This key is critical to the security of your app. You should always keep it private and in a safe place. If you lose the keystore, you won’t be able to release a new version of your app under the same package name!

Note: Google has a Google Play App Signing feature. This service lets Google manage your signing key, giving you some options if your key is lost or compromised. When using this method, you’ll sign the app with an Upload Key. Then Google will resign the app with your actual app signing key.

The next chapter will cover this in more detail, but you can learn more here: https://developer.android.com/studio/publish/app-signing.html#google-play-app-signing.

In Android Studio, use the following steps to create your signing key:

1. Click Build ▸ Generate signed Bundle / APK… from the menu.

   

2. An Android App Bundle is a format that includes all of your app’s compiled code and resources but defers APK generation and signing to Google Play. Google Play then uses your app bundle to generate and serve optimized APKs for each user’s device configuration, so users only download the code and resources they need to run your app. Select Android App Bundle and click Next.

   

3. Select Create new… to create a new keystore. A keystore can hold multiple signing keys, each of which is referred to by an alias name.

   

4. The New Key Store dialog appears.

   

5. Select the Key store path where you want to store the file. You must use a specific extension, such as .jks. Otherwise, the Google Play console may throw an error when you try to upload the APK.

6. Fill in the keystore Password and repeat it in the Confirm field. Make sure you store this password safely because you’ll need it whenever you access the keystore.

7. Fill in the following items for the Key:

• Alias: enter a name for the key, usually the name of your app.

• Password: enter a password for this alias.

• Confirm: repeat your password.

• Validity (years): leave this at 25 years. The key expires after this time.

• Certificate: enter your personal information in these fields. The user won’t see your data, but it’s part of the signing certificate in the APK file.

8. Click OK. The original dialog, with the values already populated, appears.

   

9. If you don’t want to enter passwords each time you build a release version, check Remember passwords.

10. To take advantage of Google Play App Signing, check Export encrypted key for enrolling published apps in Google Play App Signing and choose a destination folder to save the encrypted key. This key is encrypted for transfer to Google Play.

11. Click Next.

12. Fill in the Destination Folder. Typically, this a folder outside of your main project folder.

    Under Build Variants, ensure you’ve selected release.

    

13. Click Finish.

    Android Studio builds and signs the release Android App Bundle file and places it in the destination folder. A popup appears at the bottom right corner of Android Studio when the build is complete.

    Android Studio names the final output file app-release.aab.

You’ll follow these same steps each time you build a release version. However, you can skip steps three through seven since you already created the keystore and key.

Note: It’s worth mentioning again that you must keep your release keystore and password secure! If someone gets ahold of your key, they can do all sorts of damage, including distributing malicious apps under your identity.

Checking your file size

Check the size of the app bundle file. If it’s over 500MB, you won’t be able to publish it as-is to the Play Store. You can get around this limitation by using dynamic feature modules.

While this isn’t an issue for most apps, if you find yourself with a large bundle file, check out this guide to using app bundles and dynamic feature modules: https://developer.android.com/guide/app-bundle/. You can learn more about dynamic features in this tutorial : https://www.raywenderlich.com/7023243-navigation-and-dynamic-features as well as the Android App Distribution book.

Release testing

Test the release file on as many devices as you possibly can. Subtle bugs can show up when running the release versus debug versions of your app, especially when running on different hardware devices. At a minimum, test on at least one phone and one tablet.

You can test your Android App Bundle using bundletool to generate APKs from your app bundle and deploy them to a connected device. You can find details about downloading and using bundletool here: https://developer.android.com/studio/command-line/bundletool

Alternatively, you can use the Play Store to deploy to devices to test your release build. You’ll learn how in the following sections.

Nothing beats testing your app on a real device, so it’s a good idea to have at least one around. Interacting with your app on an actual device provides immediate feedback on many aspects of your app’s user experience, including gestures, touch targets, and inconsistencies you might not notice on the emulator.

You should also test your app on a variety of device types from different manufacturers, as well as screen sizes and resolutions. Most of us don’t have the luxury of a vast library of hardware. That’s where the Firebase Test Lab can come in handy. It lets you test your app on a wide variety of devices and Android versions. For more information on Firebase Test Lab, refer to the documentation here: https://firebase.google.com/docs/test-lab/

Other publishing methods

In the next chapter you will learn how to distribute your app using the Play Store. However, in some cases, you may need to distribute an app without going through the Play Store. It might be an enterprise app that will never go public, or it might be a side project you’re distributing to friends and family.

There are a few ways to distribute an app directly.

Email distribution

Email requires the least amount of work on your part. All you do is attach the APK file to an email and have your users open the email on a compatible Android device.

Users will need to configure their devices to allow unknown sources before installing the APK. It’s a good idea to include instructions in the email when sending out the APK.

If a user is running Android 8.0 or newer, they should look for the Install unknown apps section in the device settings.

If a user is running a version before Android 8.0, they should enable Unknown sources in the Security section of the device settings.

When the user opens an email with an APK attached, they can download the APK.

The user can then find the APK in their downloads app or by pulling down the notifications view. When they tap the APK file, they’ll be prompted to install the app.

Website distribution

Another option is to host the APK file on your website or a cloud share service such as Dropbox, Google Drive, or Slack. You can either send a link to the download location or point the users to the download page on your site. Whether the user taps the link from an email or the browser on the device, they’ll be prompted to install the APK.

As with email distribution, the user must configure the device to allow unknown sources.

Internal app sharing

There is a somewhat hidden feature in the Play Store that also allows you to directly distribute APKs to select small email lists. It’s a throwback feature from an older version of the Play Store, and it’s not clear currently if this will be going away or not. You will explore this in further detail in the next chapter.

Other app stores

There are some other app stores available for publishing your app. You may want to take time to explore which options are available.

One of the most well-known stores is the Amazon Appstore. Amazon devices such as the Fire TV and Fire Tablet come with the Amazon Appstore by default. It contains apps made especially for Amazon products as well as many apps also found in the Google Play store. There’s no registration fee for developers on the Amazon Appstore, and it also offers some unique monetization models.

There are some fundamental differences between Google and Amazon in the way apps are purchased and how in-app billing is handled. However, in both cases, you’ll get 70% of the app earnings.

One big difference is that you can’t switch a free app on Google Play to a paid one. You must make that decision during the initial rollout. Amazon lets you start your app as free and change to paid at any time. The Amazon App store process is a bit more involved and requires you to wrap your APK in their code.

You can always start by releasing to the Google Play store and then decide later if you also want to distribute the app to other app stores.

Key Points

In this chapter you learned:

• How to clean up and prepare your code for publication to the Play Store.
• The recommended best practices for versioning your app.
• How to create the app bundle for distribution of your app on the Play Store.
• Alternate methods from the Play Store for distributing your app.

Where to go from here?

Congratulations, you now have an APK file ready for distribution! All that’s left is to create a new app release and upload your signed APK file. You’ll cover this and the publishing step in the next chapter.