Android – Page 5 – Roo's View

i9000 ICS – CyanogenMod 9 Alpha

One of the things that I look for in a phone is community support. For me there are two main reasons this is important: 1) It’s nice to have a large group of people you can ask questions of, or an active forum you can search for answers on 2) When later versions of Android are released, that community will hopefully build a version for your phone.

If you’ve been watching the tech news, there have been rumors that Samsung will support Ice Cream Sandwich (ICS) on the Samsung Galaxy S (SGS) and claims that it won’t. The latest news appears to be that they will not upgrade the device, a bit sad as it was only released 18 months ago. So not even kept current through the length of most cell company contracts. This is one area where the iPhone has done right for the consumer.

If you’re interested in getting ICS for your i9000 (or in my case the i9000m) skip over to the XDA Forum and read through the huge thread. The team behind it are the same folk who helped bring CyanogenMod to the SGS originally and are now working on CM9. This is an alpha, there will be rough edges and I don’t suggest people leap in unless they are very brave.

I originally tried Build 11 and that didn’t work well enough for me to switch from the 7.1 stable I was on but it was close. Build 12 appears to be quite good, with a few changes I needed to make for my usage, specifically adding dropbear (SSHD) and rsync so I can do nightly backups (which I’ll talk about at the end of this post).

The forum thread has these instructions for people coming from CM7

Upgrading from CM7?

Do a Nandroid Backup!

WIPE (wipe data/factory reset + wipe cache partition)

Install the ROM from internal sdcard using ClockworkMod (CWM) Recovery

Optionally install the Google Addon

I would recommend that you consider getting CM7 first, it’s a good base to work from and there will be better how to and help to get it working. Experience there will translate over to working with the ICS Alpha.

Here are my steps I used when moving to ICS .

Do some backups of your application data
Backup SMS using SMS Backup+
Backup Plume settings (and any other apps that support backup)
Take some screenshots of your home screens, nice reference to what you have. Also consider grabbing a list of the apps you have installed
Reboot into recovery – perform a backup in CWM
“backup and restore -> Backup”
Mount USB mode in CWM
” mounts and storage -> mount USB storage”
Copy backup to PC (just in case something really bad happens)
Copy new ICS Alpha files to phone
teamhacksung_galaxysmtd-ota-eng.BUILD12.zip
gappsv7.1.zip
Now wipe from CWM
“wipe data/factory reset”
“wipe cache partition”
Install the two .zip files we copied above, build12 first.
At this point my heart always stops, as during the install of the firmware, the phone will reboot suddenly. Do. Not. Panic.
It will automatically boot into ICS after the install. Now optionally reboot into recovery to install gapps.

There is a list of known issues in the main thread, you can post bug reports there but please search the thread so you don’t ask something obvious. There is another thread for discussion (ie: anything that is not a bug report).

Each time I’ve done this type of upgrade I seem to get burned by the Android Market treating the new ROM as if it were a new device, thus it doesn’t restore any of my apps. Good thing I had taken a backup of the list above. Having done this a few times, using a desktop web browser to the Market and installing from there to my phone is much faster.

My experience so far

The good stuff:

ICS is very, very pretty
Recent applications with preview is cool
Quick access to camera on lock screen is nice
Web browser handling of multiple windows more like iOS Safari
Calendar is a big improvement, phone interface much nicer too
It has USB mode instead of MTP

Why it’s still an alpha

I was unlucky and had a sync problem with the calendar
This is a known problem with a solution – flash the gapps_fixer.zip
Every once in a while the lock screen has no touch response, lock/unlock again with power button fixes
I had mapped long press menu to search, that CM feature isn’t supported (yet?)
I miss “quiet times” from CM – using Sound Manager v2 to get same function
Power-off sound comes a while after screen is dark – I disabled the sound to resolve

So far no major issues. Only 1 of the ~50 apps I use indicated it wasn’t compatible – and I’m sure that’s just how they’ve tagged it in the market. The battery life appears to be about the same as CM 7.1.

One observation was my modem didn’t change from KG3 unlike my experience flashing CM7 where the modem did change, it seems my understanding of how the modem is updated (or not) is flawed.

I also briefly tried out a pure AOSP from Onecosmic and while it seems a bit more mature than the CM9 Alpha, it didn’t fit what I wanted (personal taste).

Getting SSHD and rsync working

I had previously written about getting SSHD working on CM7.1 and that I used rsnapshot to do incremental nightly backups of my phone. This has saved me at least once when my phone got very sick and needed to be wipe and freshly installed, having a day old backup was nice. Also when going from version to version I’m able to grab configuration details like the dropbear configuration – this allows me to reuse the same keyed ssh login without having to repeat the entire setup.

The ICS Alpha was missing dropbear. It turns out that the version from CM7.1 can be used – I specifically picked the ones from nightly build 181.

First you need to remount the /system filesystem to be read-write.

mount -o remount,rw /dev/block/mtdblock2 /system

Grab dropbear, dropbearkey and rsync and put them in /system/xbin. Make sure to use chmod 755 on them to make them executable. Probably a good idea to reboot after this.

As I’m going to re-use my configuration files from my backup, I don’t need to use the setup steps from my blog post – I just use the abbreviated version below, but if you’re doing this clean follow the original write up.

# mkdir /data/dropbear # mkdir /data/dropbear/.ssh

Copy the following files from backup to the phone

/data/dropbear/.ssh /data/dropbear/.ssh/authorized_keys /data/dropbear/dropbear_rsa_host_key /data/dropbear/dropbear_dss_host_key

Then just fix the permissions

# chmod 755 /data/dropbear /data/dropbear/.ssh # chmod 644 /data/dropbear/dropbear*host_key # chmod 600 /data/dropbear/.ssh/authorized_keys

