Reader Feedback: Manifest Permissions Editor

[UPDATE: 13 Feb, 2011: This problem now longer exists in ADT 9.0.0 (the version right after 0.9.9).]

The Android Manifest file editor within Eclipse provides a number of useful editing tabs to wrangle the complexities of this file. One such tab is the Permissions tab. Use the Permissions tab to manage the permissions that your application uses and grants to others.

If you've been working with Android for a while, then you may be familiar with the permissions listed in the drop-down when you register a new permission using the uses-permission tag. We refer to this feature in both our books; specifically in Sam's Teach Yourself Android Application Development in 24 Hours, Hour 5, "Configuring the Android Manifest File."

Unfortunately, a recent update to the Android Development Tools plugin removed this drop-down. We're not sure if it's a bug or not yet, but the drop-down disappeared in the software update between ADT 0.9.8 or ADT 0.9.9.

What used to look like:

Permissions tab from ADT 0.9.7 showing the drop-down list of values

Now looks like:

Permissions tab from ADT 0.9.9, with the corresponding Browse... dialog

When you press the Browse... button, the dialog comes up.

The field provided still works for typing in permissions values by hand, instead of selecting them from a list. The alternate method, editing the XML file directly from the last tab, hasn't changed at all.

So where is one to get these values to type in yourself? On page 90 and 91 of the SAMS book, we've listed a number of the most common permission values. However, the best place to get the appropriate values for your applications is from the Android SDK documentation. Permissions are defined in the documentation for the android.Manifest.permission class. Also conveniently listed with these values is a short description of what they enable the application to do. Before including a permission within your application, always check the documentation to determine if that is the most appropriate one to use.

Creating Useful AVDs

Various Android Virtual Devices

Many new Android developers just use a basic, default Android Virtual Device (AVD) for development purposes. This is fine when you're just getting started, but when you get serious about designing and developing apps for specific devices, you'll want to give some thought to configuring AVDs to match devices your users actually own.

In some cases, you can just switch to testing on real hardware instead of the emulator. If you have a lot of devices for your team, you can probably just switch to using devices. However, if you can't afford devices for everyone on the development and test team or can't get your hands on some unusual devices with unique hardware characteristics, you can create AVDs to simulate these. Head over to Mobiletuts+ and read our tutorial about creating AVDs that come as close as possible to simulating the following devices:

• HTC Evo 4G
• Google/HTC Nexus One
• Motorola Droid
• T-Mobile/HTC G1
• Archos 5 Internet Tablet

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 SDK API Level 6!

Congratulations to the Android SDK for leveling once again! (I can't help but think of gaming when the API Level is mentioned.) We're now at Level 6, which corresponds to Android 2.0.1, Release 1.

The SDK Tools have been updated, as well, to Release 4, which now requires the updated Eclipse plug-in 0.9.5.

Many handsets still have Android 1.6 and, if rumors are to be believed, will remain so. Thus, Android 1.6, Release 2, is now available to resolve some platform issues. It also requires SDK Tools, Release 4. Curiously, though, it has not "leveled up." Will this be an issue? How will applications and developers know if their Android 1.6 has defects found in Release 1 or not?

Get it all* now while it's hot! :)

*If I'm counting correctly, that's four new things:

• Android 2.0.1, Release 1, SDK
• Android 1.6, Release 2, SDK
• SDK Tools, Release 4
• Eclipse ADT Plug-in 0.9.5

When "Eclipse loading framework information into layout resource editor" Fails

The Android Development Plug-in for Eclipse is a great tool many Android developers rely upon. I personally use some features much more than others. For example, I rarely use the Layout Resource editor to preview layout files. Instead, I just edit the XML directly and run it in the Emulator. (I have also been known to edit HTML with notepad, that's just how I roll.)

So it came as a bit of a surprise (read: annoyance) when I tried to do just that--preview a layout file in Eclipse--the other day and it failed. Eclipse seemed to try to load the layout designer saying, "Eclipse is loading framework information and the Layout library from the SDK folder." Then it up and failed to load it. Over and over. You couldn't see the layout preview, nor the Properties pane or the Outline mode to add new controls to the layout tree.

You might be wondering why I bothered to investigate this since I could have just gone back to the XML and blown it off. Well, I needed a screenshot of the Layout preview mode for our new book. Nuff said.

At first, I thought it was just me overestimating the tool's abilities, trying to preview a layout that was too complex for the preview (this happens often when I include some of the more complex View controls in layouts). So I created a new project with its simple default layout file, and that didn't load either. So that wasn't it.

I did a quick search on the Android developer forums and a couple people were complaining on the forums about this over a year ago. One person suggested recreating your workspace. Well, that didn't work, either. I widened my search to the web and ran across a little note on Brian Klug's wiki, suggesting that the older versions of the Android plug-in JAR files might be hanging around, mucking things up. Thanks, Brian! This sent me in the right direction.

We've had a number of new revisions of Android lately. which have improved (greatly) the Android tool chain, that have had several new JAR file updates. Next, I had to find the android JAR files on my machine. First, I checked where Brian had suggested: c:\eclipse\plugins (basically, in the plugins directory of the eclipse installation path). As my luck would have it, they were not there. Instead, a quick file search for "com.android*.jar" showed that they were hiding in C:\Users\YourUserName\.eclipse\org.eclipse.platform_3.4.0_867647348\features.

With a little investigation, I found several older versions (0.8.x and 0.9.0) of the android JAR files installed with the new ones (0.9.1 is the latest for Android SDK 1.5 r3). I shut down Eclipse, deleted all the older JAR files, leaving only the 0.9.1 versions.
Specifically, I only kept these two android JAR files:

• com.android.ide.eclipse.adt_0.9.1.v200905011822-1621
• com.android.ide.eclipse.ddms_0.9.1.v200905011822-1621

When I relaunched Eclipse, the layout preview began to function again. Incidentally, this was on a Windows installation of the Android tools. When I checked the Mac install of Android 1.5 R3, the JAR files were hanging about in (rather than the expected /Developer/Applications/eclipse/plugins~/.eclipse), but the layout preview did load without issue.

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.