Projects act as containers for storing things such as code and resource files. The SDK tools
expect your projects to follow a specific structure so it can compile and package your
application correctly, so it is highly recommended that you create them with Eclipse and ADT or
with the android tool on the command line. There are three types of projects, and
they all share the same general structure but differ in function:
.apk file that you install on a
device..apk file at build time.When you use the Android development tools to create a new project, the essential files and
folders will be created for you. There are only a handful of files and folders generated for you,
and some of them depend on whether you use the Eclipse plugin or the android tool to
generate your project. As your application grows in complexity, you might require new kinds of
resources, directories, and files.
Android projects are the projects that eventually get built into an .apk file that you install
onto a device. They contain things such as application source code and resource files.
Some are generated for you by default, while others should be created if
required. The following directories and files comprise an Android project:
src/src/your/package/namespace/ActivityName.java. All other source code
files (such as .java or .aidl files) go here as well.bin.apk file and other
compiled resources.jnigen/R.java file and
interfaces created from AIDL files.assets/.apk file as-is, and the original filename is preserved. You can navigate this
directory in the same way as a typical file system using URIs and read files as a stream of
bytes using the the AssetManager. For example, this is a good
location for textures and game data.res/anim/color/drawable/layout/menu/raw/assets/ directory only differs in the way that you access them. These files
are processed by aapt and must be referenced from the application using a resource
identifier in the R class. For example, this is a good place for media, such as MP3
or Ogg files.values/res/ directory, resources written to XML files in this folder are not
referenced by the file name. Instead, the XML element type controls how the resources is
defined within them are placed into the R class.xml/PreferenceScreen, AppWidgetProviderInfo, or Searchability
Metadata. See Application Resources
for more information about configuring these application components.libs/AndroidManifest.xmlbuild.propertiesbuild.xmldefault.propertiesThe 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 Android 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 and run it on an Android device.
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 in the dependent application and 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.
Once you have added references to library projects to your Android project, you can set their relative 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.
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 platforms 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.
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.
Use 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).
You cannot export a library project to a JAR file
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.
One library project cannot reference another
A library cannot depend on another library
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 in their manifest
files, in a <uses-library>
element.
Library project cannot include AIDL files
The tools do not support the use of AIDL files in a library project. Any AIDL files used by an application must be stored in the application project itself.
Library projects cannot include raw assets
The tools do not support the use of raw asset files (saved in the assets/ directory)
in a library project. Any asset resources
used by an application must be stored in the assets/ directory of the application
project itself. However, resource files saved in the
res/ directory are supported.
Platform version must be lower than or equal to the Android 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 not 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 names
There is no requirement for the package name of a library to be the same as that of applications that use it.
Each library project creates its own R class
When you build the dependent application project, library projects are compiled and
merged with the application project. Each library has its own R class, named according
to the library's package name. The R class generated from main
project and the library project is created in all the packages that are needed including the main
project's package and the libraries' packages.
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. 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
in figure 1, 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.
Figure 1. Library project migration error
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 in figure 2.
Figure 2. Remove from Build Path menu item
Figure 3. Unlink folder confirmation window
This should resolve the error and migrate your library project to the new ADT environment.
Test projects contain Android applications that you write using the Testing and Instrumentation framework. The framework is an extension of the JUnit test framework and adds access to Android system objects. The file structure of a test project is the same as an Android project.
src/.java
file, but can include one.gen/R.java file and
interfaces created from AIDL files.assets/res/AndroidManifest.xml<instrumentation>
element that connects the test project with the application project.build.propertiesbuild.xmldefault.propertiesThere are two recommended ways of setting up testing on code and resources in a library project: