Publish to the Google Play Store

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

You can unlock the rest of this video course, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now

You perform five main tasks to prepare your application for release. First, gather materials for release. To publish on Google Play, you need a hi-res icon, feature graphic and free screenshots, et cetera. You might also have to prepare promotional and marketing materials to publicize your application. You'll see this in detail in the later episode, when you create a store listing. Google also recommends that you prepare and provide one end-user license agreement with your application. It protects an app developers interest 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 later episode, you'll see how to build your application for release. The fourth 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 the scores. In the fifth step, as a developer you should test your application in release mode. 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 these 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 a 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 cannot change it. There is also confusion among developers, for the difference between package name specified in Manifest and application ID specified in build.gradle. You'll switch to Android Studio to understand better. For demo purpose, I've 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. Go to AndroidManifest.xml and you see the package specified. Now, go to app modules, build.gradle, and you'll see the application ID specified. Ideally, you should keep both as same. Towards the end of the build process, the build tools override the package name using the application ID property from build.gradle file. Hence, application ID must be universally unique in order to publish your app to Google play. And once you publish your app, you cannot change it for that app. Just before you upload and publish your first version, however, you are free to finalize and change it. You'll see how to do that now. First update the Application ID manually. Select the second word "raywenderlich" and update it to "bhavnathacker". Click Sync Now. Now, go to AndroidManifest, select the word "raywenderlich" right click, Refactor, Rename. Select Rename Package. Update it to bhavnathacker. Click Refactor. Now, switch to Project scope, and open app, main, java, and you see the package name throughout the app has been changed to com.bhavnathacker.android.rwmagic8ball. Make sure you deactivate logging, and disable 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 modules build.gradle file. Check release build type. If you find debuggable attribute, just remove it. Switch to Android Studio now, to see further on removing logging and optimization. Go to app modules, build.gradle. When you make a new android project in Android Studio, it sets minifyEnabled for 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 defacto for Android for a long time, while R8 is a more recent edition. If you built your project using Android gradle plugin 3.4.0 or higher, it uses R8. Optimizer allows code-shrinking and optimization for your projects release build type. Setting minifyEnabled to true can have consequences like runtime crashes, especially in more complex apps. As it requires you to write ProGuard rules, to tell the compiler 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 to the links in the 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. Click Sync Now. For your app security, you should remove debugging log messages from your apps 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 the following code to the ProGuard-rules.pro. This code removes Verbose, Debug, Information Warning and other lock calls from the release build. Awesome. If your app communicates with external services, has URLs, API keys, et cetera, or other configuration items that are different during development, change them to Production Settings. You should clean up your Project Directories to ensure that it only contains files needed by your app to build. Look into your project's res/directory for all drawable files, layout files, and value files that you are no longer using and delete them. Review contents of your assets directory and your res/raw directory for raw assets files and static files that you need to update or remove prior to release. In Android Studio, run Remove Unused Resources command, in 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 the manifest. You must specify and verify values for android:icon and android:label attributes, which are located in the application element in manifest. You must also verify versionCode and versionName in your app module's build.gradle. VersionCode is the internal version number which the user can't see. It is 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 major.minor.point release format, for the versionName. Android provides several tools and techniques to make your application compatible with wide range of devices. To make your application available to large number of users, you should consider adding support for multiple screen configurations, optimize your application for Android-tablet devices, et cetera. 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.