Preparing to publish!

Ok, I'm ready to (attempt) to take the plunge, and upload my app(s) to the Android marketplace. I have a couple up there in draft form, but which one to upgrade? There is no way to distinguish between them. Ok, apparently I'm on 5. It must add the later ones on top. Or it's in order by package name. Anyway, let's try 5.

And I get this:

"The new apk's versionCode (1) already exists"

Ok. How to handle versioning?

Here's what google says:

Versioning Your Applications
Quickview

Your application must be versioned
You set the version in the application's manifest file
How you version your applications affects how users upgrade
Determine your versioning strategy early in the development process, including considerations for future releases.

In this document

Setting Application Version
Specifying Your Application's System API Requirements

See also

Preparing to Publish Your Application
Publishing On Android Market
The AndroidManifest.xml File

Versioning is a critical component of your application upgrade/maintenance strategy.

Users need to have specific information about the application version that is installed on their devices and the upgrade versions available for installation.
Other applications — including other applications that you publish as a suite — need to query the system for your application's version, to determine compatibility and identify dependencies.
Services through which you will publish your application(s) may also need to query your application for its version, so that they can display the version to users. A publishing service may also need to check the application version to determine compatibility and establish upgrade/downgrade relationships.

The Android system itself does not ever check the application version information for an application, such as to enforce restrictions on upgrades, compatibility, and so on. Instead, only users or applications themselves are responsible for enforcing any version restrictions for applications themselves.

The Android system does check any system version compatibility expressed by an application in its manifest, in the minSdkVersion attribute. This allows an application to specify the minimum system API with which is compatible. For more information see Specifying Minimum System API Version.

// I think I need to set my minSDK to 8. Ok, done.



Setting Application Version

To define the version information for your application, you set attributes in the application's manifest file. Two attributes are available, and you should always define values for both of them:

android:versionCode — An integer value that represents the version of the application code, relative to other versions.

The value is an integer so that other applications can programmatically evaluate it, for example to check an upgrade or downgrade relationship. You can set the value to any integer you want, however you should make sure that each successive release of your application uses a greater value. The system does not enforce this behavior, but increasing the value with successive releases is normative.

Typically, you would release the first version of your application with versionCode set to 1, then monotonically increase the value with each release, regardless whether the release constitutes a major or minor release. This means that the android:versionCode value does not necessarily have a strong resemblance to the application release version that is visible to the user (see android:versionName, below).

// That's good.

Applications and publishing services should not display this version value to users.

android:versionName — A string value that represents the release version of the application code, as it should be shown to users.

The value is a string so that you can describe the application version as a .. string, or as any other type of absolute or relative version identifier.

As with android:versionCode, the system does not use this value for any internal purpose, other than to enable applications to display it to users. Publishing services may also extract the android:versionName value for display to users.

You define both of these version attributes in the element of the manifest file.

Here's an example manifest that shows the android:versionCode and android:versionName attributes in the <manifest> element.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.package.name"
android:versionCode="2"
android:versionName="1.1">
<application android:icon="@drawable/icon" android:label="@string/app_name">
...
</application>
</manifest>

In this example, note that android:versionCode value indicates that the current .apk contains the second release of the application code, which corresponds to a minor follow-on release, as shown by the android:versionName string.

The Android framework provides an API to let applications query the system for version information about your application. To obtain version information, applications use the getPackageInfo(java.lang.String, int) method of PackageManager.

// Ok, that looks good, I don't have to change anything, once I delete and reload.


Specifying Your Application's System API Requirements

If your application requires a specific minimum version of the Android platform, or is designed only to support a certain range of Android platform versions, you can specify those version requirements as API Level identifiers in the application's manifest file. Doing so ensures that your application can only be installed on devices that are running a compatible version of the Android system.

To specify API Level requirements, add a element in the application's manifest, with one or more of these attributes:

android:minSdkVersion — The minimum version of the Android platform on which the application will run, specified by the platform's API Level identifier.
android:targetSdkVersion — Specifies the API Level on which the application is designed to run. In some cases, this allows the application to use manifest elements or behaviors defined in the target API Level, rather than being restricted to using only those defined for the minimum API Level.
android:maxSdkVersion — The maximum version of the Android platform on which the application is designed to run, specified by the platform's API Level identifier. Important: Please read the documentation before using this attribute.

