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?

This chapter will help you get your app ready for release. Although this chapter focuses primarily on preparing the app for the Google Play Store, most of the steps will apply regardless of the publishing platform.

Here’s a quick overview of each step involved:

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

You’re ready to walk through these items in detail.

Code cleanup

The first step is to make sure your project and code are ready for release. Here are a few items to consider:

• Choose a good package name. Once you submit an app to the store, you cannot change the package name. The package name is embedded in AndroidManifest.xml but can be set 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 this is to use a reverse naming convention based on a domain name that you own. For example, PodPlay published by raywenderlich.com has a package name of com.raywenderlich.podplay.

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

• Turn off debugging for release builds. By default, Android Studio creates debug and release build types for new projects.

  For the release build type, debugging is disabled by default. You can verify this by looking at app.gradle in the buildTypes section. Check that it has the following definition for the release build type:

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

  If you have a debuggable true line in the release build type, remove it.

  minifyEnabled enables code shrinking, obfuscation, and optimization for your projects release build type. Doing this increases build times and might introduce certain types of bugs, which is why you don’t enable this for the debug builds and is another reason why you need to thoroughly test your release build. ProGuard is the name of a tool that used to be used to help shrink your code for release. It removed unused code and libraries. It also obfuscated class, property and method names. Since Android Gradle version 3.4.0, Proguard was replaced by R8. R8 does the same thing ProGuard used to, but it’s developed and maintained by the Android team, and it does the job better. To make the transition to R8 simpler for developers, though, the code still refers to “proguard-rules”. For more details see https://developer.android.com/studio/build/shrink-code#enable

• Remove logging by deleting Log calls in the code or let R8 remove the calls during the release build.

  To have R8 remove the logs, 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 removes verbose, debug and information log calls, but it leaves warnings and errors. Make sure that any remaining warning or error messages do not log any personal data.

• Verify 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.

• 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.

• Perform any final localization tasks such as translating your string files to other languages.

Versioning information

Before releasing the app, make sure you have a good versioning strategy. This is 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 helps with debugging.

The best place to specify your app version is in the app.gradle build file. Two primary settings control versioning: versionCode and versionName. These are normally located in the defaultConfig section, as shown below:

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

• versionCode: This is the internal version number, which the user cannot 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 will not 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. Just don’t forget to update the string with each new release.

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

Build 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, the APK produced is signed with a debug key, which is automatically generated by Android Studio. This debug APK also has a special debuggable flag set and includes extra information to make debugging easier.

You can’t submit an APK built for debugging to the Play Store because Google won’t allow it. Also, you should not distribute it directly to users.

To make sure the debuggable flag is not set, and to have Android Studio build an optimized Release version of the APK, use the Release build type. Like the debug version, the release APK must be signed, but in this case, it should be with your own private signing key.

Create a signing key

Your first step in building a release version is to generate a signing key, which you’ll use to sign the app. This key is stored in a keystore file, and any future versions of the same app must be signed with the same key.

This key is critical to the security of your app. It should always be kept 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 you lose your key or it gets compromised. When using this method, you’ll sign the app with an Upload Key, and then Google will resign the app with your actual app signing key. This is covered more in the next chapter, but you can learn more here: https://developer.android.com/studio/publish/app-signing.html#google-play-app-signing.

Use the following steps inside Android Studio 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 they download only 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, with each one 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 to 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 to 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, and 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. Normally, this a folder outside of your main project folder.

    Under Build Variants, ensure release is selected.

    

13. Click Finish.

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

    The final output file is given the name app.abb.

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

Note: It’s worth mentioning one more time that it’s critical that you keep your release keystore secure! If someone else gets a hold of your key, they can do all sorts of damage, including distributing malicious apps under your identity.

Check 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. This is not an issue for most applications, but if you find yourself with a large bundle file, you can find details about using app bundles and dynamic feature modules files here: https://developer.android.com/guide/app-bundle/

Release testing

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

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

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 a real device will provide immediate feedback on many aspects of your app’s user experience, including gestures, touch targets, and inconsistencies you might not have otherwise noticed on the emulator. However, you also want your app to be tested on a wide variety of device types from different manufacturers, screen sizes and resolutions. Most of us don’t have the luxury of having a huge library of hardware like that. That’s where the Firebase Test Lab can come in handy. It allows you to test your app on a wide variety of different devices and Android versions. For more information on Firebase Test Lab see the documentation here: https://firebase.google.com/docs/test-lab/

Google Play Store

Now that your release APK is ready, it’s time to go over the steps to create a Google Play Store listing.

Google Play Console signup

The first step is to sign up for a Google Play Console account. The Google Play Console is your gateway to managing and publishing your apps on the Google Play Store.

Go here to sign in or sign up for a new Google Play Console account:

https://play.google.com/apps/publish/

