Chapters

Hide chapters

Android Apprentice

Third Edition · Android 10 · Kotlin 1.3 · Android Studio 3.6

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section II: Building a List App

Section 2: 7 chapters
Show chapters Hide chapters

Section III: Creating Map-Based Apps

Section 3: 7 chapters
Show chapters Hide chapters

30. Preparing for Release
Written by Fuad Kamal

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

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.

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

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.

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.

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.

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.

The main console

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

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:

Store graphic assets

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

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:

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.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now