When preparing to install your application, the system checks the value of this attribute and compares it to the system version. If the android:minSdkVersion value is greater than the system version, the system aborts the installation of the application. Similarly, the system installs your application only if its android:maxSdkVersion is compatible with the platform version.

If you do not specify these attributes in your manifest, the system assumes that your application is compatible with all platform versions, with no maximum API Level.

To specify a minimum platform version for your application, add a element as a child of , then define the android:minSdkVersion as an attribute.

For more information, see the manifest element documentation and the API Levels document.


// Ok, it's kind of deja vu, but I'm going to review the publishing checklist again:

Preparing to Publish: A Checklist

Publishing an application means testing it, packaging it appropriately, and making it available to users of Android-powered mobile devices.

If you plan to publish your application for installation on Android-powered devices, there are several things you need to do, to get your application ready. This document highlights the significant checkpoints for preparing your application for a successful release.

If you will publish your application on Android Market, please also see Publishing on Android Market for specific preparation requirements for your application.

// I'll check that after this.

For general information about the ways that you can publish an applications, see the Publishing Your Applications document.

Before you consider your application ready for release:

Test your application extensively on an actual device // done
Consider adding an End User License Agreement in your application // skipping
Consider adding licensing support // done
Specify an icon and label in the application's manifest // done
Turn off logging and debugging and clean up data/files // done

Before you do the final compile of your application:

Version your application // done
Obtain a suitable cryptographic key // done I believe, there's one specified on my account in the Marketplace
Register for a Maps API Key, if your application is using MapView elements // Don't need

Compile your application // done

After you compile your application:

Sign your application // done
Test your compiled application // done

Before you consider your application ready for release
1. Test your application extensively on an actual device

It's important to test your application as extensively as possible, in as many areas as possible. To help you do that, Android provides a variety of testing classes and tools. You can use Instrumentation to run JUnit and other test cases, and you can use testing tools such as the UI/Application Exerciser Monkey.

// Let's run the monkey again. While that's running, keep going.

To ensure that your application will run properly for users, you should make every effort to obtain one or more physical mobile device(s) of the type on which you expect the application to run. You should then test your application on the actual device, under realistic network conditions. Testing your application on a physical device is very important, because it enables you to verify that your user interface elements are sized correctly (especially for touch-screen UI) and that your application's performance and battery efficiency are acceptable.
If you can not obtain a mobile device of the type you are targeting for your application, you can use emulator options such as -dpi, -device, -scale, -netspeed, -netdelay, -cpu-delay and others to model the emulator's screen, network performance, and other attributes to match the target device to the greatest extent possible. You can then test your application's UI and performance. However, we strongly recommend that you test your application on an actual target device before publishing it.

2. Consider adding an End User License Agreement in your application

To protect your person, organization, and intellectual property, you may want to provide an End User License Agreement (EULA) with your application.

3. Consider adding support for Android Market Licensing

If you are publishing a paid application through Android Market, consider adding support for Android Market Licensing. Licensing lets you control access to your application based on whether the current user has purchased it. Using Android Market Licensing is optional.

For complete information about Android Market Licensing Service and how to use it in your application, see Licensing Your Applications.

4. Specify an icon and label in the application's manifest

The icon and label that you specify in an application's manifest are important because they are displayed to users as your application's icon and name. They are displayed on the device's Home screen, as well as in Manage Applications, My Downloads, and elsewhere. Additionally, publishing services may display the icon and label to users.

To specify an icon and label, you define the attributes android:icon and android:label in the element of the manifest.

As regards the design of your icon, you should try to make it match as much as possible the style used by the built-in Android applications.

5. Turn off logging and debugging and clean up data/files

For release, you should make sure that debug facilities are turned off and that debug and other unnecessary data/files are removed from your application project.

Remove the android:debuggable="true" attribute from the element of the manifest.
Remove log files, backup files, and other unnecessary files from the application project.
Check for private or proprietary data and remove it as necessary.
Deactivate any calls to Log methods in the source code.

Before you do the final compile of your application
6. Version your application

