AdvanTej

Enterprise mobility and Android

2011-06-09T21:45:00.000-07:00

Its quite some time after the GoogleIO. Have been busy digesting some info and thinking a lot. Just a day before IO, I wrote some of my thoughts on Enterprise mobility. Today, I'll try and visit certain aspects in detail as well as try to list what Android has to offer as of now.

Now, from current trends in market and from my understanding till date, I see the current enterprise mobility having 3 components as follows :

1. Device Management
2. Security
3. Application management

Enterprises looking for a complete mobility solution are mostly looking at these three areas. I'll try to briefly touch on each of these and discuss what Android has to offer (and not offer) to enterprise mobility. [For clear separation, I have marked Android Specific details in BLUE : I know Green (#A4C639) would have been appropriate, but I didn't think it was good for reading :)]

1. Device Management : Device management (DM) mainly deals with being able to remotely alter certain aspects of the devices. Again, I see DM being split into the following.

i. Provisioning deals with mass deployment of various settings on large number of handsets. For instance, provisioning the devices with corporate WiFi information, VPN access parameters and configuration of email settings etc... For the IT department, being able to provision these settings is beneficial since it helps them carry out the tedious task as well as reduces chances of human error and avoid complex email instructions.

Blackberry and iOS have most of the DM functions baked into the platform. This means, one can configure a DM server (may require manual steps). Once configured, the DM server can send commands to the device which will be understood by the device platform and reacted accordingly.

Android, however, requires an on-device management agent (aka Device administrator) which should implement the Device Admin APIs (Android 2.2 onwards) in order to perform any of the DM functions. Furthermore, Android doesn't support provisioning out of the box. Rather of all the top IT demands (WiFi, VPN, Exchange etc...), only WiFi can be configured programmatically by the on-device agent.

ii. Device Control deals with being able to remotely take certain actions on the device that may affect the end user. E.g. device lock, unlock, wipe, set/reset password.

With the device admin software installed, Android can do these basic device control functions like device wipe, lock/unlock and set/reset password.
There is however one way to achieve device control functions without having to install any device admin. The trick here is that most Android devices ship with a Email application which can be configured with Exchange information. By default Exchange uses the ActiveSync protocol for syncing mails. Of lately (I guess Android 2.2 onwards), I have seen that while configuring Exchange, the platform shows the standard Device Management screen asking for adding the Exchange as a device admin. If you do this, then by configuring the Email, you can execute device control commands like lock/unlock, set/reset password, wipe etc... To check this go to Settings -> Location and Security -> Select Device administrators. You should be able to see Email application being listed if you have configured Exchange (ActiveSync ).

iii. Device Policies : Policies allow enterprises to control certain settings of the device. This is different from provisioning in that policies can be considered as 'enforced' settings. While someone may change the provisioned settings, device policies are not "meant" to be changed. On Blackberry and to some extent the iOS, the platform restricts the user from changing any policies set by the IT administrator. These policies may include restrictions on the browser to disable javascript, avoid using the phone as USB storage device, disabling camera, etc...

Again, in the case of Android, you will need the on-device admin app to control (only) a subset of what the IT demands traditionally. Basic policies like enforcing a device password, password quality etc.. are supported out of the box with the Device admin APIs.

2. Security : By far, this is THE feature enterprises cannot live without. When enterprises allow data to be accessed remotely, its security is of prime importance. There are 3 components related to security that I visualize as follows:

i. Encryption : Any data that is stored by any application as well as any data that is communicated to and from the device, needs to be encrypted.

Android apps can use SSL tunnels through with data can be transported. However, the data stored on the device (phone memory and SD) is up to the applications. Prior to honeycomb (Android 3.0) there is no support for turning on encryption on the device. Even with Honeycomb, a device administrator application can request for the encryption process to begin, and it will start the encryption ONLY IF it is supported by the device on which the agent is running. Things are still pretty unclear about the way encryption is supported (hardware vs software etc...). One of my previous posts raises these issues. I'll update both the blog posts once enough information is available.

ii. Device Policies : I have purposefully included policies again under Security. I think this link is important to note. This is just to remind that policies are restrictive settings enforced in order to avoid security compromise.

