The Android Development Tools (ADT) plugin for Eclipse adds powerful extensions to the Eclipse integrated development environment. It allows you to create and debug Android applications easier and faster. If you use Eclipse, the ADT plugin gives you an incredible boost in developing Android applications:
To begin developing Android applications in the Eclipse IDE with ADT, you first need to download the Eclipse IDE and then download and install the ADT plugin. To do so, follow the steps given in Installing the ADT Plugin.
If you are already developing applications using a version of ADT earlier than 0.9, make sure to upgrade to the latest version before continuing. See the guide to Updating Your ADT Plugin.
Note: This guide assumes you are using the latest version of the ADT plugin. While most of the information covered also applies to previous versions, if you are using an older version, you may want to consult this document from the set of documentation included in your SDK package (instead of the online version).
The ADT plugin provides a New Project Wizard that you can use to quickly create a new Android project (or a project from existing code). To create a new project:
Unless you know that you'll be using new APIs introduced in the latest SDK, you should select a target with the lowest platform version possible.
Note: You can change your the Build Target for your project at any time: Right-click the project in the Package Explorer, select Properties, select Android and then check the desired Project Target.
minSdkVersion attribute in the
<uses-sdk>
of your Android Manifest file. If you're unsure of the appropriate API Level to use,
copy the API Level listed for the Build Target you selected in the Target tab.Tip: You can also start the New Project Wizard from the New icon in the toolbar.
Once you complete the New Project Wizard, ADT creates the following folders and files in your new project:
src/<Android Version>/ (e.g., Android 1.1/)android.jar file that your application will build against.
This is determined by the build target that you have chosen in the New Project
Wizard.gen/R.java file
and interfaces created from AIDL files.assets/res/AndroidManifest.xmldefault.propertiesAn Android Virtual Device (AVD) is a device configuration for the emulator that allows you to model real world devices. In order to run an instance of the emulator, you must create an AVD.
To create an AVD from Eclipse:
Give it a name, a platform target, an SD card size, and a skin (HVGA is default).
Note: Be sure to define a target for your AVD that satisfies your application's Build Target (the AVD platform target must have an API Level equal to or greater than the API Level that your application compiles against).
Your AVD is now ready and you can either close the SDK and AVD Manager, create more AVDs, or launch an emulator with the AVD by selecting a device and clicking Start.
For more information about AVDs, read the Android Virtual Devices documentation.
Create multiple AVDs that each define a different device configuration with which your application is compatible, then launch each AVD into a new emulator from the SDK and AVD Manager. Set the target mode in your app's run configuration to manual, so that when you run your application, you can select from the available virtual devices.
Running your application from Eclipse will usually require just a couple clicks, whether you're running it on the emulator or on an attached device. The information below describes how to get set up and run your application from Eclipse.
Before you can run your application on the Android Emulator, you must create an AVD.
To run (or debug) your application, select Run > Run (or Run > Debug) from the Eclipse menu bar. The ADT plugin will automatically create a default launch configuration for the project. Eclipse will then perform the following:
By default, Android run configurations use an "automatic target" mode for selecting a device target. For information on how automatic target mode selects a deployment target, see Automatic and manual target modes below.
If debugging, the application will start in the "Waiting For Debugger" mode. Once the debugger is attached, Eclipse will open the Debug perspective.
To set or change the launch configuration used for your project, use the launch configuration manager. See Creating a Run Configuration for information.
Be certain to create multiple AVDs upon which to test your application. You should have one AVD for each platform and screen type with which your application is compatible. For instance, if your application compiles against the Android 1.5 (API Level 3) platform, you should create an AVD for each platform equal to and greater than 1.5 and an AVD for each screen type you support, then test your application on each one.
Before you can run your application on a device, you must perform some basic setup for your device:
Read Setting up a Device for Development for more information.
Once set up and your device is connected via USB, install your application on the device by selecting Run > Run (or Run > Debug) from the Eclipse menu bar.
The run configuration specifies the project to run, the Activity to start, the emulator or connected device to use, and so on. When you first run a project as an Android Application, ADT will automatically create a run configuration. The default run configuration will launch the default project Activity and use automatic target mode for device selection (with no preferred AVD). If the default settings don't suit your project, you can customize the launch configuration or even create a new.
To create or modify a launch configuration, follow these steps as appropriate for your Eclipse version:
In the Target tab, consider whether you'd like to use Manual or Automatic mode when selecting an AVD to run your application. See the following section on Automatic and manual target modes).
You can specify any emulator options to the Additional Emulator Command
Line Options field. For example, you could add -scale 96dpi to
scale the AVD's screen to an accurate size, based on the dpi of your
computer monitor. For a full list of emulator options, see the Android Emulator
document.
By default, a run configuration uses the automatic target mode in order to select an AVD. In this mode, ADT will select an AVD for the application in the following manner:
However, if a "preferred AVD" is selected in the run configuration, then the application will always be deployed to that AVD. If it's not already running, then a new emulator will be launched.
If your run configuration uses manual mode, then the "device chooser" is presented every time that your application is run, so that you can select which AVD to use.
As you begin developing Android applications, understand that all Android applications must be digitally signed before the system will install them on an emulator or an actual device. There are two ways to do this: with a debug key (for immediate testing on an emulator or development device) or with a private key (for application distribution).
The ADT plugin helps you get started quickly by signing your .apk files with a debug key, prior to installing them on an emulator or development device. This means that you can quickly run your application from Eclipse without having to generate your own private key. No specific action on your part is needed, provided ADT has access to Keytool.However, please note that if you intend to publish your application, you must sign the application with your own private key, rather than the debug key generated by the SDK tools.
Please read Signing Your Applications, which provides a thorough guide to application signing on Android and what it means to you as an Android application developer. The document also includes a guide to exporting and signing your application with the ADT's Export Wizard.
The SDK includes an example application called TicTacToeMain that shows how a dependent application can use code and resources from an Android Library project. The TicTacToeMain application uses code and resources from an example library project called TicTacToeLib.
To download the sample applications and run them as projects in your environment, use the Android SDK and AVD Manager to download the "Samples for SDK API 8" component into your SDK.
For more information and to browse the code of the samples, see the TicTacToeMain application.
An Android library project is a development project that holds
shared Android source code and resources. Other Android application projects can
reference the library project and, at build time, include its compiled sources
in their .apk files. Multiple application projects can reference
the same library project and any single application project can reference
multiple library projects.
If you have source code and resources that are common to multiple application projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
Structurally, a library project is similar to a standard Android application
project. For example, it includes a manifest file at the project root, as well
as src/, res/ and similar directories. The project can
contain the same types of source code and resources as a standard
Android project, stored in the same way. For example, source code in the library
project can access its own resources through its R class.
However, a library project differs from an standard Android application
project in that you cannot compile it directly to its own .apk or
run it on the Android platform. Similarly, you cannot export the library project
to a self-contained JAR file, as you would do for a true library. Instead, you
must compile the library indirectly, by referencing the library from a dependent
application's build path, then building that application.
When you build an application that depends on a library project, the SDK
tools compile the library and merge its sources with those in the main project,
then use the result to generate the .apk. In cases where a resource
ID is defined in both the application and the library, the tools ensure that the
resource declared in the application gets priority and that the resource in the
library project is not compiled into the application .apk. This
gives your application the flexibility to either use or redefine any resource
behaviors or values that are defined in any library.
To organize your code further, your application can add references to multiple library projects, then specify the relative priority of the resources in each library. This lets you build up the resources actually used in your application in a cumulative manner. When two libraries referenced from an application define the same resource ID, the tools select the resource from the library with higher priority and discard the other.
ADT lets you add references to library projects and set their relative priority from the application project's Properties. As shown in Figure 2, below, once you've added a reference to a library project, you can use the Up and Down controls to change the ordering, with the library listed at the top getting the higher priority. At build time, the libraries are merged with the application one at a time, starting from the lowest priority to the highest.
Note that a library project cannot itself reference another library project and that, at build time, library projects are not merged with each other before being merged with the application. However, note that a library can import an external library (JAR) in the normal way.
The sections below describe how to use ADT to set up and manage library your projects. Once you've set up your library projects and moved code into them, you can import library classes and resources to your application in the normal way.
Android library projects are a build-time construct, so you can use them to
build a final application .apk that targets any API level and is
compiled against any version of the Android library.
However, to use library projects, you need to update your development environment to use the latest tools and platforms, since older releases of the tools and platforms do not support building with library projects. Specifically, you need to download and install the versions listed below:
Table 1. Minimum versions of SDK tools and plaforms on which you can develop library projects.
| Component | Minimum Version |
|---|---|
| SDK Tools | r6 (or higher) |
| Android 2.2 platform | r1 (or higher) |
| Android 2.1 platform | r2 (or higher) |
| Android 2.0.1 platform | not supported |
| Android 2.0 platform | not supported |
| Android 1.6 platform | r3 (or higher) |
| Android 1.5 platform | r4 (or higher) |
| ADT Plugin | 0.9.7 (or higher) |
You can download the tools and platforms using the Android SDK and AVD Manager, as described in Adding SDK Components. To install or update ADT, use the Eclipse Updater as described in ADT Plugin for Eclipse.
A library project is a standard Android project, so you can create a new one in the same way as you would a new application project. Specifically, you can use the New Project Wizard, as described in Creating an Android Project, above.
When you are creating the library project, you can select any application name, package, and set other fields as needed, as shown in the diagram below. Click Finish to create the project in the workspace.
Next, set the project's Properties to indicate that it is a library project:
The new project is now marked as a library project. You can begin moving source code and resources into it, as described in the sections below.
You can also convert an existing application project into a library. To do so, simply open the Properties for the project and select the "is Library" checkbox. Other application projects can now reference the existing project as a library project.
Figure 1. Marking a project as an Android library project.
A library project's manifest file must declare all of the shared components that it includes, just as would a standard Android application. For more information, see the documentation for AndroidManifest.xml.
For example, the TicTacToeLib
example library project declares the Activity GameActivity:
<manifest>
...
<application>
...
<activity android:name="GameActivity" />
...
</application>
</manifest>
If you are developing an application and want to include the shared code or resources from a library project, you can do so easily by adding a reference to the library project in the application project's Properties.
To add a reference to a library project, follow these steps:
As soon as the Properties dialog closes, Eclipse rebuilds the project, including the contents of the library project.
The figure below shows the Properties dialog that lets you add library references and move them up and down in priority.
Figure 2. Adding a reference to a library project in the properties of an application project.
If you are adding references to multiple libraries, note that you can set their relative priority (and merge order) by selecting a library and using the Up and Down controls. The tools merge the referenced libraries with your application starting from lowest priority (bottom of the list) to highest (top of the list). If more than one library defines the same resource ID, the tools select the resource from the library with higher priority. The application itself has highest priority and its resources are always used in preference to identical resource IDs defined in libraries.
In the manifest file of the application project, you must add declarations
of all components that the application will use that are imported from a library
project. For example, you must declare any <activity>,
<service>, <receiver>,
<provider>, and so on, as well as
<permission>, <uses-library>, and similar
elements.
Declarations should reference the library components by their fully-qualified package names, where appropriate.
For example, the TicTacToeMain
example application declares the library Activity GameActivity
like this:
<manifest>
...
<application>
...
<activity android:name="com.example.android.tictactoe.library.GameActivity" />
...
</application>
</manifest>
For more information about the manifest file, see the documentation for AndroidManifest.xml.
As you develop your library project and dependent applications, keep the points listed below in mind.
Resource conflicts
Since the tools merge the resources of a library project with those of a dependent application project, a given resource ID might be defined in both projects. In this case, the tools select the resource from the application, or the library with highest priority, and discard the other resource. As you develop your applications, be aware that common resource IDs are likely to be defined in more than one project and will be merged, with the resource from the application or highest-priority library taking precedence.
Using prefixes to avoid resource conflicts
To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the project (or is unique across all projects).
No export of library project to JAR
A library cannot be distributed as a binary file (such as a jar file). This is because the library project is compiled by the main project to use the correct resource IDs.
A library project can include a JAR library
You can develop a library project that itself includes a JAR library, however you need to manually edit the dependent application project's build path and add a path to the JAR file.
A library project can depend on an external JAR library
You can develop a library project that depends on an external library (for
example, the Maps external library). In this case, the dependent application
must build against a target that includes the external library (for example, the
Google APIs Add-On). Note also that both the library project and the dependent
application must declare the external library their manifest files, in a <uses-library>
element.
Library project can not include raw assets
The tools do not support the use of raw asset files in a library project.
Any asset resources used by an application must be stored in the
assets/ directory of the application project
itself.
Targeting different Android platform versions in library project and application project
A library is compiled as part of the dependent application project, so the API used in the library project must be compatible with the version of the Android library used to compile the application project. In general, the library project should use an API level that is the same as — or lower than — that used by the application. If the library project uses an API level that is higher than that of the application, the application project will fail to compile. It is perfectly acceptable to have a library that uses the Android 1.5 API (API level 3) and that is used in an Android 1.6 (API level 4) or Android 2.1 (API level 7) project, for instance.
No restriction on library package name
There is no requirement for the package name of a library to be the same as that of applications that use it.
Multiple R classes in gen/ folder of application project
When you build the dependent application project, the code of any libraries
is compiled and merged to the application project. Each library has its own
R class, named according to the library's package name. The
R class generated from the resources of the main project and of the
library is created in all the packages that are needed including the main
project’s package and the libraries’ packages.
Testing a library project
There are two recommended ways of setting up testing on code and resources in a library project:
Library project storage location
There are no specific requirements on where you should store a library project, relative to a dependent application project, as long as the application project can reference the library project by a relative link. You can place the library project What is important is that the main project can reference the library project through a relative link.
This section provides information about how to migrate a library project created with ADT 0.9.7 to ADT 0.9.8 (or higher). The migration is needed only if you are developing in Eclipse with ADT and assumes that you have also upgraded to SDK Tools r7 (or higher).
The way that ADT handles library projects has changed between
ADT 0.9.7 and ADT 0.9.8. Specifically, in ADT 0.9.7, the src/
source folder of the library was linked into the dependent application project
as a folder that had the same name as the library project. This worked because
of two restrictions on the library projects:
gen/ source folder), andsrc/ and be
stored at the root of the project.In ADT 0.9.8, both of those restrictions were removed. A library project can
have as many source folders as needed and each can have any name. Additionally,
a library project can store source folders in any location of the project. For
example, you could store sources in a src/java/ directory. In order
to support this, the name of the linked source folders in the main project are
now called <library-name>_<folder-name> For
example: MyLibrary_src/ or MyLibrary_src_java/.
Additionally, the linking process now flags those folders in order for ADT to recognize that it created them. This will allow ADT to automatically migrate the project to new versions of ADT, should they contain changes to the handling of library projects. ADT 0.9.7 did not flag the linked source folders, so ADT 0.9.8 cannot be sure whether the old linked folders can be removed safely. After upgrading ADT to 0.9.8, you will need to remove the old linked folders manually in a simple two-step process, as described below.
Before you begin, make sure to create a backup copy of your application or save the latest version to your code version control system. This ensures that you will be able to easily revert the migration changes in case there is a problem in your environment.
When you first upgrade to ADT 0.9.8, your main project will look as shown
below, with two linked folders (in this example, MyLibrary and
MyLibrary_src — both of which link to
MyLibrary/src. Eclipse shows an error on one of them because they
are duplicate links to a single class.
To fix the error, remove the linked folder that does not contain the
_src suffix.
MyLibrary folder) and choose Build Path >
Remove from Build Path, as shown below.
This should resolve the error and migrate your library project to the new ADT environment.
You can execute arbitrary code when paused at a breakpoint in Eclipse. For example,
when in a function with a String argument called "zip", you can get
information about packages and call class methods. You can also invoke arbitrary
static methods: for example, entering android.os.Debug.startMethodTracing() will
start dmTrace.
Open a code execution window, select Window > Show View > Display from the main menu to open the Display window, a simple text editor. Type your expression, highlight the text, and click the 'J' icon (or CTRL + SHIFT + D) to run your code. The code runs in the context of the selected thread, which must be stopped at a breakpoint or single-step point. (If you suspend the thread manually, you have to single-step once; this doesn't work if the thread is in Object.wait().)
If you are currently paused on a breakpoint, you can simply highlight and execute a piece of source code by pressing CTRL + SHIFT + D.
You can highlight a block of text within the same scope by pressing ALT +SHIFT + UP ARROW to select larger and larger enclosing blocks, or DOWN ARROW to select smaller blocks.
Here are a few sample inputs and responses in Eclipse using the Display window.
| Input | Response |
|---|---|
zip |
(java.lang.String)
/work/device/out/linux-x86-debug/android/app/android_sdk.zip |
zip.endsWith(".zip") |
(boolean) true |
zip.endsWith(".jar") |
(boolean) false |
You can also execute arbitrary code when not debugging by using a scrapbook page. Search the Eclipse documentation for "scrapbook".
Although the recommended way to debug is to use the ADT plugin, you can manually run DDMS and configure Eclipse to debug on port 8700. (Note: Be sure that you have first started DDMS).