Android Application Provisioning Strategies

Posted by


This tutorial discusses the various options that are available as of the M5 SDK of deploying Android apps to devices. As the next release of the SDK is provided, I’m sure more options and strategies will become available.

Android 101

To get started with Android, click here.


There aren’t any good solutions out right now. App provisioning and management are left out of the M5 SDK, and we have to wait until a future release to see this in place. Once it’s in place, these other strategies outlined here may or may not be viable. However, if you can preload an APK file into a device, then the solutions outlined here might work for you.

What is an Android executable?

Java source code gets compiled to .class files, which run on any standard Java Virtual Machine on any OS. However, Android SDK has tools that converts these .class (binary files) to .dx files which are then run on the Android’s Dalvik VM. These DEX files have to be generated by tools in the SDK. Android applications are a bundle of these DEX files, and other assets/resources (images, resource bundles for various languages, constants, etc.). This bundle is an uncompressed ZIP file called an .APK file. These APK files have to be loaded using SDK tools right now.

How are executables loaded?

Right now, with the M5 SDK, APK files can only be loaded using the tools. In the future it might be possible to load the APK file via the Web using the built in web browser. Or there might be an application provisioning service provided by Google. However, none of these options are available right now. Read on if you want to roll out your own application provisioning services.

Extending applications once they’ve been installed

Unlike Java SE it’s not possible to load class files or JAR files over the network and have them installed to the machine hosting the JVM. Since Android converts all .class files to DEX files, this dynamic nature of Java is lost in the Android environment. If you want to download new binaries, it will be necessary to provide these new classes (their DEX files) in the APK file that’s reloaded to the device. Alternatively, you can load new APK files into the device, and use the code in them by registering the new modules with the Android device (that they just got downloaded into). You can use Services, Intents, and IntentRecievers to do this sort of thing.

Accessing class files in an app’s own APK file

It’s currently not even possible for an app to access the class files in it’s own APK file, much less download another APK file from the web, or download more binary content externally (network, etc).

Deployment Scenarios

Given the “embedded systems” nature of Android, and it’s use of DEX files, it’s not going to be possible to dynamically update an app’s binary executable footprint over the network (like it is for JavaSE). However, it will be possible to download entirely new APK files (applications) from the network. This might happen in a variety of ways:

  1. Provide a URL from which an APK file can be downloaded (using the built in web browser) and installed on the client. JavaME/Blackberry and Windows Mobile do OTA app provisioning this way, so I can see Android doing it the same way. If an older version of the an app is already installed, it will get overwritten with the new one… all the data, etc. can be re-used by the new version (and automatically migrated to a new canonical format, if this is needed).
  2. You can create and host something similar to the iPhone App Store for Android.

Google App Store

At this year’s Google IO conference, where they showed off a phone running android, they mentioned the possibility of an application management infrastructure rolled out by google to manage roll out of apps to mobile devices, etc. Conceptually, it could be similar to how the iPhone App Store works, minus the royalties to Apple :). And minus any of the restrictions that the iPhone SDK places on 3rd party apps. The SDK is in milestone 5 form right now… which is an early beta, so there are many things simply missing from it – application provisioning and upgrading being 2 of them.

Here’s a link with more information on the app store/infrastructure that Google has in the works.

Your own Android app store

There are non-Google open source solutions (Java server and Android client) software that enabled OTA provisioning of apps through a separate app itself. Here’s how the accomplish this magic:

  1. APK files are downloaded over the network and stored on the Android device’s filesystem
  2. they are then installed on the Linux machine from the filesystem (using “adb install” command).

However, the client application to do this provisioning must first be loaded on to the device! So, there’s the chicken and the egg problem. Without getting the provisioning client on the device in the first place, you won’t be able to get OTA provisioning 🙂 .

Here are some examples of what’s out there today:

  1. Slideme client and server software – we can use this to host our own app/widget update center for Sonar.
  2. Slideme marketplace – this marketplace is open for 3rd parties to deploy android apps on (assuming the client device has slideme installed).
  3. Trackdroid – similar to slideme marketplace.

You can use the Slideme software and host your own library of apps on your server. Slideme marketplace is a publicly accessible server that they host which provides access to lots of 3rd party apps.

Loading your apps from HTTP

This solution also faces the same problem as the previous one – you must load the client app to make this happen on the device, before you can provision apps OTA. HttpDownloader is an APK file that you can install on your device that will allow other APK files to be downloaded from HTTP.