XDAOSP Project Progress (and teaser photos)

Riding the thunder of Cyanogen’s 5.0.7 announcement, I’ve made some great progress with XDANDROID for our devices. Much of this progress comes from cyanogen’s great work, enabling the Nexus-targetted applications to run on other hardware. Note that for all of this work, I’ve cherry picked cyanogen’s changes in hopes of keeping XDANDROID as close to upstream AOSP as possible. We can worry about feature releases later.

First of all, Gallery3D is now fully functional. In fact, I had gotten it to run before, but it would crash on rotation, sucking the GPU’s memory dry. A simple fix from cyanogen has alleviated that problem. Our XDANDROID fork brings his work to our releases. Here’s a look:

Gallery3D running on XDANDROID

Next up, we have some work with Live Wallpapers, also as seen on Nexus. These are a little more difficult to deal with. Most of them use complex RenderScripts, resulting in a lot of GPU memory hogging. This, in turn, leads to out-of-memory errors and Android system crashes. Unfortunately, I have not yet managed to get these working reliably with hardware 3D rendering. I’ve gotten the Grass wallpaper to run for a short time (2 seconds) before crashing. However, they do run as expected (but slowly) with software rendering, which is good progress. Here’s a look at the Nexus live wallpaper…

Nexus Live Wallpaper on XDANDROID

To get that working at all, I needed to change the base Android framework. The Live Wallpapers use a library called RenderScript, which does the heavy graphical lifting. In upstream AOSP, RenderScript expects an OpenGLES-2.0 capable GPU to be available. Our devices don’t have that luxury, so we have to make it happy with what we’ve got. That means not only letting it render with OpenGLES-1 hardware, but conforming to the GPU’s additional requirements because of that. Luckily, cyanogen made it as easy as flipping a couple of switches in the product config (vendor/xdandroid/msm/BoardConfig.mk).

All of this work is going to be committed (or already has) to gitorious. I still have some more work to do, primarily concerning the Live Wallpapers, then adding a buildspec.mk switch to enable those apps over the default ones. I’m also going to try my hand at getting Launcher2 working, but that could be quite tedious as it’s currently hard-coded to WVGA devices.

If you’re following XDAOSP Eclair development, see the project wiki for updates on how to enable those apps. Thanks for reading!

Quickie: XDANDROID Repository Documentation, Plus…

Just a quick post today… The XDANDROID Eclair repositories on gitorious are working pretty well for me. In hopes of getting other people into the build process, I’ve taken the time to do some documentation on how to build XDANDROID from source. Updated information is available on the XDANDROID gitorious wiki. This information will continually be updated as development commences and options or procedures change.

And now for a free preview teaser. At phhusson’s request(s), I’ve started initial development of a user-oriented XDANDROID kitchen (for Linux only at the moment). In the future, this may allow us to build an online kitchen similar to MoDaCo’s. Stay tuned for development of that kitchen. Current prerelease version (with no documentation) is available at my files repository.

XDANDROID Kitchen Screenshot

XDANDROID Eclair WiFi Tethering

Most of the devices supported by XDANDROID have had both WiFi and 3G working for a while now. In Windows Mobile, there are third party programs that allow you to bridge the 3G connection to an ad-hoc WiFi connection, providing a wireless tether for a notebook computer. After some work last night, I’ve been able to whip up a solution for WiFi-based tethering for Android on our handsets, complete with a friendly GUI. Read on to see what you’ll need to do for this to work on your XDANDROID phone.

Continue reading “XDANDROID Eclair WiFi Tethering”

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!

Another Eclair Build Service: initramfs

That’s right, we have yet another automated method of breaking Android on your WinMo phones! In the same spirit as the rootfs build service, we’ve got the nice, new initramfs build service. See the original post about why we needed the rootfs build service for the exact same reasons behind this build service.

Continue reading “Another Eclair Build Service: initramfs”

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.