Friday, February 25, 2011

Getting gingerbread on Nexus One

If you are an impatient person like me (when it comes to gadgets !), with a nexus one but no gingerbread yet, you might definitely be aware that there are official versions of Gingerbread 2.3.3 floating out there.

I faced some problems getting gingerbread to my N1.

<noobie_skip>
I had CM7 on my nexus one which is gingerbread but I wanted to get to a stock version (why ? my choice :D and for some reason gapps wasn't able to install the GMail app on CM7 !) Noobies, you are supposed to ignore this block
</noobie_skip>

So, I was able to get back to stock version 2.2 using instructions here. From then on my impatience triggered ignorance and things started to go foo bar !

I started getting a very strange error. Something like :

assert failed: file_getprop(“/system/build.prop”, “ro.build.fingerprint”) == “google/passion/passion/mahimahi:2.2.2/FRG83G/91102:user/release-keys” ll file_getprop(“/system/build.prop”, “ro.build.fingerprint”) == “google/passion/passion/mahimahi:2.3.3/GRI40/102588:user/release-keys”
E:Error in /sdcard/update.zip 
(status 7)
Installation aborted



Eventually, I figured out that I was trying to directly jump from FRG33 to GRI40 (This is Gingerbread 2.3.3) ! All the zip files floating out there are incremental - they only take you one level up !

So, you may want to check the file name. For e.g. :
2854b06b22b9.signed-passion-FRG83G-from-FRG83D.2854b06b.zip

This file will take you from FRG83D to FRG83G. You will need to go on flashing each one. So find all the zip files that will take you from your version up to GRI40
For me it was from FRG83 -> FRG83D, then FRG83D -> FRG83G and finally FRG83G -> GRI40

Wooohooooo. Gingerbread it is !

Hope this helps someone !

Note: Unfortunately I cannot provide you with all the zip file paths. Since the links may be broken or get broken over time and I do not wish to keep on updating those. Use our friend Google to get to the files ! :)

Thursday, February 17, 2011

Android : Passing data between main thread and worker threads.

There may be situations where you want to spawn a thread from your Activity or Service to handle long running (and may be blocking) tasks. In such cases, its sometimes necessary to pass data back and forth between the main thread and the worker thread(s). E.g. if the worker thread finishes a task and returns the result to the main activity to display the results OR you want to keep a worker thread around and ask it to switch between tasks depending on some message you pass to it.

In the past, I faced some problems understanding these concepts associated with different classes in android.os like the Handler, Looper, HandlerThread etc...

I'll try to explain these concepts in a simple language. Probably most of these explanations are from the developer documentation, but I thought consolidating these at one place may help to get a good picture.

Ok. So, when an application runs, it runs in a Main thread called as the UI thread. Any other thread can be created using the standard java.lang.Thread class. As I said in a typical situation you will spawn a thread, may be pass some data to it OR the thread may pass back some data to the Main thread from time to time as well as when its done executing.

Let us consider the task where we need to send data to a worker thread. So first, we create a worker thread.

STEP 1: Create a worker thread

class MyThread extends Thread {
    @Override
    public void run(){
    }
}

In our main thread...

MyThread mThread = new MyThread();
mThread.start();

When you have to pass any messages to a thread or get messages from a thread, the receiving thread needs a MessageQueue. By default, a thread created by using the java.lang.Thread class will not have a MessageQueue associated with it. Its just a plain old thread as in the Fig. 1 (Yes, I know. What an innovative diagram !! :D ).




Now, we need to attach a MessageQueue to our thread. The Looper class provides the method prepare() to create a message queue for a thread. We need to call this method from the receiving thread's run method.


STEP 2: Call the Looper methods


class MyThread extends Thread {
    @Override
    public void run(){
           Looper.prepare();
           Looper.loop();
    }
}



As you see, there is one more Looper method called in the code. This loop() method will start running the message loop for the current thread. In simple terms, it will start looking at the MessageQueue and processing the messages. This is how I interpret the Looper as in Fig. 2.



But, who sends the messages to the MessageQueue and how are these processed ? There is a class called the Handler. The Hander allows us to send and process Messages (as well as Runnable Objects) associated with the thread's MessageQueue. So, we need to create a Handler. It is important to note that the Handler is associated with the thread that creates it ! The Handler provides methods to handle (receive) Messages as well as send and schedule messages. For details, please refer to documentation.



