The term phone doesn’t suit Android devices even if you can make GSM or CDMA voice calls with them. They feel like small computers with phone functionality as an extra. A feature phone works better as a phone than a touchscreen smartphone.

Touchscreen smartphones lack some very basic features — some of the major ones being buttons and feedback. The lack of call and end buttons is limiting — I hate having to tap my finger at the screen to end a call. CyanogenMod has a feature which allows me to use the power button to end a call but it isn’t as responsive as the end button in basic phones.

The redial functionality is also gone. I don’t know about other phones but at least Android phones don’t come with redial. When the called number is busy or there’s a network issue, letting the phone redial the number itself in a loop was very useful. Even if you chose not to use automatic redial, you could instantly dial the last number with which you were on a call by pressing the call button twice (and without waiting for the first button press to register). With Android and presumably other full screen touchscreen smartphones, it takes at least twice the time. There’s also the risk of unintentionally calling a different person (and it does happen frequently) — it wasn’t so easy to make mistakes when we had buttons and the person who was going to be called was clearly highlighted on the screen.

However SMS functions are better in Android. The SMS messages are in an SQLite database and are very easy to transfer, backup or delete (assuming you have root). The best part is being able to delete multiple messages on the basis of any criteria. Incoming messages can be automatically deleted — it is very useful for spam.

One major issue with Android phones are unrootable phones and locked bootloaders. It would be best if phones came rooted and didn’t have locked bootloaders (or one didn’t have to lose the warranty to unlock them). Without rooting your phone, you cannot take proper backups of your phone. Unlocked bootloaders let you install custom recovery images which take filesystem backups of your phone (including apps on the SD card); the only lower level way after that is sector to sector backups; unfortunately restoring those backups are not ideal on flash based storage devices because of their nature. In other words, you cannot take proper backups of your phone without an unlocked bootloader. And some Android device manufacturers go out of their way to lock the bootloaders.

I can use cell-id, WiFi and GPS location detection to do a huge variety of things with the help of LocationManager. This does come at a price though — my phone updates its location with cell-id or WiFi every minute for I don’t know what. I guess it wants to send real-time location updates to Google of every user (see below for the nefarious stuff the Talk service does). Now that Android devices have become quite popular in India, this means Google can easily spy on people.

I can record routes with both cell-id/wifi and GPS easily; in fact I can also get NMEA output from the GPS chipset in my phone though it seems some chipsets or phones don’t support NMEA outputs.

I wish I could set different beep/vibration behaviours depending on the caller/any other factor. The stock phone/dialer application doesn’t give such an option; maybe I could disable vibration in the dialer app and vibrate the phone with varying lengths from my own service/BroadcastReceiver depending on the caller or any other factor. But that’s a bit risky; in case my service misbehaves or is not active at the time of an incoming call (if Android decides to kill it for sometime to free up memory — which it does often when the uptime is >2-3 days), I might not know about the call at all (if phone is on vibrate only) until I turn on the screen again (which could be several hours later). I wonder how third-party apps such as Dialer One or other dialer apps work. Do they rely on TelephonyManager informing them on time when a call arrives and keeping a service on all the time to get those messages?

Easy scripting like in Python isn’t in Android yet; you need to change the code, compile it and install the app if you want to change a behaviour or add support for a new one. You cannot do this from within the phone or from any computer; you need to set up a dev environment for Android first. Which, in itself, might not have been so bad except that the installer for the Android SDK is somewhat like a web installer (similar to Google Chrome); you cannot download everything at one go and perform an offline-installation (if you can, it’s not documented). If you want to modify some behaviour, your desktop is not around and you didn’t remember to copy both the Android SDK and Eclipse to your phone earlier, you need a good Internet connection to download both the SDK and Eclipse and then the Android Eclipse plug-in. And that’s a huge pain if all you have is an EDGE connection on your phone.

It would be much easier if I could just ssh into my phone from a laptop/netbook while traveling and modify some scripts using a text editor such as emacs/nano/vim to modify behaviour on triggers (Intents in Android lingo).

When I first started programming for my Android phone, I hated it. I tried to adapt Android development to Python development style — code in emacs, run it on another terminal. Within a few days I gave up on emacs for Android development and tried Eclipse. I hated it. I wished I could go back to emacs. Eventually I got used to Eclipse and ‘became native’. Developing on Eclipse turned out to be much faster and easier than on emacs! However it does take a lot of resources.

Sleep behaviour on Android phones seem to be very device dependent. HTC phones seem to have much more aggressive power conservation policies than some Samsung phones. It seems you can even make apps so that some Samsung phones don’t sleep at all without acquiring any wakelocks — very funny.

Forcing Android phones to go into deep sleep would be very useful. It seems the best way to get a phone into deep sleep is to disable Internet (both WiFi and mobile data), turn off background data, make sure no apps are visibly active in the background (such as MyTracks recording a track) and press the power button to turn off the screen. If I know I’m short on battery, I wish I could do tell my phone to be in deep sleep for the next x hours and wake up only when there’s a call/SMS.

I am not sure how Android manages deep sleep with data network on and GTalk connected. When GTalk is connected, it must be able to receive incoming messages. But when the CPU is in deep sleep, GTalk won’t know if somebody has sent a message — the GTalk process has presumably been suspended. So does GTalk wake up the CPU every minute or so and poll for new messages? It would be cool if one could control the polling interval. I suspect the Android cloud to device messaging framework (c2dm) uses Talk in the back end to relay messages between Google servers and the apps installed on one’s phone.

I am also not sure about the factors Android uses to determine when to go into deep sleep. Why does it take a lot of time (some hours) to go into deep sleep when both EDGE and GTalk are connected but goes to sleep within five minutes when Internet is off? Is some application on my phone keeping the phone awake when Internet is on? If GTalk can be connected during deep sleep, why is there a hesitation to go into deep sleep when GTalk is on? Or is the factor completely unrelated to GTalk?

GTalk in Android also does some fishy things from what I’ve read in the logs in my phone. Even if you choose to keep yourself signed out, the Talk service keeps phoning home periodically to inform Google of your status and presumably your location too. This means all Android phones connected to Google could essentially be used as surveillance devices for the whole populace within moments. I will leave the implications of that to your imagination.

You may have noticed that I haven’t written about iOS or winmo or BlackBerry at all. This is because I own only an Android phone; if I had, say, a BlackBerry phone, I might have wrote about BlackBerry phones and not much about Android phones.