Nexus One vs. HTC Desire

Since February my phone has been the Nexus One. When I got it I wrote up a brief review where I compared it to the iPhone 3G and the HTC G1, so I guess this is a sort of exit review for the Nexus One as my new phone is the HTC Desire (also known as the Bravo or A8181).

The HTC Desire is almost the same hardware as the Nexus One. The wikipedia page has a good feature comparison so I’ll try avoid going over that ground. You can see from the photo at the top of this post that they share pretty much the same form factor. The Desire has a little bit of the HTC chin design where the Nexus did not. The Nexus notably has the three brass dots for the docking station which the Desire does not.

Looking at the back, things are pretty much identical. The Nexus One has a band of exposed aluminum frame (which can host an engraving), and the power button is slightly different likely due to the small difference in back cover design. The size, general shape, and weight of the phones are basically identical. I do notice that the Desire feels ‘flatter’ for some reason, and it almost feels as if it is a slightly more refined phone.

The Desire has a Super LCD vs the Nexus AMOLED. There is a visible difference here, and one that sticks in my head. In day to day use it isn’t bothersome, but more than just a subtle difference. The Super LCD tends to have washed out blacks, and appears a little bit dimmer to my eye. In every other aspect the two displays are equivalent, enough to make the differences a non-issue for day to day use. The Desire has a gorilla glass screen, where the Nexus did not.

The dock was a nice feature on the Nexus, just drop it in and it charged. I rarely plugged it into a microUSB connector. However the dock also discouraged the use of any sort of bumper case for the Nexus, I’ve got a case on order for the Desire already.

So while these two phones are quite similar, the button layout is not. Let’s compare the HTC G1 (top), Nexus One (middle), and HTC Desire (bottom):

The G1 actually had buttons dedicated to phone functions, it also had 5 function buttons vs. 4 in the later phone. The Nexus had touch sensitive buttons, which took some getting used to after having real buttons. The track ball was transparent and allowed for coloured notifications. The Desire swaps the track ball for an optical track-pad, some people really dislike this but I haven’t found it to be a problem. The back and search button is a rocker, effectively working as independent buttons.

Looking across the layouts, the home button has wandered around in different locations for every one. Search and menu are fairly consistent, but I’m not sure it helps much. Layout changes like this really mess with your head/muscle memory.

In stock form there are bigger differences between the two devices. However, both are fairly friendly to root and flash with your favorite community ROM. I’ve been running CyanogenMod since I got the G1 and continue to do so with the Desire.

Looking at the internal storage is where we notice some big differences. Nexus One: 196MB, Desire: 148MB. Having come from the Nexus meant that I very quickly started to hit out of storage problems, forcing me to move more of my apps to the SD Card. Everything fits without resorting to apps2sd or other hacks.

Speaking of hacks, you can change this if you are willing to flash a new HBOOT – this is of course somewhat scary as messing up HBOOT may be difficult to recover from. It also requires the phone be in S-OFF (developer) mode, allowing modification of /system while Android is running. Contrary to most of the material out there you can run in S-ON mode and have custom firmware, there are some limitations but no deal breakers (my Desire is currently S-ON).

 

 

Cyanogenmod 7 and sshd

Remote access to your phone might seem a bit odd, but being able to access my NexusOne from a computer with a real keyboard is nice when you need to poke around inside the internals. It also makes updating the photos, music, or movies possible without additional apps or cabling the phone to my PC. Today I forgot my phone at home, and was able to verify that I had “lost” it at home vs. somewhere else by ssh‘ing into my home network, then connecting over the local network to my phone using ssh.

There were 3 main steps:

  1. set the phone hostname on boot
  2. configure sshd
  3. make it start on boot

Step one was really easy, turns out it is a supported feature of CyanogenMod 7 (CM7). Enter the Settings menu,  choose Applications then Development, now select Device Host Name. That’s it, I didn’t even need to reboot (the setting is persistent across reboots).

Step two is the most involved, the cyanogenmod wiki has some instructions as does this tutorial. I’ll attempt to provide a guided walk-through here.

