Updating The Sun JDK On Debian

The final version of sun-jdk-6 in Debian Wheezy before it was removed was 6u26. The latest from Oracle (excluding Java7) is 6u30, so I decided to manually install it myself.

In fact it couldn’t be easier, all you do is download the jdk-6u30-linux-x64.bin file and run it, which extracts it to a directory called jdk1.6.0_30, which you then rename to java-6-sun-1.6.0_30 and move to /usr/lib/jvm, you then delete the java-6-sun symlink and recreate it to point to the newer directory:

root@localhost:/usr/lib/jvm$ ln -s java-6-sun-1.6.0_30 java-6-sun

As alternatives is setup to point to /usr/lib/jvm/java-6-sun there’s no need to update anything for the files we need to build Android for example:

root@localhost:/usr/lib/jvm$ update-alternatives --get-selections | grep java
...
appletviewer                   auto     /usr/lib/jvm/java-6-sun/bin/appletviewer
firefox-javaplugin.so          auto     /usr/lib/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so
java                           manual   /usr/lib/jvm/java-6-sun/jre/bin/java
javac                          auto     /usr/lib/jvm/java-6-sun/bin/javac
javadoc                        auto     /usr/lib/jvm/java-6-sun/bin/javadoc
javah                          auto     /usr/lib/jvm/java-6-sun/bin/javah

jar seems to have been replaced by fastjar on Debian, so there’s no need to link the Oracle version in /usr/lib/jvm/java-6-sun/bin/jar

Finally its a good idea to add this environment variable in ~/.bashrc – again pointing to the symlink, not the specific version:

export JAVA_HOME="/usr/lib/jvm/java-6-sun"

Apparently Cyanogenmod7 will compile using OpenJDK6 (and 7 with a patch) even though AOSP won’t compile with anything other than Sun JDK6.

I’ve also updated the blog to WordPress 3.3

What A Recovery

I’ve been playing with compiling Cyanogenmod7′s fork of Koush’s ClockWorkMod Recovery 3.0.2.7

The github source is here and of course Gerrit for the latest code under review.

First you compile CM7 for your target platform as usual. This is needed to create some supporting libraries and the actual recovery.img file, including the kernel for your phone of course:

. build/envsetup.sh && brunch blade

Then you create the signed flashable zip:

TARGET_PRODUCT=cyanogen_blade make recoveryzip

That results in out/target/product/blade/utilities/update.zip

You can also set the product to zte_blade but because it will differ from the CM7 build target, it will recompile a lot of stuff, but it still works just fine (in fact that’s what I have installed).

ROMManager still reports the version as 3.0.2.7, but when you boot into recovery it shows as “CWM-based recovery 4.0.1.4″. It seems to be faster doing backups than Koush’s version as it doesn’t output verbose messages and progressbars.

Update: just noticed the zip isn’t actually suitable for a first-time recovery install, its only an update to replace a stock recovery or an earlier clockworkmod. the recovery.img file is is fine though – it includes the kernel and formats the /recovery partition.

Building An Android Kernel

As I’ve been compiling Cyanogenmod for the ZTE Blade, I thought I’d have a look at compiling the kernel instead of applying binary patches. I found this tutorial which kind of helped, here’s my simplified summary:

1. Pull kernel source from Github (currently weighs in at 1.7Gb):

git clone git://github.com/TomGiordano/kernel_zte_blade.git

2. Get the .config file – most tutorials say to get this from your phone which is running the kernel that you want to compile, but actually its already stored in git:

cp ~/kernel_zte_blade/arch/arm/configs/cyanogen_blade_defconfig ~/kernel_zte_blade/.config

3. Build the kernel:

make ARCH=arm CROSS_COMPILE=~/cyanogenmod/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

4. Build CM7 as usual, and to make things easier we’re going to copy a few files all into the same directory, including the split_bootimg.pl we downloaded:

mkdir ~/custom_kernel
cd ~/custom_kernel/
 
cp ~/split_bootimg.pl .
cp ~/kernel_zte_blade/arch/arm/boot/zImage .
cp ~/cyanogenmod/out/host/linux-x86/bin/mkbootimg .
cp ~/cyanogenmod/out/target/product/blade/update-cm-7.1.0-RC1-Blade-KANG-signed.zip .
cp ~/cyanogenmod/out/host/linux-x86/framework/signapk.jar .
cp ~/cyanogenmod/build/target/product/security/testkey.* .
 
unzip update-cm-7.1.0-RC1-Blade-KANG-signed.zip