iii. Compliance : Now, we have policies in place. And as I said these need to be enforced on the device. However, it may happen that the user knowingly or unknowingly changes some setting that violates certain policy (that cannot be technically enforced on the device - technology limitation). This may put corporate data at risk. It is important for the IT to determine such instances. This leads to constantly monitoring the device and making sure that it is "in compliance" with the policies.
Usually, compliance checking may be done on the server that monitors the device. This can be achieved by querying the device for certain parameters periodically and then running the compliance rules against the values received. These rules usually test whether the device adheres to all the policies, if not then the resulting actions could be anything from blocking corporate access for that device to wiping the device. This totally depends on the IT policies for the enterprise.

The device admin app can play the role of reporting parameter values to the DM server. To monitor Android for certain metrics, the server can implement the Google C2DM (cloud to device messaging discussed in this blog post) to send query messages to a device admin app which can reply back.

3. Application Management : One of the basic goals for enterprises is to mobilize the business. As a result, enterprises have started mobilizing many internal applications. So, as a part of enterprise mobility, the IT also has to manage the mobile apps. Application management (AM) can be again viewed as having the two main functions :

i. Monitor/Debug apps : Since most of the applications may be internal apps, the development and testing phase becomes critical. Also, since these apps may directly affect employee productivity, debugging these apps during development and after deployment is crucial too. One of the tasks of AM is to help the development and debugging process easier. Once the app is in production, AM can help monitor the status of apps and surface any problems earlier. Monitoring of apps may also refer to getting an apps inventory and determining "blacklisted" apps from security point of view. This may tie back to compliance.

ii. Deploy / Remove apps : With many such applications there is a demand for Enterprise application catalog on which apps would be listed and shown/accessed depending on the role of the employee. Since these apps may contain critical corporate information, it is important for the IT to be able to control these apps remotely. Being able to install, remove these apps is one of the most popular demands from IT.

With Android, anyone can "sideload" an application. This means all the application (apk) files can be accessed via a webpage. However, there are few points to note. In order to install any application that is not listed in the Android Market (consumer app), one has to enable a setting called applications from an "Unknown Source". While doing so, the user gets a dreaded message that may scare him off. Also, it is worth noting that there is currently no official way to push the application on the device and install/uninstall it without the user intervention. If you already have your device admin agent on the device, then it can download the app binary and trigger the install process or trigger the uninstall process of an existing app which will redirect the user to the install/uninstall approval screen. There are some app markets (like AppBrian) which have (with limited capabilities) "managed" to remotely push and install applications on Android phones. However, there is no official way to do so.

So, here is a complete picture of how I see Enterprise mobility as of now:

To summarize, Android really doesn't have much to offer at this moment apart from few Device Admin APIs and Encryption (hardware dependent - 3.0 onwards). With the growing demand for Android and the changing trend of Employee liable devices, it certainly is a challenge for IT. The Google enterprise team unfortunately didn't seem to address most of these issues and didn't seem open to a lot of questions posed at the GoogleIO. The talk at GoogleIO can be found here : (http://www.google.com/events/io/2011/sessions/taking-android-to-work.html) I hope they have some plan for the Enterprise mobility because the wave has just begun.

Understanding Enterprise Mobility

2011-05-09T11:55:00.000-07:00

[I'm sitting at a Starbucks waiting for the GoogleIO registration to open up. There is an interesting session 'Taking Android to work' which I'll be attending. Google's approach to enterprise mobility seems to be different than Blackberry or Apple : they don't have anything baked into the platform. The GoogleIO session will hopefully provide more insights into the future path. If you are an attendee and interested in this topic, I would definitely love to have a chat with you. You can follow me on Twitter : @advantej ]

For the past few months, I'm trying to understand the enterprise mobility space. It had kind of existed in the past but emerging again with a new face altogether. Its definitely a larger wave than the earlier one.

A look into the past:
Laptops introduced mobility into enterprise. There were cell phones before, but those weren't 'smart' enough. Their primary purpose was just to carry out conversations. Laptops made it possible to take the work with you. There was also a short period that showcased Personal Digital Assistants (PDAs) which were rather bulky to carry around and capabilities mostly limited to managing your schedule, taking notes and some basic messaging. But the truly workable mobile devices were laptops.

The Enterprise Viewpoints: Two sides of a coin
The Good:
For enterprises, mobility means a lot. It is a means of growing business, capturing opportunities and bringing back information, knowledge, keeping the organization going on, no matter where the people in the organization are. Be it the CEO, CTO, marketing or sales people or any other management folks or your awesome engineers: mobility builds the necessary bridges whenever it matters to achieve the required goals.

The Worrisome:
However, practically this means accessing company resources from devices and environments on which enterprises may not have any control. While mobility helps enterprises grow the concern about information security in uncontrolled environments makes enterprises take a step back.