Before you compile your application, you must make sure that you have defined a version number for your application, specifying an appropriate value for both the android:versionCode and android:versionName attributes of the element in the application's manifest file. Carefully consider your version numbering plans in the context of your overall application upgrade strategy.

If you have previously released a version of your application, you must make sure to increment the version number of the current application. You must increment both the android:versionCode and android:versionName attributes of the element in the application's manifest file, using appropriate values.

For detailed information about how to define version information for your application, see Versioning Your Applications.
7. Obtain a suitable cryptographic key

If you have read and followed all of the preparation steps up to this point, your application is compiled and ready for signing. Inside the .apk, the application is properly versioned, and you've cleaned out extra files and private data, as described above.

Before you sign your application, you need to make sure that you have a suitable private key. For complete information about how to obtain (or generate) a private key, see Obtaining a Suitable Private Key.

Once you have obtained (or generated) a suitable private key, you will use it to:

Register for a Maps API Key (see below), if your application uses MapView elements.
Sign your application for release, later in the preparation process

8. Register for a Maps API Key, if your application is using MapView elements

For complete information about getting a Maps API Key, see Obtaining a Maps API Key.

If your application uses one or more Mapview elements, you will need to register your application with the Google Maps service and obtain a Maps API Key, before your MapView(s) will be able to retrieve data from Google Maps. To do so, you supply an MD5 fingerprint of your signer certificate to the Maps service.

During development, you can get a temporary Maps API Key by registering the debug key generated by the SDK tools. However, before publishing your application, you must register for a new Maps API Key that is based on your private key.

If your application uses MapView elements, the important points to understand are:

You must obtain the Maps API Key before you compile your application for release, because you must add the Key to a special attribute in each MapView element — android:apiKey — in your application's layout files. If you are instantiating MapView objects directly from code, you must pass the Maps API Key as a parameter in the constructor.
The Maps API Key referenced by your application's MapView elements must be registered (in Google Maps) to the certificate used to sign the application. This is particularly important when publishing your application — your MapView elements must reference a Key that is registered to the release certificate that you will use to sign your application.
If you previously got a temporary Maps API Key by registering the debug certificate generated by the SDK tools, you must remember to obtain a new Maps API Key by registering your release certificate. You must then remember to change the MapView elements to reference the new Key, rather than the Key associated with the debug certificate. If you do not do so, your MapView elements will not have permission to download Maps data.
If you change the private key that you will use to sign your application, you must remember to obtain a new Maps API Key from the Google Maps service. If you do not get a new Maps API Key and apply it to all MapView elements, any MapView elements referencing the old Key will not have permission to download Maps data.

Compile your application

When you've prepared your application as described in the previous sections, you can compile your application for release.
After you compile your application
9. Sign your application

Sign your application using your private key and then align it with the zipalign tool. Signing your application correctly is critically important. Please see Signing Your Applications for complete information.
10. Test your compiled and signed application

Before you release your compiled application, you should thoroughly test it on the target mobile device (and target network, if possible). In particular, you should make sure that any MapView elements in your UI are receiving maps data properly. If they are not, go back to Register for a Maps API Key and correct the problem. You should also ensure that the application works correctly with any server-side services and data that you are providing or are relying on and that the application handles any authentication requirements correctly.

After testing, you are now ready to publish your application to mobile device users.

// Ok, good. Unlike the last time I tried, I made it through this list pretty quickly. What hung me last time - was it licensing?

// Let's take a look at publishing.

Publishing on Android Market
Quickview

You can publish your application using a hosted service such as Android Market or through a web server.
Before you publish, make sure you have prepared your application properly.
Android Market makes it easy for users of Android-powered devices to see and download your application.

In this document

About Android Market
Publishing Updates on Android Market
Using Android Market Licensing Service
Linking to Your Apps on Android Market
Opening an app's details page
Performing a search
Build an Android Market button
Summary of URI formats

See also

Application Licensing
Preparing to Publish

Interested in publishing your app on Android Market?

Go to Android Market to create a developer account and upload your application. For more information about the required assets, listing details, and options, see Uploading applications.

If you've followed the steps outlined in Preparing to Publish, the result of the process is a compiled .apk file that is signed with your private release key. Your application is now ready to be published publicly so users can install it.

