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

XDAndroid 2.2.1 Build FRX02

In case you’ve missed it, the XDAndroid Project today released its newest Froyo series build, FRX02. This is the second of our official releases to have a build number. We’ve got some really nice bug fixes, improvements and features for you this time.

Here’s an abbreviated list of changes since FRX01:

  • The following bugs were fixed:
    • 2 – Talk.apk missing
    • 4 – Buttons cut off in the open call menu.
    • 14 – Startup.txt file is incorrect
    • 20 – OpenWnn IME selected by default
  • Google Apps updated to 20101020.1
  • Transitioned to hdpi graphics and fonts
  • Ambient light sensor and hardware auto brightness for RAPH and RHOD (WisTilt2)
  • Debug output for battery service emergency shutdowns (by request of camro)
  • Data roaming off by default (can be dangerous for international users) (emwe)
  • armv6j instruction support from cyanogenmod

I love the light sensor support that WisTilt2 came up with. Give him lots of thanks (and donations!) for the great work.

Check out the release from your preferred thread on XDA-Developers (I like the official Raphael thread myself) and give us some feedback on IRC or file some bugs! Thanks again for using XDAndroid!

Important XDAndroid Button Changes for Touch Pro/Diamond

For a long time, Raphael and Diamond users have had an… interesting button configuration, to put it nicely. New users had to learn how to ignore the labels on the buttons in order to effectively use their device.

With recent changes in the kernel to provide a different keycode for the Power button, I’ve had to reconfigure the HTC Fuze (RAPH110) layout to fix that button. At the same time, I decided it’s convenient to remap all the Raphael and Diamond buttons to their intuitive functions.

As of the next rootfs release, the device buttons will be performing the following functions…

Device Key    |   Android Function
Power             Enter and exit sleep mode
Home              Go to home screen (long press, Recent Apps)
Back              Back (same as before)
DPad Center       Menu
Start Call        Dialer (same as before)
End Call          End call (same as before - configurable in Spare Parts)

This is only for Touch Pro and Touch Diamond users. Please see our tracking bug for the development discussion that led to this change.