Preparing and publishing to the Android marketplace
[Please note this tutorial was written just before Android Market turned into Google Play – the fundamentals are the same although we’ll be updating this tutorial shortly with references to Google Play]
The most exciting and often terrifying part of developing a mobile application is that one day we get to deploy it and get it into the hands of users. In the Android ecosystem just like the hardware we have a diversity in the application distribution networks. As developers we can choose to deploy our applications via Google’s Android Market as well as many others like Amazon AppStore AppBrain and SlideMe. The upside of all this diversity is that it offers developers a chance to market their application via a number of different channels unlike iOS which is restricted to Apple’s distribution network. Furthermore the next few years will see Android make its way into cars and home automation systems — most likely with their own custom application market stores.
In this master class we look at the specific steps to publish an application to the most prominent application distribution platform — the Android market run by Google. However the other application stores follow a similar publishing pattern and hence this knowledge is transferable. We will publish a small application called “Up Time” and walk through the steps required. All resources used in the master class series are available on GitHub.
A Short Recap
Before getting into the details of publishing an application here is a recap of the core Android concepts covered in the previous masterclasses (available online at). An Android application is made up of Activities that map to an individual window / screen of functionality in an application. We place UI components (called Views) inside a container called a layout and attach this layout container to an activity. The UI is described in an XML file and paired with a Java class that provides the interactivity. The Android framework mandates conventions which specify a set of folders that every Android project must have. The conventions specify location of resource such as images and data for the development tools to process them and generate references to use these resources from within the XML UI description files and Java code. The framework is designed to help developers construct UI that works on devices with varying screen sizes with minimal pain.
Every activity in an Android application has its own life cycle and activities communicate between each other using short messages known as intents. The Android architecture allows any application to send a message to another other application via intents. This flexibility permits developers to make use of functionality provided by other applications with minimal pain. For instance we can broadcast a message requesting display of a web page and all registered browsers will respond – the user then has the choice of selecting the application that they want to use (we will make specific use of this feature in this master class).
As elaborated in previous master class articles Android applications can make use of Maps via the use of Google APIs that are available as a free add-on from within the Eclipse IDE. We can also build applications that incorporate image galleries video and audio by using the media APIs provided as part of the SDK. The platform also provides us with a rich data persistence layer including a light weight database management system that allows us to use SQL.
The UptimeDroid Application
We will use the Up Time application as our sample in order to explain the publishing process. The key functionality of this application fits within the theme of MeDroid. This application is inspired by the Up Time command of Unix systems. However rather than show how long a computer has been running since last reboot we will show the up time (in days) for a person based on their date of birth (see Figure 1).
Figure 1 – The Uptime Droid Application Main Screen
The look and feel of this application is based on the MeDroid colour scheme however since we are publishing this to the master we made a number of specific changes within the code base preparing it for a long life in the market. In particular we make use of Styles and Themes which can improve developer productivity and introduce consistency.
Styles and Themes
In previous master classes you may have noticed that the layout XML files tend to be very verbose and repetitive — with a number of elements repeating for each and every view in the layout. The good news is that Android offers us a nice and elegant mechanism to reduce this repetition and verbosity by using styles and themes. This mechanism also allows us to reuse similar styles across multiple layout files (or even applications) easily. In addition to reducing the repetition in the layout files styles and themes greatly help with ongoing maintenance and updates. That is they should be used in applications that are going to be active in the market for a period of time.
So what exactly is a style? A style is a set of properties that specify the look and format of a UI view (or window). Typically we use styles to specify the font size padding colours and layout height / width. Of course the platform allows us a great deal of flexibility on what goes into a style file. We specify styles in an XML file — res/values/styles.xml.
Lets start with a simple example that illustrates it better. In this example we define the style for the header of an activity. The first line of a style definition is the name which needs to be unique across our application.
<style name="ActivityHeadingLabel"> <item name="android:layout_width">fill_parent</item> <item name="android:layout_height">wrap_content</item> <item name="android:layout_gravity">center_vertical</item> <item name="android:background">@color/medroid_white</item> <item name="android:paddingBottom">2dp</item> <item name="android:paddingLeft">10dp</item> <item name="android:textColor">@color/medroid_blue</item> <item name="android:textSize">21sp</item> <item name="android:textStyle">bold</item> </style>
The style definition above makes use of colours defined in a separate resource file colors.xml (note file name follows American spelling) as well. Once a style is defined we can use it within our layout XML file as shown below (see 3rd line):
<TextView android:id="@+id/actLabel" style="@style/ActivityHeadingLabel" android:text="Current Jobs" />
Styles are powerful and certainly help reduce the verbosity of layout XML code. However one design restriction of a style is that they are attached to a single UI view. As in a style can help us specify the properties of a single TextView or a single ImageView. Although this seems fine a style cannot be passed down to any children within a container. That is if we specify a style for a layout (ViewGroup) then it is not passed down to all of the children.
If we want to specify a set of properties that will apply down the UI hierarchy or the entire application — we need to use themes. A theme is a style and can be stored either in the styles.xml file or the themes.xml file (sadly a tad confusing). However the difference is in how we attach a theme to a container. It is easier to show with some example code see below.
The theme is defined as shown in the example code snippet below:
<style name="MeDroidTheme" parent="android:Theme.Light"> <item name="android:windowBackground">@drawable/background</item> </style>
The code snippet defines a background bitmap (stored in the res/drawable- folders). The rest of the attributes for this style are inherited from a built-in Android light-theme. The built-in Android theme is accessible for all applications and if you are curious how the built-in Android light-theme is specified then you can see the actual source code. This is one of the greatest advantages of open-source platforms like Android — we get to see directly how to build a complex theme. Similarly the default styles that specify how various UI views are rendered in the Android platform are available here.
Once the theme is defined we attach it to the entire application in the manifest file. As discussed in earlier master classes the manifest file defines the global configuration and permissions of the application. The code snippet below shows how to set a theme for the entire application. In our case this theme defines a background bitmap for all activities in the application. We can also attach a theme per activity (which are also specified in the manifest file).
<application android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:debuggable="false" android:theme="@style/MeDroidTheme"> ...
Styles and themes allow us to reuse repeating elements in Android applications. Although this feature is powerful and can ensure consistency across the application these custom styles are not available automatically for the standard views when we construct the UI using the graphical layout editor. That is when we drag and drop a view in the layout editor they will use the default styling. Thankfully this limitation can be overcome by creating custom components and making them available within the Eclipse graphical layout editor. The method for creating custom components is elaborated in the developer documentation available online and worth considering for large and complex projects.
Publishing an Application – An Overview
Once the application UI has been cleaned-up (via the use of styles and themes) and we are happy with the overall quality of the application we are ready to publish the application to the market. In Android this process is relatively straight forward and involves a few simple steps:
- Prepare an application for release
- Take Screen Shots of Application
- Create a Signed Application Package
- Create a developer account on Android market
- Upload the signed application and write up a description
- Activate the application and Publish to Android Market
- Download the test the application from the market
These steps are elaborated further in the sections that follow.
Prepare an Application for Release
Once we are happy with the functional aspects of the code base we need to prepare the application by configuring certain aspects in order to prepare it for release. The default configuration that we have been working on so far was to create debug builds. Specifically these builds are great during development as we can test and play with the application on our own devices with minimal fuss. Additionally if a debug build crashes during construction we get a fairly detailed program trace allowing us to investigate the likely cause and take corrective actions. However the applications that we publish to the market should not contain the debug flag as the additional detail is often irrelevant for the user.
In order to disable the debug flag in the application we need to set the debuggable attribute in the manifest file (to false) as shown in the third line of the code snippet below. A note of warning — this flag should only be set before publishing an application and not during development. Once the debug flag is disabled the IDE does not get detailed information about the cause of any crashes making it harder to correct faults. In case you are wondering why we bother with this additional switching — the advantage of disabling the debugging information is that the application code tends to run more efficiently.
<application android:icon="@drawable/ic_launcher" android:label="@string/app_name" android:debuggable="false" android:theme="@style/MeDroidTheme">
Screen Shots of your Application
A standard requirement of the Android market is screen grabs of your application. There are a number of different methods to obtain these screen shots but an elegant option is available from within the Eclipse IDE. In order to use Eclipse to take a screen shot of your application you have to enable the Android Devices view.
To show Devices View in the Eclipse menu: Window > Show View > Other. Then expand Android sub-tree and select Devices. This will enable the Devices View which should dock it to the bottom part of the IDE window (see Figure 2). In the Devices View there is a camera icon in the top-right hand which will screen capture from a connected device (the icon is highlighted in Figure 2). This view shows all virtual and real devices connected to your computer. This view also shows you all of the various devices that are currently available from inside Windows.
Figure 2 – Devices View in Eclipse IDE
Just like the Devices View there are a few other useful views that are worth exploring (again to see these views Window > Show View > Other > Expand Android sub-tree). The two views that are used by developers often are the Emulator Control View and the Log message View. The emulator view allows you to control the emulator and make phone calls to it for example as as well as send the emulator as SMS. The log message view (called LogCat) shows the log messages that are produced by the Android systems as well as applications running on the device. The log view is worth having a closer look at to get a better understanding of what is going on inside the phone.
Create a Signed Application Package
Once the code is cleaned-up and the application manifest file is updated to create a release build we need to create a signed application package. In Android these packages are APK files that users install and run. An APK file is a compressed archive (like a ZIP file) that contains the application the manifest file as well as all associated resources and other required content. In fact you can open the APK file and see its contents by using a program like WinZip.
The security model of the Android platform requires all application packages be signed before they can be installed and run on a device. So far in previous master classes the Eclipse IDE has created debug builds for us and these were signed by a special debug key that comes as part of the platform. However in order to publish to the market we need to sign our applications with our own private key. The good news is that (unlike iOS) we can create a private key by ourselves and sign our applications with it. The downside is that there is no authority that checks our identity. So how do we generate a private key? We use Eclipse IDE and run the export wizard which will create a private key sign the application with it and create an APK file for us.
In Eclipse start the application export wizard by Selecting File -> Export. Select the Export Android Application option (see Figure 3). After this select the Eclipse project that contains the application that you want to export (see Figure 4)
Figure 3 – Export an Android Application Wizard
Figure 4 – Select Project to Export
Once the project is selected we need to create a secure private key following a two step process. First we need to create a key store — an encrypted file that holds the actual key. In the second step we create the actual key and provide some identify information. The key store can hold multiple keys and this option may be needed if we are distributing the application via multiple channels. The Eclipse wizard automates the above process via a graphical wizard (see Figure 5 and Figure 6). Once the key is constructed the wizard will create a signed application package (APK file) and place it in a location of our choice. It is this file that we need to upload to the Android market. It is a good practice to store these release APK files in a folder within the Eclipse project and ensure that you have an appropriate backup.
Figure 5 – Create a secure key store
Figure 6 – Create a key and identify information
Note: The identity information that we provide into the private key holds our digital identity and hence it is worth safeguarding the key store file. That is if we misplace or lose our key then newer applications that we release will be treated as it they are from a different provider. More importantly the key ensures that we can upgrade our applications on the Android market. In short — be paranoid about your keys. This point is really worth repeating so here we go again — being paranoid about the key store and the keys is a good thing.
Create a developer account on Android market
Publishing an application to the Android market requires us to pay a fee ($25) and register as an Android application developer. The process is relatively quick and requires you to have a Google account agree to the legal terms and pay the fee via Google checkout.
In order to signup as a developer go to https://market.android.com/publish/signup (note it is the more secure https protocol). The signup page requests your phone number email address and expects you to provide a developer/company name under which all of the applications will be published (see see Figure 7). Developer accounts are registered and activated almost immediately and you will receive an email with a confirmation.
Figure 7 – Android Developer Signup Page
Upload the Signed Application Activate and Publish
In order to upload and publish an application navigate to https://market.android.com/publish/Home. Select the Upload application button and you will be presented with a form where you need to provide details about the application as well as the APK file. The publishing process (see Figure 8) requires at least two screen shots of the mobile application as well as a hi-resolution icon image that can be shown in the Android market. The form structure changes from time to time and by the time you read this article the form may be slightly different to the one shown in this article so it is worth reading the expectations carefully when you attempt the upload task.
Figure 8 – Providing Application Details
Once you have provided a description of the application and two screen shots you are ready to upload the APK file that you exported earlier from within Eclipse. Just select the APK files tab and upload your file. Once uploaded you have to explicitly activate the APK file and save. This will trigger the publishing process onto the official Android Market.
The application will appear in the Android market within a short period of time. A reasonably expectation is around 15 minutes. However sometimes this process is nearly instantaneous sometimes it takes nearly an hour.
Download the test the application from the market
This is the final step in publishing. Search for your application on Android market and check that the public facing information meets your expectations. After this download the APK file to a mobile device and ensure it works (just in case). This final verification step is mainly to avoid any nasty surprises that will cause a flurry of negative comments and poor ratings.
Updating a released application
Once an application is released a common expectation is to provide users with updates that correct defects as well as offer new functionality. There are two specific steps that we need to do this. First we need to update the Manifest file with the new version code — this is a numeric increment (that is 1234 etc.). We also need to change the version name shown to the end user (e.g. 1.1.2). The code snippet below shows an updated version information in the Manifest file for the Uptime application.
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.rvasa" android:versionCode="2" android:versionName="1.1"> <uses-sdk android:minSdkVersion="8"/>
Once the manifest file contains the new version code we need to export a new APK file from Eclipse IDE using the same private key as used for the initial version. Following this we need to upload the new APK file to the market and provide additional information describing new changes in the update. The final step is to activate the new APK file (see Figure 9) and deactivate the previous release. We mentioned this earlier but the point is worth stressing again — applications cannot be updated if the certificate changes from one version to the next. That is we have to sign the APK with the same identity.
Figure 9 – Updating the APK file
MeDroid Sample Application
Over the last few master classes we explored different areas of the Android platform with an intention of bringing them together. To get your started on this journey a Medroid project with all of the scaffolding required has been provided as part of the online resources (Medroid on Github). The project provided for you makes use the MeDroid styles themes and provides the navigation framework — all you have to do is add your imagination and bring it to life.
The best way to get the resources from Github is via use of a git client. However if you are not familiar with git you can get the project files via the use of a browser. Navigate to the project page at http://github.com/rvasa/medroid. Click on resources and then select the master class folder and click on the ZIP file. This will display details about that file (in terms of the commit) and show a link with the title “View Raw”. Right-click on this link and save file to get the ZIP file.
In this master class we covered how to prepare and publish an application to the Android market. In the next master class we will cover how to prepare a mobile ready web page and cover a hot question that many face as they move towards mobile applications — should your application be built using mobile optimised HTML5 technologies or should it be an application that takes advantage of the platform or should it be a hybrid?.
Home: Main masterclass index