In the laptop/PDA wave, managing devices was pretty much conventional. There was nothing new to do at least for the laptops because they had to deal with the same operating systems on laptops for which IT management was already being used for a long time.

For pretty much long time, RIM provided enterprises with a solution to control the Blackberry mobile devices, enabling them to configure, manage and enforce policies on the devices.

With Apple and Android powered devices entering the consumer market with different form factors, mobility has a new face. Not just that there are a lot of devices from different vendors and operating systems, its the fact that employees are consumers first. They are pretty much demanding the use of devices of their choice for accessing enterprise resources. Moreover, people don't like to carry multiple devices : a personal device and a company owned device. They want it there - all in one.

The challenge for the IT is to support multiple mobile devices ensuring safety and security of enterprise resources. Apart from security which is central to enterprise mobility, IT demands being able to configure devices no matter what OS its running.

Being a newbie to this space, I think of a lot of questions that I'm trying to answer. With many enterprise applications emerging, is enterprise mobility management limited to managing just the devices ? What about the applications ? Do we need to control and analyse those too ? With employee owned devices is it acceptable to enforce enterprise policies all the time ? Some policies require control over the hardware as well. In my masters thesis, I explored context awareness frameworks for mobile devices and prototyped one. I was wondering if it makes sense to exploit user context for enterprise policies. This may help in selectively applying policies depending on user context. This may help develop a win-win situation where employees don't feel controlled all the time but would be able to access the required resources. (For curious reader : here is an interesting academic research project trying to identify high level contextual aspects for a mobile user.)

Have got these questions and many more.... but one thing for sure - this wave is very large, unavoidable, with a lot of challenges and comes with competitive problems for the architects and engineers to solve.

[Thank you Starbucks for the internet !]

Android Thread Constructs(Part 4): Comparisons

2011-03-31T11:54:00.000-07:00

In this series of posts we have seen the following thread constructs:
1. Basic threads and communication between them [see article]
2. Understanding the Main thread or the UI thread [see article]
3. IntentService [see article]
4. AsyncTask [see article]

NOTE: These are Android specific constructs. Android also includes the java.util.concurrent package which can be leveraged for concurrent tasks. That is out of the scope of my discussion.]

So, when to use what ? What is the exact purpose of each ? What are the drawbacks of using one over the other ? Which one is easier to program ?

I came across all these questions when trying to understand each of these. In due course of time, I have come up with some guidelines which I discuss in this post.

NOTE: Any of the recommendations made in this post and the table below are not comprehensive and final. There may be better and alternate ways of doing things. I would love to know any different views and get an insight into a different thought process. The views expressed in this post are my personal views.

Service
Before proceeding further, let me touch on the Service class. Traditionally speaking, the notion of service reminds us of task running in the background while we can work and interact with the UI. This causes confusion for newbies. Because in Android, even if the Service runs in the background, it runs on the Main Thread of the application. So, if at the same time if you have an activity displayed, the running service will take the main thread and the activity will seem slow. It is important to note that a Service is just a way of telling Android that something needs to run without a user interface in the background while the user may not interacting with your application. So, if you expect the user to be interacting with the application while the service is running and you have a long task to perform in a service, you need to create a worker thread in the Service to carry out the task.
So, even if Service is not a threading construct, its a way of executing a task at hand. Hence I have included it in the comparison.

The table below tries to summarize various aspects of four task execution mechanisms : Service, Thread, IntentService, AsyncTask.

Most of the points in the table are self-explanatory. However, some points that need an explanation are numbered and explained below the table. Also, this table is just to summarize about the concepts discussed in the previous posts. So, if anything is still unclear, I recommend to go through each individual posts in this series.

	Service	Thread	IntentService	AsyncTask
When to use ?	Task with no UI, but shouldn't be too long. Use threads within service for long tasks.	- Long task in general. - For tasks in parallel use Multiple threads (traditional mechanisms)	- Long task usually with no communication to main thread. (Update)- If communication is required, can use main thread handler or broadcast intents[3] - When callbacks are needed (Intent triggered tasks).	- Long task having to communicate with main thread. - For tasks in parallel use multiple instances OR Executor [1]
Trigger	Call to method onStartService()	Thread start() method	Intent	Call to method execute()
Triggered From (thread)	Any thread	Any Thread	Main Thread (Intent is received on main thread and then worker thread is spawed)	Main Thread
Runs On (thread)	Main Thread	Its own thread	Separate worker thread	Worker thread. However, Main thread methods may be invoked in between to publish progress.
Limitations / Drawbacks	May block main thread	- Manual thread management - Code may become difficult to read	- Cannot run tasks in parallel. - Multiple intents are queued on the same worker thread.	- one instance can only be executed once (hence cannot run in a loop) [2] - Must be created and executed from the Main thread

