Since the Android version of Pulse was released in July of last year, we’ve released 40 some updates. Here are some of the basic and more advanced best practices that we’ve accumulated:

The Basics

To publish an update, you must sign it with the same private key you used when you initially published the app. After you publish the initial version, back up your key and make sure you don’t forget the keystore password, otherwise your app will be un-updateable.  You’ll have to change the package name and publish as a separate app, but if you have any users, this is really a bad situation to be in. Make sure to back up your keystore!

In general, you want to test the new version on a variety of devices with different screen sizes and running different versions of Android. Building a community of beta-testers can be a great way to get some feedback and testing on a bunch of devices.

Testing Upgrades

Make sure to test various upgrade combinations. For example if you’re going to be releasing version 2.0, test upgrades from the last few versions (1.7 → 2.0, 1.8 → 2.0, 1.9 → 2.0) because a lot of users don’t install updates immediately after they are published.  To facilitate upgrade testing, you can keep an internal-only Dropbox folder with all the previous Market versions, and upload a new one when you have an updated version of the app.

When you have a previous version running on your device, add a few widgets (if your app has them) and shortcuts to the home screen, and make sure they stick around and keep working after upgrades. Double-check that you are not changing any of the things that cannot change. Also make sure user settings are persisted through upgrades.

Another thing to watch out for when upgrading is database changes. If you use the standard SQLite database, make sure your onUpdate method handles upgrading your database appropriately.  If you have any tutorials when the app first opens, check that the messaging is appropriate for upgrades as well as new installs. Someone who has been using your app for a year shouldn’t get a welcome message or another walkthrough of how your app works.

By accessing the version name (use PackageManager to get the the app’s PackageInfo which includes version name) and saving the current version name somewhere like SharedPrefs, you can easily figure out whether it’s a new install or upgrade or same version, and handle messaging or anything else appropriately.

Communication with Users

The changelog is the main place where you can communicate with users about changes in the recent version. Even if it’s a small update with trivial bug fixes, you definitely need to put something in the changelog. If you forget to add messaging in the changelog, many Android users will give you 1-star reviews if you have an empty changelog, and then after you do update the changelog, Android Market can take up to a few hours to persist those changes.

We tend to keep change history around for the last few updates, since not all users are on the current version.

Post-Publication

Even if you’ve done your best right up until you click “Publish,” bugs will probably show up in production. For the next few days, keep an eye on crash reports through the Android Developer dashboard, and be ready to release a quick fix release if anything urgent comes up.  For whichever version control system you use, always keep a branch synced to the latest published version, so if there are any crash reports or email feedback that require quick fixes, you won’t be introducing any new bugs into the app.

If you’ve found any other useful guidelines or tips for releasing updates, we’d love to hear them!