6. Unzipping the KANG has given us the META-INF and system directories and boot.img file, which we must now unpack:

./split_bootimg.pl boot.img

6a. Optionally copy across the .ko files mentioned in modules.order to system/lib/modules/2.6.32.9-perf/ the highlighted ones are probably not neccessary:

grep -v test modules.order | sed 's|^kernel/||g'
 
arch/arm/mach-msm/reset_modem.ko
crypto/ansi_cprng.ko
drivers/scsi/scsi_wait_scan.ko
drivers/net/wireless/libra/librasdioif.kodrivers/input/evbug.koarch/arm/oprofile/oprofile.ko

7. Recreate the boot.img with the new kernel:

./mkbootimg --cmdline 'androidboot.hardware=blade console=ttyMSM2,115200 g_android.product_id=0x1354 g_android.serial_number=Blade-CM7' --base 0x2600000 --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot.img

6. Zip up the new boot.img and old META-INF and system directories:

zip -r rom.zip META-INF boot.img system

7. Sign the zip:

java -jar signapk.jar testkey.x509.pem testkey.pk8 rom.zip rom-signed.zip

8. Generate an md5sum of the signed zip so users can check it downloaded properly:

md5sum rom-signed.zip > rom-signed.zip.md5sum

And here’s the screenshot of the running ROM with my kernel:

Click for fullsize

Click for fullsize

Bluetooth

As part of my frustration with PulseAudio and my Skype headset, I thought I’d try using my little USB Bluetooth dongle and my headset. Well after a couple of hours I managed to get mplayer to play out of my headset but upon reboot I can’t get it to work, and PA didn’t detect it anyway, so no good for Skype – which annoyingly these days only uses PA and not direct ALSA devices.

I paired my BT headset with my Android phone which worked nicely, but the voice dialler is shit – no better than via the phone’s mic.

I also wasted an hour more trying to get PA to route Skype to my wired headsets and everything else via the monitor speakers – with the option to switch easily, but that didn’t work so I’m back to my odd little hack of firing up alsamixer and switching between 2 channel and 6 channel a couple of times and loading Skype then turning off the Surround channel using amixer.

I also updated the blog to WordPress 3.2.1

Edify Scripting And Git Patches

I’ve been working on Edify scripting to create a flashable zip that allows me to patch a regular CM7 nightly build with a reverted libaudio.so and updated libcamera.so

There’s literally no documentation anywhere! There’s some very old posts about Amend scripts (update-script) on XDA but nothing about the newer Edify scripts (updater-script and update-binary) that CM7 uses.

My script is based on the script from gapps:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ui_print("Mounting /system");
run_program("/sbin/busybox", "mount", "/system");
 
ui_print("Extracting libraries");
show_progress(0.100000, 0);
package_extract_file("libcamera.so", "/system/lib/libcamera.so");
package_extract_file("libaudio.so", "/system/lib/libaudio.so");
show_progress(0.100000, 10);
 
ui_print("Setting permissions");
show_progress(0.200000, 0);
set_perm(0, 0, 0644, "/system/lib/libcamera.so");
set_perm(0, 0, 0644, "/system/lib/libaudio.so");
show_progress(0.200000, 10);
 
run_program("/sbin/busybox", "umount", "/system");
ui_print("Installation complete!");

There’s not a huge amount of documentation about the folder structure of a zip or apk, but essentially its this:

libaudio.so
libcamera.so
META-INF/com/google/android/
   updater-script
   update-binary

You have to take update-binary from another zip file, such as a the CM7 zip itself.

There’s also very little documentation about signing zips. I found that the command to do that is:

java -jar signapk.jar testkey.x509.pem testkey.pk8 update.zip update-signed.zip

signapk.jar can be found in the out/host/linux-x86/framework/ directory of a compiled build and the AOSP signing keys can be found in the build/target/product/security/ directory of the Android source tree.

To make a patch to revert libaudio I had to diff against the version before HEAD for that whole directory – we have to do it this way as the previous commit is different for AudioHardware to AudioPolicyManager – this is “get the previous commit, whatever that may be”, not “get this specific commit for this specific file”:

cd device/zte/blade/libaudio/
git diff HEAD^ > ~/libaudio.patch

Then I can apply the patch to HEAD (optionally check for errors first):

git apply --check ~/libaudio.patch

No we have a patch to revert to a previous version, kind of the opposite of what patches are usually for!

I’ve created a new directory on my server for all the CM7 stuff like patches and KANG builds here, which includes this signed zip patch.