Finally, our app is ready! This is the best moment while developing a new app; it is time to upload it to Play Store, get feedback from users, and hopefully get thousands of downloads.
We need to export the app to an APK file; in order to be uploaded to Play Store, it has to be signed with a release certificate. This point is very important; once an application is signed with a certificate, if we upload it to Play Store and want to upload a new version in the future, it has to be signed with the same certificate.
This certificate will be created by us during the release process. It needs an alias and a password, so ensure that you remember these details and save the certificate file in a safe place. Otherwise, say your app gets good ratings and a good number of downloads, and you want to update the version, but you don't have your certificate or have forgotten the password. In this case, you won't be able to update, you will have to upload a new app with a different package name, and it will start with zero downloads and zero ratings.
Another important thing to take into consideration while releasing the app is code obfuscation. If we export the app without obfuscating the code, anyone can download the APK and decompile it, allowing them to see your code, which can be a security problem if you have Parse IDs, server access details, a GCM project number, and so on in it.
We can obfuscate the code using Proguard. Proguard is a tool included in the Android build system. It obfuscates, shrinks, and optimizes the code, removing unused code and renaming classes, fields, and methods to prevent reverse engineering.
Beware of this renaming of classes and methods; it can affect your crash and error reports as the stack trace will be obfuscated. However, this is not a problem as we can retrace them with a mapping file that we will save while releasing the app, which will allow us to convert the crash and report to readable and not obfuscated code.
To activate Proguard, we need to set the minifyEnabled property to true in buildTypes. You can execute the following code for this:
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}In our project, we have a proguard-rules.pro file, where we can add the rules to be considered while obfuscating. For instance, some third-party libraries cannot work properly if we obfuscate them, and there is no risk in leaving these libraries without obfuscation as they are not something that we created; we just added them to our project.
To prevent a third-party library from being obfuscated, we can add the rule -keep along with the rule and -dontwarn to ignore warnings. For instance, we added calligraphy to use custom fonts; this is how we can ignore it during the obfuscation:
# DONT OBFUSCATE EXTERNAL LIBRARIES
# CALLIGRAPHY
-dontwarn uk.co.chrisjenx.calligraphy.**
-keep class uk.co.chrisjenx.calligraphy.** {*;}
# TIMBER
-dontwarn timber.log.**
-keep class timber.log.** {*;}Using keep and the name of the package, we will keep all the classes inside this package.
We will add Proguard in the debug mode to create a crash intentionally and see how the stack trace looks obfuscated:
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.view.View.setVisibility(int)' on a null object reference
at com.packtpub.masteringandroidapp.SplashActivity.onCreate(Unknown Source)We can copy this stracktrace in a text file and go to app/build/outputs/mapping/product_flavor_name/ release_or_debug/mapping.txt to get our mapping.txt file.
Consider that we execute the retrace command in <sdk_root>/tools/proguard with the following code:
retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
In this case, we will have the crash in the correct line, as follows:
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.view.View.setVisibility(int)' on a null object reference at com.packtpub.masteringandroidapp.SplashActivity.onCreate(SplashActivity.java:21) at android.app.Activity.performCreate(Activity.java:6289)
Remember to save a copy of mapping.txt with every release of your app; this file is overwritten every time we release it, so it's very important to save the file at the moment of every release. Alternatively, if you have a repository and you tag the commits for every release, you can go back and generate the same release again, which will have the same mapping file in theory.
Now that we have our app protected against reverse engineering, we can continue with the release process.
When we export an application, what we do is create an APK file in the release mode and sign it with a certificate. This certificate is proof that an app in Play Store is ours, and with it, we can upload the same app as we explained before. We will export the app and create a certificate this time.
To export our application, we have two ways: one way is to use Gradle and the terminal inside Android Studio and the second way is to use the wizard in Android Studio. We will see both, but let's create the certificate using the second way first.
Navigate to Build | Generate Signed Apk; you will see a dialog similar to the following:
If we have exported this app before and created a certificate for it then, we just need to select a path and insert the alias and password, and this will export a new version of the app signed with the existing certificate.
For us, this is the first time that we are exporting MasteringAndroidApp, so we will click on Create new…. On the next screen, we need to select the path where will save the certificate, which is a .keystore file.
We also need a password for the keystore and a password for the alias inside the certificate. For a date with validity, 100 years will be okay; if your app lives more than you, it won't be your problem! Finally, some personal information in at least one field is required here:
Finally, it will ask us which flavor we want to export, and it will create the .apk, pointing to us the path of the file.
This way is straightforward, but there is an automated way to export the app using the command line and Gradle; it's very useful if we want to build the app with Jenkins, for instance.
To do this, we need to add a signing configuration in build.gradle so that when the app is generated automatically, it will know which keystore and which alias and passwords to use. The following code will help in doing this:
signingConfigs {
release {
storeFile file("certificate.keystore")
storePassword "android"
keyAlias "android"
keyPassword "android"
}
}There is no need to say that this can lead to a security problem; the password is written in build.gradle and the certificate file is included in our project. If we do this, we need to keep the project safe. If this is a concern, you can read the password and the alias at runtime with the following code:
storePassword new String(System.console().readPassword("
$ Enter keystore password: "))
keyAlias System.console().readLine("
$ Enter key alias: ")
keyPassword new String(System.console().readPassword("
$ Enter key password: "))When we run the command to generate the signed APK, it will ask us for the password alias and alias password. We can use the following line of code for this:
>./gradlew assembleRelease
With our app exported, we can proceed to the last step: uploading to Play Store.
To publish an app, we need a Google developer account. If you don't have one, you can obtain one from https://play.google.com/apps/publish/.
The first step to creating a publisher account is to enter the basic information and read and accept the developer distribution agreement. The second step is the payment of a development license fee of 25 dollars for the creation of the account. This is all we have to pay to publish an app, and it's paid just a single time—one single payment for a lifetime's license. We can't complain, considering in iOS, the fee is 99 dollars yearly.
The final and third step needs the developer's name, which will appear under the name of our application. Take a look at the following example in Google Inc:
We also need the e-mail, a mobile number, and our website, which is optional. According to Google, it is needed in case someone has to contact us in relation to the content published.
When we open the publisher account, if we have no apps published, we will see four of the main features of the developer console, as shown in the following image:
The first option is to publish an Android app, and it is the option we will follow in the book. However, before this, we will describe quickly the other options to keep in mind.
The second option is about the Google Play game services. If you develop a game where you want the players to save and submit their score and have a scores ranking, you will need a server to store these scores and retrieve them, maybe even have a username and a login for the player. The game services do this for us.
It provides an API that is shared across games, linked with the Google account of the user, where we can manage leaderboards and achievements. It even provides the API and infrastructure to implement multiplayer games, both real-time multiplayer and turn-based ones.
The third option, the one at the bottom to the left, is about sharing the developer console. We might want to allow other developers to update an app. This will help, for instance, in the case of a company, where there will be people in charge of setting the name, description, images of the app, and marketing in general and other people in charge of the app upload and the developers. We can configure the access to the console and to a specific application.
The fourth and final option is the merchant account; we need this if want to sell paid apps or in-app products. This is an example of the merchant account from a paid app; we can see payments completed and cancelled. If a user purchases our app, he/she has two hours to claim a refund in case he/she didn't like it.
We saw an empty developer console with the four main options because we didn't have an app published yet; if we had apps published, this is what we would see. The Publish button is at the top in this case:
On the initial screen, we can see the different apps, whether they are free or paid, the active installs, and the total installs. Active installs mean the people that have the app at the moment and that did not uninstall it after downloading. Total installs mean the count of all the times the app was installed.
We can also see the ratings and number of crashes. We can take a look at more details, such as comments from the users and error crash reports, if we click on the app and go into the detail view.
Continuing with the upload process, when we click on + Add new application, we are asked for a name and a default language. After this, we can choose how to start the process by uploading an APK or preparing the store listing.
These are two different processes: one is uploading the APK file, and the other is setting the title of the app, a description, an image, if it is paid or free, and so on—all the different options to be shown in Play Store.
Let's start with the uploading of the APK file and the different testing groups.
Remember that when we upload an APK, the package name of our application has to be unique in the Play Store; we can only upload an APK with an existing package name if we want to update an app previously published by us and if the certificate that we used to sign the initial download is the same certificate we used to sign the new APK.
The first things we notice when we click on upload the APK are the three different tabs with the names: Production, Beta, and Alpha.
We can release our app in two test groups and in production. Production means that it is published in Play Store; it is public and visible to everyone. For a while, this was the only option available in the developer console until they added the staged rollout.
The staged rollout allows us to release the app to a limited group of users. To select the users, we have different options; we can invite these users by e-mail, share a link, or create a Google group or G+ community, inviting the users to the group and sharing the link of the app with them. Only these users will then see the app in the Play Store. This is useful to get feedback from some users before our app is released to the world and, of course, to prevent bugs and bad reviews of the app in production. We can also select the percentage of users our app is to be published to in production; for instance, if we have a million users, we can release to 10 percent first and double-check that everything is ok before doing a massive release.
We can have different versions of our app in different stages; for instance, we can have version 1.0.0 published, 1.0.1 in beta testing, and 1.0.2 in alpha testing. We can roll out the APK from alpha to beta and from beta to production, but we can't roll back.
The concept that we will now explain is very important. Once we publish a version of our app, we can't go back to a previous published version. It could happen that we have a working version of our app in the Play Store, we develop a new version, it works fine in our device, and we think it is ready to be uploaded. It's Friday afternoon, and we don't bother testing because we think, "Oh, I'm sure it's fine. I just did a small change of two lines, that won't affect anything". We upload version 1.0.4. After a couple of hours, we start receiving crash reports from Play Store. It's the moment of panic; the only thing we can do now is undo the publishing of the current app to prevent more damage and start working on a fix as soon as possible. However, if the fix is not easy, the most sensible thing would be to generate the last known working version again (1.0.3), increase the version number and code to 1.0.5, and upload it to Play Store.
However, this could get worse; if we had a database and the structure changed from 1.0.3 to 1.0.4 and our code is not ready to accept a downgrade of the database from 1.0.4 to 1.0.3 renamed as 1.0.5, we will know that we will be working all weekend, only to be fired on Monday morning. To sum up our point, it is much better to prevent rather than heal; so, use the staged rollout, do all the testing necessary before releasing, and avoid releasing on Friday afternoon just in case.
Preparing the store listing for a developer can be the most boring part, but it needs to be done in order to publish an app; there are some mandatory assets and fields that we can't skip.
First, we need a title for our app, a short description of up to 80 characters and a long description of up to 4000. The title will be the first thing that we see while searching for our app; the short description can be seen, for instance, in tablets while browsing apps. This is the elevator pitch of our app, and we need to describe it here in the main function:
The long description will be shown when we go to the detail view of this app. In terms of appearing in more searches and earning visibility, it is good to identify and add keywords related to our app in the description. The use of unrelated keywords to attract downloads is banned from Google, and if you do this, you will receive a warning in the developer console, and your app will need some changes before being approved and published again.
At this point, we have the option to internationalize our app's listing, repeating these three fields mentioned in as many languages as we want, and they will be displayed in different languages automatically, depending on the user's language.
The next step is to develop the graphics, and we need to take screenshots here. Screenshots can easily be taken in your device with a key combination; for instance, in a Samsung Galaxy 3, this is done by pressing the volume down and menu keys at the same time. They can also be taken from Android Studio by selecting the camera icon in the Android view.
Apart from screenshots, we need a 512 x 512 hi-res icon; this must be the same as or very similar to the icon that we are using for our app in the uploaded version, otherwise it will throw a warning. For this reason, it's good to create the icon in 512 x 512 always and then scale it down to use in our app. The other way around will result in a scaled up image with bad quality. This is an example of where the icon is displayed:
The last image we need is the feature graphic. This is a 1024 x 500 graphic that shows the features of our app. This is the graphic that will be shown in our app featured on Google Play. It will be shown in the Play Store app; if we have a promo video, the feature graphic will still be shown while the video is not playing.
We need to continue with categorization; depending on whether our app is a game or an application, we need to choose different categories. If you are not sure about which category to choose, take a look in Play Store for apps similar to yours.
After this, we need to select the content rating; starting in May 2015, every app needs to have the new rating system. According to Google, this new content rating provides an easy way to communicate familiar and locally relevant content ratings to your users and helps improve app engagement by targeting the right audience for your content as seen in https://support.google.com/googleplay/android-developer/answer/188189.
Our contact details are automatically completed, so the last thing we need to do is accept the privacy policy, and then we can click on Pricing & Distribution.
This is where we make our app free or paid; this step can't be reverted. If the app is a paid one, we can set a price, and Google will convert it to different currencies in different countries; although, we can set different prices for each country. We can opt into different developer groups; for instance, if we develop an app for kids, we can include it in designed for families. This will increase our chances to be highlighted in kids' sections and distributed for third-party networks related with kids' apps.
In this section, we can select the countries were we want our app to be distributed as well. This can be used as well as a staged releasing strategy the first the time the app is published.
Completing all of the above, we will be able to publish our app by clicking on Publish in the upper right corner.
If the button is disabled, you can click on Why can't I publish?, and it will list the requirements on the left-hand side. Once the app is published, it can take a couple of hours to appear in the Play Store. The easiest way to find out whether the app is published yet is to navigate to our app using the package name in the URL. In our case, the URL would be, https://play.google.com/store/apps/details?id=com.packtpub.masteringandroidapp.
This is it! We have completed the book from the beginners' to a more advanced level with enough knowledge to upload an app well-designed and built that is backward-compatible and monetized.
We wish you success with your apps and we hope you make the next Angry Birds or the next WhatsApp!
Note
Thanks a lot for purchasing and finishing this book. For suggestions, improvements, or any feedback, don't hesitate to contact me at <[email protected]> or follow me on Twitter at @AntPachon.