Moving Towards Over-the-Air Updates

The XDAndroid Project currently distributes system updates as compressed, whole filesystem images which the users then unpack onto their SD cards, replacing the originals. This is done for the rootfs, initramfs and system images. Additionally, the project distributes updated versions of the (re)bootloader (HaRET) configuration files and the Linux kernel used to boot into Android.

By far the largest individual piece is the system image (system.ext2). This image typically runs around 60-70MB compressed. Updating in this fashion is not a terrible inconvenience for most users, however the files are large, require tedious uploading by the packagers (and more waiting time for the users) and suck up tons of bandwidth. This is problematic for the servers that host the images, the packagers that upload the images, and the users that download the images (particularly those downloading over the cellular network directly).

To alleviate this, I have been considering (for some time now) rolling over-the-air update packages in the same style as official Android updates from Google. These packages are zip files, signed by and authenticated as originating from the XDAndroid project. The zip files contain a series of binary patches used to update from an old build to a new build without replacing the entire system image.

Over-the-Air (OTA) update packages are useful for a number of reasons: 1. they’re much, much smaller than full filesystem images (24MB for the FRX01 to FRX02 OTA update file); 2. they’re guaranteed authentic (our installer only handles packages signed by the project); 3. they cost less for the project to distribute and the users to receive, in both data and storage space; etc. The only problem? We have no bootloader, which is what traditionally invokes the update process on a native Android device.

Well, problem solved. In the latest rootfs at the time of writing this, I have added over-the-air update support. Since we have no true bootloader, we rely on the rootfs to act as such. In a way, this works out to be a bit easier, since our rootfs has an entire embedded Linux environment to work with. All we need to do is check for an package and invoke the updater. Piece of cake!

From a user’s standpoint, the update process is done like so:

  1. An OTA update package ( is downloaded from XDAndroid’s servers
  2. The file is copied (NOT extracted) to whichever directory your startup.txt file is in (ie. /sdcard/andboot)
  3. The user boots HaRET and enters Linux
  4. The rootfs finds that and starts updating the device
  5. The updater completes (hopefully!) and reboots the device (into Windows Mobile)
  6. The user boots HaRET again and the device boots to the updated Android system.

Ultimately, this new OTA update support will eventually allow us to roll an Android program that will download these updates (and perhaps also kernels and rootfs and initramfs images) and place them on the SD card automatically. Until that’s ready, though, it’s just a matter of the user putting it on the card as Still no more difficult than a system.ext2 replacement, while being much less taxing on our Internet pipes.

So there you have it: a nice, verbose description of a neat little new feature. We look forward to (probably) distributing FRX03 as an OTA update package (as well as a system.ext2 for those of you who like to do that). And finally, since I know everybody wants to see some proof, here’s a screenshot of the updater in action on a my RAPH110/ATT Fuze…

The XDAndroid Updater in action