CM: chromium doesn’t build with JDK 1.7

If you build Android or CyanogenMod and you run into issues with HashSet_jni.h you need the following changes to the chromium_org project:

diff --git a/base/android/jni_generator/ b/base/android/jni_generator/
index de865d5..d4a2324 100755
--- a/base/android/jni_generator/
+++ b/base/android/jni_generator/
@@ -555,18 +555,21 @@ class JNIFromJavaSource(object):
return JNIFromJavaSource(contents, fully_qualified_class)

+def MultipleReplace(string, rep_dict):
+ pattern = re.compile("|".join([re.escape(k) for k in rep_dict.keys()]), re.M)
+ return pattern.sub(lambda x: rep_dict[], string)

class InlHeaderFileGenerator(object):
"""Generates an inline header file for JNI integration."""

def __init__(self, namespace, fully_qualified_class, natives,
- self.namespace = namespace
- self.fully_qualified_class = fully_qualified_class
+ self.namespace = MultipleReplace(namespace, {'':''})
+ self.fully_qualified_class = MultipleReplace(fully_qualified_class, {'':''})
self.class_name = self.fully_qualified_class.split('/')[-1]
self.natives = natives
self.called_by_natives = called_by_natives
- self.header_guard = fully_qualified_class.replace('/', '_') + '_JNI'
+ self.header_guard = MultipleReplace(fully_qualified_class, {'/':'_', '':''}) + '_JNI'

def GetContent(self):
"""Returns the content of the JNI binding file."""

In addition I needed to fix LinkNode in the Gallery app.

CyanogenMod 9 for HTC Wildfire S (ALPHA3)

Maybe you already know that I worked since January 2012 on porting CM9 to the HTC Wildfire S (Marvel). It took quite a while to figure out how Android is working and how to get the the OS correctly talking with the hardware. Today I’ve released ALPHA3 of my work which is a pretty stable version. The Wildfire S is not a supported Android 4.0 device, so you have to workaround a lot of things and use old binary blobs. This also means there will probably never be an official CM9 release for the Wildfire S. However most of the stuff is working pretty well and you can live with the known bugs.

Known bugs:

  • Camera isn’t fully working, you can take pictures without problems.
  • OMX codecs aren’t fully working cause they are too old. We asked Quallcom to release new OMX codecs for ARMv6 but they said it will not be possible to get it working with QDSP5.
  • The device reboots if you turn blootooth on sometimes and bluetooth drains the battery.

You can download ALPHA3 of the ROM here.

Have fun.

CM9 (Android 4.0 ICS) and deep sleep

I’ve had the problem that the device didn’t want to switch into deep sleep mode if radio was on. What is deep sleep? To make it simple we break it down. Your device has 3 modes. The fisrst is “Screen On and Awake”, “Awake” and “Deep Sleep”. If you use your device it you’re in the first mode and you need a obviously a lot of battery. The second “Awake” means it is doing some background work. Checking for calls, checking Emails, syncing contacts. The last one means it goes for some time into a mode were it uses almost no battery, and this is Deep Sleep. If you don’t do anything and your phone is in your pocket you want that it is in the Deep Sleep mode most of the time.

My HTC Wildfire S didn’t want to go into the “Deep Sleep” mode at all if radio was turned on. It worked with Airplane mode. I thought this has something todo with RIL but I was wrong. Actually it was a bluetooth wakelock. The wakelock “msm_serial_hs_dma” was held all the time. The problem is that the msm7227 platform doesn’t supports quick switch-on/off of the bluetooth module and you need to deactivate it with an overlay else ICS always tries to trigger it.

So adding

<bool name="config_bluetooth_adapter_quick_switch">false</bool>

to overlay/frameworks/base/core/res/res/values/config.xml fixed the problem and the wakelock was gone. and segfaults

If you try to get a new Android version, in this case CyanogenMod9, working on your old phone you have to deal with binary blobs. One of these blobs is the library talking to the radio,

I wanted to document what I learned about I’ve wanted to get the library version matching my baseband version working with cm9. This resulted it several segfaults. So I’ve started to strace the rild process to find what’s going wrong, which permissions are missing etc. The library doesn’t check return values so it segfaults. One of these segfaults was a missing kernel interface called usb_function_switch. The file should be in /sys/devices/platform/msm_hsusb/usb_function_switch. I’ve implemented that function in the kernel and it still segfaulted and I had no idea what to do now. Today I analyzed the RADIO logs and stumpled upon:

D/RILJ    (  328): [0100]> SCREEN_STATE: false
D/HTC_RIL ( 1360): ril_func_screen_state_notified():called
D/HTC_RIL ( 1360): ril_func_screen_state_notified():Not found 'ether:' in USB_STATE_PATH

As it segfaulted directly after closing /sys/devices/platform/msm_hsusb/usb_function_switch it smelled like it expeced to have something like:


I’ve dived into the code and found out that in my kernel tree it was called rndis and in the htc kernel tree it was called ether. So I’ve fixed that and added the other values of /sys/devices/platform/msm_hsusb/usb_function_switch it started to work just fine. I hope this post will help other developers with similar problems.

This is the full set of the usb_function_switch: