Tip: Speeding Up Your Android Emulator Launch

The latest version of the Android emulator comes with a feature called "snapshots." It needs to be enabled as a feature of each AVD. Luckily, this version also includes the ability to edit existing AVDs.

First, enable the feature:

Enabling Snapshots

Second, when launching the AVD, choose to load from the snapshot and save the snapshot. When a snapshot isn't found, the AVD boots up from scratch. As we all know, this takes quite a long time even on very fast machines.

Enable Snapshot options

Now, when you exit, the system will store off a snapshot of the state of the AVD. This takes a little while, depending on how much RAM is assigned to the AVD. After saving the state once, the AVD will now launch very quickly - usually in just a couple of seconds.

However, the exit is no longer super speedy and often triggers "Not Responding" type messages. If you always want to return to exactly where you left off, this is how it will work. Overall, the behavior is much faster. However, if you want it to come up clean each time, just make sure the first time you boot it's clean, then exit to save the snapshot. Now, when you launch the AVD, only check load from snapshot, but make sure save to snapshot is unchecked.

Don't save over old snapshot

Now, the system will just load the AVD from the one snapshot you created and not save the state each time you exit. This means super speedy launches into a cleanly booted emulator as well as super speedy exits since the snapshot doesn't have to be saved each time.

You'll start to feel like you don't need to keep the emulators running all the time. You also won't necessarily go looking for a phone each time just to save the emulator boot-up time. (You'll still go after the phone or tablet when debugging for performance or with code bases that are otherwise slow on the emulator or other such reasons.)

How much difference does it actually make? Here are some test results running on a 6 core 3 GHz desktop with 8GB of RAM and a relatively speedy SSD:

• Cold launch of Android 3.0 emulator to a usable state: 4 minutes 35 seconds
• Snapshop launch of same Android 3.0 AVD: 8 seconds

That cuts the emulator launch time by 97%. Put another way, the cold launch takes 34 times longer. Taking these steps is well worth the minimal additional effort.


Happy Android Coding!

Tip: Installed Application Not Installed Error

Have you ever loaded up an application, ready to debug, but then seen a message along the lines of, "Application Not Installed" display? This usually has an accompanying LogCat error:

ActivityManager: java.lang.SecurityException: Permission Denial: starting Intent

The cause and solution are very simple:

• This error is most likely caused by a duplicate Activity class entry in the manifest file. 

 <activity  
   android:name=".MainActivity"  
   android:label="@string/app_name">  
   <intent-filter>  
     <action  
       android:name="android.intent.action.MAIN" />  
     <category  
       android:name="android.intent.category.LAUNCHER" />  
   </intent-filter>  
 </activity>  
 <!-- lots of stuff -->  
 <activity  
   android:name="MainActivity"></activity>  

The solution should be clear by now:

• Remove the duplicate tag from the AndroidManifest.xml file 
• Build the application again
• Reload the application

This is quite the opposite of forgetting to add an Activity class to the manifest file. And, yet, it leads to a failure just the same. Proper maintenance of the manifest file is important. It's not a file to mess around with.

Happy Android Coding!

Quick Tip: Eclipse, Source Control, and default.properties

Here's a quick tip for you:

When using Eclipse project properties to change the Project Build Target, make sure the default.properties file is writeable. This may mean checking it out from source control before editing the properties. In our configuration, the Perforce file is not writable and changing the Project Build Target settings with Eclipse does not check out the default.properties file from source control. So, I have to first check it out, then modify the Eclipse settings.

Although default.properties is automatically generated by the Android Tools, the catch is it must also be checked in source control. Usually, this does not trigger an error, either. Instead, the default.properties file will just be out of sync with the settings and possible create strange behavior.

Android Development Tip: Managing AVDs with the Eclipse Android Development Tools Plug-In

I've updated my Eclipse development environment a number of times in the past few weeks, what with the Android 1.5 preview, then the release version. I checked for updates this week and noticed yet another version of the ADT Eclipse plugin was available. One interesting new feature added in the latest version is an Android Virtual Device (AVD) manager, accessible from within Eclipse.

All emulator instances using the Android 1.5 SDK require an AVD configuration. Sure, you can use the android command line interface to create and manage AVDs, but if you just want to create a simple AVD quickly, you can now use the little wizard provided with the ADT plugin. The AVD manager button is added to your Eclipse toolbar. It looks like a little black cell phone.

Simply click it and the AVD manager will launch, listing all AVDs on your system. You can Add and Delete AVDs, as well as Refresh the AVD listing.


When creating a new AVD, you can set the following information:

• The AVD friendly name
• The Target Android system
• The Skin
• Whether or not to create an SD Card Image
• 
  You cannot create custom hardware profiles. That, you still need to use the android command line tool for.