The XDAndroid project had been using the #htc-linux channel on the freenode IRC network to collaborate development. Inadvertently, our Android-related discussion there had been stepping on some toes. That channel is used for kernel development and many of the regulars don’t wish to have Android discussion there to deter from lower-level work being completed. To solve this problem, we’ve created our own channel, also on freenode: #xdandroid. For those of you who have visited or frequented #htc-linux with us, please check out the new channel. We’ll be having all XDAndroid IRC discussion on there from now on. It’s just getting started now, but we plan to have some nice features in there to help collaboration. Thanks!
(Note: We’ll have a web-based client available on the wiki soon.)
It’s time to introduce yet another XDAndroid service: the official XDAndroid wiki. This work-in-progress wiki has lots of useful information already. The Wiki will hopefully serve as the documentation hub for the project. Currently, the wiki can only be edited by developers. Ultimately, my goal for the wiki is to have it get users very involved in the development process. It’s a bit of a cathedral right now, instead of a bazaar. In time, I hope to get it to a point where users can contribute and developers (or trusted editors) can moderate effectively. Please leave some feedback on the wiki, its layout and the documentation. We really need to know how useful it is for users and how we can make it better!
On a related note, the guy who gave us the domain (and a year’s registration!), sd73ta on XDA, also included a Google Apps standard edition account. So all of the developers will eventually have @xdandroid.com email addresses if they so wish. Thanks a lot, sd73ta!
Just a quick update… phhusson has managed to get GPS working on most of our devices now. He has already released a working library for Rhodium, which has been integrated into the latest rootfs. Work will be done to build a library for our other devices (ie. Raphael and Diamond) soon. Keep an eye on the XDANDROID twitter account to see when that hits rootfs. Thanks phhusson!
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:
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…
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!
By request, the XDANDROID project now has a twitter identity. If you follow XDANDROID on twitter, you’ll get the latest updates to rootfs and initramfs builds as they happen. The tweets for those two services will include a link to download and a link to the commit log. I’m also trying out twitterfeed for kernel updates, so we’ll see how that goes.
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.
One of the ongoing goals of the XDANDROID project has been to build an entire system from the Android open-source project. This is a relatively simple task on its own: you check out the tree, configure it quickly (or just let the build system choose the generic defaults), and `make` it. Of course, with a generic build, there will be many pieces of hardware (and some software) left unsupported by the resulting images. For XDANDROID, we’d like to have a fully (or at least mostly) functional set of images as a result of a simple `make` command, after the obligatory configuration. With some recent work that I’ve pushed into a few new source repositories on gitorious, we hope to be on our way to achieving this goal. Read on to see what we’ve got and how to use it.
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.
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!