Publish to the Google Play Store

Slides

You perform five main tasks to prepare your application for release. First, gather materials fo release.

To publish on google play, you need a high res icon, feature graphic and few screenshots etc. You might also have to prepare promotional and marketing materials to publicize your application. You will see this in detail in the later episode when you create store listing.

Google also recommends that you prepare and provide one End User License Agreement with your application. It protects an App Developer’s interests in their App – in particular – any intellectual property rights of individual or organization. After you gather all of your supporting materials, you can start configuring your application for release.

In this episode, you will focus in detail on how to configure your app for release. In the later episode, you will see how to build your application for release.

The 4th Step, of Preparing Remote servers, comes in if your application depends on external servers and services. Here, you need to be sure they are secure and production ready. However, being very app specific, these are beyond the scope of this course.

And 5th Step, as a developer you should test your app in the release mode as well before you proceed.

Now, you’ll see the changes that google recommends to make to your source code, resource files, and application manifest prior to releasing your application.

Although most of the configuration changes listed here are optional, they are considered good coding practices and google encourages you to implement them. In some cases, you may have already made these configuration changes as part of your development process.

First, is choosing a good package name. Make sure, package name that you have set is suitable over the life of your application. Because, once you publish your app, you can not change it.

There is also confusion among developers for the difference between Package name specified in Manifest and applicationId in build.gradle. You will switch to Android Studio to understand better.

For demo purpose, I have used a sample project from Fastlane tutorial for Android at our site. You should work on your own app that you desire to publish. Open your project in Android studio and in the project window, select Android Scope.

You will see, Package name specified in AndroidManifest and

applicationId specified in App Module’s build.gradle. Ideally, you should keep both as same. Towards the end of the build process, the build tools override the package name using the applicationId property from the build.gradle file

Hence, applicationId must be universally unique in order to publish your app in Google Play and once you publish your app, you can not change it for that app. Just before you upload and publish your first version however, you are free to finalize and change it.

You will see how to do that now. applicationId , you have to update manually. Update the middle word “raywenderlich” to “bhavnathacker”. Click Sync now.

Now go to AndroidManifest. Select the word “raywenderlich”. Right click and select Refactor> Rename. Select Rename Package and rename the word to “bhavnathacker”. In Refactoring preview, verify and confirm the refactoring by clicking “Do Refactor”.

Switch to project Scope.

You will see that Package name throughout the app has been changed now.

Make sure you deactivate logging and disable the debugging option before you build your application for release.

Check <application> tag in your manifest file, and if you find, debuggable attribute , just remove it.

Verify app module’s build.gradle file. Check release buildType.

If you find, debuggable attribute, just remove it.

Switch to Android Studio now to see further on removing logging and optimisation.

Go to App module’s build.gradle.

When you make a new Android project in Android Studio, it sets minifyEnabled for the release build type to false. Setting minifyEnabled to true enables an optimizer. Android Studio comes with two main optimizers: ProGuard and R8.

ProGuard has been the de facto for Android for a long time, while R8 is a more recent addition. If you have built your project using Android Gradle plugin 3.4.0 or higher, it uses R8. Optimizer allows code shrinking and optimization for your project’s release build type

Setting minifyEnabled to true can have consequences like rutime crashes, especially in more complex apps as it requires you to write proguard rules to tell the complier which classes are to be ignored while obfuscating the code.

Also you should test your release build to make sure it works properly. You can refer the links in resources to learn more about this and decide whether to set it to true. So, finally if you decide to set it to true, go ahead.

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

Alternatively, you can let R8 remove the calls during the release build if you have set minifyEnabled to true. To do so, add following code to the proguard-rules.pro.

-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(...);
  public static int w(...);
  public static int e(...);
}

This code removes verbose, debug, information, warning and error log calls from release build. Awesome!

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

You should cleanup your project directories to ensure that it only contains files needed by your app to build.

Look into your project’s res/ directory for old drawable files, layout files, and values files that you are no longer using and delete them.

Review the contents of your assets/ directory and your res/raw/ directory for raw asset files and static files that you need to update or remove prior to release.

In Android Studio, run the Remove unused Resources command in the Refactor menu, that will take care of removing unused files.

Next is to Review and update your manifest and Gradle build settings

You should specify only those permissions that are relevant and required for your application using <uses-permission> element in Manifest. You must specify and verify values for android:icon & android:label attributes, which are located in the element in Manifest.

You must also verify the versionCode and versionName in your app module’s build.gradle.

versionCode 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. versionName 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.

Android provides several tools and techniques to make your application compatible with a wide range of devices. To make your application available to the large number of users, you should consider adding support for multiple screen configurations , Optimize your application for Android tablet devices etc.

Further discussion on this is beyond the scope of this course and you can refer to official Android documentation link provided in the Resources for details.

If you are releasing a paid application through Google Play, consider adding support for Google Play Licensing. It is optional however, Licensing lets you control access to your application based on whether the current user has purchased it.

To know more about licensing, refer to the link in the resources.

That’s it about Configuring Application for release. In the next episode. You will see how to create a new developer account.