Community
-Welcome to the Android developers community! We're glad you're here and invite you to participate in these discussions. Before posting, please read the Groups Charter that covers the community guidelines.
+Community
+Welcome to the Android developers community! We're glad you're here and invite you to participate in these discussions. Before posting, please read the Groups Charter that covers the community guidelines.
Note: If you are seeking discussion about Android source code (not application development), then please refer to the Open Source Project Mailing lists.
@@ -53,48 +53,42 @@ phrasing your questions, read android-beginners -- Subscribe using Google Groups: android-developers -
- Subscribe via email: android-developers-subscribe@googlegroups.com - +
- Subscribe via email: android-developers-subscribe@googlegroups.com
- Subscribe using Google Groups: android-discuss -
- Subscribe via email: android-discuss-subscribe@googlegroups.com - +
- Subscribe via email: android-discuss-subscribe@googlegroups.com
- Subscribe using Google Groups: android-ndk -
- Subscribe via email: android-ndk-subscribe@googlegroups.com - +
- Subscribe via email: android-ndk-subscribe@googlegroups.com
- Subscribe using Google Groups: android-security-discuss -
- Subscribe via email: android-security-discuss@googlegroups.com - +
- Subscribe via email: android-security-discuss@googlegroups.com
- Subscribe using Google Groups: android-security-announce -
- Subscribe via email: android-security-announce-subscribe@googlegroups.com - +
- Subscribe via email: android-security-announce-subscribe@googlegroups.com
The Android API Level is an integer that indicates a set of APIs available in an Android SDK -and on a version of the Android platform. Each version of the Android platform supports a specific set -of APIs, which are always backward-compatible. For example, Android 1.5 supports all APIs available in -Android 1.0, but the reverse is not true. If an application uses APIs -available in Android 1.5 that are not available in 1.0, then the application should never be installed -on an Android 1.0 device, because it will fail due to missing APIs. The API Level ensures this does not happen -by comparing the minimum API Level required by the applicaiton to the API Level available on the device.
+In this document
+-
+
- What is API Level? +
- Uses of API Level +
- Development Considerations + + +
- Filtering the documentation +
When a new version of Android adds APIs, a new API Level is added to the platform. The new APIs
-are available only to applications that declare a minimum API Level that is equal-to or greater-than
-the API Level in which the APIs were introduced. The API Level required by an application is declared with the
-<uses-sdk> element inside the Android manifest, like this:
See also
+-
+
- <uses-sdk> manifest element +
<uses-sdk android:minSdkVersion="3" />+
The value for minSdkVersion is the minimum API Level required by the application.
-If this is not declared, then it is assumed that the application is compatible with all versions and defaults to
-API Level 1. In which case, if the application actually uses APIs introduced with an API Level greater than 1, then
-the application will fail in unpredictable ways when installed on a device that only supports API Level 1
-(such as an Android 1.0 device).
-See the <uses-sdk>
-documentation for more about declaring the API Level in your manifest.
As you develop your application on Android, it's useful to understand the +platform's general approach to API change management. It's also important to +understand the API Level identifier and the role it plays in ensuring your +application's compatibility with devices on which it may be installed.
-For example, the {@link android.appwidget} package was introduced with API Level 3. If your application
-has set minSdkVersion to 1 or 2, then your application cannot use this package,
-even if the device running your application uses a version of Android that supports it.
-In order to use the {@link android.appwidget} package, your application must set minSdkVersion
-to 3 or higher. When the minSdkVersion is set to 3, the application will no longer be able to install
-on a device running a platform version with an API Level less than 3.
The sections below provide information about API Level and how it affects +your applications.
-Despite the name of the manifest attribute (minSdkVersion), the API Level is not directly
-associated with a specific SDK. For example, the SDK for Android 1.0 uses
-API Level 1 and the SDK for Android 1.1 uses API Level 2. So it may seem that the API Level increases consistently.
-However, it's possible that a subsequent platform
-releases will not introduce new APIs, and thus, the API Level will remain the same. In addition, there are often
-multiple SDK releases for a single platform version (there were three SDK releases for Android 1.5), and
-there's no guarantee that the API Level will remain the same between these. It's possible (but unlikely) that
-a second or third SDK for a given version of the platform will provide new APIs and add a new API Level.
-When you install a new SDK, be sure to read the SDK Contents on the install page, which specifies the API
-Level for each platform available in the SDK. Also see the comparison of
-Platform Versions vs. API Levels, below.
For information about how to use the "Filter by API Level" control +available in the API reference documentation, see +Filtering the documentation at the +end of this document.
-Note: During an "Early Look" SDK release, the APIs may not be final, so the
-API Level number cannot be specified. In this case, a string value matching the
-platform codename must be used as the value for minSdkVersion. This codename value
-will only be valid while using the Early Look SDK with the emulator. An application using this API Level
-can never be installed on an Android device. When the final SDK is released, you must update your manifest to use
-the official API Level integer.
What is API Level?
-Platform Versions vs. API Levels
+API Level is an integer value that uniquely identifies the framework API +revision offered by a version of the Android platform.
-The following table specifies the maximum API Level supported by each version of the Android platform. -(Every platform is backward-compatible to API Level 1.)
+The Android platform provides a framework API that applications can use to +interact with the underlying Android system. The framework API consists of:
+ +-
+
- A core set of packages and classes +
- A set of XML elements and attributes for declaring a manifest file +
- A set of XML elements and attributes for declaring and accessing resources +
- A set of Intents +
- A set of permissions that applications can request, as well as permission +enforcements included in the system +
Each successive version of the Android platform can include updates to the +Android application framework API that it delivers.
+ +Updates to the framework API are designed so that the new API remains +compatible with earlier versions of the API. That is, most changes in the API +are additive and introduce new or replacement functionality. As parts of the API +are upgraded, the older replaced parts are deprecated but are not removed, so +that existing applications can still use them. In a very small number of cases, +parts of the API may be modified or removed, although typically such changes are +only needed to ensure API robustness and application or system security. All +other API parts from earlier revisions are carried forward without +modification.
+ +The framework API that an Android platform delivers is specified using an +integer identifier called "API Level". Each Android platform version supports +exactly one API Level, although support is implicit for all earlier API Levels +(down to API Level 1). The initial release of the Android platform provided +API Level 1 and subsequent releases have incremented the API Level.
+ +The following table specifies the API Level supported by each version of the +Android platform.
| Platform Version | API Level |
|---|---|
| Android 1.0 | 1 |
| Android 1.1 | 2 |
| Android 1.6 | 4 |
| Android 1.5 | 3 |
| Android Donut | Donut |
| Android 1.1 | 2 |
| Android 1.0 | 1 |
Viewing the API Reference Based on API Level
+Uses of API Level in Android
-The Android API reference includes information that specififies the minimum API Level required for each -package, class, and member. You can see this information on the right side of each header or label.
+The API Level identifier serves a key role in ensuring the best possible +experience for users and application developers: -
By default, the reference documentation shows all APIs available with the latest SDK release. -This means that the reference assumes you're using the latest API Level and will show you everything available -with it. If you're developing applications for a version of Android that does not support the latest API Level, -then you can filter the reference to reveal only the packages, classes, and members available for that API Level. -When viewing the reference, use the "Filter by API Level" selection box (below the search box) to pick the API Level -you'd like to view.
+-
+
- It lets the Android platform describe the maximum framework API revision +that it supports +
- It lets applications describe the framework API revision that they +require +
- It lets the system negotiate the installation of applications on the user's +device, such that version-incompatible applications are not installed on a +user's device +
Each Android platform version stores its API Level identifier internally, in +the Android system itself.
+ +Applications can use a manifest element provided by the framework API —
+<uses-sdk> — to describe the minimum and maximum API
+Levels under which they are able to run, as well as the preferred API Level that
+they are designed to support. The element offers two key attributes:
-
+
android:minSdkVersion— Specifies the minimum API Level +on which the application is able to run. The default value is "1".
+android:maxSdkVersion— Specifies the maximum API Level +on which the application is able to run.
+
For example, to specify the minimum system API Level that an application
+requires in order to run, the application would include in its manifest a
+<uses-sdk> element with a android:minSdkVersion
+attribute. The value of android:minSdkVersion would be the integer
+corresponding to the API Level of the earliest version of the Android platform
+under which the application can run.
When the user attempts to install an application, the Android system first
+checks the <uses-sdk> attributes in the application's
+manifest and compares them against its own internal API Level. The system
+allows the installation to begin only if these conditions are met:
-
+
- If a
android:minSdkVersionattribute is declared, its value +must be less than or equal to the system's API Level integer. If not declared, +the system assumes that the application requires API Level 1.
+ - If a
android:maxSdkVersionattribute is declared, its value +must be equal to or greater than the system's API Level integer. +in the system itself. If not declared, the system assumes that the application +has no maximum API Level.
+
When declared in an application's manifest, a <uses-sdk>
+element might look like this:
<manifest> + ... + <uses-sdk android:minSdkVersion="4" /> + ... +</manifest>+ +
The principal reason that an application would declare an API Level in
+android:minSdkVersion is to tell the Android system that it is
+using APIs that were introduced in the API Level specified. If the
+application were to be somehow installed on a platform with a lower API Level,
+then it would crash at run-time when it tries to access APIs that don't exist.
+The system prevents such an outcome by not allowing the application to be
+installed if the lowest API Level it requires is higher than that of the
+platform version on the target device.
For example, the {@link android.appwidget} package was introduced with API
+Level 3. If an application uses that API, it must declare a
+android:minSdkVersion attribute with a value of "3". The
+application will then be installable on platforms such as Android 1.5 (API Level
+3) and Android 1.6 (API Level 4), but not on the Android 1.1 (API Level 2) and
+Android 1.0 platforms (API Level 1).
For more information about how to specify an application's API Level
+requirements, see the <uses-sdk>
+ section of the manifest file documentation.
Development Considerations
+The sections below provide information related to API level that you should +consider when developing your application.
+ +Application forward compatibility
+ +Android applications are generally forward-compatible with new versions of +the Android platform.
+ +Because almost all changes to the framework API are additive, an Android +application developed using any given version of the API (as specified by its +API Level) is forward-compatible with later versions of the Android platform and +higher API levels. The application should be able to run on all later versions +of the Android platform, except in isolated cases where the application uses a +part of the API that is later removed for some reason.
+ +Forward compatibility is important because many Android-powered devices +receive over-the-air (OTA) system updates. The user may install your +application and use it successfully, then later receive an OTA update to a new +version of the Android platform. Once the update is installed, your application +will run in a new run-time version of the environment, but one that has the API +and system capabilities that it depends on.
+ +In some cases, changes below the API, such those in the underlying +system itself, may affect your application when it is run in the new +environment. For that reason it's important for you, as the application +developer, to understand how the application will look and behave in each system +environment. To help you test your application on various versions of the Android +platform, the Android SDK includes multiple platforms that you can download. +Each platform includes a compatible system image that you can run in an AVD, to +test your application.
+ +Application backward compatibility
+ +Android applications are not necessarily backward compatible with versions of +the Android platform older than the version against which they were compiled. +
+ +Each new version of the Android platform can include new framework APIs, such +as those that give applications access to new platform capabilities or replace +existing API parts. The new APIs are accessible to applications when running on +the new platform and, as mentioned above, also when running on later versions of +the platform, as specified by API Level. Conversely, because earlier versions of +the platform do not include the new APIs, applications that use the new APIs are +unable to run on those platforms.
+ +Although it's unlikely that an Android-powered device would be downgraded to +a previous version of the platform, it's important to realize that there are +likely to be many devices in the field that run earlier versions of the +platform. Even among devices that receive OTA updates, some might lag and not +receive an update for a significant amount of time.
+ +Selecting a platform version and API Level
+ +When you are developing your application, you will need to choose +the platform version against which you will compile the application. In +general, you should compile your application against the lowest possible +version of the platform that your application can support. + +
You can determine the lowest possible platform version by compiling the
+application against successively lower build targets. After you determine the
+lowest version, you should create an AVD using the corresponding platform
+version (and API Level) and fully test your application. Make sure to declare a
+android:minSdkVersion attribute in the application's manifest and
+set its value to the API Level of the platform version.
Declaring a minimum API Level
+ +If you build an application that uses APIs or system features introduced in
+the latest platform version, you should set the
+android:minSdkVersion attribute to the API Level of the latest
+platform version. This ensures that users will only be able to install your
+application if their devices are running a compatible version of the Android
+platform. In turn, this ensures that your application can function properly on
+their devices.
If your application uses APIs introduced in the latest platform version but
+does not declare a android:minSdkVersion attribute, then
+it will run properly on devices running the latest version of the platform, but
+not on devices running earlier versions of the platform. In the latter
+case, the application will crash at runtime when it tries to use APIs that don't
+exist on the earlier versions.
Testing against higher API Levels
+ +After compiling your application, you should make sure to test it on the
+platform specified in the application's android:minSdkVersion
+attribute. To do so, create an AVD that uses the platform version required by
+your application. Additionally, to ensure forward-compatibility, you should run
+and test the application on all platforms that use a higher API Level than that
+used by your application.
The Android SDK includes multiple platform versions that you can use, +including the latest version, and provides an updater tool that you can use to +download other platform versions as necessary.
+ +To access the updater, use the android command-line tool,
+located in the <sdk>/tools directory. You can launch the Updater by using
+the android command without specifying any options. You can
+also simply double-click the android.bat (Windows) or android (OS X/Linux) file.
+In ADT, you can also access the updater by selecting
+Window > Android SDK and AVD
+Manager.
To run your application against different platform versions in the emulator, +create an AVD for each platform version that you want to test. For more +information about AVDs, see Android Virtual Devices. If +you are using a physical device for testing, ensure that you know the API Level +of the Android platform it runs. See the table at the top of this document for +a list of platform versions and their API Levels.
+ + + +Filtering the Reference Documentation by API Level
+ +Reference documentation pages on the Android Developers site offer a "Filter +by API Level" control in the top-right area of each page.
+ +The "Filter by API Level" lets you show documentation only for parts of the
+API that are actually accessible to your application, based on the API Level
+that it specifies in the minSdkVersion attribute in its manifest
+file
When you filter the reference documentation by an API level, only the APIs +available at that API level are shown. APIs introduced in a later API level are +grayed out and their content is masked, since they would not be accessible to +your application.
+ +Note that filtering by API Level in the documentation does not provide a view +of what is new or introduced in each API Level. Filtering simply provides a way +to view the entire API associated with a given API Level, while excluding API +elements introduced in later API Levels.
+ +By default, API Level filtering is enabled and set to show the latest API +Level. If you do not want to use filtering reference documentation, select the +highest available API Level.
+ +Note that the reference documentation for API elements also specifies the API +Level at which the element was introduced. The API Level for packages and +classes is specified as "Since <api level>" at the top-right corner of the +content area on each documentation page. The API Level for each class member is +specified in the member's detailed description section header, at the right +margin.
diff --git a/docs/html/guide/developing/eclipse-adt.jd b/docs/html/guide/developing/eclipse-adt.jd index a5cf7358500cf..c3ec2e552cc53 100644 --- a/docs/html/guide/developing/eclipse-adt.jd +++ b/docs/html/guide/developing/eclipse-adt.jd @@ -149,15 +149,15 @@ on running your applicaiton.Creating an AVD
-With ADT 0.9.2 and above, the Android AVD Manager provides a simple graphical interface +
With ADT 0.9.3 and above, the Android SDK and AVD Manager provides a simple graphical interface
for creating and managing AVDs. (If you're using ADT version 0.9.1 or older, you must
use the android tool to create your AVDs—read the AVD guide to
Creating an AVD.)
-
To create an AVD with the Android AVD Manager:
+To create an AVD with the AVD Manager:
-
-
- Select Window > Android AVD Manager, or click the Android AVD Manager icon (a black device) +
- Select Window > Android SDK and AVD Manager, or click the Android SDK and AVD Manager icon (a black device) in the Eclipse toolbar.
- In the Virtual Devices panel, you'll see a list of existing AVDs. Click New
@@ -169,7 +169,7 @@ use the
androidtool to create your AVDs—read the AVD guide t - Click Create AVD.
Your AVD is now ready and you can close the Android AVD Manager. +
Your AVD is now ready and you can close the AVD Manager. In the next section, you'll see how the AVD is used when launching your application on an emulator.
@@ -217,7 +217,7 @@ to start, the emulator options 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 setting don't suit your project, you can +(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 @@ -256,6 +256,12 @@ for your Eclipse version:
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.
tools/ directory of your SDK and run:
android create project \
---target <targetID> \
+--target <target_ID> \
+--name <your_project_name> \
--path /path/to/your/project \
--activity <your_activity_name> \
--package <your_package_namespace>
@@ -96,11 +97,14 @@ android create project \
to an Android platform library (including any add-ons, such as Google APIs) that you would like to
build your project against. To see a list of available targets and their corresponding IDs,
execute: android list targets.
+ name is the name for your project. This is optional. If provided, this name will be used
+ for your .apk filename when you build your application.path is the location of your project directory. If the directory does not exist,
it will be created for you.activity is the name for your {@link android.app.Activity} class. This class file
+ activity is the name for your default {@link android.app.Activity} class. This class file
will be created for you inside
- <path_to_your_project>/src/<your_package_namespace_path>/.<path_to_your_project>/src/<your_package_namespace_path>/.
+ This will also be used for your .apk filename unless you provide a the name.
package is the package namespace for your project, following the same rules as for
packages in the Java programming language.android create project \ --target 1 \ ---path ./myProject \ ---activity MyActivity \ ---package com.example.myproject +--name MyAndroidApp \ +--path ./MyAndroidAppProject \ +--activity MyAndroidAppActivity \ +--package com.example.myandroid
The tool generates the following files and directories:
@@ -123,7 +128,8 @@ android create project \default.properties - Properties for the build system. Do not modify
this file.build.properties - Customizable properties for the build system. You can edit this
- file to overried default build settings used by Ant.src/your/package/namespace/ActivityName.java - The Activity class
you specified during project creation.bin/ - Output directory for the build script.tools/ folder.
-Note: You should refrain from moving the +
Caution: You should refrain from moving the location of the SDK directory, because this will break the build scripts. (They will need to be manually updated to reflect the new SDK location before they will work again.)
@@ -153,14 +159,15 @@ work again.) a new project from existing code, use theandroid update project command to update the project to the new development
environment. You can also use this command to revise the build target of an existing project
-(with the --target option). The android tool will generate any files and
+(with the --target option) and the project name (with the --name
+option). The android tool will generate any files and
folders (listed in the previous section) that are either missing or need to be updated,
as needed for the Android project.
To update an existing Android project, open a command-line
and navigate to the tools/ directory of your SDK. Now run:
-android update project --target <targetID> --path path/to/your/project/ +android update project --name <project_name> --target <target_ID> --path path/to/your/project/
-
@@ -169,11 +176,13 @@ android update project --target <targetID> --path path/to/you
like to build your project against. To see a list of available targets and their corresponding IDs,
execute:
pathis the location of your project directory.
+ nameis the name for the project. This is optional—if you're not + changing the project name, you don't need this.
android list targets.
Here's an example:
-android update project --target 2 --path ./myProject +android update project --name MyApp --target 2 --path ./MyAppProject@@ -237,8 +246,9 @@ install JDK in a non-space directory, for example:
c:\java\jdk1.6.0_02Building in debug mode
For immediate application testing and debugging, you can build your application
-in debug mode and immediately install it on an emulator. In debug mode, the build tools automatically
-sign your application with a debug key. However, you can (and should) also test your
+in debug mode and immediately install it on an emulator. In debug mode, the build tools
+automatically sign your application with a debug key and optimize the package with
+{@code zipalign}. However, you can (and should) also test your
application in release mode. Debug mode simply allows you to run your application without
manually signing the application.
@@ -248,9 +258,9 @@ manually signing the application.
Open a command-line and navigate to the root of your project directory.
Use Ant to compile your project in debug mode:
ant debug
- This creates your Android application .apk file inside the project bin/
- directory, named <your_DefaultActivity_name>-debug.apk. The file
- is already signed with the debug key.
+ This creates your debug .apk file inside the project bin/
+ directory, named <your_project_name>-debug.apk. The file
+ is already signed with the debug key and has been aligned with {@code zipalign}.
@@ -267,23 +277,86 @@ about Running Your Application.
your application in release mode. Once you have built in release mode, it's a good idea to perform
additional testing and debugging with the final .apk.
-To build in release mode:
+Before you start building your application in release mode, be aware that you must sign
+the resulting application package with your private key, and should then align it using the
+{@code zipalign} tool. There are two approaches to building in release mode:
+build an unsigned package in release mode and then manually sign and align
+the package, or allow the build script
+to sign and align the package for you.
+
+Build unsigned
+
+If you build your application unsigned, then you will need to
+manually sign and align the package.
+
+To build an unsigned .apk in release mode:
- Open a command-line and navigate to the root of your project directory.
- Use Ant to compile your project in release mode:
ant release
- This creates your Android application .apk file inside the project bin/
- directory, named <your_DefaultActivity_name>.apk.
- Note: The .apk file is unsigned at this point.
- You can't install it on an emulator or device until you sign it with your private key.
-Because release mode builds your application unsigned, your next step is to sign
-it with your private key, in order to distribute it to end-users. To complete this procedure,
+
This creates your Android application .apk file inside the project bin/
+directory, named <your_project_name>-unsigned.apk.
+
+Note: The .apk file is unsigned at this point
+and can't be installed until signed with your private key.
+
+Once you have created the unsigned .apk, your next step is to sign the .apk
+with your private key and then align it with {@code zipalign}. To complete this procedure,
read Signing Your Applications.
+When your .apk has been signed and aligned, it's ready to be distributed to end-users.
+
+Build signed and aligned
+
+If you would like, you can configure the Android build script to automatically
+sign and align your application package. To do so, you must provide the path to your keystore
+and the name of your key alias in your project's {@code build.properties} file. With this
+information provided, the build script will prompt you for your keystore and alias password
+when you build in release mode and produce your final application package, which will be ready
+for distribution.
+
+Caution: Due to the way Ant handles input, the password that
+you enter during the build process will be visible. If you are
+concerned about your keystore and alias password being visible on screen, then you
+may prefer to perform the application signing manually, via Jarsigner (or a similar tool). To instead
+perform the signing procedure manually, buid unsigned and then continue
+with Signing Your Applications.
+
+To specify your keystore and alias, open the project {@code build.properties} file (found in the
+root of the project directory) and add entries for {@code key.store} and {@code key.alias}.
+For example:
+
+
+key.store=/path/to/my.keystore
+key.alias=mykeystore
+
+
+Save your changes. Now you can build a signed .apk in release mode:
+
+
+ - Open a command-line and navigate to the root of your project directory.
+ - Use Ant to compile your project in release mode:
+
ant release
+
+ - When prompted, enter you keystore and alias passwords.
+
Caution: As described above,
+ your password will be visible on the screen.
+
+
+
+This creates your Android application .apk file inside the project bin/
+directory, named <your_project_name>-release.apk.
+This .apk file has been signed with the private key specified in
+{@code build.properties} and aligned with {@code zipalign}. It's ready for
+installation and distribution.
+
+
+Once built and signed in release mode
+
Once you have signed your application with a private key, you can install it on an
emulator or device as discussed in the following section about
Running Your Application.
@@ -329,7 +402,7 @@ id:2
you'll use this in the next step.
Create a new AVD using your selected deployment target:
- android create avd --name <your_avd_name> --target <targetID>
+ android create avd --name <your_avd_name> --target <target_ID>
Next, you'll be asked whether you'd like to create a custom hardware profile.
If you respond "yes," you'll be presented with a series of prompts to define various aspects of the
device hardware (leave entries blank to use default values, which are shown in brackets). Otherwise,
diff --git a/docs/html/guide/developing/tools/avd.jd b/docs/html/guide/developing/tools/avd.jd
index b8f205ec0f7e6..06b1245c426db 100644
--- a/docs/html/guide/developing/tools/avd.jd
+++ b/docs/html/guide/developing/tools/avd.jd
@@ -11,6 +11,8 @@ page.title=Android Virtual Devices
hardware options, system image, and data storage.
You create AVD configurations to model different device environments
in the Android emulator.
+ The android tool offers a graphical Android AVD
+ Manager and a command-line interface for creating AVDs.
In this document
@@ -72,9 +74,18 @@ reference of emulator options, please see the Emulator
documentation.
-To create and manage AVDs, you use the android tool provided in the Android
-SDK. For more information about how to work with AVDs from inside
-your development environment, see To create and manage AVDs, you use the android tool provided in
+the tools/ directory of the Android SDK. The tool provides both a
+graphical AVD manager and a command-line interface that you can use to
+create AVDs. To access the graphical AVD manager, run the
+android tool without options. The sections below describe how to
+use the android command-line interface to create and manage AVDs.
+Note that some functionality, such as the capability to create an AVD with a
+custom hardware configuration, are only available through the command-line
+interface.
+
+For more information about how to work with AVDs from inside your development
+environment, see Developing in Eclipse with
ADT or Developing in
Other IDEs, as appropriate for your environment.
@@ -89,11 +100,11 @@ you need to create an AVD before you can run any application in the emulator
+