The ICS Alpha is also missing the ability to set the hostname, you can hack around it by using the following command.

# setprop net.hostname yourhostname

And of course, we need to launch dropbear

# dropbear -s -g

I still need to figure out how to get these into a script that will run on reboot, for now I’m just doing the last two command manually after every reboot.

Unlocking Samsung Galaxy S Vibrant (Bell)

I’ve been a big fan of unlocked GSM phones since my first one back in 2009. I’ve also been through a surprising number of different phone since then, but all of them have been 2nd (or 3rd) hand and have been a good price for a phone that still has lots of use left in it. My latest phone the Samsung Galaxy S Vibrant (i9000m) is no different, but it came to me locked to Bell.

I purchased the i9000m knowing it could be easily unlocked if you had the right magic. With the stock firmware, if you don’t have the phone unlocked you’ll see what’s pictured at the top of this post when you install a SIM card.

It turns out the forums have a great how to guide, with pointers to an app on the Android Market if you’re afraid of a little bit of hex editing. It should go without saying that I selected the hex editing route. I’ll describe the steps I used here, but all credit to the folks in the forums for figuring this out.

I will assume that you’ve rooted your i9000m and you’re not incapable of using a hex editor.

Step 1: We’re going to copy some non-volatile memory off the phone that contains the ‘lock’. Perform the following commands on the phone (probably via ADB).

$ su # cat /efs/nv_data.bin >> /sdcard/nv_data.bin

Now copy that file onto your PC for editing. Make a backup of the original before step 2.

Step 2: Edit that file, I used hexedit on Ubuntu. The lock bit is inside of the byte at 0x181469 in the file. See the green circle below, change that 01 into a 00 and save the file.

Starting at offset 0x181468 you should see the series of digits: ff 01 00 00 00 00 46 46

The XDA post describes it as follows:

There are 5 different types of locks in 5 different bytes

the FF byte should be left alone
the first byte after the FF is the network lock
the next byte is the network subset lock
the next byte is the sp lock
the next byte is the cp lock
the last byte appears to be a data lock.
the 46 46 should be left alone

Step 3: Use the modified file to update your phone. Let’s assume you copied the modified file to /sdcard/nv_data.bin on the phone, and again the commands below are executed on the phone.

$ su # rm /efs/nv_data.bin # rm /efs/nv_data.bin.md5 # cat /sdcard/nv_data.bin >> /efs/nv_data.bin # chmod 755 /efs/nv_data.bin # chown radio.radio /efs/nv_data.bin || chown 1001.1001 /efs/nv_data.bin # reboot

That’s it, you’re unlocked. The unlock should persist across ROM (firmware) changes.

References: a great article with pointers to valuable information on the i9000 series.

Samsung Galaxy S Vibrant: CyanogenMod 7.1

While I switched phones, I wasn’t interested in switching away from the community firmware (CyanogenMod) that I’ve been running for the last several phones. Above you see the Samsung Galaxy S Vibrant pictured next to the HTC Desire. You can clearly see the difference in screen size (resolution is identical).

For purposes of firmware changes, the i9000m is very similar to the international version of the i9000. CyanogenMod for the i9000 has only been moved to stable as of 7.1 – so support for it is still relatively new. Compared to the Desire which shares much with the NexusOne and has a very stable base in the community.

Initially my plan was to root, unlock, then start playing with firmware changes. After banging my head for an evening trying to get SuperOneClick to work under Linux I gave up my initial plan. [Recent experience shows that SuperOneClick 2.2 works fine under Windows]. Plan B was to just install CyanogenMod after which we’ll have root and we can unlock.

Since I did this, the wiki instructions have changed and now specify 2.3 as the base, when I did this they specified 2.2. If in doubt, follow the wiki.

The steps break down the following steps

First we install heimdall on our PC
We use that to install custom kernel with root on the phone
Then we flash CyanogenMod via ClockworkMod recovery that came with that new kernel package

Step 1) So heimdall is a cross platform open source firmware tool for Samsung devices. It seems to work well under Ubuntu and you can use the CLI, or add a GUI package.

Step 2) I used the GUI and found it to be straight forward installing the speedmod kernel. Simply place your device into download mode, point heimdall at the kernel file you download via the wiki and off you go.

At this point we are running a rooted device AND we have ClockworkMod recovery image installed. We could at this point decide to unlock the device and use it as is. Since we’re so close, let’s just move on to step 3.

Step 3) Install CyanogenMod + optional Gapps. I suggest you get these via the Forum and grab the latest. This is as simple as place the files on the internal SD card, and boot into recovery. From there I suggest you follow the instructions and do a full wipe / factory reset then do the installation.

The install of CyanogenMod 7.1 will result in your ClockworkMod being upgraded as well, this is an artifact of the Samsung system layout which seems to lump everything into a single update lump. In my case this meant I also got a modem that was more suitable for use in the United States and registered with my local carriers as roaming. I ended up using the KG3 radio.

In the photo at the top of the screen, both devices are running basically identical configurations. I used TitaniumBackup to get to this state, but I won’t recommend it in general. The resulting installation worked, but exhibited some instabilities. I can’t pin the blame on TitaniumBackup, but the wisdom of the forum was that it can introduce problems. What it did do for me is something that I find to be a real problem moving from device to device, the Android Market treats each device you connect individually – there doesn’t appear to be an easy way to say “take all the apps on this device, and put them on this other one”.

The nice thing about the sequence of steps here is that we haven’t needed to change the bootloaders at all, this increases the safety factor of what we’ve done as we should be able to easily get into recovery or worst case download mode to fix things.