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…
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.
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.
That’s right, the XDAndroid system is no more… after you select Power Off from the power menu. With phhusson’s help, we found a magic switch that powers off the device. This is currently not well tested, but has worked for me on a RAPH110 (AT&T Fuze). We’ve had varying reports of success. In one incident, I had the device turn on automatically a couple hours after shutdown, so we still have to look at the shutdown procedure.
(To my followers freaking out about The XDAndroid Project “shutting down”, I sincerely apologize for the title of this post, but it’s too good to pass up.)
In other news, one of the fine folks over at the PPCGeeks forum discovered something interesting regarding battery life on our devices. Apparently some of the Touch Pro2 chargers have a little LED in the transformer block which indicates a connection to the device. Interestingly, when the poster left the charger plugged into his device and removed it from the power outlet, the LED stayed lit. This suggested that there was power being drawn by the USB port, even when nothing was connected to it.
After a lot of mucking around with debug interfaces (which led to the power down thing from above being discovered), we finally tracked it down to the HTC Headset support (internally named HTC 2 Wire or H2W). After disabling the driver, the port was no longer active. In my internal testing, I found there was likely a small gain in battery life with the port disabled. Unfortunately, it seems like this difference isn’t very big as I was still able to burn through about 40% of the battery (in WinMo measurement) after under 7 hours.
We’re still tinkering with some battery related things, and trying to get a better understanding of what certain parts of the system do. Hopefully we’ll stumble across something useful like we did with the shutdown switch.
Another week, another Froyo update. Before I begin: if you’ve been building systems, we now have updated build documentation on the XDAndroid wiki for the froyo branch. Check it out!
Work on Froyo has continued to progress rapidly. The bugs are starting to dwindle and I’m beginning to work on features more and more.
GSM users will be happy to hear that I’ve finally integrated the Access Point Names (APNs) list correctly, and it will be installed with babijoee’s next system release. CDMA users shouldn’t feel left out either, since with the help of hamagc on IRC, I was also able to add the CDMA generic APN again. The vast majority of providers should have settings that work out of the box from now on.
Many users reported shortcomings in the on-screen keyboard. Touch sensitivity is still a bit off (and I don’t see that changing — these screens are pretty small), but I was able to pull some autocomplete dictionaries out of cyanogenmod’s source tree. The dictionaries make the keyboard much more useful, of course. This will also be in babijoee’s next build.
Finally, by popular demand I have re-enabled the touch-friendly incoming call screen. This screen is similar to the unlock screen when you turn the device back on: it offers two pull switches to answer or reject an incoming call. The touch-friendly screen displayed during an accepted (or dialed) call, however, is still disabled. The layout is buggy on VGA phones.
I’ve begun investigating the possibility of issuing over-the-air updates for XDAndroid systems. Building OTA update packages is easy, thanks to the Android build system. The difficult parts are integrating an update mechanism into our rootfs, and developing infrastructure for Android’s checkin service to contact and check for or receive updates. This would be a pretty neat feature down the road.