STEP 3: Create a Handler to receive the Messages

class MyThread extends Thread {
    public Handler mHandler;

    @Override
    public void run(){
           Looper.prepare();

           mHandler = new Handler() {
                   public void handleMessage(Message msg) {
                       // Act on the message
                   }
           };
           Looper.loop();
    }
}

If you notice, this code is the same that is listed on the Looper documentation page here.  Few things to mention here are. The Handler is created in this thread, hence it is associated with the default Looper (read MessageQueue) in the current thread. There are constructors for the Handler that allow us to specify the Looper (again, read MessageQueue). This allows us to write a cleaner code by writing the Handler class separately and passing on a Looper (again, again, read MessageQueue) when the Handler is created. I'll get to this in a while. But as I have insisted, it is worth noting that whenever the developer documentation refers to a Looper, you can assume they are talking about a queue. I'm really not sure why they have surfaced the Looper class. It creates more confusion (at least for me). Also, when dealing with passing the messages, with this mechanism, we really need not care of the MessageQueue call. That is the reason I haven't linked it to the documentation. Anyways... things are what they are ! For me, I like to interpret this whole mechanism as depicted in Fig. 3.


Let me know if you like PAT or your way of viewing it !

So, now any other thread having the reference to mHandler will be able to call the send or post methods of the Handler class to send a Message (or a runnable object) to our thread. The code for sending message will look like:

Message msg = Message.obtain();
msg.obj =  // Some Arbitrary object
mHandler.sendMessage(msg);

Pretty simple yeah ! Btw, there are various methods to set/get data for the Message object which can be found in the developer documentation for the Message class.

Summary of Steps :
1. Create a Handler in the receiving thread [If it is the main thread, create one in the main thread]. By default the handler will be associated with the default queue (Looper).
2. So, if the receiving thread is created by using java.lang.Thread, then we need to call the Looper.prepare() and Looper.loop() in order to set up the message queue for the thread.
3.  In the sending thread, prepare a message object (or a Runnable object)
4. Get a reference to the Handler in the sending thread and call the send/post methods on it to send a message.

HandlerThread:
Since by default java.lang.Thread doesn't contain a message queue (Looper), Android provides a class called as the HandlerThread which already contains a message queue. The only difference in using the HandlerThread class over the method described above is that you need not call the Looper.* methods.

On creation of a HandlerThread, Android will create a thread containing the looper. So, in the main thread the code will look like:

HandlerThread myThread = new HandlerThread("Worker Thread");  
myThread.start(); 

We separately create a Handler as follows:

