Mark Murphy - Beginning Android

• Join a separate set of Google Groups [43] http://source.android.com/discuss for Android platform development

Ed Burnette, a nice guy who happened to write his own Android book, is also the manager of Planet Android, [44] http://www.planetandroid.com/ a feed aggregator for a number of Android-related blogs. Subscribing to the planet’s feed will let you monitor quite a few Android-related blog posts, though not exclusively related to programming.

Now to focus more on programming-related Android-referencing blog posts; you can search DZone for “android” and subscribe to a feed [45] http://www.dzone.com/links/feed/search/android/rss.xml based on that search.

You might also consider keeping tabs on those mentioning Android in Twitter messages, such as by using a Summize feed. [46] http://summize.com/search.atom?lang=enq=android

Android is a continuously changing product. In fact, while this book was being put into production Google and the Open Handset Alliance released Android 1.5.

This was great for you, the developer, because Android 1.5 adds in quite a bit more to the product.

On the other hand, the timing left a bit to be desired in terms of getting this book into print. The vast majority of what you have read so far is accurate for Android 1.1 and Android 1.5. This Appendix will point out the exceptions — the places where Android changed and so the advice for Android 1.1 is no longer correct. Those changes are few in number, so the bulk of this Appendix is spent covering what is new and how, in basic terms, you can make use of the new material as a developer. This material is nowhere near the depth that you will find in the rest of the book, because Android 1.5 has been available for only a few weeks, and it will take months to write up everything that is new and exciting.

Android 1.5 introduced the Android Virtual Device (AVD) system. This allows you to have multiple Android emulator images available, targeting different device profiles. Each image can vary in terms of Android API version (e.g., 1.1 versus 1.5), available add-ons (e.g., whether or not Google Maps are included), and hardware capabilities (e.g., does it have a touch screen?).

To create an AVD, you must first choose a “target”. Targets represent a combination of an API version and a set of available add-ons. You can find out the available targets for your environment by executing the following command:

android list targets

For example, at the time of this writing, three targets are available:

• 1, indicating the Android 1.1 SDK with no add-ons

• 2, indicating the Android 1.5 SDK with no add-ons

• 3, indicating the Android 1.5 SDK with the Google Maps add-on

Then, once you have a target in mind, to create the AVD itself, execute the following command:

android create avd -n ... -t ...

The first ellipsis indicates where you specify your own name for this AVD; the second ellipsis is where you fill in the target you wish from the available targets in your environment.

If you choose a target that represents a “standard system image” (i.e., no add-ons), you will be prompted to optionally configure the hardware profile. If you go through that process, you will be able to determine how much RAM is in your emulated device, whether or not it has a touchscreen, etc.

With the new AVD system comes a new way of creating and updating projects for use with the Ant build system.

To create a new project, run android create project. This will require a few additional parameters, notably:

• -kto supply the package name to use with your application (e.g., -k com.commonsware.android.sample)

• -nto supply the name of the project, which will determine the name of the APK file (e.g., -n MyProject)

• -ato supply the name of the activity class (e.g., - a MyMainActivity)

• -tto supply the target ID for use with this project, following the same target system used when creating AVDs, described in the preceding section “Getting Started, Virtually” (e.g., -t 3)

• -pto indicate where the project files should be generated (e.g., -n MyProject)

To update an existing project, run android update project. This will replace your build.xml file and do a few other odds and ends to convert a project to be built using the Android 1.5 build system. As with android create project, you will want to provide a few additional parameters on the command, including:

• -tto supply the target ID for use with this project, following the same target system used when creating AVDs, described in the preceding section “Getting Started, Virtually” (e.g., -t 3)

• -pto indicate where the project files should be generated (e.g., -n MyProject)

In addition to using the target ID system to indicate what level of device your project is targeting, you can use a new AndroidManifest.xmlelement to specify hardware that is required for your application to run properly.

You can add one or more elements inside the element. Each element specifies one valid configuration of hardware that your application will work with.

At the present time, there are five possible hardware requirements you can specify this way:

• android:reqFiveWayNavto indicate you need a 5-way navigation pointing device of some form (e.g., android:reqFiveWayNav="true")

• android:reqNavigationto restrict the 5-way navigation pointing device to a specific type (e.g., android:reqNavigation="trackball")

• android:reqHardKeyboardto specify if a hardware (physical) keyboard is required (e.g., android:reqHardKeyboard="true")

• android:reqKeyboardType, probably used in conjunction with android:reqHardKeyboard, to indicate a specific type of hardware keyboard that is required (e.g., android:reqKeyboardType="qwerty")

• android:reqTouchScreento indicate what type of touchscreen is required, if any (e.g., android:reqTouchScreen="finger")

Since the Android M5 SDK in the summer of 2008, Google Maps has been available to application developers willing to agree to the terms and conditions. However, since Google Maps is not part of the open source Android project, there was always the possibility that some Android devices would not have Google Maps on them. For example, anyone porting Android via the open source project to existing hardware on a “homebrew” basis would unlikely be in a position to license Google Maps.

To accommodate this and similar scenarios with other possible technology, Android 1.5 has introduced a more formal add-on mechanism. You can see this with the target ID system, whereby some targets have Google Maps and others do not. If a device manufacturer decides to add some APIs to their devices that are unique to them, presumably they could use this same add-on system to help developers target their devices. This also opens up the possibility for other platform-level optional components, particularly ones that might need to be licensed, such as the oft-rumored Adobe Flash add-on.