Part 3 - Publishing an Application on Google Play
- PDF for offline use:
Let us know how you feel about this.
Although there are many app markets for distributing an application, Google Play is arguably the largest and most visited store in the world for Android apps. Google Play provides a single platform for distributing, advertising, selling, and analyzing the sales of an Android application.
This section will cover topics that are specific to Google Play, such as registering to become a publisher, gathering assets to help Google Play promote and advertise your application, guidelines for rating your application on Google Play, and using filters to restrict the deployment of an application to certain devices.
To distribute an application through Google Play, a developer account must be created. This only needs to be performed once, and does involve a one time fee of $25USD.
All applications need to be signed with a cryptographic key that expires after October 22, 2033.
The maximum size for an APK published on Google Play is 100MB. If an application exceeds that size, Google Play will allow extra assets to be delivered through APK Expansion Files. Android Expansion files permit the APK to have 2 additional files, each of them up to 2GB in size. Google Play will host and distribute these files at no cost. Expansion files will be discussed in another section.
Google Play is not globally available. Some locations may not be supported for the distribution of applications.
Becoming a Publisher
In order to publish applications on Google play, it is necessary to have a publisher account. To sign up for a publisher account follow these steps:
- Visit the Google Play Android Developer console at https://play.google.com/apps/publish .
- Enter basic information about your developer identity.
- Read and accept the Developer Distribution Agreement for your locale.
- Pay the $25 USD registration fee.
- Confirm verification by e-mail.
- After the account has been created, it is possible to publish applications using Google Play.
Google Play does not support all countries in the world. The most up to date lists of countries can be found in the following links:
Supported Locations for Free Publishers – This is a list of all countries where developers may register as publishers.
Supported Locations for Merchants – This is a list of all countries where developers may register as merchants and sell paid applications.
Supported Locations for Distributing Applications – This is a list of all countries where applications may be distributed.
Preparing Promotional Assets
In order to effectively promote and advertise an application on Google Play, Google allows developers to submit promotional assets such as screenshots, graphics, and video to be submitted. Google Play will then use those assets to advertise and promote the application.
A launcher icon is a graphic that represents an application. Each launcher icon should be a 32-bit PNG with an alpha channel for transparency. An application should have icons for all of the generalized screen densities as outlined in the table below:
36 x 36 px
48 x 48 px
72 x 72 px
96 x 96 px
Launcher icons are the first things that a user will see of applications on Google Play, so care should be taken to make the launcher icons visually appealing and meaningful.
Tips for Launcher Icons:
Simple and uncluttered – Launcher icons should be kept simple and uncluttered. This means excluding the name of the application from the icon. Simpler icons will be more memorable, and will be easier to distinguish at the smaller sizes.
Icons should not be thin – Overly thin icons will not stand out well on all backgrounds.
Use the alpha channel – Icons should make use of the alpha channel, and should not be full-framed images.
High Resolution Application Icons
Applications on Google Play require a high fidelity version of the application icon. It is only used by Google Play, and does not replace the application launcher icon. The specifications for the high-resolution icon are:
- 32-bit PNG with an alpha channel
- 512 x 512 pixels
- Maximum size of 1024KB
The Android Asset Studio is a helpful tool for creating suitable launcher icons and the high-resolution application icon.
Google play requires a minimum of two and a maximum of eight screen shots for an application. They will be displayed on an application’s details page in Google Play.
The specs for screen shots are:
- 24 bit PNG or JPG with no alpha channel
320w x 480h or 480w x 800h or 480w x 854h. Landscaped images will be cropped.
This is an optional image used by Google Play:
Used by the featured section of Google Play. This graphic may be displayed alone without an application icon.
- 1024w x 500h PNG or JPG with no alpha channel and no transparency.
- All of the important content should be within a frame of 924x500. Pixels outside of this frame may be cropped for stylistic purposes.
This graphic may be scaled down: use large text and keep graphics simple.
This is a URL to a YouTube video showcasing the application. The video should be 30 seconds to 2 minutes in length and showcase the best parts of your application.
Publishing to Google Play (Xamarin Studio 5.9 and Later)
Xamarin Studio 5.9 introduces a new, integrated workflow for publishing apps to Google Play. In Part 2, we created a new certificate for signing Android apps. Next, we'll follow these steps to publish our app on Google Play:
Log into your Google Play Developer account to create a new project that is linked to your Google Play Developer account.
Create an OAuth Client.
Enter the resulting Client ID and Client Secret into Xamarin Studio.
Register your account with Xamarin Studio.
Sign the application with your certificate.
Publish your signed application to Google Play.
In Archive for Publishing, the Sign and Distribute... dialog presented two choices for distribution. Select Google Play and click Next:
In the Google Play API Account dialog, you must provide the Client ID and Client Secret that provides API access to your Google Play Developer account:
First, login into your Google Play Developer account. If you do not already have a Google Play Developer account, see Getting Started with Publishing. Also, Google Play Developer API explains how to use the Google Play Developer API. Log into the API Access page on the Google Play Developer Console, accept the Terms of Service, then click Create new project:
The new API project is automatically generated and linked to your Google Play Developer Console. Next, click Create OAuth Client to associate an OAuth client with your app:
When a user requests access to their private data using your app, your OAuth Client ID is used to authenticate your app, at which time your branding information is presented to the user. The following example illustrates the kind of branding information that is required – fill in this form with information about you and your company:
Next, when the Client ID Settings dialog is displayed; click Create client:
A new Client ID is created and displayed. Click View in Google Developers Console to see more information:
The Google Developers Console provides a view of the OAuth information (Client ID and Client Secret) that is needed for completing the Sign and Distribute dialog:
Use this information to complete the Google Play API Account dialog in Xamarin Studio. You can give the account a description – this makes it possible to register more than one Google Play account and upload future APK's to different Google Play accounts. Copy the Client ID and Client Secret to this dialog, then click Register:
If the Client ID and Client Secret are accepted, a Registration Successful message is displayed. Click Next:
In the Google Play Account dialog, select a Google account and a track for uploading the application:
Google Play offers four possible tracks for uploading your app:
Alpha – Used for uploading a very early version of your app to a small list of testers.
Beta – Used for uploading an early version of your app to a larger list of testers.
Rollout – Allows you to select a percentage of users who will receive an updated version of your app; this makes it possible for you to slowly increase the percentage from say, 10% of users and increase it to 100% of users while you iron out bugs.
Production – Select this track when the app is ready for full distribution from the Google Play store.
For more information about Google Play testing and staged rollouts, see Use alpha/beta testing and staged rollouts.
Next, choose a signing identity to sign your app. If you have an existing signing identity, you can select Use Existing Key. If you do not have an existing key (also referred to as a certificate), see Creating a New Certificate for information about creating a new key. After you have selected a certificate to sign the application, click Next:
Finally, your app can be uploaded to Google Play. The Publish to Google Play dialog summarizes information about your app – click Publish to publish your app to Google Play:
Note that you must have at least one APK already uploaded before you can use Publish to Google Play; otherwise, you may get this error:
No application was found for the given package name. 
To resolve this error, manually upload an APK (such as an Ad-Hoc build) via the Google Play Developer Console, then use the Publish to Google Play dialog for subsequent APK updates. The next section explains the manual upload process.
Manually Uploading the APK
If you are uploading your APK to Google Play for the first time (or you are using Xamarin Studio 5.9 or earlier), you must manually upload your APK through the Google Play Developer Console. This section explains the steps required in this process.
Once the APK has been compiled and the promotional assets prepared, the application must be uploaded to Google Play. This is done by logging in to the Google Play Developer Console, pictured below:
Clicking on the Upload Application button will initialize the process of distributing an application by displaying a dialog to upload an APK:
Upload the release-ready APK that is to be distributed and any APK expansion files that may be required by the application. Once the APK is uploaded, it is saved as a draft. It cannot be published until more details are provided to Google Play. The product details page is broken up into several sections to capture this information; each described in more detail below.
All of the promotional assets that were prepared are uploaded in this section. This section contains mandatory fields. The page provides guidance as to what promotional assets must be provided and what format they should be provided in. A screen shot of the Upload Assets section appears below:
The section is used to enter the information that Google Play will display to potential users of the application. It is also where supported languages may be specified, and the application can be categorized.
This section is used to specify options that can affect what devices will be able to download the application. Options include:
Copy Protection – This is deprecated. If an application needs to enforce licensing policies, then the Google Licensing Services should be used instead. The Google Licensing Services will be discussed in more detail later on in this document.
Content Rating – Google Play requires that all applications specify a content rating. Guidelines for content rating will be discussed later on in this document.
Countries Distribution – This allows control over what countries an application may be distributed to.
Pricing – This option allows a price to be set for paid applications, or the application can be distributed free of charge to all users. Once an application is specified as free, it must remain free. Google Play will not allow an application that is free to change to a priced app. It is possible to sell content with in-app billing with a free app. Google Play will allow a paid app to change at any time to a free app.
The following screenshot shows a sample of the Publishing Options for an application:
This section is used to collect contact information about the developer of the application.
Enable Google Cloud Messaging Stats
This is an optional section. If the application makes use of Google Cloud Messaging or the now deprecated Cloud 2 Device Messaging, the ID’s or tokens would be entered here.
This is a mandatory section and is used to declare that the application meets the Android Content Guidelines and acknowledgement that the application is subject to U.S. export laws:
Guidelines for Content Rating
All applications on Google Play must be rated according to the Google Play ratings system. In addition to the content rating, all applications must adhere to Google's Developer Content Policy.
The following table shows the four levels in the Google Play rating system and provides some guidelines as features or content that would require or force the rating level:
May not access, publish, or share location data.
May not host any user-generated content.
May not enable communication between users.
Applications that access, but do not share, location data
Depictions of mild or cartoon violence
References to drugs, alcohol or tobacco.
Gambling themes or simulated gambling
Profanity or crude humor.
Suggestive or sexual references.
Intense fantasy violence
Allowing users to find each other
Allowing users to communicate with each other.
Sharing of a user's location data
A focus on the consumption or sale of alcohol, tobacco, or drugs
A focus on suggestive or sexual references
The items in Medium maturity list are subjective. As such it is possible a guideline that may seem to dictate a Medium maturity rating may be intense enough to warrant a High maturity rating.
Google Play Filters
When users browse the Google Play website for applications, they are able to search all published applications. When users browse Google Play from an Android device, the results are slightly different. The results will be filtered according to compatibility with the device that is being used. For example, if an application must send SMS messages, then Google Play will not show that application to any device which cannot send SMS messages.
The filters that are applied to a search are created from the following:
- The hardware configuration of the device.
- Declarations in the applications manifest file.
- The carrier that is used (if any).
- The location of the device.
The following table shows the manifest elements and attributes that can be used to filter applications:
Google Play will use the attributes to determine if an application can be deployed to a device based on the screen size. Google Play will assume that Android can adapt smaller layout to larger screens, but not vice-versa. So an application that declares support for normal screens will appear in searches for large screens, but not small screens.
If a Xamarin.Android application does not provide a <supports-screen> element in the manifest file, then Google Play will assume all attributes have a value of true and that the application supports all screen sizes.
This element must be added to AndroidManifest.xml manually.
This manifest element is used to request certain hardware features, such as the type of keyboard, navigation devices, a touch screen, etc.
This element must be added to AndroidManifest.xml manually.
This manifest element declares hardware or software features that a device must have in order for the application to function.
This attribute is informational only. Google Play will not display the application to devices that do not meet this filter. It's still possible to install the application by other means (manually or downloading).
This element must be added to AndroidManifest.xml manually.
This element specifies that certain shared libraries must be present on the device, for example Google Maps.
This element may also be specified with the Android.App.UsesLibaryAttribute. For example:
[assembly: UsesLibrary("com.google.android.maps", true)]
This element is used to infer certain hardware features that are required for the application to run that may not have been properly declared with a <uses-feature> element.
For example, if an application requests permission to use the camera, then Google Play assumes that devices must have a camera, even if there is no <uses-feature> element declaring the camera.
This element may be set with the Android.App.UsesPermissionsAttribute. For example:
The element is used to declare the minimum Android API Level required for the application.
This element may set in the Xamarin.Android options of a Xamarin.Android project.
This element is used to filter applications that do not match the screen size and density specified by this element.
Most applications should not use this filter. It is intended for specific high performance games or applications that required strict controls on application distribution. The <support-screen> attribute mentioned above is preferred.
This element is used to declare GL texture compression formations that the application requires.
Most applications should not use this filter. It is intended for specific high performance games or applications that required strict controls on application distribution.