[1] API Level 11 (Android 3.0) introduces the executeOnExecutor() method, that runs multiple tasks on a thread pool managed by AsyncTask. Below API Level 11, we need to create multiple instances of AsyncTask and call execute() on them in order to start parallel execution of multiple tasks.

[2] Once you create an object of an AsyncTask and call execute, you cannot call execute on that object again. Hence, trying to run an AsyncTask inside a loop will require you to each time create a new object in the loop before calling the execute on it.
To be very precise, you cannot do something like :
   TestAsyncTask myATask = new TestAsyncTask();
   for (int i = 0; i < count; i++) {
   myATask.execute("one", "two", "three", "four");
   }

But you can do :

   for (int i = 0; i < count; i++) {
   TestAsyncTask myATask = new TestAsyncTask();
   myATask.execute("one", "two", "three", "four");
   }

[3] Thanks to comment posted by Mark Murphy (@commonsguy) : "there's nothing stopping an IntentService from communicating back to activities. A broadcast Intent is good for that, particularly with setPackage() to keep it constrained to your app (available on Android 2.1, IIRC). An ordered broadcast can be particularly useful, as you can rig it up such that if none of your activities are on-screen, that some manifest-registered BroadcastReceiver picks up the broadcast and raises a Notification."

Conclusion:
With a pretty understanding of the AsyncTask and the IntentService classes provided by Android, it would be a good idea to leverage these for most of the tasks as against trying to manage threads manually or implement your class as a Service unless there is really a need to do so.

Tricky Things:
There are some tricky scenarios that need some special handling. After all, we are dealing with a mobile environment and things are pretty unpredictable. For instance, the user opens your activity in which you start an AsyncTask, but before completion of the task, the user decides to exit the application (say by pressing the back button). Or your activity may be terminated (read kicked off) due to say an incoming call, when you are running a long task in the background. In such cases, where your application is not shutdown, but any foreground tasks have been closed or changed, all the background tasks need to know of this and try to exit gracefully.

Android thread constructs (Part 3) : AsyncTask

2011-03-18T12:19:00.000-07:00

After examining thread communication, UI thread and then IntentService, I would like to talk about another threading construct called AsyncTask.

Similar to IntentService, AsyncTask allows us to run long running tasks in the background. However, unlike IntentService the implementation is not straight forward. One of the reason people might think is that it involves generics ! There is no need to be afraid about those really. We just need to know 2 important things. One is the type of data that will be moving around and secondly these types cannot be primitive types like int, float, boolean etc... Before going further into the implementation, let me try to explain at a conceptual level.

Concept:

You have a long task to do. You extend the AsycTask class and somewhere in there, specify your task. Then, from the main thread, create an instance of your extended class and call the execute() method. This should somehow result in a background thread executing your task. Pretty simple !

Now, there are 3 kinds of data that you will be dealing with:

1) Params : The parameters you pass on to the background task

2) Progress : The data units which the background task will be passing to you (UI thread) reporting its progress.

3) Result : The data that will be returned by the background task (to the UI thread) on completion.

Clearly there seems to be a communication going on between the UI thread and the worker thread. Hence, I like to visualize the AsyncTask as follows:

All the methods mentioned in the diagram will be a part of the extended AsyncTask class but however will run on different threads as indicated.

1) You have an instance of the AsyncTask and will call the execute() method. This method runs on the UI thread and serves as a trigger to the platform to spawn a worker thread.

2) Before handling the control to the worker thread, the platform will execute the onPreExecute() method on the main thread. We can perform any necessary task setup.

3) After this method finishes, the platform executes the doInBackground() method on the worker thread.

4,5) Now, whenever the worker thread calls the publishProgress() method, the platform calls the onProgressUpdate() method on the main thread with the parameters passed to the publishProgress() method.

6,7) Finally when the long running task is over i.e. the doInBackground() method returns, the return value is passed to the onPostExecute() method.

And, for all this to happen our AsyncTask class needs to know the datatypes for the 3 kinds of data discussed above.