class MyHandler extends Handler { 
    public MyHandler(Looper myLooper) { 
        super(myLooper);
    }
    public void handleMessage(Message msg) { 
    }

Now in the main thread, we get the looper for the HandlerThread and pass it when we create the Handler as follows:

Looper mLooper = myThread.getLooper(); 
MyHandler mHandler = new MyHandler(mLooper); 

Whenever we want to send a message from the main thread, we do it in a similar fashion.

Message msg = mHandler.obtainMessage(); 


msg.obj =  // Some Arbitrary object
mHandler.sendMessage(msg); 


I like to visualize this as shown below in Fig. 4 where we write the Handler separately and then pass a looper to it on its creation.





Friday, February 11, 2011

Nokia chooses WP7 over Android

Going through the news reader this morning, I learnt that Nokia, one of the greatest manufacturers of mobile devices has chosen WP7 over Android. Not that I hate WP7 (as of yet, since I haven't tried it), but I would have loved to have my favorite Android on Nokia devices.
Being from India, where Nokia phones are seen as prime devices (at least till recently), and having used few of Nokia phones before, I was eagerly waiting to hear Nokia adopt Android.
Now, it will be an interesting market to see. I'm not much concerned how this affects WP7 (sorry Microsoft, not a big fan), though for the time being it will definitely be a breather for them. I'm worried about the future of Nokia. But still I hope that somewhere in future, Nokia will shake hands with the green robot !

BTW, did I hear somewhere that Nokia CEO Stephen Elop is a former Microsoft employee ! Ahem ahem ...

Thursday, February 10, 2011

Android development cheatsheet


Here is a list of commands I find useful when developing applications. Do add to comments any commands that you use and find useful. I'll update accordingly. Also, I would be interested if anyone has any android UI related cheat sheets :)


android
-    Create/delete/view Android Virtual Devices
-    Create/update projects
-    Update the SDK with new platforms, addons and docs.

android list target
android list avd
android --help
android create avd –n <avd_name> -t <target_ID> -c <size>[K|M]
android create project --target <target_ID> --name <prjname> --path <where>
                       --activity <activityname> --package <package_namespace>

android update project [--name|-n] <prjname> [--target|-t] <target_ID>
                       [--path|-p] <thepath_to_prj>

android create lib-project --target <target_ID> --name <prjname> --path <where> 
                           --package <package_namespace>

adb
adb [-d|-e] install <path_to_your_bin>.apk
adb push <local> <remote>    - copy file/dir to device
adb pull <remote> [<local>]  - copy file/dir from device
e.g : adb push foo.txt /sdcard/foo.txt
adb shell
adb devices
adb –s emulator-5554 shell

#sqlite3 /data/data/com.example.google.rss.rssexample/databases/rssitems.db
sqlite>.exit
adb logcat [<option> … [<filter-spec>] …
[V – Verbose, D – Debug, I – Info, W – Warning, E – Error, F – Fatal, S – Silent]

adb logcat <tag1>:<priority1> …..
e.g. : adb logcat ActivityMgr:I MyApp:D *:S

others 
mksdcard [-l label] <size>[K|M] <file>
emulator –avd <avd_name> –sdcard <file>
telnet localhost <emulator-port>


#From inside telnet:


- sms send <sender phone number> <text message>
- geo fix <longitude> <latitude> [<altitude>]



Thursday, February 3, 2011

Android 3.0 encryption : Initial Thoughts


A little background:

Few days back Google released a preview version for the Android 3.0 SDK code named HoneyComb. For quite some time now, the enterprise has been asking for device management features for the Android Platform. Blackberry has these features integrated into their solution. Recently Apple also embraced the initiative and supported enterprise features in their iOS 4.

The obvious reason for these trends is due to the customer demands. Earlier, enterprises used to provide employees with smart phones (read blackberries) to access corporate resources. Blackberry was the only solution providing secure corporate access, encryption and security policies. However, with iPhone getting popular, the momentum shifted in last couple of years. Now, instead companies providing the smartphones, employees demand the type of phone they want and companies' IT departments have the daunting task to support these smartphones. These demands lead Apple to add device management support to iOS.

Android seems to be a very different game. It is gaining a lot of popularity these days. The open nature of it has enabled the platform to be adopted by a huge number of manufactures resulting in a burst of Android powered devices. In the corporate world, employees are asking for supporting Android devices too.

Some initial thoughts (technical):

In Froyo (Android 2.2), google introduced some device admin APIs. Using these, some basic device management functionalities could be achieved. (Device lock, set password, device wipe). However, one primary concern for corporates is Encryption !

Just few days back, google released a preview version of honeycomb SDK. This is my interpretation of the Encryption API found in HoneyComb preview SDK. I'll update the blog or write a new post when I learn more on this.

As a device admin, an application first has to check weather Encryption is supported by the tablet (in hardware). I don't think there is software encryption algorithm in honeycomb. I'll be surprised to see a software encryption (it will defenitely slow down the tablet in my opinion - but who knows, there are always surprises in the world !).

So, assuming there is hardware support, the admin app can test it (using the getStorageEncryptionStatus) and then call the start encryption method (setStorageEncryption). This will trigger the hardware encryption process. According the honeycomb preview api documentation, this will encrypt only the application storage area (i.e. all the internal memory - my guess) and may not the external memory (sd card).

SDK documentation for the setStorageEncryption says:

<snip>
This policy controls encryption of the secure (application data) storage area. Data written to other areas (e.g. the directory returned by getExternalStorageDirectory() may or may not be encrypted.
</snip>

I came across an engaget article that says that the motorola xoom has an option to encrypt the entire tablet. This is a bit incomplete and misleading. Does this mean that Motorola has extended honeycomb to encrypt the SD card as well ? Who knows, only time will tell. I'm curious to know what kind of encryption is supported - hardware/software. Will it (and how much) affect the performance ? and will this initiative please corporates and will they embrace Android devices ?

Time will tell and if it tells me first, I'll update the blog :) Do leave any comments if you find any information or corrections.