Month: January 2010

Not much in terms of actual breakthroughs today, except for one gem.

chamonix (Sven) on XDA was able to get cellular geolocation working in Android today. This occurs via a request to the radio firmware by a piece of Android software known as the RIL (radio interface library). It was another simple fix, but finding the cause of such a problem is like looking for a needle in a haystack. It ultimately came down to being a bug in the Android reference RIL (written by Android developers as a base for manufacturers to use when porting to a new device). The reference RIL was using decimal values where it should have used hex values in the radio request for geolocation. Oops. chamonix found the simple two-liner fix and it works flawlessly now.

Of minor note, I’ve begun testing the htc-msm-2.6.27 kernel branch with NO_HZ on. This is a low-level change (referred to as a tickless system in peoplespeak). It allows the kernel to fire interrupts as needed, not during a set schedule (say, 100 times per second, which our non-tickless kernel does). As a result, the system can spend more time doing nothing, enabling more power efficiency through the idle sleep mode while the phone is on but inactive. It’s not a huge power saver (yet), but Android’s default kernel config suggests that NO_HZ be activated where possible.

The NO_HZ option was deactivated in previous builds due to a serious clock skew problem while the phone was idle. Since we now have idle (and deep) sleep working, hopefully this will no longer be an issue, since the phone may be in idle sleep (saving and restoring timer values) instead of just sitting there with no timer firing.

If NO_HZ works out, the next step in power savings is to disable vsync on the display. Currently, the display fires an interrupt for each frame. It runs at 60Hz, so that’s (up to, in theory) 60 wakeups per second with the display on. In reality it won’t be that many, since the display will change (for animations or redrawing the clock or whatever), but still significant while the phone is on. It won’t be easy, though, since nobody really knows how to make it happen yet.

As usual, babijoee has posted updated images with the latest changes on the port project thread.

phhusson has done more work attempting to get the camera going, even bringing a newer (I believe 2.6.31) V4L stack back into the 2.6.27 branch. No success yet, but he’s probably getting close. Hopefully sleeping on it can help him out.

I was able to map the push-to-talk button found on Fuze in the kernel. phhusson committed it for me. I’ve mapped it to the camera keycode in Android.

I also fixed the keyboard arrow keys. For some background, the Fuze/Raphael has a directional pad (DPAD) on the front of the device, as well as arrow keys on its slide-out keyboard. They both use the same scan codes (what the kernel spits out as input events). When Android rotates the screen (which happens when opening the keyboard or tilting the phone) it also rotates the directional pad controls (so up and down become left and right, since the user is now holding the phone sideways). Unfortunately, Android does not also rotate the arrow keys, so they are never correct from a user’s perspective (up and down will go left and right in the user interface, respectively).

To fix this, I had to use a hack with Android key layout files, which translated kernel scan codes to Android key codes (usually placed in /system/usr/keylayout/*.kl). Previously we were using a single keylayout file for the various input devices on the phone (the capacitive front-face buttons are one device, the power button itself is another device, and the keyboard and volume controls are a third device).

I separated the keylayout file into two files: one for the keyboard/volume controls and another for everything else. In doing so, I was able to define a standard set of keycodes for the DPAD, which still rotates automatically in Android. For the keyboard, I defined the arrow keys as pre-rotated arrow keys. Normally this would be a problem because while the phone is not rotated, those keys are all wrong. But the user will never have access to the keyboard unless the phone is rotated (remember, the keyboard slides out, which Android responds to by rotating the screen).

This acted exactly the way I was hoping it would (which doesn’t happen much for me with Android internals). babijoee is updating the thread with the new bundle. We’re getting a lot of little details fixed up, and I’m very excited to see how polished it’s getting.

In the future, babijoee might try to get Android 2.1 Flan (as seen on Nexus One) going on our devices, but there’s so much graphical stuff going on that it’ll definitely need some help with acceleration. Acceleration is one of the few major things left on the to-do list.

XDA-Developers has an ongoing project to port Android to a number of HTC-manufactured Windows Mobile phones, including my own HTC Fuze (the AT&T version of HTC Touch Pro). The project has been incredibly successful, due to the phones having very similar hardware to a lot of the HTC Android phones.

Recently, I’ve been getting a little involved with the Android 2.0 (Eclair) port to these devices. With help from the developers in that community, I’ve been able to make a couple small contributions. My usefulness is mainly due to me having lots of Linux experience, a tiny bit of Android experience, a strong programming background, and most importantly, an HTC Fuze, being one of the few American guys there.

Anyway, I’ve been able to help the port get stable deep sleep working in the kernel (which gives Android much more useful battery life on the devices), working outbound texting (SMS) on North American providers (by providing logs to the smart guy), and a Fuze-specific keyboard layout for Android.

We’re still not done yet, though. The following are not yet working in Android (probably in order of importance for daily consumption):

• Camera – work has been done, but internal testing is ongoing before public (binary) release. The hangup is now mostly in userspace
• Bluetooth – this shouldn’t be too bad to get working, but it’s been low priority
• GPS – I don’t know of any recent progress with this yet. It’s some time down the road.
• Accelerated Graphics – I have no idea what progress has been made on this. This would be nice to have, but obviously is not integral to the system (Android works great now even without it)

…Among some low-level system things to work out.

Most of what isn’t mentioned is working. This includes phone calls (most important for a phone), texting, mobile data and 3G, etc. Testing the port is of utmost importance. There are many users interested in the project, but not lots of people with the experience required to directly contribute. Concise reports detailing exactly what went wrong and under which circumstances is very useful to the developers.

A lot of the work on this port is being done by phhusson and babijoee on XDA-developers. Please donate to them as you see fit. Also, please provide feedback to any or all of us via the thread or on freenode IRC in #xdandroid.

Obviously, I’m very interested in feedback about the Fuze keyboard layout. I appreciate bug reports, success reports, and improvement suggestions. Thanks.

[1] XDA-Devs port thread: http://forum.xda-developers.com/showthread.php?t=601751

[2] Freenode IRC #htc-linux: irc://irc.freenode.net/xdandroid