It is important to note that just like IntentService, AsycTask also spawns a SINGLE worker thread and hence only one task can be run in background. Furthermore, once an instance of our AsyncTask is created, you can call the execute() method on it only ONCE. An exception will be thrown if you try to call execute() on the same instance of AsyncTask more than once. Hence, with AsyncTask if you want to run multiple tasks in background, create multiple instances and call execute on them.

Note: API level 11 (Honeycomb) adds the executeOnExecutor() method which enables to run multiple tasks on a pool of threads managed by AsyncTask class. I have not studied and tried this. I will update the post (or write a new one) once I try this out.

Implementation details:

Extend the AsyncTask class and pass to it the datatypes for Params, Progress and Result

class TestAsyncTask extends AsyncTask<String, Integer, Integer> {
}

So, here, we are telling that our worker thread will accept String parameters as input, the worker thread may publish the progress to the main thread as an Integer value and finally the return value of the doInBackground method will be an Integer. Note that the Integer class is used instead of primitive data type int.

Now, It may happen that, you have a worker thread that doesn't need any input, doesn't wish to convey any progress or any result. In that case, the AsyncTask definition will look like:

class TestAsyncTask extends AsyncTask<Void, Void, Void>{
}

Okay. Sticking with the first example, lets add in the doInBackground, onProgressUpdate and onPostExecute methods.

