My previous Gingerbread-related post painted a grim picture of the progress I had been making up to that point. Little work had been done on stabilizing the system. Lots of features and hardware support were broken. In general, there was a ton of work to do.
Well, that work is getting done. Slowly, I’ve been working through the long list of issues and knocking out whatever I can in reasonably short time. We’re moving towards a completely unsupported prerelease system image meant for testing, probably within the next couple of weeks. Again, that would be completely unsupported and not an official release. We would not advertise it on any official release channels (wiki or forums).
With that out of the way, here’s a list of major fixes since my last post:
The severe drop in 2D performance has been fixed
The SD card is now visible within Android again
Screen backlight issues that I posted about are actually kernel-related auto-backlight issues on Raph/Diam/Blac only
Gingerbread’s strange sleep of death has been resolved
UPDATE: Audio is working
For developers: build system changes have been pushed to the repositories to allow you to build the system (gapps needs to be updated to generate working system images, though)
Due to a request by developers, I’ve started building up mailing list infrastructure for the project. Initially, we will have just one list, xdandroid-dev, to be used exclusively for development discussion. This discussion will include chatter regarding bug fixes, new features, and other proposed changes. The xdandroid-dev mailing list will likely have small, experimental code changes posted (in the form of source patches) and will provide a live look at development, along with the IRC channel.
Technically-abled users are encouraged to join development discussion on this list. Posting to the list is limited to members only, however membership is open and users can register with no administrative approval. If you are interested in observing or joining development discussion, please subscribe to the list. The XDAndroid Project has a big shortage of Android developers and we’re looking for all the help we can get!
It’s been very slow around here lately. Being busy with work and holidays hurts productivity. However, I’m starting to get back into the groove.
Gingerbread is proving to be a beast to port. A lot has changed from Froyo and we’ll be left making square pegs fit in round holes. As usual, all old platforms have been abandoned, except for the venerable Nexus One of course. This makes it somewhat annoying to get all the older hardware working as it did in older versions.
Here’s an incomplete list of things which have broken in the upgrade to Gingerbread:
Severe drop in 2D graphics performance (a fix is in progress, pending testing and commit to our frameworks/base fork)
Existing sensors library is incompatible, so the accelerometer is not working
Location services crash the system during initialization (bootloop); additionally, removing Location provider causes Browser to crash at Google home page
Trying to activate bluetooth crashes the system
SD card is not visible (as mounted) in Android
Screen backlight stays on when it should sleep (display turns black)
Device hangs in sleep mode
There are other issues here and there that aren’t important or difficult enough to list here, or that I haven’t found yet. Also important to note is that I’ve been testing exclusively on a Raphael (ATT Fuze) so any issues with other platforms (Rhodium in particular) may not be found by me.
I’ll be working actively on these issues in the immediate future. Needless to say, the Gingerbread release is probably a long way off. There is a lot of work to be done, and unfortunately Gingerbread is mostly a solo effort by myself at the moment. If you’d like to help out, or if you know someone who can help, please drop by our IRC channel and join the development discussion. We need all the help we can get.
As I’ve mentioned before, development on porting the newest version of Android to our devices is underway. Last night was release day, so the work that I did was all on getting the build environment ready. Now that I’m able to build images, we now have to worry about bring-up on the actual hardware.
There are still some changes left to be pushed into the XDAndroid AOSP repositories, but most of the codebase that I’m using is already there. With every new version of Android, we need rootfs changes to add support, so that’s the next bit of code that has to be pushed (and it’s mostly completed now, waiting for me to push).
Today, I was able to get the system booted and semi-usable. After merging upstream configuration changes into the rootfs, the system entered boot animation without a hitch. Unfortunately the current version of Google Apps has one incompatible package (the Network Location provider) which caused a “bootloop”. After removing that package, it resolved the crash and the system booted normally.
There’s still no ETA on a release, of course, since a lot of work has to be done to get everything going. In short testing, I found that WiFi is no longer functional, the window manager is very slow, and as mentioned before the Google package has to be updated. There will also be a number of (expected) crashes involved with certain hardware functions, due to changes in software interfaces between the releases.
So, now that we have a running system, how about some pictures?
As the XDAndroid Twitter account has eluded to a short time ago, we have indeed begun official development on the new version of Android for our devices, gingerbread.
As development progresses, I will be updating the issues, successes and planning we have to do to get gingerbread running on our devices. Keep watching for new posts. Don’t forget, release announcements will always be made via the xda-developers forums and twitter. Thanks for using XDAndroid!
Hello XDAndroid users! Been a while… but we have another release for you! Build FRX03 is now available hot off the grill. We’re changing things up a bit this time around: we have released both a traditional system image, as well as a small OTA update file (as discussed on here previously).
The recommended method is the OTA update.zip. However, for users who don’t have a completely original FRX02 to upgrade from, the system.ext2 file will be necessary.
Here’s a list of changes in the new build:
Disable slow background blurring for some dialogs (thanks emwe)
Internal improvements to auto-backlight implementation (emwe)
Disable JIT by default for various stability improvements
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:
An OTA update package (update.zip) is downloaded from XDAndroid’s servers
The update.zip file is copied (NOT extracted) to whichever directory your startup.txt file is in (ie. /sdcard/andboot)
The user boots HaRET and enters Linux
The rootfs finds that update.zip and starts updating the device
The updater completes (hopefully!) and reboots the device (into Windows Mobile)
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…
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.
This is old news for most users by now, but the XDAndroid project now has a bug tracking system. It’s a standard Bugzilla installation, so it will likely be familiar to many users.
This was done to facilitate better bug reporting by our faithful users, of course. However, it also is meant to help developers (me) keep track of what must be done for the next release.
Another nice side effect of the bug tracker is that it makes the developers’ work more transparent. Users can now see progress made on bugs in a more verbose manner (aside from the IRC channel). And for when we get close to a release, they can check up on bugs that are scheduled to be fixed in that release — and possibly help fix them or test their fixes. For instance, users can search for bugs that will be fixed in FRX02. Closer to release, we’ll have a release engineering bug which depends on all of those being fixed (for easier search accessibility).
So if you come across any issues in XDAndroid, check out the tracker. If you don’t see your bug there, open an account (we don’t spam!) and let us know about it. This tracker takes care of both the kernel and the Android filesystem images.
The XDAndroid Project is pleased to announce the first stable release of XDAndroid 2.2 (Android Froyo). This build is a significant milestone in the project. This is an important release of the system image component, which is just one piece of the bundles we release occasionally. Incremental releases of the other components will continue normally. Read on for a full, somewhat technical, list of important changes in this build.
