Not all colors are showing in gnome-terminal (and xterm)!?

This incidence happened to me on my office vnc session (on 64b CentOS, kernel Version 2.6.29.4). I was in a vnc session and I typed ls --colors=always. I was expecting the output to be colorized as per the values set by 'dircolors'. But to my surprise I saw that the output was not colorized! I googled on this issue and saw some suggestions in many of the linux forums. I kept on trying each one of these solutions below:

• Setting TERM=xterm
• Setting TERM=xterm-color
• Setting force_use_color=yes
• Changing (and playing with) the values for gnome color palette.

But, none of them gave back the colors! Frustrating!
However, to my surprise, on a ssh session on the same machine, I was able to get the colors displayed! So, this definitely seemed to be an issue with the vnc session. (Indeed it was :D). I then checked the command used to create this vnc session and it was created with '-depth 8' (8bpp, bits per pixel). Somehow, gnome-terminal (as well as xterm) do not display (multiple) colors when you are in an 8bpp vnc session. But you know, even in that situation (8bpp), 'konsole' was able to display the colors!

By now, you'd have figured out the solution ;).
Yes! the solution is to start a vnc session using the option '-depth 24' to the command 'vncserver'.

Happy coding!

PS: If you set the depth to be 24bpp, then the bandwidth consumption of vnc viewer would increase. A solution for that is to set your vnc viewer to work with lesser colors. EG: 'Low (64 colors)'.

TouchUtils.clickView too slow!?

Here's the scenario...

• You have written an android test-suite for your application.
• Your test cases use 'TouchUtils.clickView' class by android, in order to simulate clicking the buttons on your view.
• However, time between each click is slow to the extent that it has become the bottleneck in your test-suite! 

In the implementation of TouchUtils.clickView, there's a sleep of 1000ms (1sec) after every call made to this function. This is the reason for the delay you've been seeing.

 So, I went ahead and copied the code for 'clickView' and created my own class for providing users with programmable delays. This would help the verification guys to fine tune the delays between each clicks. Hence, trying to keep the runtime of the test-suite under control.

 This class 'MyTouchUtils' can be found here. Just save this file to your project and 'import' this class into your test files. Then, if you want to simulate a click event with 200ms of delay after the click, just do the following:MyTouchUtils.myClickView(this, view, 200);

 Of course there's a trade-off involved between the time given for your program to settle down, digest your click event and produce the results; and the total runtime of your test-suite. So, you have to make the decision accordingly.

Happy Coding!

Android Instrumentation Testing

This article will talk about a strange "permission denial" issue which occurs when  trying to run android instrumentation on eclipse. Of course it'll also disclose the solution to it :).

So, what's the problem?

Whenever you try to run the android test-suite for your application, you see an error message like the following in the 'Console' area of your eclipse IDE.
"Test run failed: Permission Denial: starting instrumentation ComponentInfo{<testPackage>/android.test.InstrumentationTestRunner} from pid=123, uid=123 not allowed because package <testPackage> does not have a signature matching the target <targetPackage>"

Reason?

The error message is pretty self-descriptive. As you might have figured out, it's basically due to a signature mismatch between the <targetPackage> and <testPackage>. In simple words, eclipse is using different certificates for signing up your application and for it's test-suite.

Solution?

Generally, when you are running test-cases on your application, you would want to use debug certificates. Eclipse, by default uses debug certificates. So, best way to solve this is to start from scratch. For that, just do the following. In the 'Package Explorer' right click on your target application -> Source -> Clean up. Repeat the same thing for your test application as well. After this, rebuild both of them. Then you'll be right back on the track.

Happy coding!