Introduction to Android Application Development, Fourth Edition (2014)
Part V. Publishing and Distributing Android Applications
Chapter 19. Publishing Your Android Application
After you’ve developed and tested your application, the next logical step is to publish it so that other people can enjoy it. You might even want to make some money. A variety of distribution opportunities are available to Android application developers. Many developers choose to sell their applications through mobile marketplaces such as Google Play. Others develop their own distribution mechanisms—for example, they might sell their applications from a website. You may even want to have fine-grained control over who can install your application using new features with the Google Play Developer Console. Regardless, developers should consider which distribution options they plan to use during the application design and development process, because some distribution choices might require code changes or impose restrictions on content.
Choosing the Right Distribution Model
The application distribution methods you choose to employ depend on your goals and target users. Here are some questions you should ask yourself:
Is your application ready for prime time, or are you considering a beta period to iron out the kinks?
Are you trying to reach the broadest audience, or have you developed a vertical market application? Determine who your users are, which devices they are using, and their preferred methods for seeking out and downloading applications.
How will you price your application? Is it freeware or shareware? Are the payment models (single payment versus subscription model versus ad-driven revenue) you require available on the distribution mechanisms you want to leverage?
Where do you plan to distribute? Verify that any application markets you plan to use are capable of distributing within those countries or regions.
Are you willing to share a portion of your profits? Distribution mechanisms such as Google Play take a percentage of each sale in exchange for hosting your application and distributing and collecting application revenue on your behalf.
Do you require complete control over the distribution process, or are you willing to work within the boundaries and requirements imposed by third-party marketplaces? This might require compliance with further license agreements and terms.
If you plan to distribute yourself, how will you do so? You might need to develop more services to manage users, deploy applications, and collect payments. If so, how will you protect user data? What trade laws must you comply with?
Have you considered creating a free trial version of your application? If the distribution system under consideration has a return policy, consider the ramifications. You need to ensure that your application has safeguards to minimize the number of users who buy your app, use it, and return it for a full refund. For example, a game might include safeguards such as a free trial version and a full-scale version with more game levels than could possibly be completed within the refundable time period.
Protecting Your Intellectual Property
You’ve spent time, money, and effort to build a valuable Android application. Now you want to distribute it but perhaps you are concerned about reverse engineering of trade secrets and software piracy. As technology rapidly advances, it’s impossible to perfectly protect against either.
If you’re accustomed to developing Java applications, you might be familiar with code obfuscation tools. These are designed to strip easy-to-read information from compiled Java byte codes, making the decompiled application more difficult to understand and reverse engineer. Some tools, such as ProGuard (http://proguard.sourceforge.net), support Android applications because they can run after the .jar file is created and before it’s converted to the final package file used with Android. ProGuard support is built into Android projects created with the Android tools.
Google Play also supports a licensing service called the License Verification Library (LVL). This is available as a Google Play add-on but works on Android API Level 3 and higher. It applies only to paid applications distributed through Google Play. It requires application support—code additions—to be fully utilized, and you should seriously consider obfuscating your code if you use it. The service’s primary purpose is to verify that a paid application installed on a device was properly purchased by the user. You can find out more at the Android Developer website:http://d.android.com/google/play/licensing/index.html.
You may also be concerned about rogue applications impersonating your brand or performing trademark and/or copyright infringement. Google has many mechanisms set up for reporting infringements, so if this does occur, you should report those infringements to protect your brand. In addition to using the mechanisms Google provides for reporting infringements, you may also need to consult with legal counsel.
Following the Policies of Google Play
When you publish your application to Google Play, you must agree to certain policies that Google enforces. One of those policies is the Developer Distribution Agreement, which can be found here: http://play.google.com/about/developer-distribution-agreement.html. By accepting the agreement, you are agreeing to not perform certain prohibited actions that are outlined within the agreement.
Another term of service that you agree to is the Developer Program Policies as defined here: http://play.google.com/about/developer-content-policy.html. This includes rules that prohibit spam, restrict content, and govern ad implementations, and it even outlines subscription and cancellation policies. Staying up-to-date on the current policies of Google Play is very important to avoid any negative repercussions for failure to comply with them.
Billing the User
Unlike some other mobile platforms you might have used, the Android SDK does not currently provide built-in billing APIs that work directly from within applications. Instead, billing APIs are normally add-on APIs that are provided by the distribution channels.
For selling your applications on Google Play, you must register for a Google Wallet Merchant account. Once registered, you need to connect your Google Wallet Merchant account to your Developer Console account. Google Wallet is the billing provider for processing application payments from within Google Play.
Google Play allows you to sell your application in 130 different countries, enabling you to accept the currencies that your users are used to spending. Users will be able to make purchases from their Android devices or from the Web, and Google Play provides an easy way to track and manage the entire process. Google Play accepts many different forms of payment, including direct carrier billing, credit card, gift card, or a stored Google Play balance. Any revenue that you generate is paid out to you in monthly installments to your Google Wallet Merchant account.
If an application needs to charge ad hoc fees for goods sold within the application (that is, subscriptions or in-app products), the application developer must implement an in-app billing mechanism. Google Play provides an In-app Billing API for billing support within any application published to Google Play (http://d.android.com/google/play/billing/index.html).
Rolling your own in-app billing system? Most Android devices can leverage the Internet, so using online billing services and APIs—PayPal, Amazon, or others, for example—is a common choice. Check with your preferred billing service to make sure it specifically allows mobile use and that the billing methods your application requires are available, feasible, and legal for your target users. Similarly, make sure any distribution channels you plan to use allow these billing mechanisms (as opposed to their own).
Leveraging Ad Revenue
Another method to make money from users is to have an ad-supported mobile business model. Android itself has no specific rules against using advertisements within applications. However, different markets may impose their own rules for what’s allowed. For instance, Google’s AdMob Ads service allows developers to place ads within their applications. (Read more at https://developers.google.com/mobile-ads-sdk/docs/.) Several other companies provide similar services.
Collecting Statistics Regarding Your Application
Before you publish, you may want to consider adding some statistics collection to your application to determine how your users use it. You can write your own statistics-collection mechanisms, or you can use third-party add-ons such as the Google Analytics App Tracking SDK for Android. Ensure that you always inform your users if you are collecting information about them, and incorporate your plans into your clearly defined EULA and privacy policy. Statistics can help you not just see how many people are using your application, but also how they are actually using it.
Now let’s look at the steps you need to take to package and publish your application.
Packaging Your Application for Publication
Developers must take several steps when preparing an Android application for publication and distribution. Your application must also meet several important requirements imposed by the marketplaces. The following steps are required for publishing an application:
1. Prepare and perform a release candidate build of the application.
2. Verify that all requirements for the marketplace are met, such as configuring the Android manifest file properly. For example, make sure the application name and version information are correct and the debuggable attribute is set to false.
3. Package and digitally sign the application.
4. Test the packaged application release thoroughly.
5. Update and include all the required resources for the release.
6. Make sure that your servers or services used by your application are stable and production ready.
7. Publish the application.
The preceding steps are required but not sufficient to guarantee a successful deployment. Developers should also take these steps:
1. Thoroughly test the application on all target handsets.
2. Turn off debugging, including Log statements and any other logging.
3. Verify permissions, making sure to add ones for services used and to remove any that aren’t used, regardless of whether they are enforced by the handsets.
4. Test the final, signed version with all debugging and logging turned off.
Now, let’s explore each of these steps in more detail, in the order they might be performed.
Preparing Your Code for Packaging
An application that has undergone a thorough testing cycle might need changes made to it before it is ready for a production release. These changes convert it from a debuggable, preproduction application into a release-ready application.
Setting the Application Name and Icon
An Android application has default settings for the icon and label. The icon appears in the application launcher and can appear in various other locations, including marketplaces. As such, an application is required to have an icon. You should supply alternative icon drawable resources for various screen resolutions. The label, or application name, is also displayed in similar locations and defaults to the package name. You should choose a short, user-friendly name that displays under the application icon in launcher screens.
Versioning the Application
Next, proper versioning is required, especially if updates could occur in the future. The version name is up to the developer. The version code, though, is used internally by the Android system to determine if an application is an update. You should increment the version code for each new update of an application. The exact value doesn’t matter, but it must be greater than the previous version code. Versioning within the Android manifest file is discussed in Chapter 5, “Defining Your Application Using the Android Manifest File.”
Verifying the Target Platforms
Make sure your application sets the <uses-sdk> tag in the Android manifest file correctly. This tag is used to specify the minimum and target platform versions that the application can run on. This is perhaps the most important setting after the application name and version information.
Configuring the Android Manifest for Filtering
If you plan to publish through the Google Play store, you should read up on how this distribution system uses certain tags within the Android manifest file to filter applications available to users. Many of these tags, such as <supports-screens>, <uses-configuration>, <uses-feature>, <uses-library>, <uses-permission>, and <uses-sdk>, were discussed in Chapter 5. Set each of these items carefully, because you don’t want to accidentally put too many restrictions on your application. Make sure you test your application thoroughly after configuring these Android manifest file settings. For more information on how Google Play filters work, see http://d.android.com/google/play/filters.html.
Preparing Your Application Package for Google Play
Google Play has strict requirements for application packages. When you upload your application to the Android Developer Console, the package is verified and any problems are communicated to you. Most often, problems occur when you have not properly configured your Android manifest file.
Google Play uses the android:versionName attribute of the <manifest> tag within the Android manifest file to display version information to users. It also uses the android:versionCode attribute internally to handle application upgrades. The android:icon and android:label attributes must also be present because both are used by Google Play to display the application name to the user with a visual icon.
Warning
The Android SDK allows the android:versionName attribute to reference a string resource. Google Play, however, does not. An error is generated if a string resource is used.
Disabling Debugging and Logging
Next, you should turn off debugging and logging. Disabling debugging involves removing the android:debuggable attribute from the <application> tag of the AndroidManifest.xml file or setting it to false. You can turn off the logging code within Java in a variety of different ways, from just commenting it out to using a build system that can do this automatically.
Tip
A common method for conditionally compiling debug code is to use a class interface with a single, public static final boolean that’s set to true or false. When this is used with an if statement and set to false, because it’s immutable, the compiler should not include the unreachable code, and it certainly won’t be executed. We recommend using some method other than just commenting out the Log lines and other debug code.
Tip
If you don’t specify the android:debuggable attribute, incremental builds will automatically turn it on and export/release builds will leave it off. Specifying the value as true will also cause export/release builds to actually do a debug build.
Verifying Application Permissions
Finally, the permissions used by the application should be reviewed. Include all permissions that the application requires, and remove any that are not used. Users appreciate this.
Packing and Signing Your Application
Now that the application is ready for publication, the file package—the .apk file—needs to be prepared for release. The package manager of an Android device will not install a package that has not been digitally signed. Throughout the development process, the Android tools have accomplished this through signing with a debug key. The debug key cannot be used for publishing an application to the wider world. Instead, you need to use a true key to digitally sign the application. You can use the private key to digitally sign the release package files of your Android application, as well as any upgrades. This ensures that the application (as a complete entity) is coming from you, the developer, and not some other source (imposters!).
Warning
A private key identifies the developer and is critical to building trust relationships between developers and users. It is very important to secure private key information.
Google Play requires that your application’s digital signature validity period end after October 22, 2033. This date might seem like a long way off and, for mobile, it certainly is. However, because an application must use the same key for upgrading and because applications that are designed to work closely together with special privileges and trust relationships must also be signed with the same key, the key could be chained forward through many applications. Thus, Google is mandating that the key be valid for the foreseeable future so application updates and upgrades are performed smoothly for users.
Note
Finding a third-party certificate authority that will issue a key is optional, but self-signing is the most straightforward solution. Within Google Play, there is no benefit to using a third-party certificate authority.
Although self-signing is typical of Android applications, and a certificate authority is not required, creating a suitable key and securing it properly are critical. The digital signature for Android applications can impact certain functionality. The expiry of the signature is verified at installation time, but after it’s installed, an application continues to function even if the signature has expired.
You can export and sign your Android package file from within the Android IDE as follows (or you can use the command-line tools):
1. In the Android IDE, right-click the appropriate application project and choose the Android Tools, Export Signed Application Package... option. (Alternatively, after right-clicking the appropriate package, you can choose Export, expand the Android section, and choose Export Android Application, which defaults to a signed application.)
2. Click the Next button.
3. Select the project to export (the one you right-clicked before is the default, or you can select Browse... to choose another project) and click Next.
4. On the Keystore selection screen, choose the Create new keystore option and enter a file location (where you want to store the key) as well as a password for managing the keystore. (If you already have a keystore, choose Browse to pick your keystore file and then enter the correct password.)
Warning
Make sure you choose a strong password for the keystore. Remember where the keystore is located, too. The same one is required to publish an upgrade to your application. If it’s checked into a revision-control system, the password helps protect it. However, you should consider adding an extra layer of privilege required to get to it.
5. Click the Next button.
6. On the Key Creation screen, enter the details of the key, as shown in Figure 19.1.
Figure 19.1 Creating a new key for exporting a signed Android application in the Android IDE.
7. Click the Next button.
8. On the Destination and key/certificate checks screen, enter a destination for the application package file.
9. Click the Finish button.
You have now created a fully signed and certified application package file. The application package is ready for publication. For more information about signing, see the Android Developer website: http://d.android.com/tools/publishing/app-signing.html.
Note
If you are not using the Android IDE, you can use the keytool and jarsigner command-line tools available within the JDK, in addition to the zipalign utility provided with the Android SDK, to create a suitable key and sign an application package file (.apk). Althoughzipalign is not directly related to signing, it optimizes the application package for more efficient use on Android. The Android IDE runs zipalign automatically after the signing step.
Testing the Release Version of Your Application Package
Now that you have configured your application for production, you should perform a full final testing cycle, paying special attention to subtle changes to the installation process. An important part of this process is to verify that you have disabled all debugging features so that logging has no negative impact on the functionality and performance of the application.
Including All Required Resources
Before releasing your application, you need to make sure that all the required resources are available for access from your application. Testing that these resources are working properly and accessible is extremely important. Also, be sure that the most recent versions of these resources are included.
Readying Your Servers or Services
Make sure that your servers or any third-party services that your application accesses are stable and work well in a production setting. The last thing you want is to have a strong application with a weak back end. If your application is accessible via the Web, and not just a standalone application, ensuring proper and stable access to your servers and services should be a priority.
Distributing Your Application
Now that you’ve prepared your application for publication, it’s time to get it out to users—for fun and profit. Before you publish, you may want to consider setting up an application website, tech support email address, help and feedback forum, Twitter/Facebook/Google+/social network du jour account, and any other infrastructure you may want or need to support your published application.
Publishing to Google Play
Google Play is the most popular mechanism for distributing Android applications at the time of this writing. This is where a typical user purchases and downloads applications. As of this writing, it’s available to most, but not all, Android devices. As such, we show you how to check your package for preparedness, sign up for an Android Developer Console account, and submit your application for download to Google Play.
Note
Google Play is updated frequently. We have made every attempt to provide the latest steps for uploading and managing applications. However, these steps and the user interfaces described in this section may change at any time. Please review the Google Play Developer Console website (https://play.google.com/apps/publish) for the latest information.
Signing Up for Publishing to Google Play
To publish applications through Google Play, you must register for a publisher account and set up a Google Wallet Merchant account.
Note
As of this writing, only developers (“merchants”) residing in certain approved countries may sell priced applications on Google Play due to international laws, as described here: https://support.google.com/googleplay/android-developer/answer/150324?hl=en. Developers from many other countries can register for publisher accounts, but they may publish only free applications at this time. For a complete list of supported publisher countries, see https://support.google.com/googleplay/android-developer/answer/136758?hl=en.
To sign up for a Google Play publisher account, you need to follow these steps:
1. Go to the Google Play Developer Console sign-up website at https://play.google.com/apps/publish, as shown in Figure 19.2.
Figure 19.2 The Google Play publisher sign-in page.
2. Sign in with the Google account you want to use. If you do not yet have a Google account, click the Sign Up button and create one first.
3. You must first agree to the Google Play Developer Distribution Agreement by ticking the check box, as shown in Figure 19.3, then press Continue to payment. As of this writing, a $25 (USD) one-time registration fee is required to publish applications.
Figure 19.3 Accepting the Google Play Developer Distribution Agreement.
4. Note that Google Wallet is used for registration payment processing, so you must also set up a Google Wallet account, if you don’t already have one, as shown in Figure 19.4.
Figure 19.4 Setting up a Google Wallet account.
5. Once the Google Wallet account has been set up, you must then accept the $25 registration fee (shown in Figure 19.5).
Figure 19.5 Accepting the $25 registration fee.
6. You then proceed to Complete your Account details (see Figure 19.6). Enter the required information and click Complete registration.
Figure 19.6 Complete your account details page.
Tip
Always print out the actual agreement you sign as part of the registration process, in case it changes in the future.
When you successfully complete these steps, you are presented with the home screen of the Google Play Developer Console, as seen in Figure 19.7. Signing up and paying to be an Android Developer does not create a Google Wallet Merchant account. A merchant account is used for payment processing purposes. From the Developer Console, you should be able to set up a merchant account by following the link in the lower-right section of the screen. If you are creating a paid app, feel free to set this up at any time.
Figure 19.7 The Developer Console start page.
Uploading Your Application to Google Play
Now that you have an account registered for publishing applications to Google Play and have a signed application package, you are ready to upload it for publication.
From the main page of the Google Play Developer Console website, sign in and click the Publish an Android App on Google Play button. You should now see an Add New Application dialog, as seen in Figure 19.8.
Figure 19.8 The Add New Application dialog.
From this page, you can create a new listing in the Developer Console for your application. In order to publish a new application, enter a Title and click the Upload APK button on this dialog. You will now see a new application listing requesting that you Upload your first APK (see Figure 19.9). There are three options for uploading presented: Production, Beta Testing, and Alpha Testing. The Beta and Alpha Testing options are for performing a Staged Rollout, which will be discussed later in this chapter.
Figure 19.9 Google Play application upload form.
When you click the Upload your first APK button, you are presented with a dialog that allows you to upload an .apk file from your file system by dragging and dropping the file onto the upload space or by browsing and selecting the file.
Uploading Application Marketing Assets
The Store Listing tab associated with your application begins with the Product Details section (see Figure 19.10). Here, you can perform the following tasks:
Provide additional translations of your application.
Enter an application title, description, promo text, and recent changes information.
Upload screenshots demonstrating your application on different-size devices, in particular a phone, a 7-inch tablet, and a 10-inch tablet.
Figure 19.10 Google Play Store Listing and Product Details form.
Provide a high-resolution version of your application icon, a feature graphic, a promo graphic, and a promo video.
Enter categorization data for your application.
Provide contact details for your application.
Link to a privacy policy that your application provides.
Configuring Pricing and Distribution Details
The Pricing and Distribution tab associated with your application allows you to enter pricing information for your application (see Figure 19.11). Here, you can do the following:
Specify whether the application is free or paid.
Specify the countries where you would like to distribute your application.
Opt in to Google Play for Education.
Provide consent for acknowledging that your application abides by the Android content guidelines and export laws of your country.
Figure 19.11 Developer Console Pricing and Distribution tab.
Note
Currently, a 30% transaction fee is imposed for hosting applications within the Android Market. Prices can range from $0.99 to $200 (USD), and similar ranges are available in other supported currencies. For more details, see https://support.google.com/googleplay/android-developer/answer/138412.
Configuring Additional Application Options
There are a few other tabs associated with your application that allow you to configure additional setup tasks:
Specify in-app products for your application. This requires adding the BILLING permission to your APK and setting up a merchant account.
Manage services and APIs such as Google Cloud Messaging (GCM), Licensing and In-app Billing, and Google Play Game Services.
Implement additional optimization tips for improving your app listing on Google Play.
Managing Other Developer Console Options
In addition to managing your applications, you can also set up Google Play Game Services and review detailed financial reports for your paid applications. To review financial reports, you must have a merchant account set up to enable paid apps. Financial information is downloadable in CSV format.
Google Play Game Services
A new addition to Google Play is the Google Play Game Services APIs. These APIs allow you to add leaderboards, achievements, and real-time and multiplayer services and to save game data using the Cloud Save APIs. From the Developer Console, you must accept the Google APIs terms of service before you can begin integrating Game Services into your application.
Note
Google Play Game Services APIs provide many useful tools for game developers, but there are no rules prohibiting non-game applications from using these APIs.
Publishing Your Application to Google Play
Once you have entered all the required information, you should be ready to transition your application from a draft to publishing on Google Play. Once you publish, your application appears in Google Play almost immediately. After publication, you can see statistics, including ratings, active installs, and crashes in the All Applications section of the Developer Console (see Figure 19.12).
Figure 19.12 Viewing application statistics within the Google Play Developer Console.
Tip
Receiving crash reports from a specific device? Check your application’s market filters in the Android manifest file. Are you including and excluding the appropriate devices? You can also exclude specific devices by adjusting the Supported Devices settings of the application listing.
Managing Your Application on Google Play
Once you’ve published your application to Google Play, you will need to manage it. Some considerations include understanding how the Google Play return policy works, managing application upgrades, and, if necessary, removing your application from publication.
Understanding the Google Play Application Return Policy
Google Play currently has a 15-minute refund policy on applications. That is to say, a user can use an application for 15 minutes and then return it for a full refund. However, this applies only to the first download and first return. If a particular user has already returned your application and wants to “try it again,” he or she must make a final purchase—and can’t return it a second time. Although this limits abuse, you should still be aware that if your application has limited reuse appeal, you might find that you have a return rate that’s too high and need to pursue other methods of monetization.
Upgrading Your Application on Google Play
You can upgrade existing applications from the Android Developer Console. Simply upload a new version of the same application using the Android manifest file tag android:versionCode. When you publish it, users receive an Update Available notification, prompting them to download the upgrade.
Warning
Application updates must be signed with the same private key as the original application. For security reasons, the Android package manager does not install the update over the existing application if the key is different. This means you need to keep the key corresponding with the application in a secure, easy-to-find location for future use.
Removing Your Application from Google Play
You can also use the Unpublish action in the Android Developer Console to remove the application from Google Play. The Unpublish action is immediate, but your application entry in the Google Play store application might be cached on handsets that have viewed or downloaded your application. Keep in mind that unpublishing the application makes it unavailable to new users but does not remove it from existing users’ devices.
Google Play Staged Rollouts
In the case that you are not yet ready to offer your application for download to the entire world, you are able to distribute it as a prerelease version using Staged Rollouts. This allows you to define alpha and beta test groups, so you are able to generate feedback prior to offering your application to all of Google Play. Any reviews provided will not be visible in the Google Play store, which provides you an opportunity to fix any defects that may generate negative reviews before they affect the perception of your application.
Publishing to the Google Play Private Channel
If you have a Google Apps domain, Google allows you to launch and distribute your application in a private way to the users of your Google Apps domain. The distribution occurs through the Google Play store and can be useful if your application should be restricted to only those within your organization. Rather than having to set up your own distribution mechanisms for internal distribution, you are able to leverage all of the powerful features that Google Play provides, without needing to make your application available to users other than the group that should have access.
Translating Your Application
Since Google Play is available to users in 130 different countries, and growing, you should think about translating your application into different languages early in the development process. There are simple measures that you can take to prepare your application for localization, including the following:
Design your application with localization in mind from Day 1.
Know which languages you may want to target first.
Do not hard-code strings into your application. Instead, use string resources for any text, so when the time comes, all you need to do is have the string resources translated.
The Google Play Developer Console is now offering a pilot program for translation; once accepted, you will be able to hire professional translators to translate the string resources you provide. This helps to streamline the translation process and provides a simple way to find translators.
Make sure once your application has been translated that you also test the application in each language. Some translations may require more textual content, thereby pushing your user interface out of whack. Testing for this scenario is important because users won’t want to use an application that does not display properly.
Publishing Using Other Alternatives
Google Play is not the only place available to distribute your Android applications. Many alternative distribution mechanisms are available to developers. Application requirements, royalty rates, and licensing agreements vary by store. Third-party application stores are free to enforce whatever rules they want on the applications they accept, so read the fine print carefully. They might enforce content guidelines, require additional technical support, and enforce digital signing requirements. Only you and your team can determine which are suitable for your specific needs.
Tip
Android is an open platform, which means there is nothing to prevent a handset manufacturer or an operator (or even you) from developing an Android application store.
Here are a few alternative marketplaces where you might consider distributing your Android applications:
Amazon Appstore is an example of an Android-specific distribution website for free and paid applications (http://amazon.com/appstore).
Samsung Apps is an app store managed by one of the most successful Android device manufacturers on the market (http://apps.samsung.com).
GetJar boasts about having over 100 million users, so this is definitely an Android market to consider adding your application to (http://www.getjar.com/).
Soc.io Mall (formerly AndAppStore) is an Android-specific distribution site for free applications, e-books, and music using an on-device store (http://mall.soc.io).
Handango distributes mobile applications across a wide range of devices with various billing models (http://www.handango.com).
AT&T Apps is an example of a store run by the carrier AT&T for its mobile subscribers (http://www.att.com/shop/apps.html).
Self-Publishing Your Application
You can distribute Android applications directly from a website, server, or email. The self-publishing method is most appropriate for vertical market applications, content companies developing mobile marketplaces, and big-brand websites wanting to drive users to their branded Android applications. It can also be a good way to get beta feedback from end users.
Although self-distribution is perhaps the easiest method of application distribution, it might also be the hardest to market, protect, and make money in. The only requirement for self-distribution is to have a place to host the application package file.
There are downsides to self-distribution. The Google Play licensing service will not be available to help you protect your application from piracy. In addition, Google Play’s In-app Billing service is not available to apps outside Google Play; therefore, you will have to manage the billing aspects yourself. Furthermore, end users must configure their devices to allow packages from unknown sources. This setting is found under the Security section of the device’s Settings application, as shown in Figure 19.13. This option is not available on all consumer devices in the market.
Figure 19.13 Settings application showing the required check box for downloading from unknown sources.
After that, the final step the user must take is to enter the URL of the application package into the Web browser on the handset and download the file (or click a link to it). When the file is downloaded, the standard Android install process occurs, asking the user to confirm the permissions and, optionally, confirm an update or replacement of an existing application if a version is already installed.
Summary
You’ve now learned how to design, develop, test, and deploy professional-grade Android applications. In this final chapter, you learned how to prepare your application package for publication using a variety of revenue models. You also learned about different distribution strategies. Whether you publish through Google Play, alternative markets, your own website, email, or some combination of these options, you can now build a robust application from the ground up and distribute it for profit (or fame!).
So, now it’s time to go out there, fire up your favorite IDE, and build some amazing applications. We want to encourage you to think outside the box. The Android platform leaves the developer with a lot more freedom and flexibility than most other mobile platforms. Take advantage of this. Use what works and reinvent what doesn’t. You might just find yourself with a killer app.
Finally, if you’re so inclined, we’d love to know about all the exciting applications you’re building. You’ll find our contact information in the Introduction to this book. Best of luck!
Quiz Questions
1. What is the name of the obfuscation tool provided with the Android SDK?
2. True or false: The In-app Billing APIs have been added to the Android SDK.
3. What is the name of the Google third-party add-on for collecting statistics regarding your application?
4. What is the difference between the manifest settings versionName and versionCode?
5. True or false: You should disable logging before uploading your application to Google Play.
6. True or false: You are not allowed to self-sign applications that you want to upload to Google Play.
7. What type of merchant account is required for Google Play in order to create paid applications?
Exercises
1. Read through the “Publishing Overview” section and accompanying subsections from the Android documentation found at the following URL: http://d.android.com/tools/publishing/publishing_overview.html.
2. Read through all of the sections and subsections from the Distribute tab from the Android Developers website found at the following URL: http://d.android.com/distribute/index.html.
3. Publish your first real application on Google Play.
References and More Information
The Google Play website:
https://play.google.com/store
Android Tools: “Publishing Overview”:
http://d.android.com/tools/publishing/publishing_overview.html
Android Developers Distribute: Publishing:
http://d.android.com/distribute/googleplay/publish/index.html
Android Tools: “ProGuard” http://d.android.com/tools/help/proguard.html
Android Google Services: “Filters on Google Play”:
http://d.android.com/google/play/filters.html
Android Google Services: Google Play Distribution: “Application Licensing”:
http://d.android.com/google/play/licensing/index.html
Android Google Services: Games:
http://d.android.com/google/play-services/games.html
Android Developers Distribute: Policies: “Google Play Policies and Guidelines”:
http://d.android.com/distribute/googleplay/policies/index.html