Hour 24. Publishing Your Apps
What You’ll Learn in This Hour
Publishing to Google Play and other markets
Making money with your app
After you have created an app, you need a way to get that app to your users. In almost all cases, that means making the app available in an app marketplace. Google Play is the Google app marketplace, but it is not the only place to make apps available. Amazon and others can be appropriate options. Selling in an app marketplace requires having your AndroidManifest.xml file set up properly and your app signed. This hour covers that topic as well as some ways to make money with your app.
Preparing for Release
Hour 23 covered adding finishing touches to an app. For an app to be successful, it must be functionally complete, well tested, and as polished as possible. Whether an app is functionally complete is your decision. In general, focusing on key features and doing them well is a good idea. Spend time on the part of the app that users will use all the time.
Releasing an app that you have tested only in an emulator is possible. Except for the simplest of apps, though, this practice is not advised. Your app should be tested on a real device and if possible multiple devices. Test on different-sized devices and on different versions of the Android operating system. If you have internationalized your app, make sure to test in the target locales.
After your app is functionally complete and tested, look for opportunities to add finishing touches. Do you have a great icon? Does the text in the app convey what it should? A silly game might have a different tone from a financial app. Are you able to remove text and use images or animation to convey meaning? Check the Android design principles for inspiration at http://developer.android.com/design/get-started/principles.html.
Preparing the Android Manifest File for Release
Before release, you need to make a number of changes to the application configuration settings of the Android manifest file. Though some of these items seem obvious, the idea is to have them in a checklist to verify the release. Other items are important for showing how the app is made available in an app marketplace like Google Play. Use this list to double-check your Android manifest file.
Android Manifest Checklist
Review the Android manifest file as follows:
Verify that the application icon is set appropriately. Check the various drawable resource directories to ensure that it is set for all densities.
Verify that the application label is set appropriately. This represents the application name as users see it.
Verify the application package name. The app marketplace uses the package name to identify the app. If you do not like your package name, this is the time to change it.
Verify that the application version name is set appropriately. The version name is a friendly version label that developers (and marketplaces) use.
Verify that the application version code is set appropriately. The version code is a number that the Android platform uses to manage application upgrades.
Confirm that the application uses-sdk setting is set correctly. You can set the minimum, target, and maximum Android SDK versions supported with this build.
Confirm that the uses-screens setting is set properly. This property is not required.
If you had set it, disable the debuggable option.
Confirm that all application permissions are appropriate. Request only the permissions the application needs with uses-permission.
You can look at the Hour23OpenSource project and consider the Android manifest checklist. First, note that this app really is for demo purposes. It shows toolbar menu choices that are not used for example. It serves just as an example for working through the checklist:
package="com.bffmedia.hour23opensource"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="16" />
<uses-permission android:name="android.permission.INTERNET" />
The package name is com.bffmedia.hour23opensource. This is not a particularly good name. You can see the versionCode and versionName. VersionName is what displays to the user. You can use a scheme that includes text and numbers as part of your naming scheme. The versionCode is just a number. It is for your internal use and to indicate the latest version to Google Play or other markets. The versionCode and versionName can be different. You can have versionName “1.07a” and a version code of 9. The target and minimum SDK version make sense and so does using only the Internet permission. There is no uses-screens option and that is acceptable.
The icon set is ic_launcher. It is the default graphic, and it should be changed to represent the app.
Tip: Use the Android Asset Studio
The Android Asset Studio includes an easy way to make icons for your app. The icons are generated into all the desired densities for images. The online tool is easy to use. Other useful features are available in the Android Asset Studio. Check it out at http://android-ui-utils.googlecode.com/hg/asset-studio/dist/index.html.
The app name is included in the application element as follows:
android:label="@string/app_name"
You can look up the app_name in the strings.xml resource file and see that the app name is Hour23OpenSource. It is not likely to generate a lot of app sales or excitement.
Using <uses-feature> Wisely
The uses-feature tag indicates whether a particular hardware feature is used in the app. For the camera app in Hour 20, this is added to the Android manifest:
<uses-feature android:name="android.hardware.camera" />
Google Play will filter apps based on this setting.
You can indicate that an app uses the camera, but does not require it, as follows:
<uses-feature android:name="android.hardware.camera"
android:required="false" />
Signing Your Apps
Android application packages must be digitally signed for the Android package manager to install them. Throughout the development process, Eclipse has used a debug key to manage this process. However, for release, you need to use a real digital signature—one that is unique to you and your company. To do this, you must generate a private key.
You 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 is coming from you, the developer, and not someone pretending to be you.
Self-signing of signatures is standard for Android applications. Code signing allows the Android system to ensure app updates come from the same source as the original app. Because the signature is self-signed, it cannot confirm the identity of the developer, only that the original app and the update come from the same source. You should ensure your private key is kept safe.
Application updates must be signed with the same private key. 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.
Warning: Keep Your Key Safe!
Your key is critically important—keep it safe! Ideally, only the person in charge of building the release version should have access to the key. Your key should be backed up—preferably with at least one copy kept offsite.
Exporting and Signing the Package File Using Eclipse
Eclipse makes exporting and signing the Android package file easy. This section goes through the steps to create the signed package using Eclipse and then considers the command-line options for using signing packages.
To create the signed package:
1. In Eclipse, right-click on the appropriate project and choose the Android Tools option.
2. Choose Export Signed Application Package.
3. The Project will be checked for export; click Next.
4. On the KeyStore selection screen, choose Create New Keystore. Enter a location and name for the keystore and enter and confirm a password.
5. Enter data for key creation. This includes a password, validity in years, and other information. The validity must be more than 25 years. See Figure 24.1.
6. Choose a destination for your APK file and click Finish.
That’s it. The APK is the Android package file. It is the Android executable that can be tested and then added to Google Play or other markets.
Signing Apps Using Command-Line Tools
Knowing something about the command-line tools that are available for creating keystores and signing packages can also be useful.
The command-line tools keytool and jarsigner are part of the Java Development Kit (JDK). You can use keytool to create a keystore and jarsigner to sign the Android package file.
To get help, you can enter the tool name at a command line. If the tools are not available at the command line, you need to check the path to your JDK. You can find information on keytool and jarsigner at http://docs.oracle.com/javase/6/docs/technotes/tools/#security.
Creating a key with keytool is easiest understood by example:
keytool -genkey -v -keystore hour23.keystore -alias hour23 -keyalg RSA -validity
10000
This command creates a keystore in the file hour23.keystore. It is valid for 10,000 days and has an alias of hour23. Figure 24.2 shows the session that occurs after entering this command.
After you create the keystore, you can use it to sign an APK file using jarsigner. The following assumes you have an unsigned APK called hour23opensource.apk:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore hour23.keystore
hour23opensource.apk hour23
The –sigalg and –digestalg parameters use the Android recommended values. The keystore parameter is specified by the file that you created: hour23.keystore. The hour23opensource.apk file is listed, and the last parameter is the alias name.
This results in a signed Android package. You should run jarsigner – verify hour23opensource.apk to verify the results.
You can do an optimization process for the final APK file by using the Android command-line tool zipalign. The command is as follows:
zipalign -v 4 hour23opensource.apk hour23opensource-aligned.apk
Exporting the Certificate File
Recall from Hour 22 that Facebook required a key hash to identify your app. After you have a private key and have signed the APK file, you can generate the proper key hash for Facebook via the keytool command, as follows:
keytool -exportcert -alias hour23 -keystore hour23.keystore | openssl sha1 -binary
| openssl base64
The keystore alias and keystore file are specified. The result is a hash key that is displayed on the command line. That result is what should be populated into the Facebook developer tool.
Testing the Package
Several ways exist to test the signed Android package. The easiest is to email it to an account on an Android device. When you open the attached APK, you should get an option to load the package. Be sure that in the Android Settings app (under Security), you have specified that it’s OK to load Android apps from outside the Android market. You specify that unknown sources are allowed.
You can copy the APK file to the device and launch it with a File Manager tool. An app such as Astro File Manager works well for this.
You can also use command-line tool for installing and uninstalling. To install, refer to the apk file:
adb install hour23opensource.apk
To uninstall, refer to the package:
adb uninstall com.bffmedia.hour23opensource
Use the command adb devices to list all devices. To specify a device for installation, use the –s flag:
adb -s 016B756E0E01C005 install hour23opensource.apk
Publishing Your App
With a signed app, you are technically ready to publish your application. This section covers the basics of publishing your app on Google Play and considers some alternative markets. Putting thought and consideration into your presentation and marketing efforts in various app markets is important. The app name, icon, description, and supporting graphics are all important for making a good impression.
Publishing on Google Play
Google Play is Google’s app marketplace for Android. It provides an easy way for a developer to publish apps and is probably the most common way that users acquire apps.
To publish applications through the Android Market, you must register as a developer. Registering as a developer verifies who you are to Google and provides a way for Google to pay you when someone buys your app. There is a $25 one-time fee to sign up as a Google Developer. Signing up is a simple online process; go to https://play.google.com/apps/publish/.
After you have your developer account, you can add a new application. You are given the choice to upload the APK or set up the store listing. See Figure 24.3.
For an app to have a chance to be successful, take advantage of all the available fields on Google Play when you add an app. Add screenshots, descriptive text, promo text, and so on. You can include screenshots for both phone devices and tablets. The screenshots to include should show key elements of your app and ideally how a user interacts with your app.
Store Listing
You will see additional options for your app including Game Center and other services. Google Play is a helpful area to explore and understand the opportunities for making apps available to users in the best way.
Figure 24.4 gives an idea of some of the screenshot options that are available.
Uploading the APK
When you upload an APK to Google Play, Google Play will read the APK file and provide information about the APK such as the number of supported devices. You can upload for alpha and beta testing. To do so, you specify a Google Group or Google+ community.
Figure 24.5 shows the result of uploading the Hour 23 app as an alpha.
You have an opportunity in Google Play to pay for localizing the app. The idea is that your app will include a strings.xml resource file in English that can be pulled from the uploaded APK and translated into other languages. This might be a great option for certain apps. A fee is charged for the translations. See Figure 24.6.
Publishing on Amazon
Publishing on Amazon is similar to publishing on Google Play. Choose the Mobile App Distribution option from https://developer.amazon.com/.
You can develop specifically for Kindle Android-based devices or generic Android devices. A Kindle-specific version for the Amazon market might make sense. Kindle Fire is based on Android. If you are developing for the Kindle Fire, getting a device to test on is recommended.
What About OUYA or Other Markets?
OUYA is an Android-based game console that connects to a TV. You can find out more at http://www.ouya.tv/develop/.
If you download the OUYA Developer Kit (ODK), you’ll find that it is an Android development environment. Libraries specific to the OUYA cover how to respond to the controller and other specific features.
The development of the OUYA shows that new markets do become available for Android apps.
In Korea, the T-Store is a large app distributor. If you have an app that would do well in Korea, translating it and selling it at the T-Store would make sense.
The T-Store developer center is at http://dev.tstore.co.kr/.
Monetizing Your App
Making apps that people use can be fun and rewarding. Making money with your apps is also fun and rewarding. Many variations exist, but most app monetizaion schemes fall into one of four models: free, advertising, paid, and in-app billing.
Free Apps
With free apps, you can build a user base and work out the bugs in your app and maybe in your idea or product. Some apps become popular first and then you try to figure out how to make money later. Or some apps build a large user base and are acquired by a larger company. Don’t dismiss free as a good option for many apps.
Ad Supported
Including mobile ads in your apps is easy to do. You can try AdMob, Amazon, or one of many other ad providers. To include ads in your app, you download an ad SDK and incorporate the ad into your app. You might add an ad slot into your layouts, or determine a good spot within your app to show an ad-based activity. The model is similar to the process you followed for the Facebook SDK in Hour 22.
Paid
The paid model is easy to understand. You set a price level in Google Play and other markets, and users pay for your app. Many apps sell for $0.99 in the U.S., but you might have a specialty app that can sell for significantly more or a great app that can sell for $4.99. Determine the proper price for your app to maximize revenue.
In-App Payments
Google Play and Amazon have different in-app payment options. The classic model for an in-app payment is a game in which there is a virtual currency. Players can earn the currency by playing the game or they can buy the currency with actual money. In-app purchases can give a user the ability to try an app without any upfront expense.
You can mix and match these options. You might decide your app should have an ad-supported version and a paid version without ads. Creating a business around an app always starts with creating a great app. After that part is done, you can experiment with how to make money.
Summary
This hour covered the process of producing a signed Android application and distributing it on various app marketplaces. The signing process is critical for security and for maintaining apps. Multiple app markets exist, including Amazon, and you can take advantage of new opportunities to distribute Android apps on new devices such as the OUYA and in many markets around the world.
Q&A
Q. Is this everything there is to know about selling apps?
A. No, this hour is a good start. You can look into app licenses and privacy policies. This hour mentions in-app billing and using ad SDKs, but does not cover the details.
Q. How can I limit my application to only specific types of devices?
A. Google Play attempts to filter applications available to those compatible with the specific user’s device. Each application package includes important information in the Android manifest file. Certain manifest file settings can be used to specify what types of devices your application does or does not support. For example, whether or not an app uses the camera can be determined. After that’s done, the app will be available only for appropriate devices.
Workshop
Quiz
1. Is it possible to make an app that optionally uses the camera?
2. What are some common ways of making money with an app?
3. True or false: Google Play provides free translations for your app.
Answers
1. Yes, you can indicate in the Android manifest file that the app uses the camera, but does not require it.
2. Free apps might ultimately make money. Other apps are ad supported, paid, or have in-app billing.
3. False. It offers a paid translation service.
Exercise
Choose any exercise app from this book, export it, and sign it. You can use the Hour23Opensouce app or create a brand-new app. Sign up for a developer account on Google Play and Amazon. Check out OUYA and begin to make great apps that appeal to you. When you begin to create an app, creating one that you care about is ideal.