2. App Store Quick Start

Written by Fuad Kamal

So you’ve 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. Later in this book you’ll explore in greater depth many of the topics you’ll touch on briefly in this chapter. 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 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 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 referenced, 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. You’ll learn more about R8 later. For now, know that 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

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.gradle build 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’ll learn more about dynamic feature modules in future chapters.

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/

Creating your Google Play Store listing

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

Google Play Console signup

First, 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 up for a new Google Play Console account or sign in if you already have one:

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

First, verify that you’re signed in with the correct account. Read and agree to the developer agreement. Then click CONTINUE TO PAYMENT. The current one-time registration fee is $25.

After you finish paying, you’ll go 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 finish with signup, you’ll move to the main console.

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

• All apps is where you add new apps or manage existing ones.
• Inbox is where you’ll find messages from Google Play.
• Users and permissions is where you can add additional users to your account and manage what those users can do and see under your account.
• Order Management lets you manage orders, including giving refunds, for paid apps or in-app purchases.
• Download Reports provides various reports, including crashes, reviews, statistics, user acquisition and financial records.

And finally, Settings provides several sub-sections:

• Developer account: You can manage profile settings, control API access and set up payment options. In this section, you’ll find Developer page, 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.
• Preferences: This is where you set notification preferences and control privacy settings.
• Email lists: You can manage alpha and beta testers from this section. Note that you can only use Gmail addresses for your tester distribution lists.
• License testing is where you test your licensing and in-app billing integrations. You can set up testers to make in-app purchases without getting charged anything.
• Manage game projects provides additional features for games. You can find more info here: https://developers.google.com/games/services/.
• Pricing templates: You can use pricing templates to set up or manage the same set of prices for multiple paid apps and in-app products.

Creating your first app

Click Create app on the main console screen.

In the future, when you have other published apps, you’ll use the Create app button at the top of your list of apps instead:

Note: At this point, you’re only preparing the store listing and creating a draft version of the app. You won’t publish anything until you use the Publish step.

Fill out the Create app form:

1. First, fill in the title of your app.

   

2. Then choose the default language for your app.

   

3. Select whether it’s an app or a game.

   

4. Then select whether your app is paid or free. If you choose free, you can only change this up until the app publishes. After that, free apps can never convert to paid apps.

   

5. Check the legal declarations.

   

6. Finally, click Create app.

After that, you return to the dashboard page. You’re not quite done yet. You still need to fill out a bunch of information about your app and upload the app bundle you created earlier. But now the dashboard presents a wizard listing the remaining steps and what you need to do:

It might seem like a lot of steps, but it’s not too bad. Fill out all the required information under the First steps task. As you finish each section, a checkmark appears next to that section to show it’s complete:

You can’t skip this step. The Release your app task has a lock icon, and you can’t access it until you complete this.

Note: At this point, you’re only preparing the store listing and creating a draft version of the app. You won’t publish anything until you complete the Release your app step.

Go back to the All apps section and see your new app listed there with App status set to draft:

Click your app’s name to go back to the dashboard and setup steps. The majority of the steps gather information so the Play Store can categorize your app properly. However, the final step, Set up your store listing, asks you to upload some graphic assets. Setting up your store listing is critical since it defines how potential users find and perceive your app.

Main store listing

Click Set up your store listing to view the sub-tasks there. App name is already complete. Fill out the short and full description fields.

Store graphic assets

Your app needs the following graphic assets:

• App icon: This icon only shows up in the Play Store. Your app’s launcher icon still shows on the user’s device. Apply Pixels is an excellent resource for easily creating app icons and other assets required by the Play Store: https://applypixels.com.

• Featured graphic: You’ll find the featured graphic at the top of your app listing.

• Screenshots: You’re required to upload at least two screenshots, although you can have up to eight per device type. You can upload portrait or landscape orientation screenshots.

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

For specifics on the image dimensions and more, see the descriptions in the Play Store Console.

• Video: While not required, it’s highly recommended you provide a video demo of your app. A video is a great way to capture potential users’ attention. You’ll get into this more later in the book.

Once you complete the First Steps section, your app title and icon will appear on the dashboard. The Release your app section is now unlocked.

Releasing your app

Click Select testers to go to the Internal testing page. You’ll learn about the different release types in the next chapter. For now, create a quick email list in this section with a list of testers who will test your first app release. If you don’t have any testers, list your email address so you can deploy builds to your device through the Play Store. You also have the option to provide a feedback URL or email address for testers to provide feedback.

Once you create one or more test group email lists, select one and click Save changes on the bottom right.

Finally, click Create new release in the upper right corner. You’ll go to the page where you upload your app bundle and make the app available to testers.

You’ll see a note reminding you Google will manage the signing key for you. Click Continue. Then drag and drop app-release.aab, the app bundle you created earlier, onto the section titled App bundles and APKs to upload your release.

When your app bundle uploads successfully, you’ll see it listed beneath the upload section with details about the build:

Next, provide a name for the release under Release details. If you haven’t already thought about a release naming strategy, now would be a good time to do so. You want to be able to distinguish each release to avoid confusion and address bugs as they appear.

Finally, fill out the release notes section and click Save. Then click Review release at the bottom.

If there are any issues with your release, they’ll appear on the next screen. You can Edit release to address them.

If you have no errors, click Start rollout to internal testing at the bottom of the screen. You’ll see a confirmation dialog. Click Rollout to release your app.

Congratulations! You’ve released your app to the Google Play Store!

Note: It may take a little time for your app to appear published on the Google Play Console. You also might need to refresh the Google Play Console page to see the publication status update. If you included your own Gmail address in the selected tester list, you can search for and install your app using the Google Play app on your Android device.

Once your release shows as published, click Testing -> Internal testing in the Google Play Console to see the release under the Releases tab.

Click the Testers tab. You’ll also see a Copy link button at the bottom. You can use it to get a URL your testers can use to install the app.

Key points

• A keystore stores your signing key details. Keep track of the passwords and store them in a safe place, or you won’t be able to continue releasing your app under the same name.
• R8 provides a mechanism for optimizing and obfuscating your app. Choose your options wisely and test thoroughly to avoid bugs.
• The Google Play Console provides a dashboard through which you can manage your app releases, testers and much more.

Where to go from here?

Take some time to go through all of the menu items on the Google Play Console. You’ll discover Google provides developers with several 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” (https://www.youtube.com/watch?v=vj3Y8L5HLdg) from Google I/O 2017. Members of the Google Play team go over some of the fantastic tools available to developers.

You’ve released your app to the Google Play Store, but there’s much more to creating a successful app. The rest of this book will dive deep into these topics.