Verify that you’re signed in with the correct account first. Read and agree to the developer agreement, and then click CONTINUE TO PAYMENT. The current registration fee is $25, and it only has to be paid once.

After you finish the payment, you’re taken to the Developer Profile screen. Make sure you pick a good Developer name as it’s shown in the Play Store below the name of your app.

The main console

Once you’re finished with signup, you’ll get to the main console.

In the menu on the left, you have several options:

• All Applications is where you add new applications or manage existing ones.
• Game Services provides a lot of additional features for games. You can find more info here: https://developers.google.com/games/services/.
• Order Management, if you have a paid app or in-app purchases, you can manage orders including giving refunds.
• Download Reports provides a variety of reports, including crashes, reviews, statistics, user acquisition and financial records.
• Alerts is where you can see any alerts generated by the Play Store for your apps.

And finally Settings provides several sub-sections:

• Developer account: You can manage profile settings, add other console users, control API access and set up payment options.
• Developer page: Here’s where you can configure how your developer page looks in the Play Store. Your developer page won’t be available until you publish your first app.
• Pricing templates: You can use pricing templates to setup or manage the same set of prices for multiple paid apps and in-app products.
• Manage email lists: You can manage alpha and beta testers from this section.
• Preferences: This is where you set notification preferences and control privacy settings.

Creating your first app

To get started, click PUBLISH AN ANDROID APP ON GOOGLE PLAY on the main console screen. In the future when you already have other apps published, you will instead use the “create application button” at the top of your list of applications:

Note: At this point, you’re just preparing the store listing and creating a draft version of the app; nothing gets published until you use the Publish step.

First, fill in the title of your app and click CREATE.

This creates the app and presents you with several pages of information related to it.

The first page you’ll see is the Store listing. Here’s a partial view of this page:

Click the “Save Draft” button at the bottom of the page. Go back to the home console screen, and you’ll see the new app you just added, with a status of Draft.

Click on the app name to go into the Dashboard view for the app. Look at the left side of the screen. The items with grayed out checkmarks to the right represent the things you must complete before publishing the app.

You’ll start with the Store Listing first, but before you can begin, you need to gather a few items.

Store graphic assets

There are some graphic assets your app is expected to have. They are:

• Screenshots: You’re required to upload at least two screenshots, although you can have up to eight per device type. The size of a screenshot has to be at least 320px on the shortest side and no longer than 3840px on the longest side. You can upload portrait or landscape orientation screenshots.

Note: You can create screenshots from the emulator by using the camera icon on the emulator toolbar.

• High-res icon: A high-res icon is required with a size of 512px x 512px. This gets displayed in the Play Store only. Your app’s launcher icon is still shown on the user’s device.

• Featured graphic: The featured graphic is required and should be 1024px by 500px. It’s shown at the top of your app listing.

Privacy policy

If your app requests access to sensitive information or is in the Designed for Families program, you must provide a link to a privacy policy. This privacy policy must discuss specific privacy policies related to the app.

Store listing

Click Store listing and fill out the following required items:

• Short description: Up to 80 characters. Mention the most important feature of your app and explain why a user would want to install it. Think of this as the app promotional text.

• Full Description: Up to 4000 characters. Provide the full benefits and features of your app. Use keywords in the description that users are likely to use when searching for an app like yours.

List out the main features one-by-one and highlight the most important ones. You can use rich formatting in your description, but some of it may only appear in the Google Play Store app. This includes URL links, UTF-8 characters and Emojis.

• High-res icon: Drag your high-res icon into place.

• Screenshots: Drag your screenshots to the appropriate device tabs.

Feature graphic: Drag your feature graphic into place.

• Application Type: Choose between application or game.

• Category: Select the category that best matches your app. Music & Audio was chosen for PodPlay.

• Tags: While not required, adding tags to help Google categorize your app will make it more likely to be found when users search for your app. If you click the Manage Tags button you will be redirected to a separate screen for this. Make sure you click SAVE DRAFT before doing that.

• Content Rating: You may see a message, “You need to fill a rating questionnaire and apply a content rating”. This appears if you haven’t yet uploaded an APK and filled out the content rating questionnaire. You’ll do this in the next chapter.

• Contact Details: Check your contact details to make sure they’re accurate. This information is displayed on the app page.

• Private Policy: Enter the URL for your privacy policy if required by your app.

Click SAVE DRAFT.

The Determining content rating and Pricing and distribution sections require you to first upload an APK to Google Play before you can fill this out. These sections are covered in the next chapter.

Where to go from here?

Congratulations, most of the hard work is done! 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.

Take some time and go through all of the menu items of the Play console. You’ll discover that Google provides developers with tons of tools to help apps succeed once they’re in the Play Store.

You should also check out the YouTube video “Use Android Vitals in the Google Play Console to Understand and Improve Your App’s Performance” from Google I/O 2017. Members of the Google Play team go over some of the fantastic tools available to developers.