class TestAsyncTask extends AsyncTask<String, Integer, Integer> {

protected Integer doInBackground(String... strings) {

// Long running task - say processing of each passed string

for (int i = 0; i < strings.length; i++){

// Do processing of strings[i]

publishProgress(i); // publish that ith string is processed

}

return 0;

}

protected void onProgressUpdate(Integer... item){

Log.d("TestP", item[0] + " item has been processed");

}

protected void onPostExecute(Integer result){

Log.d("TestP", "AsyncTask returned : " + result);

}

From the main thread (say from your Activity or service), create an instance of the AsyncTask.

TestAsyncTask myATask = new TestAsyncTask();
myATask.execute("one", "two", "three", "four");

As mentioned before, if you want to run multiple AsyncTasks in parallel, just create another instance and call execute on it.

TestAsyncTask myATask2 = new TestAsyncTask();

myATask2.execute("five", "six", "seven", "eight");

There are 4 threading rules we need to follow for AsyncTask to work properly. These are mentioned in the AsyncTask documentation, but I'll mention those again so that everything is available at one place.

1. The task instance needs to be created on the main thread.

2. The execute() method needs to be called on the main thread.

3. Do not explicitly call any of the preExecute(), postExecute(), doInBackground() and onProgressUpdate() methods.

4. The task can be executed only once on one instance.

Thats all you need to know to execute AsyncTask.
I'm pretty much excited about my next post. I'm planning to do a comparison of various background mechanisms that we have seen till now as well as try to come up with some guidelines. I'm still working on it, hope to post them soon. Stay tuned !

Android Thread Constructs(Part 2): Intent Service

2011-03-17T20:35:00.000-07:00

Continuing from Part 1 about the UI thread, today, I would like to discuss the IntentService class.

Concept:

In simple terms, IntentService provides a mechanism to run a long task in the background. We need not worry of any thread creation and management. It is all done behind the scene. We just extend our class from the IntentService class, and implement our long task in the overridden onHandleIntent() method.

On the specified trigger (which is an Intent), the platform will spawn a worker thread for our extended class and then call the onHandleIntent method on this thread. I like to visualize this as follows:

So, all the long running code can be executed in the onHandleIntent() method. We can be sure that this will not block the main (UI) thread.

It is worth noting here that if there are multiple intents that are received, they all will NOT execute in parallel. The IntentService class spawn a SINGLE worker thread. Hence all the consecutive intents will go into the message queue for the worker thread and will execute sequentially.

So, the obvious question is : What if I want to execute multiple tasks in parallel ?

I will defer to answer this till the end of this article series. We will first go through AsyncTask in the next article and then the concluding post I will try to consider various use cases, limitations and comparisons.

Implementation details:
Now for some implementation details. Extend your class (say MyIntentService) as follows:

class MyIntentService extends IntentService {
   public MyIntentService() {
   super ("com.foo.MyIntentService");
   }
   protected void onHandleIntent(Intent intent) {
   // call to any long running task !
   }
}

Thats it. You are all set ! Now, you can trigger this by calling the startService(Intent) method. We need not worry about stopping the service. Once the long running task is done and if there are no intents lined up in the message queue, the platform will automatically stop the IntentService.

I have stated again and again, IntentService is very useful when you need to perform a long task in the background. The interesting part here is that the trigger for starting the task is an Intent ! Now that opens a lot of opportunities. Don't get it ? Here is hint : Your application need not be running at the time you want to start a background task ! All you need to do is have a PendingIntent for your IntentService. Now you can register this PendingIntent with many of the available callbacks in the Android APIs. So, now, even if your application is not running, and the PendingIntent is fired ! Wolaa - your background task is started :)

Coming up next is AsyncTask.

Android Thread Constructs(Part 1): The UI Thread

2011-03-11T14:50:00.000-08:00

Earlier, I talked on passing data between threads. I would like to continue the same "thread" of discussion and in the next few posts of this multipart article, explore and try to explain about various ways of performing tasks.

A pictorial and diagrammatic representation makes me understand concepts well. Every time I learn something new, I try to make a diagram in my mind. This helps me understand better. So, I'll be providing my own diagrams along the way.

Note : The diagrams I use are to help myself understand the concept and may not be an exact representation of the concept. You may still need to read the related documentation.

Enough said, lets get into the Thread !

The UI Thread:

So, in an Android application, each application is sandboxed and runs in its own process. Unlike traditional languages, the Android application may not have a single entry point. So, the application can be entered through from any of the application components (Activities, Services, Broadcast receivers) described in the Application Fundamentals on the developer blog.

All these application components run on a single Main thread called as the UI thread. I like to imagine this concept as in figure below:

So, as you see all the components will run on the MainThread or the UI thread. All the lifecycle methods (of Activity, Service, Receivers starting with on*) will run on the UI thread.

One of the main task of the UI thread is to manipulate the user interface. Hence, if you have long tasks to perform, you should not be doing those in the main thread. (I'm sure, you must have read this several times). The reason is that if you perform any long or blocking task - the UI thread will be blocked - hence blocking or delaying the UI updates and will lead the user to think that the system is running slow. The Android platform doesn't want this blame on itself, so when it detects that some long task is running on the UI thread for some application, it will declare that the application is "foobar-ed" and throw out the nasty ANR (Application Not Responding) dialog - pissing off the user and provoking him/her to uninstall, and underrate your application ! Deadly and Evil :O

So, in order to do longer tasks, from any of the application components, you should create threads. However, its worth noting that you should not manipulate the UI from any worker thread. i.e for example if you run a long task on a thread on a button click as follows:

public void onClick(View v) {
  new Thread(new Runnable() {
    public void run() {
      Bitmap b = loadImageFromNetwork();
      mImageView.setImageBitmap(b);
    }
  }).start();
}

Code source : http://developer.android.com/resources/articles/painless-threading.html

Here, the worker thread is trying to update the UI. As the documentation states, this may lead to hard to find and funny (not for you) problems. So, updating the UI is the job of the main thread. The following figure helps me remember that :)

Now, it is evident and advisable that we do long and/or blocking tasks on worker threads and if any results are produced, convey them to the main thread. In my previous article, I talked about passing data around threads. This involves implementing Handlers, making appropriate Looper calls, obtaining the Message Object and passing it around, getting data from it blah blah blah... (Go read the article if you havent')

Android provides certain constructs that offload from us the tasks for creation and administration of threads and let us focus on what we need to do. IntentService, AsyncTask, HandlerThread are among those.

I'm going to discuss IntentService and AsyncTask (with my diagrammatic representations) in the next articles and then try to come up with rough guidelines regarding when to use each of the constructs.

Stay tuned.

Getting gingerbread on Nexus One

2011-02-25T14:57:00.000-08:00

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 ! :)

Android : Passing data between main thread and worker threads.

2011-02-17T22:41:00.000-08:00

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(mServiceLooper);

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.

Nokia chooses WP7 over Android

2011-02-11T07:20:00.000-08:00

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 ...

Android development cheatsheet

2011-02-10T14:00:00.000-08:00

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>]

Android 3.0 encryption : Initial Thoughts

2011-02-03T12:51:00.000-08:00

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.

Android C2DM Messaging (Server Push for Android Phones)

2010-10-21T15:46:00.000-07:00

UPDATE: Added diagrams to get concepts clear.

From monday, I have been fighting to get the C2DM (Cloud to Device Messaging) working. And with somewhat frustration and a lot of help from some good people out there, I got it working ! :)

In this article I describe my findings and try to explain the concepts in simple words and list out steps you need to do to get it working. For an example code I would suggest you take a look at Gabor's blog which is this. Its really awesome.!