You can publish your application and allow users to install it any way you choose, including from your own web server. This document provides information about publishing your Android application with Android Market.
About Android Market

Android Market is a service that makes it easy for users to find and download Android applications to their Android-powered devices, either from the Android Market application on their device or from the Android Market web site (market.android.com). As a developer, you can use Android Market to distribute your applications to users on all types of Android-powered devices, all around the world.

To publish your application on Android Market, you first need to register with the service using a Google account and agree to the terms of service. Once you are registered, you can upload your application to the service whenever you want, update it as many times as you want, and then publish it when you are ready. Once published, users can see your application, download it, and rate it.

To register as an Android Market developer and get started with publishing, visit the Android Market publisher site:

http://market.android.com/publish

If you plan to publish your application on Android Market, you must make sure that it meets the requirements listed below, which are enforced by the Market server when you upload the application.

Requirements enforced by the Android Market server:

Your application must be signed with a cryptographic private key whose validity period ends after 22 October 2033.
Your application must define both an android:versionCode and an android:versionName attribute in the element of its manifest file. The server uses the android:versionCode as the basis for identifying the application internally and handling updates, and it displays the android:versionName to users as the application's version.
Your application must define both an android:icon and an android:label attribute in the element of its manifest file.

Publishing Updates on Android Market

At any time after publishing an application on Android Market, you can upload and publish an update to the same application package. When you publish an update to an application, users who have already installed the application may receive a notification that an update is available for the application. They can then choose to update the application to the latest version.

Before uploading the updated application, be sure that you have incremented the android:versionCode and android:versionName attributes in the element of the manifest file. Also, the package name must be the same as the existing version and the .apk file must be signed with the same private key. If the package name and signing certificate do not match those of the existing version, Market will consider it a new application, publish it as such, and will not offer it to existing users as an update.
Using Android Market Licensing Service

Android Market offers a licensing service that lets you enforce licensing policies for paid applications that you publish through Android Market. With Android Market Licensing, your applications can query Android Market at runtime to obtain the licensing status for the current user, then allow or disallow further use of the application as appropriate. Using the service, you can apply a flexible licensing policy on an application-by-application basis—each application can enforce its licensing status in the way most appropriate for it.

Any application that you publish through Android Market can use the Android Market Licensing Service. The service uses no dedicated framework APIs, so you can add licensing to any application that uses a minimum API Level of 3 or higher.

For complete information about Android Market Licensing Service and how to use it in your application, read Application Licensing.
Linking to Your Apps on Android Market

To help users discover your published applications, you can use two special Android Market URIs that direct users to your application's details page or perform a search for all of your published applications in Android Market. You can use these URIs to create a button in your application or a link on a web page that:

// I should probably do this.

Opens your application's details page in the Android Market application or web site.
Searches for all your published applications in the Android Market application or web site.

You can launch the Android Market application or web site in the following ways:

Initiate an Intent from your application that launches the Android Market application on the user's device.
Provide a link on a web page that opens the Android Market web site (but will also open the Android Market application if clicked from a device).

In both cases, whether you want to initiate the action from your application or from a web page, the URIs are quite similar. The only difference is the URI prefix.

To open the Android Market application from your application, the prefix for the intent's data URI is:

market://

To open Android Market from your web site, the prefix for the link URI is:

http://market.android.com/

The following sections describe how to create a complete URI for each action.

Note: If you create a link to open Android Market from your web site and the user selects it from an Android-powered device, the device's Market application will resolve the link so the user can use the Market application instead of opening the web site. As such, you should always use http://market.android.com/ URIs when creating a link on a web page. When pointing to your apps from within your Android app, use the market:// URIs in an intent, so that the Market application always opens.

// Ok. I can add this later on.

Opening an app's details page

As described above, you can open the details page for a specific application either on the Android Market application or the Android Market web site. The details page allows the user to see the application description, screenshots, reviews and more, and choose to install it.

The format for the URI that opens the details page is:

details?id=

The is a placeholder for the target application's fully-qualified package name, as declared in the package attribute of the element.
Opening the app details page from your Android app

To open the Android Market details page from your application, create an intent with the ACTION_VIEW action and include a data URI in this format:

market://details?id=