a) Let’s assume you’ve got a linux desktop machine. First we’ll create some ssh client keys. We’re going to do this as the dropbear in CM7 doesn’t support key passphrases, so passwords are not an option. The other benefit to ssh client keys is that we can automate connecting to the phone.

So on the linux destop we’ll execute:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/youruser/.ssh/id_rsa.
Your public key has been saved in /home/youruser/.ssh/id_rsa.pub.

For the passphrase we left it empty. In very simple terms – the id_rsa is the private part of the key, the id_rsa.pub is the public one. We’re going to put the public key file onto the phone later. The private one will stay safe and secure on your desktop.

b) I’ll also assume you’ve got adb installed. By connecting the phone to the desktop machine via USB we can push the key file using adb.

$ sudo platform-tools/adb push /home/youruser/.ssh/id_rsa.pub /sdcard/authorized_keys

c) Now we’ll use adb to execute a shell on the phone. This is how I used to get in with a keyboard, but doing so without a wire hook up is very convenient.

$ sudo platform-tools/adb shell

d) Time to configure dropbear, these are all executed within the shell we just created on the phone. You’ll find this is pretty much exactly what the CM wiki describes.

# mkdir /data/dropbear
# mkdir /data/dropbear/.ssh
# cp /sdcard/authorized_keys /data/dropbear/.ssh/
# dropbear-keygen

Initially I had thought I could avoid running dropbear-keygen, but it turns out this is a required step. [Edit: In CM 7.1.0 RC1 dropbear-keygen is not installed, nor does it appear to be required] Now we initialize the keys.

# dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key
# dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

And set permissions to keep things happy.

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

e) Now we get to try it.

# dropbear -v -s -g

The -v option tells it to be verbose, handy if something has gone wrong. You should now be able to connect via ssh from the linux desktop machine, but only from the user id that created the public/private key combination (of which we’ve moved the public key to the phone). Since in step 1 we set the hostname, we can do:

$ ssh myphone
The authenticity of host 'myphone (192.168.1.174)' can't be established.
RSA key fingerprint is 00:c0:b2:78:2b:af:04:72:90:bb:0d:46:f9:14:cc:3f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myphone' (RSA) to the list of known hosts.
# ls
dropbear.pid dropbear_dss_host_key dropbear_rsa_host_key

[edit: CM 7.1.0 seems to be causing me some trouble, in two areas. a) it requires the username matches, so use “ssh root@myphone” b) it doesn’t like rsa public keys but dsa works, so use “ssh-keygen -t dsa”. You’ll know you have the problem as you get a “permission denied (publickey)” error.]

f) Bonus step. We’ll add more keys from other systems we want to be able to connect to the phone from. We repeat (a) on each machine / user id we want to connect from and append the public key to the authorized_keys file.

cat /sdcard/newmachineid.pub >> /data/.ssh/authorized_keys

Now on to step three – making sshd start on boot. I’ll assume you don’t already have a /data/local/userinit.sh file yet for some other modification, if you do I’m sure you can sort this out.

[Edit – as was pointed out by Devon, the original version had !# instead of #! in the userinit.sh script, I’ve fixed the post to reflect the correct code – no worries, the wrong way still works fine as my comment indicates]
On the phone (using ssh or adb to access the shell) you run the following commands:

# echo -e '#!/system/bin/sh\n\ndropbear -s -g' > /data/local/userinit.sh
# chmod +rx /data/local/userinit.sh

You can even run vi if you want (it works!). We can check the resulting file with cat:

# cat /data/local/userinit.sh
#!/system/bin/sh

 

dropbear -s -g

That’s it, we’re done. The next logical step is to start including your phone as part of your nightly rsnapshot backups, or building some scripts to make updating music on the phone easy (and wireless).

More RAM for your G1

I’m a big fan of the cyanogenmod alternate firmware. It has allowed me to enjoy the latest versions of Android (Froyo!) on the original HTC G1. One of the most notable limitations of this device vs. almost all of the others is the amount of RAM available. The G1 has 192MB of RAM, of which only 95MB is available for programs under CM 6.0. Recently there has been a hack “EzRAM” which enables an additional 15MB of RAM for a total of 110MB. This additional RAM really makes a difference in performance.

Read on for the details of the upgrade process..

Continue reading “More RAM for your G1”