summaryrefslogtreecommitdiff
path: root/docs/html/guide/appendix/api-levels.jd
diff options
context:
space:
mode:
Diffstat (limited to 'docs/html/guide/appendix/api-levels.jd')
-rw-r--r--docs/html/guide/appendix/api-levels.jd386
1 files changed, 321 insertions, 65 deletions
diff --git a/docs/html/guide/appendix/api-levels.jd b/docs/html/guide/appendix/api-levels.jd
index 8fc899bb4cc2..31581924c744 100644
--- a/docs/html/guide/appendix/api-levels.jd
+++ b/docs/html/guide/appendix/api-levels.jd
@@ -1,81 +1,337 @@
page.title=Android API Levels
@jd:body
+<div id="qv-wrapper">
+<div id="qv">
-<p>The Android <em>API Level</em> 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.</p>
-
-<p>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
-<code>&lt;uses-sdk></code> element inside the Android manifest, like this:</p>
-
-<pre>&lt;uses-sdk android:minSdkVersion="3" /></pre>
-
-<p>The value for <code>minSdkVersion</code> 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 <code><a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">&lt;uses-sdk></a></code>
-documentation for more about declaring the API Level in your manifest.</p>
-
-<p>For example, the {@link android.appwidget} package was introduced with API Level 3. If your application
-has set <code>minSdkVersion</code> 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 <code>minSdkVersion</code>
-to 3 or higher. When the <code>minSdkVersion</code> 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.</p>
-
-<p>Despite the name of the manifest attribute (<code>minSdkVersion</code>), 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
-<a href="#VersionsVsApiLevels">Platform Versions vs. API Levels</a>, below.</p>
-
-<p class="note"><strong>Note:</strong> 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 <code>minSdkVersion</code>. 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.</p>
-
-<h2 id="VersionsVsApiLevels">Platform Versions vs. API Levels</h2>
-
-<p>The following table specifies the <em>maximum</em> API Level supported by each version of the Android platform.
-(Every platform is backward-compatible to API Level 1.)</p>
+ <h2>In this document</h2>
+<ol>
+ <li><a href="intro">What is API Level?</a></li>
+ <li><a href="#uses">Uses of API Level in Android</a></li>
+ <li><a href="#considerations">Development Considerations</a>
+ <ol>
+ <li><a href="#fc">Application forward compatibility</a></li>
+ <li><a href="#bc">Application backward compatibility</a></li>
+ <li><a href="#platform">Selecting a platform version and API Level</a></li>
+ <li><a href="#apilevel">Declaring a minimum API Level</a></li>
+ <li><a href="#testing">Testing against higher API Levels</a></li>
+ </ol>
+ </li>
+ <li><a href="#provisional">Using a Provisional API Level</a></li>
+ <li><a href="#filtering">Filtering the Reference Documentation by API Level</a></li>
+</ol>
+
+ <h2>See also</h2>
+ <ol>
+ <li><a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">&lt;uses-sdk&gt;</a> manifest element</li>
+ </ol>
+
+</div>
+</div>
+
+<p>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. </p>
+
+<p>The sections below provide information about API Level and how it affects
+your applications. </p>
+
+<p>For information about how to use the "Filter by API Level" control
+available in the API reference documentation, see
+<a href="#filtering">Filtering the documentation</a> at the
+end of this document. </p>
+
+<h2 id="intro">What is API Level?</h2>
+
+<p>API Level is an integer value that uniquely identifies the framework API
+revision offered by a version of the Android platform.</p>
+
+<p>The Android platform provides a framework API that applications can use to
+interact with the underlying Android system. The framework API consists of:</p>
+
+<ul>
+<li>A core set of packages and classes</li>
+<li>A set of XML elements and attributes for declaring a manifest file</li>
+<li>A set of XML elements and attributes for declaring and accessing resources</li>
+<li>A set of Intents</li>
+<li>A set of permissions that applications can request, as well as permission
+enforcements included in the system</li>
+</ul>
+
+<p>Each successive version of the Android platform can include updates to the
+Android application framework API that it delivers. </p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>The following table specifies the API Level supported by each version of the
+Android platform.</p>
<table>
<tr><th>Platform Version</th><th>API Level</th></tr>
- <tr><td>Android 1.0</td><td>1</td></tr>
- <tr><td>Android 1.1</td><td>2</td></tr>
+ <tr><td>Android 1.6</td><td>4</td></tr>
<tr><td>Android 1.5</td><td>3</td></tr>
- <tr><td>Android Donut</td><td>Donut</td></tr>
+ <tr><td>Android 1.1</td><td>2</td></tr>
+ <tr><td>Android 1.0</td><td>1</td></tr>
</table>
-<h2 id="ViewingTheApiReference">Viewing the API Reference Based on API Level</h2>
+<h2 id="uses">Uses of API Level in Android</h2>
+
+<p>The API Level identifier serves a key role in ensuring the best possible
+experience for users and application developers:
+
+<ul>
+<li>It lets the Android platform describe the maximum framework API revision
+that it supports</li>
+<li>It lets applications describe the framework API revision that they
+require</li>
+<li>It lets the system negotiate the installation of applications on the user's
+device, such that version-incompatible applications are not installed.</li>
+</ul>
+
+<p>Each Android platform version stores its API Level identifier internally, in
+the Android system itself. </p>
+
+<p>Applications can use a manifest element provided by the framework API &mdash;
+<code>&lt;uses-sdk&gt;</code> &mdash; 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:</p>
+
+<ul>
+<li><code>android:minSdkVersion</code> &mdash; Specifies the minimum API Level
+on which the application is able to run. The default value is "1".</li>
+<li><code>android:maxSdkVersion</code> &mdash; Specifies the maximum API Level
+on which the application is able to run.</li>
+</ul>
+
+<p>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
+<code>&lt;uses-sdk&gt;</code> element with a <code>android:minSdkVersion</code>
+attribute. The value of <code>android:minSdkVersion</code> would be the integer
+corresponding to the API Level of the earliest version of the Android platform
+under which the application can run. </p>
+
+<p>When the user attempts to install an application, the Android system first
+checks the <code>&lt;uses-sdk&gt;</code> 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:</p>
+
+<ul>
+<li>If a <code>android:minSdkVersion</code> attribute 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. </li>
+<li>If a <code>android:maxSdkVersion</code> attribute is declared, its value
+must be equal to or greater than the system's API Level integer.
+If not declared, the system assumes that the application
+has no maximum API Level. </li>
+</ul>
+
+<p>When declared in an application's manifest, a <code>&lt;uses-sdk&gt;</code>
+element might look like this: </p>
+
+<pre>&lt;manifest&gt;
+ ...
+ &lt;uses-sdk android:minSdkVersion="4" /&gt;
+ ...
+&lt;/manifest&gt;</pre>
+
+<p>The principal reason that an application would declare an API Level in
+<code>android:minSdkVersion</code> is to tell the Android system that it is
+using APIs that were <em>introduced</em> 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 tried 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.</p>
+
+<p>For example, the {@link android.appwidget} package was introduced with API
+Level 3. If an application uses that API, it must declare a
+<code>android:minSdkVersion</code> 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).</p>
+
+<p>For more information about how to specify an application's API Level
+requirements, see the <a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><code>&lt;uses-sdk&gt;</code></a>
+ section of the manifest file documentation.</p>
+
+
+<h2 id="considerations">Development Considerations</h2>
+
+<p>The sections below provide information related to API level that you should
+consider when developing your application.</p>
+
+<h3 id="fc">Application forward compatibility</h3>
+
+<p>Android applications are generally forward-compatible with new versions of
+the Android platform.</p>
+
+<p>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. </p>
+
+<p>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 your application depends on. </p>
+
+<p>In some cases, changes <em>below</em> 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. </p>
+
+<h3 id="bc">Application backward compatibility</h3>
+
+<p>Android applications are not necessarily backward compatible with versions of
+the Android platform older than the version against which they were compiled.
+</p>
+
+<p>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.</p>
+
+<p>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
+might not receive an update for a significant amount of time. </p>
+
+<h3 id="platform">Selecting a platform version and API Level</h3>
+
+<p>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.
+
+<p>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
+<code>android:minSdkVersion</code> attribute in the application's manifest and
+set its value to the API Level of the platform version. </p>
+
+<h3 id="apilevel">Declaring a minimum API Level</h3>
+
+<p>If you build an application that uses APIs or system features introduced in
+the latest platform version, you should set the
+<code>android:minSdkVersion</code> 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. </p>
+
+<p>If your application uses APIs introduced in the latest platform version but
+does <em>not</em> declare a <code>android:minSdkVersion</code> attribute, then
+it will run properly on devices running the latest version of the platform, but
+<em>not</em> 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.</p>
+
+<h3 id="testing">Testing against higher API Levels</h3>
+
+<p>After compiling your application, you should make sure to test it on the
+platform specified in the application's <code>android:minSdkVersion</code>
+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. </p>
+
+<p>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. </p>
+
+<p>To access the updater, use the <code>android</code> command-line tool,
+located in the &lt;sdk&gt;/tools directory. You can launch the Updater by using
+the <code>android</code> 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
+<strong>Window</strong>&nbsp;>&nbsp;<strong>Android SDK and AVD
+Manager</strong>.</p>
+
+<p>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 <a
+href="{@docRoot}guide/developing/tools/avd.html">Android Virtual Devices</a>. 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. </p>
+
+
+<h2 id="provisional">Using a Provisional API Level</h2>
+
+<p>During an "Early Look" SDK release, the APIs may not be final, so the API Level integer
+will not be specified. You must instead use a provisional API Level in your application
+manifest in order to build applications against the Early Look platform. In this case,
+the provisional API Level is not an integer, but a string matching the codename of the
+unreleased platform version (for example, "Eclair"). The provisional API Level will be specified
+in the Early Look SDK release notes and is case-sensitive.</p>
+
+<p>The use of a provisional API Level is designed to protect developers
+and device users from inadvertently publishing or installing applications based on the
+Early Look framework API, which may not run properly on actual devices running the final
+system image.</p>
+
+<p>The provisional API Level will only be valid while using the Early Look SDK to run
+applications in the emulator. An application using the provisional API Level can never be
+installed on an Android device. When the final SDK is released, you must replace any
+instances of the provisional API Level in your application manifest with the final
+API Level integer.</p>
+
+
+<h2 id="filtering">Filtering the Reference Documentation by API Level</h2>
-<p>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.</p>
+<p>Reference documentation pages on the Android Developers site offer a "Filter
+by API Level" control in the top-right area of each page. You can use the
+control to 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 <code>android:minSdkVersion</code> attribute of its manifest file. </p>
-<p>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.</p>
+<p>To use filtering, set the control to the same API Level as that specified
+by your application. Notice that APIs introduced in a later API Level are
+then grayed out and their content is masked, since they would not be
+accessible to your application. </p>
+<p>Filtering by API Level in the documentation does not provide a view
+of what is new or introduced in each API Level &mdash; it simply provides a way
+to view the entire API associated with a given API Level, while excluding API
+elements introduced in later API Levels.</p>
+<p>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,
+simply select the highest available API Level. </p>
+<p>Also note that the reference documentation for individual API elements
+specifies the API Level at which the elements were introduced. The API Level
+for packages and classes is specified as "Since &lt;api level&gt;" at the
+top-right corner of the content area on each documentation page. The API Level
+for class members is specified in their detailed description headers,
+at the right margin. </p>