Tag: rootfs

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 update.zip 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 (update.zip) is downloaded from XDAndroid’s servers
  2. The update.zip 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 update.zip 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 update.zip. 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

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.

Small Eclair rootfs Update

Last week, phhusson modified the rootfs init scripts for eclair (and eclairhero) to load the RIL library (libhtcgeneric-ril) from rootfs instead of what is packed in system.sqsh. This solves a minor problem with updating the RIL: there would have to be a new system.sqsh for each RIL update. That’s a problem for users, developers and servers alike. Users would have to spend time and bandwidth downloading a whole new Android bundle for a change to one little library. Developers would have to spend time repacking system.sqsh for that one little change and uploading it to the disto server. The server would spend tons and tons (and I mean tons… upwards of 75GB in the first 24 hours of release) of bandwidth hosting that new bundle.

I’ve started up a build service for libhtcgeneric-ril which occurs entirely on a backend. This means that the products of the build service aren’t directly accessible to users like the rootfs and initramfs builds are. Instead, this one builds a new libhtcgeneric-ril, commits and pushes it to the eclair-rootfs repo, and then the rootfs build service will eventually spit out a new build with the updated libhtcgeneric-ril. End-users can download the roughly-6MB file from the build service and update just the rootfs for the RIL changes.

There’s no fancy frontend or snazzy filesystem images for this one, sorry. You can check out the libhtcgeneric-ril repository on Gitorious, though. Thanks for reading!

XDANDROID Eclair, now with Bluetooth

Today I pushed a commit to enable bluetooth in the Eclair rootfs repository. The build service has already assembled an image, so you can grab it and give it a shot. This currently only works for devices with Texas Instruments bluetooth, such as Raphael and Diamond. It does not yet work with Rhodium, which uses a Broadcom chipset.

The commit was a simple few-liner to the Eclair init.rc to add an Android service which handles pairing and connecting to other Bluetooth devices. The Bluetooth chip in the phone was working already (and enabled in Donut), so it was just the Android userspace service which was missing.

As it is now, the bluetooth device appears to inhibit deep sleep for the phone, which in turn causes noticeable power drain. This will be something to take a look at down the road to see if deep sleep can be enabled with bluetooth on. It’s probably a low-priority issue at this point, since bluetooth is not essential, and users who do wish to use it can enable and disable it manually.

Eclair rootfs Build Service Moved (to subdomain)

Just a quick update: the XDANDROID Eclair rootfs Build Service has moved to a subdomain on the same server. It’s a better solution than sticking it in a userdir. Previous links will be redirected to the new location, so you don’t need to do anything.

Also, for the record: I cannot guarantee that the oldest builds in that list will remain for any specific amount of time. As the server continues to build from the git repository, those images will pile up and I’ll probably have to clean some out eventually.

As one final aside, I’d like to plug the VPS provider I use to run this build service (and all the other services the machine hosts): Linode. It’s a very popular and extremely high-quality host. The prices are reasonable, the staff are friendly and almost always available, and they have near-perfect reliability. If you need a host and one of their datacenters (Fremont, Dallas, Atlanta, New Jersey, or London) is a good location for you, check them out.

Thanks.