NOTE: Also, I would suggest you to take a look at the sample code provided by google. If I get time, I will also post some sample code (don't wait for me to do that :D). Also, just take a look at the classes in the google.android.c2dm package provided in the sample codes. No need to dig into the details, but I may talk about them later in this post.

So what is C2DM ? It is a server push mechanism provided by Google so that 3rd party applications can push messages to their applications on Android devices. Currently as of today, it is in beta, and if you are an enterprise, you will need to apply and have talks with Google before having your application out with a lot of users and lot of messages to push. However, for developers with a gmail account ID, the registration request should be pretty easily accepted and you will be "whitelisted".

Before digging into details, let us see what are the top level concepts and which components are involved. Basically there are 3 entities involved:
0. The Google C2DM service.
1. Your server application. I'll call it as the "FOOServer". This will send the message to the C2DM service which will forward it to the requested device.
2. The application on the device that receives the message. I'll simply call it DeviceApp.

So, no points to guess that C2DM acts as a middle man and does the message passing. How ? It uses the default google services on the Android phone. So the basic requirement for this whole thing to work is that there should be at least one logged-in Google account from the device.

Now, when you signup for the C2DM, you will be providing them with the following (only 2 relevant things are mentioned):
1. The Application Name. This is actually the package name that you will provide. It is very important to remember this, because this is the package name you will have to use for your DeviceApp and worst part is that in the whitelisted mail that you get from Google, this is not mentioned. I haven't found a way to look at our registered information. If anyone knows this, please comment and let me and other know. So, for the time being consider that the package name is "com.foo.test"

2. The second important thing on the registration form is the Role Account Email ID. Make sure that this email is not used on any device. I have found that the messaging will not work for that device. So, for our example lets say it is FOO@gmail.com

Just for fun, the following diagram depicts the above step.

So, till now, we have the email account ID which is FOO@gmail.com and the package name.

Who needs what
Ok, so how does each entity react to the C2DM and what IDs and credentials does it use ?

DeviceApp

The device app registers with the C2DM service. It tells the C2DM service that it would like to receive messages from FOOServer. In return it gets back a registration ID.

So,
DeviceApp -----[FOO@gmail.com]------> C2DM

C2DM --------[registrationID]--------> DeviceApp

The first action is done via a registration Intent. If you see the C2DMessaging class you will get this. Here, the DeviceApp sends the FOO@gmail.com address specifying that it would like to receive messages from this account.

Next, You will need to extend the C2DMBaseReceiver and override the onRegistered and onUnregistered methods. So, the onRegistered method will be called when the C2DM server accepts the registration. In this method you will receive a registrationID. This is a very long alpha numeric string that identifies the device.

Now, the DeviceApp needs to convey back this registration ID to the FOOServer. It is recommended that at this point you also send some unique device identifier to keep track on the FOOServer. The reason is that Google may change these registrationIDs and may not be unique. If Google changes any IDs it will push the new ID to the DeviceApp which has to handle it in similar fashion.

So, if you choose say IMEI/MEID as the unique identifier, then,

DeviceApp -----[UniqueID, registrationID]------> FOOServer

Thats it ! The device is now registered and ready to receive any messages. The following diagram shows this registration work flow:

Registration Work Flow

FOOServer:
The FOOServer will store (or update) the registrationID received into its local database. So, eventually the server will have registrationIDs from all the devices the DeviceApp is on. To send a message to a particular device, the FOOServer needs to POST to the C2DM Service the following ~~four~~ three things:
~~1. The accountName which will be FOO@gmail.com~~ (Update : Thank you @matest for pointing it out that this is not needed)
2. An authentication Token [explained below]
3. The registrationID of the device it wants to send the message.
4. The message itself ( I think the limit is 1024 charcters)

You can get the authentication token by providing the credentials for FOO@gmail.com. I used curl to get the token. In our case the command would be :

curl https://www.google.com/accounts/ClientLogin -d Email=FOO@gmail.com -d "Passwd=FooPassWord" -d accountType=GOOGLE -d source=FOOServer -d service=ac2dm

[note this command is taken from comments posted on this blog]

Getting the auth token

This should give you few very long string values one of which would start with "Auth=". This is the one you want. Even if I have used curl here, it is recommended that you get the token programmability, because even this token might change. If it changes, the new token would be returned as a response to the POST that we do to send the message.

Sending the message

I would like to thank Gabor Paller for writing a very good article on this and helping me with this process. Also, thanks to DavidMyton for his article. The comments below this article are pretty useful too. I also found this discussion on c2dm google group helpful.

I have written this in a hurry. So let me know of any "bugs" in the article and I'll fix those !!
Thank you !

Using IntelliJ (or any IDE) with command line tools for developing Android projects

2010-10-15T08:10:00.000-07:00

Recently I did some Blackberry development, and started using IntelliJ for that. I liked the concept of having the IDE separate from the build environment. There is some extra work involved but it is convenient if you need a command line interface may be to automate your builds.

Anyways jumping directly into the topic. I have here put together somethings you will need to do to use your choice of IDE and build using android command line tools. Since I have started liking to work with IntelliJ, I will also mention some IntelliJ specific tweaks.

So, clearly there are 2 parts here: The IDE set up and the build setup.

For build set up, we can just use the 'android' command to create the project. So, if we have a project in mind say TestProject, we'll create it using the command :

android create project --target 8 --name TestProject --path ./TestProject --activity TestActivity --package com.foo.Test

You can know the target by issuing the command :

android list target

I will not go deep into what are the targets and why you need them. You can find this information on the Android Developers Website.

The create project command will generate a directory structure which will contain bunch of directories and some configuration files and the build.xml required by ant.

Before you create/import the project in your IDE, issue the "ant debug" command on this generated directory structure. This will generate the R.java file which is the resource file which is needed for compiling along with your source files.

If you come from the Eclipse world, you know that there is a "workspace" in which there can be multiple "projects". Analogous to that, in IntelliJ, there is a "Project" in which there can be multiple "modules".

Talking in terms of IntelliJ, create an empty project (without any modules).

Now,

- Click File -> New Module

- In the Add Module dialog, see that "Create module from scratch" is selected. Click next

- In the Content Root field, browse to the root of this project. The name field will automatically be updated. Click Next

- It will mark the TestProject/src and the TestProject/gen directories as the source directories. This is what we want and this is why we ran the build process before creating the process. If you haven't run the build command before, it will only show the "src" directory. In that case, after you create the project, run the ant command and then come back to the module properties and mark the "gen" folder as a source folder. Doing this is important, or else it will never resolve the R.java references and is quite frustrating.

- Click Next and then Finish.

Now that we have added a new module, we'll need to add android libraries so that we can get intellicense !

- Right click on the module, go to Module Settings.

- Click on dependencies tab.

- Click Add -> Module Libraries

- Click Attach Jar Directories

- Select the specific android platform directory (that you used for creating the project with --target) For us that will be android-8 and will be located at ${ANDROID_SDK}/platforms/android-8

Select this path. Click OK twice. Click Apply.

You are all set !! But wait. There is still a trick pending !

Any time you change any of the resource files, the R.java will be outdated. No issues while building, but the IDE will start cribbing. The Eclipse plugin takes care of updating th R.java. For IntelliJ or other IDEs it might be irritating to see those unresolved references. Not just irritating to see, but some IDEs constantly bug with pop ups for unresolved references. A common mistake will be to import the generic "android.R" package ! In this case, the "R" reference will be resolved but won't find any of user defined resources.

So, each time when you add a resource, you'll need to build by issuing the ant command. But, many times the code is not complete and there is not point running the whole build. All we need is the command to generate the R.java file.

Simple, before writing any code, just run the ant command with the verbose output turned on. E.g. ant -v debug

In the -pre-build target, you will find the command for generating the R.java file. An example is as follows :

-pre-build:

-resource-src:

[echo] Generating R.java / Manifest.java from the resources...

[null] Current OS is Windows 7

[null] Executing 'C:\android-sdk_r07-windows\android-sdk-windows\platforms\android-8\tools\aapt.exe' with arguments:

[null] 'package'

[null] '-f'

[null] '-m'

[null] '-M'

[null] 'C:\androidworkspace\TestProject\AndroidManifest.xml'

[null] '-S'

[null] 'C:\androidworkspace\TestProject\res'

[null] '-I'

[null] 'C:\android-sdk_r07-windows\android-sdk-windows\platforms\android-8\android.jar'

[null] '-J'

[null] 'C:\androidworkspace\TestProject\gen'

[null]

[null] The ' characters around the executable and arguments are

[null] not part of the command.

Now, all you need to do is extract and form command from this and put it in a batch file (or shell script) and whenever you add any resources, just run the batch file in order to generate the R.java

Hope this helps someone !