The dreaded word: « Fragmentation »

With today’s rapid adoption of the Android platform, more and more articles on the web have been dedicated to the supposed « fragmentation » of the OS. Dan Morrill wrote a great post on this topic (even if he prefers talking about compatibility, and I agree with him). You can argue on the terms, but even Dan Morrill admits that there are issues that developers must solve to reach as much users as possible on the Android market. Some of the biggest are:

• The several bugs of Android 1.5 Cupcake. This is the biggest « compatibility » problem in my opinion, but I would advise you to drop this version as it represents less than 8% of the devices according to Google.
• The diversity of screen sizes and densities
• The bugs specific to custom Android interfaces (such as HTC Sense)

So what do we do?

The obvious answer is: testing, testing, testing.

Alright, testing is the solution. But if you are a developer, you will probably tell me that deploying on several Android devices is painful, and that you do not have time for that (because you are so busy developing the new killer app for the Android Market). Here at Backelite, we totally understand you. So here is an attempt to ease the deployment process on several Android devices (either real ones or AVDs).

Our solution: BkDroidTester

This solution is simple, yet quite powerful. It is basically an USB Hub (optional), and a few lines of shell script to automatically deploy an app on several devices (thanks to Cyril Siman for the original idea).

The hardware part (optional)

To connect several Android phones to one single computer, without having any alimentation trouble, the obvious solution is to use an AC-Powered USB Hub.

We went a little further with a complete test bench composed of a metal box, an USB Hub, and several universal cell phone holders. One of the benefits of this approach is to have a single USB cable (the one between the computer and the hub) to plug in and out (for example to quickly give the test bench to a colleague).

Here is a schema of the system:

And here is a picture of the final result (some people call it « the octopus »…):

The USB Hub is obviously inside the box, and the painted metal provide a great surface for the suction cups to hold onto. We decided to go with 3 mini and one micro USB for the plugs. You can use a converter if you need to use a mini USB plug with a device using micro.

The software part

We developed two small scripts that you can also use without the hardware part described above (just plug several devices to your computer and/or launch several AVD).

The scripts list all the android devices currently connected, and deploy the specified app on them all through ADB shell. More precisely, they make use of the following commands:

adb devices
adb -s <device_number> install -r <path_to_apk>
adb -s <device_number> shell am start -n <package_name>

Now let’s see how to use those scripts.

Step 1: Download the scripts
To use BkDroidTester, you first have to checkout the scripts available here. There is one to deploy an app, and one to deploy and launch a monkey test.

Step 2: Plug in the devices
You just have to connect one or more devices to your computer and/or launch AVDs (make sure all the devices are recognized using ADB).

Step 3: Configure your IDE
If you do not want to launch the BkDroidTester scripts through command line, you can integrate them directly in Eclipse or any IDE that allows you to configure external command line tools.

Here is the way to do it for Eclipse :

1. Select ‘Run > External tools > External tools configuration » or clic on the arrow next to this icon and select « External tools configuration »
2. Select « program » and press the « New » button to add a new external tool
3. Then, configure like this:
   1. Name: <the name you want>           example: « MyApp – Deploy on all Androids »
   2. Location: <path to one of the scripts (deploy or monkey)>          example: « /Users/FabienDevos/work/BkLabs/BkDroidTester/deployOnAllAndroid.sh »
   3. Working directory: <path to the APK>           example: « ${workspace_loc}/MyApp/bin »
   4. Arguments: <APK name> <package name>/<first activity with package name> example: MyApp.apk com.me.myapp/com.me.myapp.MyActivity
4. You can then launch the script by clicking on the arrow next to the icon  and choosing the script you just created (you can also configure Eclipse to launch the last used script by clicking the green icon)

The screenshot below sums it up:

The configuration is almost the same for the « monkey » script. It needs one additional parameter at the end: the number of events you want to send (eg: 5000). You also have to remove the name of the Activity: MyApp.apk com.me.myapp 5000

Pending improvements

So that’s pretty cool, but it could be a lot better. Here are a few features that we would like to add in the future:

• Android Manifest file parsing to automatically determine some parameters like the package name (and thus avoid passing them as arguments of the scripts)
• Automated cleaning of preferences or caches to have a clean fresh app each times you deploy

But as Android developers, we do like the culture of Open Source, which is why we are releasing those scripts as an Open Source Google Code project under the Apache license 2.0. Feel free to use or modify it, and if you do modify it, do not hesitate to share your improvement!

I do hope you enjoyed this article. If you have any feedback, you can either write a comment here, or submit bugs/requests on the Google Code project page.

Fabien Devos
Android engineer at Backelite