For example, here's how you can create an intent and open an application's details page in Android Market:

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("market://details?id=com.android.example"));
startActivity(intent);

This will open the Android Market application on the device to view the com.android.example application.
Opening the app details page from a web site

To open the details page from your web site, create a link with a URI in this format:

http://market.android.com/details?id=

For example, here's a link that opens an application's details page on Android Market:

App Link

When clicked from a desktop web browser, this opens the Android Market web site to view the com.android.example application. When clicked from an Android-powered device, users are given the option to use either their web browser or the Android Market application to view the application.

// Ok, I'll wait until after the apps are published to add these.

Performing a search

// Ok, I don't need to search or anything.

To initiate a search in Android Market, the format for the URI is:

search?q=

The is a placeholder for the search query to execute in Android Market. The query can be a raw text string or you can include a parameter that performs a search based on the publisher name:

// Ok, I don't need to search.

To perform a raw text search, append the query string:

search?q=
To search based on the publisher name, use the pub: parameter in the query, followed by the publisher name:

search?q=pub:

You can use this type of search to show all of your published applications.

Searching from your Android app

To initiate a search on Android Market from your application, create an intent with the ACTION_VIEW action and include a data URI in this format:

market://search?q=

The query may include the pub: parameter described above.

For example, here's how you can initiate a search in the Android Market application, based on the publisher name:

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("market://search?q=pub:Your Publisher Name"));
startActivity(intent);

This opens the Android Market application to perform the search. The search result shows all applications published by the publisher that are compatible with the current device.
Searching from a web site

To initiate a search on Android Market from your web site, create a link with a URI in this format:

http://market.android.com/search?q=

The query may include the pub: parameter described above.

For example, here's a link that initiates a search on Android Market, based on the publisher name:

Search Link

When clicked from a desktop web browser, this opens the Android Market web site and performs the search. When clicked from an Android-powered device, users are given the option to use either their web browser or the Android Market application to perform the search.
Build an Android Market button

Use the following form to generate an "Available in Android Market" button that you can use on your web site. Input either your application's package name or publisher name and the button will take users to Android Market to either view your application's information or view a list of your published apps. If users click the button while on an Android-powered device, the Android Market application will respond to show users your application(s).

This form offers four versions of the official "Available in Android Market" button at recommended sizes. If you want to create a different size, you can download an EPS file for the button images from the Android Brand Guidelines.
Package name:

or
Publisher name:

narrow and small logo narrow and large logo
wide and small logo wide and large logo

Summary of URI formats

The table below provides a summary of the URIs currently supported by the Android Market (both on the web and in the Android application), as discussed in the previous sections.
For this result Use this URI in a web page link Or this URI in an ACTION_VIEW intent
Display the details screen for a specific application http://market.android.com/details?id= market://details?id=
Search for applications using a general string query. http://market.android.com/search?q= market://search?q=
Search for applications by publisher name http://market.android.com/search?q=pub:
// Se, we can review all of that after the apps are up on the market.

Ok, so, exporting the apk, unsigned.

Run the sign script...

Uploading.

Ok, let's do some testing...

Good - the splash screen looks much better than the dark screen - but it doesn't do anything if you touch it, and then the download starts.

But - and this one I kept forgetting about - the extract progress bar isn't giving a good indication. It only get about 33% of the way there.

Here's the code:

int cntr = 0;
// Loop through all the files and folders
for (ZipEntry entry = zin.getNextEntry(); entry != null; entry = zin
.getNextEntry()) {

cntr++;

int publishedInt = (int) ((cntr / (float) numFilesInLevel) * 100);

publishProgress(publishedInt);

Let's print the counter and see how many iterations it actually gets...

Well, there seems to be the right amount, actually a few more than the 653 I though. Maybe its a UI thing.

Well, let's call it every 100 and see what happens.

Oh, I see. I'm setting the max as files, but giving a percent. This does the trick:

cntr++;
publishProgress(cntr);

Ah, I see why the download progress bar wasn't correct originally. The file count was off. So, the 1024 number was correct, after all.

Ok, now it's spot on. The file download display is a bit off, because from some reason we're getting more zip entries than files. But, it's just as delay of maybe one or two seconds

Ok. That's it for now. Will pick this up again tomorrow.