Merge "Make Theme.Holo.Dialog.Alert and Theme.Holo.Light.Dialog.Alert public"
diff --git a/core/java/android/app/NotificationManager.java b/core/java/android/app/NotificationManager.java
index 1fae516..e3242c1 100644
--- a/core/java/android/app/NotificationManager.java
+++ b/core/java/android/app/NotificationManager.java
@@ -39,13 +39,17 @@
* </ul>
*
* <p>
- * Each of the notify methods takes an int id parameter. This id identifies
- * this notification from your app to the system, so that id should be unique
- * within your app. If you call one of the notify methods with an id that is
- * currently active and a new set of notification parameters, it will be
- * updated. For example, if you pass a new status bar icon, the old icon in
- * the status bar will be replaced with the new one. This is also the same
- * id you pass to the {@link #cancel} method to clear this notification.
+ * Each of the notify methods takes an int id parameter and optionally a
+ * {@link String} tag parameter, which may be {@code null}. These parameters
+ * are used to form a pair (tag, id), or ({@code null}, id) if tag is
+ * unspecified. This pair identifies this notification from your app to the
+ * system, so that pair should be unique within your app. If you call one
+ * of the notify methods with a (tag, id) pair that is currently active and
+ * a new set of notification parameters, it will be updated. For example,
+ * if you pass a new status bar icon, the old icon in the status bar will
+ * be replaced with the new one. This is also the same tag and id you pass
+ * to the {@link #cancel(int)} or {@link #cancel(String, int)} method to clear
+ * this notification.
*
* <p>
* You do not instantiate this class directly; instead, retrieve it through
@@ -94,12 +98,11 @@
/**
* Persistent notification on the status bar,
*
- * @param tag An string identifier for this notification unique within your
- * application.
+ * @param tag A string identifier for this notification. May be {@code null}.
+ * @param id An identifier for this notification. The pair (tag, id) must be unique
+ * within your application.
* @param notification A {@link Notification} object describing how to
* notify the user, other than the view you're providing. Must not be null.
- * @return the id of the notification that is associated with the string identifier that
- * can be used to cancel the notification
*/
public void notify(String tag, int id, Notification notification)
{
diff --git a/core/java/android/nfc/NdefMessage.java b/core/java/android/nfc/NdefMessage.java
index d107b54..c79fabf 100644
--- a/core/java/android/nfc/NdefMessage.java
+++ b/core/java/android/nfc/NdefMessage.java
@@ -16,7 +16,6 @@
package android.nfc;
-import android.nfc.NdefRecord;
import android.os.Parcel;
import android.os.Parcelable;
@@ -69,11 +68,10 @@
* Returns a byte array representation of this entire NDEF message.
*/
public byte[] toByteArray() {
- //TODO: do not return null
//TODO: allocate the byte array once, copy each record once
//TODO: process MB and ME flags outside loop
if ((mRecords == null) || (mRecords.length == 0))
- return null;
+ return new byte[0];
byte[] msg = {};
@@ -104,10 +102,12 @@
return msg;
}
+ @Override
public int describeContents() {
return 0;
}
+ @Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(mRecords.length);
dest.writeTypedArray(mRecords, flags);
@@ -115,12 +115,14 @@
public static final Parcelable.Creator<NdefMessage> CREATOR =
new Parcelable.Creator<NdefMessage>() {
+ @Override
public NdefMessage createFromParcel(Parcel in) {
int recordsLength = in.readInt();
NdefRecord[] records = new NdefRecord[recordsLength];
in.readTypedArray(records, NdefRecord.CREATOR);
return new NdefMessage(records);
}
+ @Override
public NdefMessage[] newArray(int size) {
return new NdefMessage[size];
}
diff --git a/core/java/android/view/ViewGroup.java b/core/java/android/view/ViewGroup.java
index 0f9312c..ad343a3 100644
--- a/core/java/android/view/ViewGroup.java
+++ b/core/java/android/view/ViewGroup.java
@@ -870,7 +870,7 @@
switch (event.mAction) {
case DragEvent.ACTION_DRAG_STARTED: {
// clear state to recalculate which views we drag over
- root.setDragFocus(event, null);
+ mCurrentDragView = null;
// Now dispatch down to our children, caching the responses
mChildAcceptsDrag = false;
@@ -915,11 +915,28 @@
final View target = findFrontmostDroppableChildAt(event.mX, event.mY, mLocalPoint);
// If we've changed apparent drag target, tell the view root which view
- // we're over now. This will in turn send out DRAG_ENTERED / DRAG_EXITED
- // notifications as appropriate.
+ // we're over now [for purposes of the eventual drag-recipient-changed
+ // notifications to the framework] and tell the new target that the drag
+ // has entered its bounds. The root will see setDragFocus() calls all
+ // the way down to the final leaf view that is handling the LOCATION event
+ // before reporting the new potential recipient to the framework.
if (mCurrentDragView != target) {
- root.setDragFocus(event, target);
+ root.setDragFocus(target);
+
+ final int action = event.mAction;
+ // If we've dragged off of a child view, send it the EXITED message
+ if (mCurrentDragView != null) {
+ event.mAction = DragEvent.ACTION_DRAG_EXITED;
+ mCurrentDragView.dispatchDragEvent(event);
+ }
mCurrentDragView = target;
+
+ // If we've dragged over a new child view, send it the ENTERED message
+ if (target != null) {
+ event.mAction = DragEvent.ACTION_DRAG_ENTERED;
+ target.dispatchDragEvent(event);
+ }
+ event.mAction = action; // restore the event's original state
}
// Dispatch the actual drag location notice, localized into its coordinates
@@ -934,6 +951,25 @@
}
} break;
+ /* Entered / exited dispatch
+ *
+ * DRAG_ENTERED is not dispatched downwards from ViewGroup. The reason for this is
+ * that we're about to get the corresponding LOCATION event, which we will use to
+ * determine which of our children is the new target; at that point we will
+ * push a DRAG_ENTERED down to the new target child [which may itself be a ViewGroup].
+ *
+ * DRAG_EXITED *is* dispatched all the way down immediately: once we know the
+ * drag has left this ViewGroup, we know by definition that every contained subview
+ * is also no longer under the drag point.
+ */
+
+ case DragEvent.ACTION_DRAG_EXITED: {
+ if (mCurrentDragView != null) {
+ mCurrentDragView.dispatchDragEvent(event);
+ mCurrentDragView = null;
+ }
+ } break;
+
case DragEvent.ACTION_DROP: {
if (ViewDebug.DEBUG_DRAG) Log.d(View.VIEW_LOG_TAG, "Drop event: " + event);
View target = findFrontmostDroppableChildAt(event.mX, event.mY, mLocalPoint);
diff --git a/core/java/android/view/ViewRoot.java b/core/java/android/view/ViewRoot.java
index 22a7773..c7c2071 100644
--- a/core/java/android/view/ViewRoot.java
+++ b/core/java/android/view/ViewRoot.java
@@ -2493,11 +2493,12 @@
// a window boundary, so the current drag target within this one must have
// just been exited. Send it the usual notifications and then we're done
// for now.
- setDragFocus(event, null);
+ mView.dispatchDragEvent(event);
} else {
// Cache the drag description when the operation starts, then fill it in
// on subsequent calls as a convenience
if (what == DragEvent.ACTION_DRAG_STARTED) {
+ mCurrentDragView = null; // Start the current-recipient tracking
mDragDescription = event.mClipDescription;
} else {
event.mClipDescription = mDragDescription;
@@ -2557,22 +2558,10 @@
outLocation.y = (int) mLastTouchPoint.y;
}
- public void setDragFocus(DragEvent event, View newDragTarget) {
- final int action = event.mAction;
- // If we've dragged off of a view, send it the EXITED message
+ public void setDragFocus(View newDragTarget) {
if (mCurrentDragView != newDragTarget) {
- if (mCurrentDragView != null) {
- event.mAction = DragEvent.ACTION_DRAG_EXITED;
- mCurrentDragView.dispatchDragEvent(event);
- }
mCurrentDragView = newDragTarget;
}
- // If we've dragged over a new view, send it the ENTERED message
- if (newDragTarget != null) {
- event.mAction = DragEvent.ACTION_DRAG_ENTERED;
- newDragTarget.dispatchDragEvent(event);
- }
- event.mAction = action; // restore the event's original state
}
private AudioManager getAudioManager() {
diff --git a/docs/html/guide/appendix/market-filters.jd b/docs/html/guide/appendix/market-filters.jd
index e74cefb..6ca8acc 100644
--- a/docs/html/guide/appendix/market-filters.jd
+++ b/docs/html/guide/appendix/market-filters.jd
@@ -1,322 +1,353 @@
-page.title=Market Filters
-@jd:body
-
-<div id="qv-wrapper">
-<div id="qv">
-
-<h2>Quickview</h2>
-<ul> <li>Android Market applies filters to that let you control whether your app is shown to a
-user who is browing or searching for apps.</li>
-<li>Filtering is determined by elements in an app's manifest file,
-aspects of the device being used, and other factors.</li> </ul>
-
-<h2>In this document</h2>
-
-<ol> <li><a href="#how-filters-work">How Filters Work in Android Market</a></li>
-<li><a href="#manifest-filters">Filtering based on Manifest File Elements</a></li>
-<li><a href="#other-filters">Other Filters</a></li>
-</ol>
-
-<h2>See also</h2>
- <ol>
-<li><a
-href="{@docRoot}guide/practices/compatibility.html">Compatibility</a></li>
-<li style="margin-top:2px;"><code><a
-href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code></li>
-<li><code><a
-href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code></li>
-<li><code><a
-href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code></li>
-<li><code><a
-href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></li>
-<li><code><a
-href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></li>
-<li><code><a
-href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></code></a></li>
-</ol>
-
-<div id="qv-extra"> <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png">
-<div id="qv-sub-rule"> <img src="{@docRoot}assets/images/icon_market.jpg"
-style="float:left;margin:0;padding:0;"> <p style="color:#669999;">Interested in
-publishing your app on Android Market?</p> <a id="publish-link"
-href="http://market.android.com/publish">Go to Android Market »</a> </div>
-</div>
-
-</div> </div>
-
-<p>When a user searches or browses in Android Market, the results are filtered, and
-some applications might not be visible. For example, if an application requires a
-trackball (as specified in the manifest file), then Android Market will not show
-the app on any device that does not have a trackball.</p> <p>The manifest file and
-the device's hardware and features are only part of how applications are filtered
-— filtering also depends on the country and carrier, the presence or absence
-of a SIM card, and other factors. </p>
-
-<p>Changes to the Android Market filters are independent of changes
-to the Android platform itself. This document will be updated periodically to reflect
-any changes that occur. </p>
-
-<h2 id="how-filters-work">How Filters Work in Android Market</h2>
-
-<p>Android Market uses the filter restrictions described below to determine
-whether to show your application to a user who is browsing or searching for
-applications on a given device. When determining whether to display your app,
-Market checks the device's hardware and software capabilities, as well as it's
-carrier, location, and other characteristics. It then compares those against the
-restrictions and dependencies expressed by the application itself, in its
-manifest, <code>.apk</code>, and publishing details. If the application is
-compatible with the device according to the filter rules, Market displays the
-application to the user. Otherwise, Market hides your application from search
-results and category browsing. </p>
-
-<p> You can use the filters described below to control whether Market shows or
-hides your application to users. You can request any combination of the
-available filters for your app — for example, you could set a
-<code>minSdkVersion</code> requirement of <code>"4"</code> and set
-<code>smallScreens="false"</code> in the app, then when uploading the app to
-Market you could target European countries (carriers) only. Android Market's
-filters would prevent the application from being visible on any device that did
-not match all three of these requirements. </p>
-
- <p>A filtered app is not visible within Market, even if a user specifically requests
-the app by clicking a deep link that points directly to the app's ID within Market.
-All filtering restrictions are associated with an application's version and can
-change between versions. For example:</p>
-
-<ul>
-<li>If you publish a new version of your app with stricter restrictions, the app
-will not be visible to users for whom it is filtered, even if those users were
-able see the previous version.</li>
-<li>If a user has installed your application and you publish an upgrade that
-makes the app invisible to the user, the user will not see that an upgrade is
-available. </li>
-</ul>
-
-<h2 id="manifest-filters">Filtering based on Manifest Elements</h2>
-
-<p>Most Market filters are triggered by elements within an application's
-manifest file, <a
-href="{@docRoot}guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a>,
-although not everything in the manifest file can trigger filtering. The
-table below lists the manifest elements that you can use to trigger Android
-Market filtering, and explains how the filtering works.</p>
-
-<p class="table-caption"><strong>Table 1.</strong> Manifest elements that
-trigger filtering on Market.</p>
-<table>
- <tr>
- <th>Manifest Element</th>
- <th>Filter Name</th>
- <th>How It Works</th>
- </tr>
- <tr>
- <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code>
- <!-- ##api level 4## --></td>
- <td valign="top">Screen Size</td>
- <td valign="top">
-
-<p>An application indicates the screen sizes that it is capable of supporting by
-setting attributes of the <code><supports-screens></code> element. When
-the application is published, Market uses those attributes to determine whether
-to show the application to users, based on the screen sizes of their
-devices. </p>
-
-<p>As a general rule, Market assumes that the platform on the device can adapt
-smaller layouts to larger screens, but cannot adapt larger layouts to smaller
-screens. Thus, if an application declares support for "normal" screen size only,
-Market makes the application available to both normal- and large-screen devices,
-but filters the application so that it is not available to small-screen
-devices.</p>
-
-<p>If an application does not declare attributes for
-<code><supports-screens></code>, Market uses the default values for those
-attributes, which vary by API Level. Specifically: </p>
-
-<ul>
-<li><p>In API level 3, the <code><supports-screens></code> element itself
-is undefined and no attributes are available. In this case, Market assumes that
-the application is designed for normal-size screens and shows the application to
-devices that have normal or large screens. </p>
-
-<p>This behavior is especially significant for applications that set their
-<code><a
-href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">android:
-minSdkVersion</a></code> to 3 or lower, since Market will filter them from
-small-screen devices by default. Such applications can enable support for
-small-screen devices by adding a <code>android:targetSdkVersion="4"</code>
-attribute to the <code><uses-sdk></code> element in their manifest
-files. For more information, see <a
-href="{@docRoot}guide/practices/screens_support.html#strategies">Strategies for
-Legacy Applications</a>.</p></li>
-
-<li>In API Level 4, the defaults for all of the attributes is
-<code>"true"</code>. If an application does not declare a
-<code><supports-screens></code> element, Market assumes that the
-application is designed for all screen sizes and does not filter it from any
-devices. If the application does not declare one of the attributes, Market uses
-the default value of <code>"true"</code> and does not filter the app for devices
-of corresponding screen size.</li>
-</ul>
-
- <p><strong>Example 1</strong><br />
- The manifest declares <code><uses-sdk android:minSdkVersion="3"></code>
- and does not does not include a <code><supports-screens></code> element.
- <strong>Result</strong>: Android Market will not show the app to a user of a
- small-screen device, but will show it to users of normal and large-screen
- devices, users, unless other filters apply. </p>
- <p><strong>Example 2<br />
- </strong>The manifest declares <code><uses-sdk android:minSdkVersion="3"
- android:targetSdkVersion="4"></code> and does not include a
- <code><supports-screens></code> element.
- <strong>Result</strong>: Android Market will show the app to users on all
- devices, unless other filters apply. </p>
- <p><strong>Example 3<br />
- </strong>The manifest declares <code><uses-sdk android:minSdkVersion="4"></code>
- and does not include a <code><supports-screens></code> element.
- <strong>Result</strong>: Android Market will show the app to all users,
- unless other filters apply. </p>
- <p>For more information on how to declare support for screen sizes in your
- application, see <code><a
- href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code>
- and <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple
- Screens</a>.</p>
-</td>
- </tr>
- <tr>
- <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code>
- <!-- ##api level 3## --></td>
- <td valign="top">Device
- Configuration: <br />
- keyboard, navigation, touch screen</td>
- <td valign="top"><p>An application can
- request certain hardware features, and Android Market will show the app only on devices that have the required hardware.</p>
- <p><strong>Example 1<br />
- </strong>The manifest includes <code><uses-configuration android:reqFiveWayNav="true" /></code>, and a user is searching for apps on a device that does not have a five-way navigational control. <strong>Result</strong>: Android Market will not show the app to the user. </p>
- <p><strong>Example 2<br />
- </strong>The manifest does not include a <code><uses-configuration></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p>
-<p>For more details, see <a
-href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><code><uses-configuration></code></a>.</p></td>
- </tr>
- <tr>
- <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code>
- <!-- ##api level 4## --></td>
- <td valign="top">Device Features<br />
- (<code>name</code>)</td>
- <td valign="top"><p>An
- application can require certain device features to be present on the device. This functionality
- was introduced in Android 2.0 (API Level 5).</p>
- <p><strong>Example 1<br />
- </strong>The manifest includes <code><uses-feature android:name="android.hardware.sensor.light" /></code>, and a user is searching for apps on a device that does not have a light sensor. <strong>Result</strong>: Android Market will not show the app to the user. </p>
- <p><strong>Example 2<br />
- </strong>The manifest does not include a <code><uses-feature></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p>
- <p>For more details, see <code><a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code>.</p>
-<p><em>A note about camera:</em> If an
- application requests the CAMERA permission using the <a
-href="{@docRoot}guide/topics/manifest/uses-permission-element.html"> <code><uses-permission></code></a> element, Market assumes that the
- application requires the camera and all camera features (such as autofocus). For applications that require the camera and are designed to run on Android 1.5 (API Level 3), declaring the CAMERA permission is an effective way of ensuring that Market filters your app properly, since <code>uses-feature</code> filtering is not available to applications compiled against the Android 1.5 platform. For more details about requiring or requesting a camera, see the <a href="{@docRoot}guide/topics/manifest/uses-library-element.html#required"> <code>required</code></a> attribute of <code><uses-feature></code>. </p></td>
- </tr>
- <tr>
- <td valign="top">OpenGL-ES
- Version<br />
-(<code>openGlEsVersion</code>)</td>
- <td valign="top"><p>An application can require that the device support a specific
- OpenGL-ES version using the <code><uses-feature
- android:openGlEsVersion="int"></code> attribute.</p>
- <p><strong>Example 1<br />
- </strong>An app
- requests multiple OpenGL-ES versions by specifying <code>openGlEsVersion</code> multiple times in the
- manifest. <strong>Result</strong>: Market assumes that the app requires the highest of the indicated versions.</p>
-<p><strong>Example 2<br />
-</strong>An app
- requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. <strong>Result</strong>: Android Market will show the app to the user, unless other filters apply. If a
- device reports that it supports OpenGL-ES version <em>X</em>, Market assumes that it
- also supports any version earlier than <em>X</em>.
-</p>
-<p><strong>Example 3<br />
-</strong>A user is searching for apps on a device that does not
- report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). <strong>Result</strong>: Android Market assumes that the device
- supports only OpenGL-ES 1.0. Market will only show the user apps that do not specify <code>openGlEsVersion</code>, or apps that do not specify an OpenGL-ES version higher than 1.0. </p>
- <p><strong>Example 4<br />
- </strong>The manifest does not specify <code>openGlEsVersion</code>. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply. </p>
-<p>For more details, see <a
-href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>.</p></td>
- </tr>
- <tr>
- <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></td>
- <td valign="top">Software Libraries</td>
- <td valign="top"><p>An application can require specific
- shared libraries to be present on the device. </p>
- <p><strong>Example 1<br />
- </strong>An app requires the <code>com.google.android.maps</code> library, and a user is searching for apps on a device that does not have the <code>com.google.android.maps</code> library. <strong>Result</strong>: Android Market will not show the app to the user. </p>
- <p><strong>Example 2</strong><br />
- The manifest does not include a <code><uses-library></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p>
-<p>For more details, see <a
-href="{@docRoot}guide/topics/manifest/uses-library-element.html"><code><uses-library></code></a>.</p></td>
- </tr>
- <tr>
- <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></td>
- <td valign="top"> </td>
- <td valign="top"><em>(See the note in the description of <code><uses-feature></code>, above.)</em></td>
- </tr>
- <tr>
- <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a></code></td>
- <td valign="top">Minimum Framework Version (<code>minSdkVersion</code>)</td>
- <td valign="top"><p>An application can require a minimum API level. </p>
- <p><strong>Example 1</strong><br />
- The manifest includes <code><uses-sdk
- android:minSdkVersion="3"></code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Android Market will not show the app to the user. </p>
- <p><strong>Example 2</strong><br />
- The manifest does not include <code>minSdkVersion</code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Android Market assumes that <code>minSdkVersion</code> is "1" and that the app is compatible with all versions of Android. Market shows the app to the user and allows the user to download the app. The app crashes at runtime. </p>
- <p>Because you want to avoid this second scenario, we recommend that you always declare a <code>minSdkVersion</code>. For details, see <a
-href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min"><code>android:minSdkVersion</code></a>.</p></td>
- </tr>
- <tr>
- <td valign="top">Maximum Framework Version (<code>maxSdkVersion</code>)</td>
- <td valign="top"><p><em>Deprecated.</em> Android
- 2.1 and later do not check or enforce the <code>maxSdkVersion</code> attribute, and
- the SDK will not compile if <code>maxSdkVersion</code> is set in an app's manifest. For devices already
- compiled with <code>maxSdkVersion</code>, Market will respect it and use it for
- filtering.</p>
-<p> Declaring <code>maxSdkVersion</code> is <em>not</em> recommended. For details, see <a
-href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max"><code>android:maxSdkVersion</code></a>.</p></td>
- </tr>
-</table>
-
-<h2 id="other-filters">Other Filters</h2>
-<p>Android Market uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below. </p>
-
-<p class="table-caption"><strong>Table 2.</strong> Application and publishing characteristics that affect filtering on Market.</p>
-<table> <tr>
- <th>Filter Name</th> <th>How It Works</th> </tr>
-
- <tr>
- <td valign="top">Publishing Status</td> <td valign="top"><p>Only published applications will appear in
- searches and browsing within Android Market.</p> <p>Even if an app is unpublished, it can
- be installed if users can see it in their Downloads area among their purchased,
- installed, or recently uninstalled apps.</p> <p>If an application has been
- suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.</p> </td></tr>
- <tr>
- <td valign="top">Priced
- Status</td> <td valign="top"><p>Not all users can see paid apps. To show paid apps, a device
-must have a SIM card and be running Android 1.1 or later, and it must be in a
-country (as determined by SIM carrier) in which paid apps are available.</p></td>
-</tr> <tr>
- <td valign="top">Country / Carrier Targeting</td> <td valign="top"> <p>When you upload your app to
- the Android Market, you can select specific countries to target. The app will only
- be visible to the countries (carriers) that you select, as follows:</p>
- <ul><li><p>A device's country is determined based on the carrier, if a carrier is
- available. If no carrier can be determined, the Market application tries to
- determine the country based on IP.</p></li> <li><p>Carrier is determined based on
- the device's SIM (for GSM devices), not the current roaming carrier.</p></li></ul>
-</td> </tr> <tr>
- <td valign="top">Native Platform</td> <td valign="top"><p>An application that includes native
- libraries that target a specific platform (ARM EABI v7, for example) will only be
- visible on devices that support that platform. For details about the NDK and using
- native libraries, see <a href="{@docRoot}sdk/ndk/index.html#overview">What is the
- Android NDK?</a></p> </tr> <tr>
- <td valign="top">Forward-Locked Applications</td> <td valign="top"><p>To
- forward lock an application, set copy protection to "On" when you upload the
- application to Market. Market will not show copy-protected applications on
-developer devices or unreleased devices.</p></td> </tr> </table>
-
-
+page.title=Market Filters
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>Quickview</h2>
+<ul> <li>Android Market applies filters to that let you control whether your app is shown to a
+user who is browing or searching for apps.</li>
+<li>Filtering is determined by elements in an app's manifest file,
+aspects of the device being used, and other factors.</li> </ul>
+
+<h2>In this document</h2>
+
+<ol> <li><a href="#how-filters-work">How Filters Work in Android Market</a></li>
+<li><a href="#manifest-filters">Filtering based on Manifest File Elements</a></li>
+<li><a href="#other-filters">Other Filters</a></li>
+</ol>
+
+<h2>See also</h2>
+ <ol>
+<li><a
+href="{@docRoot}guide/practices/compatibility.html">Compatibility</a></li>
+<li style="margin-top:2px;"><code><a
+href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code></li>
+<li><code><a
+href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code></li>
+<li><code><a
+href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code></li>
+<li><code><a
+href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></li>
+<li><code><a
+href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></li>
+<li><code><a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></code></a></li>
+</ol>
+
+<div id="qv-extra"> <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png">
+<div id="qv-sub-rule"> <img src="{@docRoot}assets/images/icon_market.jpg"
+style="float:left;margin:0;padding:0;"> <p style="color:#669999;">Interested in
+publishing your app on Android Market?</p> <a id="publish-link"
+href="http://market.android.com/publish">Go to Android Market »</a> </div>
+</div>
+
+</div> </div>
+
+<p>When a user searches or browses in Android Market, the results are filtered, and
+some applications might not be visible. For example, if an application requires a
+trackball (as specified in the manifest file), then Android Market will not show
+the app on any device that does not have a trackball.</p> <p>The manifest file and
+the device's hardware and features are only part of how applications are filtered
+— filtering also depends on the country and carrier, the presence or absence
+of a SIM card, and other factors. </p>
+
+<p>Changes to the Android Market filters are independent of changes
+to the Android platform itself. This document will be updated periodically to reflect
+any changes that occur. </p>
+
+<h2 id="how-filters-work">How Filters Work in Android Market</h2>
+
+<p>Android Market uses the filter restrictions described below to determine
+whether to show your application to a user who is browsing or searching for
+applications on a given device. When determining whether to display your app,
+Market checks the device's hardware and software capabilities, as well as it's
+carrier, location, and other characteristics. It then compares those against the
+restrictions and dependencies expressed by the application itself, in its
+manifest, <code>.apk</code>, and publishing details. If the application is
+compatible with the device according to the filter rules, Market displays the
+application to the user. Otherwise, Market hides your application from search
+results and category browsing. </p>
+
+<p> You can use the filters described below to control whether Market shows or
+hides your application to users. You can request any combination of the
+available filters for your app — for example, you could set a
+<code>minSdkVersion</code> requirement of <code>"4"</code> and set
+<code>smallScreens="false"</code> in the app, then when uploading the app to
+Market you could target European countries (carriers) only. Android Market's
+filters would prevent the application from being visible on any device that did
+not match all three of these requirements. </p>
+
+ <p>A filtered app is not visible within Market, even if a user specifically requests
+the app by clicking a deep link that points directly to the app's ID within Market.
+All filtering restrictions are associated with an application's version and can
+change between versions. For example:</p>
+
+<ul>
+<li>If you publish a new version of your app with stricter restrictions, the app
+will not be visible to users for whom it is filtered, even if those users were
+able see the previous version.</li>
+<li>If a user has installed your application and you publish an upgrade that
+makes the app invisible to the user, the user will not see that an upgrade is
+available. </li>
+</ul>
+
+<h2 id="manifest-filters">Filtering based on Manifest Elements</h2>
+
+<p>Most Market filters are triggered by elements within an application's
+manifest file, <a
+href="{@docRoot}guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a>,
+although not everything in the manifest file can trigger filtering. The
+table below lists the manifest elements that you can use to trigger Android
+Market filtering, and explains how the filtering works.</p>
+
+<p class="table-caption"><strong>Table 1.</strong> Manifest elements that
+trigger filtering on Market.</p>
+<table>
+ <tr>
+ <th>Manifest Element</th>
+ <th>Filter Name</th>
+ <th>How It Works</th>
+ </tr>
+ <tr>
+ <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code>
+ <!-- ##api level 4## --></td>
+ <td valign="top">Screen Size</td>
+ <td valign="top">
+
+<p>An application indicates the screen sizes that it is capable of supporting by
+setting attributes of the <code><supports-screens></code> element. When
+the application is published, Market uses those attributes to determine whether
+to show the application to users, based on the screen sizes of their
+devices. </p>
+
+<p>As a general rule, Market assumes that the platform on the device can adapt
+smaller layouts to larger screens, but cannot adapt larger layouts to smaller
+screens. Thus, if an application declares support for "normal" screen size only,
+Market makes the application available to both normal- and large-screen devices,
+but filters the application so that it is not available to small-screen
+devices.</p>
+
+<p>If an application does not declare attributes for
+<code><supports-screens></code>, Market uses the default values for those
+attributes, which vary by API Level. Specifically: </p>
+
+<ul>
+<li><p>In API level 3, the <code><supports-screens></code> element itself
+is undefined and no attributes are available. In this case, Market assumes that
+the application is designed for normal-size screens and shows the application to
+devices that have normal or large screens. </p>
+
+<p>This behavior is especially significant for applications that set their
+<code><a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">android:
+minSdkVersion</a></code> to 3 or lower, since Market will filter them from
+small-screen devices by default. Such applications can enable support for
+small-screen devices by adding a <code>android:targetSdkVersion="4"</code>
+attribute to the <code><uses-sdk></code> element in their manifest
+files. For more information, see <a
+href="{@docRoot}guide/practices/screens_support.html#strategies">Strategies for
+Legacy Applications</a>.</p></li>
+
+<li>In API Level 4, the defaults for all of the attributes is
+<code>"true"</code>. If an application does not declare a
+<code><supports-screens></code> element, Market assumes that the
+application is designed for all screen sizes and does not filter it from any
+devices. If the application does not declare one of the attributes, Market uses
+the default value of <code>"true"</code> and does not filter the app for devices
+of corresponding screen size.</li>
+</ul>
+
+ <p><strong>Example 1</strong><br />
+ The manifest declares <code><uses-sdk android:minSdkVersion="3"></code>
+ and does not does not include a <code><supports-screens></code> element.
+ <strong>Result</strong>: Android Market will not show the app to a user of a
+ small-screen device, but will show it to users of normal and large-screen
+ devices, users, unless other filters apply. </p>
+ <p><strong>Example 2<br />
+ </strong>The manifest declares <code><uses-sdk android:minSdkVersion="3"
+ android:targetSdkVersion="4"></code> and does not include a
+ <code><supports-screens></code> element.
+ <strong>Result</strong>: Android Market will show the app to users on all
+ devices, unless other filters apply. </p>
+ <p><strong>Example 3<br />
+ </strong>The manifest declares <code><uses-sdk android:minSdkVersion="4"></code>
+ and does not include a <code><supports-screens></code> element.
+ <strong>Result</strong>: Android Market will show the app to all users,
+ unless other filters apply. </p>
+ <p>For more information on how to declare support for screen sizes in your
+ application, see <code><a
+ href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code>
+ and <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple
+ Screens</a>.</p>
+</td>
+ </tr>
+ <tr>
+ <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code>
+ <!-- ##api level 3## --></td>
+ <td valign="top">Device
+ Configuration: <br />
+ keyboard, navigation, touch screen</td>
+ <td valign="top"><p>An application can
+ request certain hardware features, and Android Market will show the app only on devices that have the required hardware.</p>
+ <p><strong>Example 1<br />
+ </strong>The manifest includes <code><uses-configuration android:reqFiveWayNav="true" /></code>, and a user is searching for apps on a device that does not have a five-way navigational control. <strong>Result</strong>: Android Market will not show the app to the user. </p>
+ <p><strong>Example 2<br />
+ </strong>The manifest does not include a <code><uses-configuration></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p>
+<p>For more details, see <a
+href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><code><uses-configuration></code></a>.</p></td>
+ </tr>
+ <tr>
+ <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a
+href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a>
+</code>
+ <!-- ##api level 4## --></td>
+ <td valign="top">Device Features<br />
+ (<code>name</code>)</td>
+ <td valign="top"><p>An application can require certain device features to be
+present on the device. This functionality was introduced in Android 2.0 (API
+Level 5).</p>
+ <p><strong>Example 1<br />
+ </strong>The manifest includes <code><uses-feature
+android:name="android.hardware.sensor.light" /></code>, and a user
+is searching for apps on a device that does not have a light sensor.
+<strong>Result</strong>: Android Market will not show the app to the user. </p>
+ <p><strong>Example 2<br />
+ </strong>The manifest does not include a <code><uses-feature></code>
+element. <strong>Result</strong>: Android Market will show the app to all users,
+unless other filters apply.</p>
+ <p>For complete information, see <code><a
+href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a>
+</code>.</p>
+ <p><em>Filtering based on implied features:</em> In some cases, Android
+Market interprets permissions requested through
+<code><uses-permission></code> elements as feature requirements equivalent
+to those declared in <code><uses-feature></code> elements. See <a
+href="#uses-permission-filtering"><code><uses-permission></code></a>,
+below.</p>
+</td>
+ </tr>
+ <tr>
+ <td valign="top">OpenGL-ES
+ Version<br />
+(<code>openGlEsVersion</code>)</td>
+ <td valign="top"><p>An application can require that the device support a specific
+ OpenGL-ES version using the <code><uses-feature
+ android:openGlEsVersion="int"></code> attribute.</p>
+ <p><strong>Example 1<br />
+ </strong>An app
+ requests multiple OpenGL-ES versions by specifying <code>openGlEsVersion</code> multiple times in the
+ manifest. <strong>Result</strong>: Market assumes that the app requires the highest of the indicated versions.</p>
+<p><strong>Example 2<br />
+</strong>An app
+ requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. <strong>Result</strong>: Android Market will show the app to the user, unless other filters apply. If a
+ device reports that it supports OpenGL-ES version <em>X</em>, Market assumes that it
+ also supports any version earlier than <em>X</em>.
+</p>
+<p><strong>Example 3<br />
+</strong>A user is searching for apps on a device that does not
+ report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). <strong>Result</strong>: Android Market assumes that the device
+ supports only OpenGL-ES 1.0. Market will only show the user apps that do not specify <code>openGlEsVersion</code>, or apps that do not specify an OpenGL-ES version higher than 1.0. </p>
+ <p><strong>Example 4<br />
+ </strong>The manifest does not specify <code>openGlEsVersion</code>. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply. </p>
+<p>For more details, see <a
+href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>.</p></td>
+ </tr>
+ <tr>
+ <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></td>
+ <td valign="top">Software Libraries</td>
+ <td valign="top"><p>An application can require specific
+ shared libraries to be present on the device. </p>
+ <p><strong>Example 1<br />
+ </strong>An app requires the <code>com.google.android.maps</code> library, and a user is searching for apps on a device that does not have the <code>com.google.android.maps</code> library. <strong>Result</strong>: Android Market will not show the app to the user. </p>
+ <p><strong>Example 2</strong><br />
+ The manifest does not include a <code><uses-library></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p>
+<p>For more details, see <a
+href="{@docRoot}guide/topics/manifest/uses-library-element.html"><code><uses-library></code></a>.</p></td>
+ </tr>
+ <tr id="uses-permission-filtering">
+ <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></td>
+ <td valign="top"> </td>
+ <td valign="top">Strictly, Android Market does not filter based on
+<code><uses-permission></code> elements. However, it does read the
+elements to determine whether the application has hardware feature requirements
+that may not have been properly declared in <code><uses-feature></code>
+elements. For example, if an application requests the <code>CAMERA</code>
+permission but does not declare a <code><uses-feature></code> element for
+<code>android.hardware.camera</code>, Android Market considers that the
+application requires a camera and should not be shown to users whose devices do
+not offer a camera.</p>
+ <p>In general, if an application requests hardware-related permissions,
+Android Market assumes that the application requires the underlying hardware
+features, even though there might be no corresponding to
+<code><uses-feature></code> declarations. Android Market then sets up
+filtering based on the features implied by the <code><uses-feature></code>
+declarations.</p>
+ <p>For a list of permissions that imply hardware features, see
+the documentation for the <a
+href="{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions-features"><code><uses-feature></code></a>
+element.</p>
+</td>
+ </tr>
+ <tr>
+ <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a></code></td>
+ <td valign="top">Minimum Framework Version (<code>minSdkVersion</code>)</td>
+ <td valign="top"><p>An application can require a minimum API level. </p>
+ <p><strong>Example 1</strong><br />
+ The manifest includes <code><uses-sdk
+ android:minSdkVersion="3"></code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Android Market will not show the app to the user. </p>
+ <p><strong>Example 2</strong><br />
+ The manifest does not include <code>minSdkVersion</code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Android Market assumes that <code>minSdkVersion</code> is "1" and that the app is compatible with all versions of Android. Market shows the app to the user and allows the user to download the app. The app crashes at runtime. </p>
+ <p>Because you want to avoid this second scenario, we recommend that you always declare a <code>minSdkVersion</code>. For details, see <a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min"><code>android:minSdkVersion</code></a>.</p></td>
+ </tr>
+ <tr>
+ <td valign="top">Maximum Framework Version (<code>maxSdkVersion</code>)</td>
+ <td valign="top"><p><em>Deprecated.</em> Android
+ 2.1 and later do not check or enforce the <code>maxSdkVersion</code> attribute, and
+ the SDK will not compile if <code>maxSdkVersion</code> is set in an app's manifest. For devices already
+ compiled with <code>maxSdkVersion</code>, Market will respect it and use it for
+ filtering.</p>
+<p> Declaring <code>maxSdkVersion</code> is <em>not</em> recommended. For details, see <a
+href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max"><code>android:maxSdkVersion</code></a>.</p></td>
+ </tr>
+</table>
+
+<h2 id="other-filters">Other Filters</h2>
+<p>Android Market uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below. </p>
+
+<p class="table-caption"><strong>Table 2.</strong> Application and publishing characteristics that affect filtering on Market.</p>
+<table> <tr>
+ <th>Filter Name</th> <th>How It Works</th> </tr>
+
+ <tr>
+ <td valign="top">Publishing Status</td> <td valign="top"><p>Only published applications will appear in
+ searches and browsing within Android Market.</p> <p>Even if an app is unpublished, it can
+ be installed if users can see it in their Downloads area among their purchased,
+ installed, or recently uninstalled apps.</p> <p>If an application has been
+ suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.</p> </td></tr>
+ <tr>
+ <td valign="top">Priced
+ Status</td> <td valign="top"><p>Not all users can see paid apps. To show paid apps, a device
+must have a SIM card and be running Android 1.1 or later, and it must be in a
+country (as determined by SIM carrier) in which paid apps are available.</p></td>
+</tr> <tr>
+ <td valign="top">Country / Carrier Targeting</td> <td valign="top"> <p>When you upload your app to
+ the Android Market, you can select specific countries to target. The app will only
+ be visible to the countries (carriers) that you select, as follows:</p>
+ <ul><li><p>A device's country is determined based on the carrier, if a carrier is
+ available. If no carrier can be determined, the Market application tries to
+ determine the country based on IP.</p></li> <li><p>Carrier is determined based on
+ the device's SIM (for GSM devices), not the current roaming carrier.</p></li></ul>
+</td> </tr> <tr>
+ <td valign="top">Native Platform</td> <td valign="top"><p>An application that includes native
+ libraries that target a specific platform (ARM EABI v7, for example) will only be
+ visible on devices that support that platform. For details about the NDK and using
+ native libraries, see <a href="{@docRoot}sdk/ndk/index.html#overview">What is the
+ Android NDK?</a></p> </tr> <tr>
+ <td valign="top">Forward-Locked Applications</td> <td valign="top"><p>To
+ forward lock an application, set copy protection to "On" when you upload the
+ application to Market. Market will not show copy-protected applications on
+developer devices or unreleased devices.</p></td> </tr> </table>
+
+
diff --git a/docs/html/guide/developing/eclipse-adt.jd b/docs/html/guide/developing/eclipse-adt.jd
index d0fc9b8..1594159 100644
--- a/docs/html/guide/developing/eclipse-adt.jd
+++ b/docs/html/guide/developing/eclipse-adt.jd
@@ -392,11 +392,11 @@
<ul>
<li>If you are developing multiple related applications that use some of the
-same components, you move the redundant components out of their respective
+same components, you could move the redundant components out of their respective
application projects and create a single, reuseable set of the same components
in a library project. </li>
<li>If you are creating an application that exists in both free and paid
-versions. You move the part of the application that is common to both versions
+versions, you could move the part of the application that is common to both versions
into a library project. The two dependent projects, with their different package
names, will reference the library project and provide only the difference
between the two application versions.</li>
diff --git a/docs/html/guide/developing/other-ide.jd b/docs/html/guide/developing/other-ide.jd
index ff13f43..8c61771a 100644
--- a/docs/html/guide/developing/other-ide.jd
+++ b/docs/html/guide/developing/other-ide.jd
@@ -555,11 +555,11 @@
<ul>
<li>If you are developing multiple related applications that use some of the
-same components, you move the redundant components out of their respective
+same components, you could move the redundant components out of their respective
application projects and create a single, reuseable set of the same components
in a library project. </li>
<li>If you are creating an application that exists in both free and paid
-versions. You move the part of the application that is common to both versions
+versions, you could move the part of the application that is common to both versions
into a library project. The two dependent projects, with their different package
names, will reference the library project and provide only the difference
between the two application versions.</li>
diff --git a/docs/html/guide/topics/manifest/uses-feature-element.jd b/docs/html/guide/topics/manifest/uses-feature-element.jd
index 4066daa..45f4a66 100644
--- a/docs/html/guide/topics/manifest/uses-feature-element.jd
+++ b/docs/html/guide/topics/manifest/uses-feature-element.jd
@@ -5,9 +5,9 @@
<dt>syntax:</dt>
<dd>
-<pre class="stx"><uses-feature android:<a href="#glEsVersion">glEsVersion</a>="<em>integer</em>"
- android:<a href="#name">name</a>="<em>string</em>"
- android:<a href="#required">required</a>=["true" | "false"] /></pre>
+<pre class="stx"><uses-feature android:<a href="#name">name</a>="<em>string</em>"
+ android:<a href="#required">required</a>=["true" | "false"]
+ android:<a href="#glEsVersion">glEsVersion</a>="<em>integer</em>" /></pre>
</dd>
<dt>contained in:</dt>
@@ -18,8 +18,8 @@
<img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png">
<div id="qv-sub-rule">
<img src="{@docRoot}assets/images/icon_market.jpg" style="float:left;margin:0;padding:0;">
- <p style="color:#669999;">Android Market and <uses-feature> elements</p>
- <p>Android Market filters the applications that are visible to users, so
+ <p style="color:#669999;">Android Market and <code style="color:#669999;"><uses-feature></code> elements</p>
+ <p style="margin-top:1em;">Android Market filters the applications that are visible to users, so
that users can see and download only those applications that are compatible with their
devices. One of the ways Market filters applications is by feature compatibility.</p>
@@ -27,70 +27,82 @@
<code><uses-feature></code> elements in each application's manifest, to
establish the app's feature needs. Market then shows or hides the application to
each user, based on a comparison with the features available on the user's
-device. For more information, see <a
-href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a>.</p>
+device. </p>
-<p style="margin-top:1em;">By specifying the features your application requires,
+<p style="margin-top:1em;">By specifying the features that your application requires,
you enable Android Market to present your application only to users whose
devices meet the application's feature requirements, rather than presenting it
to all users. </p>
+
+<p style="margin-top:1em;" class="caution">For important information about how
+Android Market uses features as the basis for filtering, please read <a
+href="#market-feature-filtering">Android Market and Feature-Based Filtering</a>,
+below.</p>
</div>
</div>
<dt>description:</dt>
-<dd>This element declares a specific feature used by the application. Android
-provides some features that may not be equally supported by all Android devices.
-In a manner similar to the <a
-href="uses-sdk-element.html">{@code <uses-sdk>}</a> element, this element
-allows an application to specify which device-variable features it uses. For
-example, an application might specify that it requires a camera with auto-focus
-capabilities.</p>
+<dd>Declares a single hardware or software feature that is used by the
+application.
-<p>Declaring a {@code <uses-feature>} element is informational only, meaning
+<p>The purpose of a <code><uses-feature></code> declaration is to inform
+any external entity of the set of hardware and software features on which your
+application depends. The element offers a <code>required</code> attribute that
+lets you specify whether your application requires and cannot function without
+the declared feature, or whether it prefers to have the feature but can function
+without it. Because feature support can vary across Android devices, the
+<code><uses-feature></code> element serves an important role in letting an
+application describe the device-variable features that it uses.</p>
+
+<p>The set of available features that your application declares corresponds to
+the set of feature constants made available by the Android {@link
+android.content.pm.PackageManager}, which are listed for
+convenience in the <a href="#features-reference">Features Reference</a> tables
+at the bottom of this document.
+
+<p>You must specify each feature in a separate <code><uses-feature></code>
+element, so if your application requires multiple features, it would declare
+multiple <code><uses-feature></code> elements. For example, an application
+that requires both Bluetooth and camera features in the device would declare
+these two elements:</p>
+
+<pre>
+<uses-feature android:name="android.hardware.bluetooth" />
+<uses-feature android:name="android.hardware.camera" />
+</pre>
+
+<p>In general, you should always make sure to declare
+<code><uses-feature></code> elements for all of the features that your
+application requires.</p>
+
+<p>Declared <code><uses-feature></code> elements are informational only, meaning
that the Android system itself does not check for matching feature support on
-the device before installing an application. However, note that other services
+the device before installing an application. However, other services
(such as Android Market) or applications may check your application's
-{@code <uses-feature>} declarations as part of handling or interacting
+<code><uses-feature></code> declarations as part of handling or interacting
with your application. For this reason, it's very important that you declare all of
the features (from the list below) that your application uses. </p>
<p>For some features, there may exist a specfic attribute that allows you to define
a version of the feature, such as the version of Open GL used (declared with
-<a href="#glEsVersion">{@code glEsVersion}</a>). Other features that either do or do not
+<a href="#glEsVersion"><code>glEsVersion</code></a>). Other features that either do or do not
exist for a device, such as a camera, are declared using the
-<a href="#name">{@code name}</a> attribute.</p>
+<a href="#name"><code>name</code></a> attribute.</p>
-<p>Any software or hardware features that may vary among Android-powered devices
-will be listed on this page among the attributes below. If you see any features
-here that you use in your application, you should include a
-{@code <uses-feature>} element for each one. For example, if your
-application uses the device camera, then you should include the following in
-your {@code AndroidManifest.xml}:</p>
-<pre>
-<uses-feature android:name="android.hardware.camera" />
-</pre>
+<p>Although the <code><uses-feature></code> element is only activated for
+devices running API Level 4 or higher, it is recommended to include these
+elements for all applications, even if the <a href="uses-sdk-element.html#min"><code>minSdkVersion</code></a>
+is "3" or lower. Devices running older versions of the platform will simply
+ignore the element.</p>
-<p>If you declare {@code android.hardware.camera} this way, then your application is considered
-compatible with all devices that include a camera. If your application also uses auto-focus
-features, then you also need to include a
-{@code <uses-feature>} element that declares the {@code android.hardware.camera.autofocus}
-feature. Also note that you must still request the {@link android.Manifest.permission#CAMERA
-CAMERA} permission. Requesting the permission grants your application access to the
-appropriate hardware and software, while declaring the features used by
-your application ensures proper device compatibility.</p>
-
-<p>Although the {@code <uses-feature>} element is only activated for devices running
-API Level 4 or higher, it is safe to include this for applications that declare
-a <a href="uses-sdk-element.html#min">{@code minSdkVersion}</a>
-of "3" or lower. Devices running older versions of the platform
-will simply ignore this element, but newer devices will recognize it and enforce
-installation restrictions based on whether the device supports the feature.</p>
-
-<p class="note"><strong>Note:</strong>
-For each feature required by your application, you must include a new {@code
-<uses-feature>} element. Multiple features cannot be declared in one
-instance of this element.</p>
+<p class="note"><strong>Note:</strong> When declaring a feature, remember
+that you must also request permissions as appropriate. For example, you must
+still request the {@link android.Manifest.permission#CAMERA}
+permission before your application can access the camera API. Requesting the
+permission grants your application access to the appropriate hardware and
+software, while declaring the features used by your application ensures proper
+device compatibility.</p>
</dd>
@@ -99,7 +111,35 @@
<dd>
<dl class="attr">
- <dt><a name="glEsVersion"></a>{@code android:glEsVersion}</dt>
+
+ <dt><a name="name"></a><code>android:name</code></dt>
+ <dd>Specifies a single hardware or software feature used by the application,
+as a descriptor string. Valid descriptor values are listed in the <a
+href="#hw-features">Hardware features</a> and <a href="#sw-features">Software
+features</a> tables, below. </dd>
+
+ <dt><a name="required"></a><code>android:required</code></dt> <!-- added in api level 5 -->
+ <dd>Boolean value that indicates whether the application requires
+ the feature specified in <code>android:name</code>.
+
+<ul>
+<li>When you declare <code>"android:required="true"</code> for a feature,
+you are specifying that the application <em>cannot function, or is not
+designed to function</em>, when the specified feature is not present on the
+device. </li>
+
+<li>When you declare <code>"android:required="false"</code> for a feature, it
+means that the application <em>prefers to use the feature</em> if present on
+the device, but that it <em>is designed to function without the specified
+feature</em>, if necessary. </li>
+
+</ul>
+
+<p>The default value for <code>android:required</code> if not declared is
+<code>"true"</code>.</p>
+ </dd>
+
+ <dt><a name="glEsVersion"></a><code>android:glEsVersion</code></dt>
<dd>The OpenGL ES version required by the application. The higher 16 bits
represent the major number and the lower 16 bits represent the minor number. For
example, to specify OpenGL ES version 2.0, you would set the value as
@@ -125,110 +165,6 @@
can check at run-time whether a higher level of OpenGL ES is available.)</p>
</dd>
- <dt><a name="name"></a>{@code android:name}</dt>
- <dd>The name of a feature required by the application.
- The value must be one of the following accepted strings:
-
- <table>
- <tr>
- <th>Feature</th>
- <th>Attribute Value</th>
- <th>Description</th>
- </tr><tr>
- <td rowspan="2">Camera</td>
- <td>{@code android.hardware.camera}</td>
- <td>The application requires a camera.</td>
- </tr><tr>
- <td colspan="2">
- <strong>Note:</strong> Any application that requests the
- {@link android.Manifest.permission#CAMERA} permission but does <em>not</em>
- declare any camera features with the {@code <uses-feature>} element will be assumed
- to use all camera features (auto-focus and flash). Thus, the application will not
- be compatible with devices that do not support all camera features. Please use
- {@code <uses-feature>} to declare only the camera features that your
- application does need. For instance, if you request the
- {@link android.Manifest.permission#CAMERA} permission, but you do not need auto-focus or
- flash, then declare only the {@code android.hardware.camera} feature—the other
- camera features that you do not request will no longer be assumed as required.
- </td>
- </tr><tr>
- <td>Camera auto-focus</td>
- <td>{@code android.hardware.camera.autofocus}</td>
- <td>The application requires a camera with auto-focus capability.
- As a prerequisite, {@code android.hardware.camera} must also be declared
- with a separate {@code <uses-feature>} element.
- </td>
- </tr><tr>
- <td>Camera flash</td>
- <td>{@code android.hardware.camera.flash}</td>
- <td>The application requires a camera with a flash.
- As a prerequisite, both {@code android.hardware.camera} and {@code
- android.hardware.camera.autofocus} must also be declared
- with separate {@code <uses-feature>} elements.
- </td>
- </tr><tr>
- <td>Light sensor</td>
- <td>{@code android.hardware.sensor.light}</td>
- <td>The application requires a device with a light sensor.
- </td>
- </tr><tr>
- <td>Live Wallpaper</td>
- <td>{@code android.software.live_wallpaper}</td>
- <td>The application uses or provides Live Wallpapers and should be installed only on devices that support Live Wallpapers.
- </td>
- </tr><tr>
- <td>Proximity sensor</td>
- <td>{@code android.hardware.sensor.proximity}</td>
- <td>The application requires a device with a proximity sensor.
- </td>
- </tr><tr>
- <td>Multitouch screen</td>
- <td>{@code android.hardware.touchscreen.multitouch}</td>
- <td>The application requires a device that supports multitouch.
- </td>
- </tr><tr>
- <td>Telephony</td>
- <td>{@code android.hardware.telephony}</td>
- <td>The application requires a device that includes a telephony radio with data
- communication services.
- </td>
- </tr><tr>
- <td>CDMA telephony</td>
- <td>{@code android.hardware.telephony.cdma}</td>
- <td>The application requires a device that includes a CDMA telephony radio. As a
- prerequisite, {@code android.hardware.telephony} must also be declared
- with a separate {@code <uses-feature>} element.
- </td>
- </tr><tr>
- <td>GSM telephony</td>
- <td>{@code android.hardware.telephony.gsm}</td>
- <td>The application requires a device that includes a GSM telephony radio. As a
- prerequisite, {@code android.hardware.telephony} must also be declared
- with a separate {@code <uses-feature>} element.
- </td>
- </tr>
- </table>
- </dd>
-
- <dt><a name="required"></a>{@code android:required}</dt> <!-- added in api level 5 -->
- <dd>Indicates whether the feature is required by the application. This is
- {@code true} by default. <strong>You should not use this attribute for most cases.</strong>
- </p>
-
- <p>The only situation in which you should set this attribute {@code false} is when your
- application requests the {@link android.Manifest.permission#CAMERA} permission, but will degrade
- gracefully and perform without failure if the device does not have a camera. In this situation,
- you must declare the {@code android.hardware.camera} feature and set the {@code required}
- attribute {@code false}. This is necessary because the {@link
- android.Manifest.permission#CAMERA} permission will automatically turn on the requirement for
- all camera features. So if your application uses this permission but is still compatible with
- devices without a camera, then you must set the {@code required} attribute {@code false} for
- {@code android.hardware.camera} or else it will not install on devices without a camera. Note
- that, while the permission will enable the requirement for <em>all</em> camera features, you
- only need to off the requirement for the basic camera feature.</p>
-
- </dd>
-
</dl>
</dd>
@@ -239,8 +175,680 @@
<dt>see also:</dt>
<dd>
<ul>
+ <li>{@link android.content.pm.PackageManager}</li>
+ <li>{@link android.content.pm.FeatureInfo}</li>
<li>{@link android.content.pm.ConfigurationInfo}</li>
+ <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a></li>
+ <li><a href="{@docRoot}guide/appendix/market-filters.html">Android Market Filters</a></li>
</ul>
</dd>
</dl>
+
+
+<h2 id="market-feature-filtering">Android Market and Feature-Based Filtering</h2>
+
+<p>Android Market filters the applications that are visible to users, so that
+users can see and download only those applications that are compatible with
+their devices. One of the ways Market filters applications is by feature
+compatibility.</p>
+
+<p>To determine an application's feature compatibility with a given user's
+device, the Android Market service compares:</p>
+
+<ul>
+<li>Features required by the application — an application declares features in
+<code><uses-feature></code> elements in its manifest <br/>with...</li>
+<li>Features available on the device, in hardware or software —
+a device reports the features it supports as read-only system properties.</li>
+</ul>
+
+<p>To ensure an accurate comparison of features, the Android Package Manager
+provides a shared set of feature constants that both applications and devices
+use to declare feature requirements and support. The available feature constants
+are listed in the <a href="#features-reference">Features Reference</a> tables at
+the bottom of this document, and in the class documentation for {@link
+android.content.pm.PackageManager}.</p>
+
+<p>When the user launches the Market application, the application queries the
+Package Manager for the list of features available on the device by calling
+{@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The
+Market application then passes the features list up to the Android Market
+service when establishing the session for the user.</p>
+
+<p>Each time you upload an application to the Android Market Publisher Site,
+Android Market scans the application's manifest file. It looks for
+<code><uses-feature></code> elements and evaluates them in combination
+with other elements, in some cases, such as <code><uses-sdk></code> and
+<code><uses-permission></code> elements. After establishing the
+application's set of required features, it stores that list internally as
+metadata associated with the application <code>.apk</code> and the application
+version. </p>
+
+<p>When a user searches or browses for applications using the Android Market
+application, the service compares the features needed by each application with
+the features available on the user's device. If all of an application's required
+features are present on the device, Android Market allows the user to see the
+application and potentially download it. If any required feature is not
+supported by the device, Android Market filters the application so that it is
+not visible to the user and not available for download. </p>
+
+<p>Because the features you declare in <code><uses-feature></code>
+elements directly affect how Android Market filters your application, it's
+important to understand how Android Market evaluates the application's manifest
+and establishes the set of required features. The sections below provide more
+information. </p>
+
+<h3 id="declared">Filtering based on explicitly declared features</h3>
+
+<p>An explicitly declared feature is one that your application declares in a
+<code><uses-feature></code> element. The feature declaration can include
+an <code>android:required=["true" | "false"]</code> attribute (if you are
+compiling against API level 5 or higher), which lets you specify whether the
+application absolutely requires the feature and cannot function properly without
+it (<code>"true"</code>), or whether the application prefers to use the feature
+if available, but is designed to run without it (<code>"false"</code>).</p>
+
+<p>Android Market handles explictly declared features in this way: </p>
+
+<ul>
+<li>If a feature is explicitly declared as being required, Android Market adds
+the feature to the list of required features for the application. It then
+filters the application from users on devices that do not provide that feature.
+For example:
+<pre><uses-feature android:name="android.hardware.camera" android:required="true" /></pre></li>
+<li>If a feature is explicitly declared as <em>not</em> being required, Android
+Market <em>does not</em> add the feature to the list of required features. For
+that reason, an explicity declared non-required feature is never considered when
+filtering the application. Even if the device does not provide the declared
+feature, Android Market will still consider the application compatible with the
+device and will show it to the user, unless other filtering rules apply. For
+example:
+<pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre></li>
+<li>If a feature is explicitly declared, but without an
+<code>android:required</code> attribute, Android Market assumes that the feature
+is required and sets up filtering on it. </li>
+</ul>
+
+<p>In general, if your application is designed to run on Android 1.6 and earlier
+versions, the <code>android:required</code> attribute is not available in the
+API and Android Market assumes that any and all
+<code><uses-feature></code> declarations are required. </p>
+
+<p class="note"><strong>Note:</strong> By declaring a feature explicitly and
+including an <code>android:required="false"</code> attribute, you can
+effectively disable all filtering on Android Market for the specified feature.
+</p>
+
+
+<h3 id="implicit">Filtering based on implicit features</h3>
+
+<p>An <em>implicit</em> feature is one that an application requires in order to
+function properly, but which is <em>not</em> declared in a
+<code><uses-feature></code> element in the manifest file. Strictly
+speaking, every application should <em>always</em> declare all features that it
+uses or requires, so the absence of a declaration for a feature used by an
+application should be considered an error. However, as a safeguard for users and
+developers, Android Market looks for implicit features in each application and
+sets up filters for those features, just as it would do for an explicitly
+declared feature. </p>
+
+<p>An application might require a feature but not declare it because: </p>
+
+<ul>
+<li>The application was compiled against an older version of the Android library
+(Android 1.5 or earlier) and the <code><uses-feature></code> element was
+not available.</li>
+<li>The developer incorrectly assumed that the feature would be present on all
+devices and a declaration was unnecessary.</li>
+<li>The developer omitted the feature declaration accidentally.</li>
+<li>The developer declared the feature explicitly, but the declaration was not
+valid. For example, a spelling error in the <code><uses-feature></code>
+element name or an unrecognized string value for the
+<code>android:name</code> attribute would invalidate the feature declaration.
+</li>
+</ul>
+
+<p>To account for the cases above, Android Market attempts to discover an
+application's implied feature requirements by examining <em>other elements</em>
+declared in the manifest file, specifically,
+<code><uses-permission></code> elements.</p>
+
+<p>If an application requests hardware-related permissions, Android Market
+<em>assumes that the application uses the underlying hardware features and
+therefore requires those features</em>, even though there might be no
+corresponding to <code><uses-feature></code> declarations. For such
+permissions, Android Market adds the underlying hardware features to the
+metadata that it stores for the application and sets up filters for them.</p>
+
+<p>For example, if an application requests the <code>CAMERA</code> permission
+but does not declare a <code><uses-feature></code> element for
+<code>android.hardware.camera</code>, Android Market considers that the
+application requires a camera and should not be shown to users whose devices do
+not offer a camera.</p>
+
+<p>If you don't want Android Market to filter based on a specific implied
+feature, you can disable that behavior. To do so, declare the feature explicitly
+in a <code><uses-feature></code> element and include an
+<code>android:required="false"</code> attribute. For example, to disable
+filtering derived from the <code>CAMERA</code> permission, you would declare
+the feature as shown below.</p>
+
+<pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre>
+
+<p class="caution">It's important to understand that the permissions that you
+request in <code><uses-permission></code> elements can directly affect how
+Android Market filters your application. The reference section <a
+href="permissions-features">Permissions that Imply Feature Requirements</a>,
+below, lists the full set of permissions that imply feature requirements and
+therefore trigger filtering.</p>
+
+<h3 id="bt-permission-handling">Special handling for Bluetooth feature</h3>
+
+<p>Android Market applies slightly different rules than described above, when
+determining filtering for Bluetooth.</p>
+
+<p>If an application declares a Bluetooth permission in a
+<code><uses-permission></code> element, but does not explicitly declare
+the Bluetooth feature in a <code><uses-feature></code> element, Android
+Market checks the version(s) of the Android platform on which the application is
+designed to run, as specified in the <code><uses-sdk></code> element. </p>
+
+<p>As shown in the table below, Android Market enables filtering for the
+Bluetooth feature only if the application declares its lowest or targeted
+platform as Android 2.0 (API level 5) or higher. However, note that Android
+market applies the normal rules for filtering when the application explicitly
+declares the Bluetooth feature in a <code><uses-feature></code> element.
+</p>
+
+<p class="caption"><strong>Table 1.</strong> How Android Market determines the
+Bluetooth feature requirement for an application that requests a Bluetooth
+permission but does not declare the Bluetooth feature in a
+<code><uses-feature></code> element.</p>
+
+<table style="margin-top:1em;">
+<tr>
+<th><nobr>If <code>minSdkVersion</code> is ...</nobr></th>
+<th><nobr>or <code>targetSdkVersion</code> is</nobr></th>
+<th>Result</th>
+</tr>
+<tr>
+<td><nobr><=4 (or uses-sdk is not declared)</nobr></td>
+<td><=4</td>
+<td>Android Market <em>will not</em> filter the application from any devices
+based on their reported support for the <code>android.hardware.bluetooth</code>
+feature.</td>
+</tr>
+<tr>
+<td><=4</td>
+<td>>=5</td>
+<td rowspan="2">Android Market filters the application from any devices that
+do not support the <code>android.hardware.bluetooth</code> feature (including
+older releases).</td>
+</tr>
+<tr>
+<td>>=5</td>
+<td>>=5</td>
+</tr>
+</table>
+
+<p>The examples below illustrate the different filtering effects, based on how
+Android Market handles the Bluetooth feature. </p>
+
+<dl>
+<dt>In first example, an application that is designed to run on older API levels
+declares a Bluetooth permission, but does not declare the Bluetooth feature in a
+<code><uses-feature></code> element.</dt>
+<dd><em>Result:</em> Android Market does not filter the application from any device.</dd>
+</dl>
+
+<pre><manifest ...>
+...
+ <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
+ <uses-sdk android:minSdkVersion="3" />
+...
+</manifest></pre>
+
+<dl>
+<dt>In the second example, below, the same application also declares a target
+API level of "5". </dt>
+<dd><em>Result:</em> Android Market now assumes that the feature is required and
+will filter the application from all devices that do not report Bluetooth support,
+including devices running older versions of the platform. </dd>
+</dl>
+
+<pre><manifest ...>
+...
+ <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
+ <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
+...
+</manifest></pre>
+
+<dl>
+<dt>Here the same application now specifically declares the Bluetooth feature.</dt>
+<dd><em>Result:</em> Identical to the previous example (filtering is applied).</dd>
+</dl>
+
+<pre><manifest ...>
+...
+ <uses-feature android:name="android.hardware.bluetooth" />
+ <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
+ <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
+...
+</manifest></pre>
+
+<dl>
+<dt>Finally, in the case below, the same application adds an
+<code>android:required="false"</code> attribute.</dt>
+<dd><em>Result:</em> Android Market disables filtering based on Bluetooth
+feature support, for all devices.</dd>
+</dl>
+
+<pre><manifest ...>
+...
+ <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
+ <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
+ <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
+...
+</manifest></pre>
+
+
+
+<h3>Testing the features required by your application</h3>
+
+<p>You can use the <code>aapt</code> tool, included in the Android SDK, to
+determine how Android Market will filter your application, based on its declared
+features and permissions. To do so, run <code>aapt</code> with the <code>dump
+badging</code> command. This causes <code>aapt</code> to parse your
+application's manifest and apply the same rules as used by Android Market to
+determine the features that your application requires. </p>
+
+<p>To use the tool, follow these steps: </p>
+
+<ol>
+<li>First, build and export your application as an unsigned <code>.apk</code>.
+If you are developing in Eclipse with ADT, right-click the project and select
+<strong>Android Tools</strong> > <strong>Export Unsigned Application
+Package</strong>. Select a destination filename and path and click
+<strong>OK</strong>. </li>
+<li>Next, locate the <code>aapt</code> tool, if it is not already in your PATH.
+If you are using SDK Tools r7 or earlier, you can find <code>aapt</code> in the
+<code><<em>SDK</em>>/platforms/android-<<em>platform</em>>/tools/</code> directory.
+<p class="note"><strong>Note:</strong> You must use the version of
+<code>aapt</code> that is provided for the latest platform release available. If
+you do not have the latest platform release, download it using the <a
+href="{@docRoot}sdk/adding-components.html">Android SDK and AVD Manager</a>.
+</p></li>
+<li>Run <code>aapt</code> using this syntax: </li>
+</ol>
+
+<pre>$ aapt dump badging <<em>path_to_exported_.apk</em>></pre>
+
+<p>Here's an example of the command output for the second Bluetooth example, above: </p>
+
+<pre>$ ./aapt dump badging BTExample.apk
+package: name='com.example.android.btexample' versionCode='' versionName=''
+<strong>uses-permission:'android.permission.BLUETOOTH_ADMIN'</strong>
+<strong>uses-feature:'android.hardware.bluetooth'</strong>
+sdkVersion:'3'
+targetSdkVersion:'5'
+application: label='BT Example' icon='res/drawable/app_bt_ex.png'
+launchable activity name='com.example.android.btexample.MyActivity'label='' icon=''
+uses-feature:'android.hardware.touchscreen'
+main
+supports-screens: 'small' 'normal' 'large'
+locales: '--_--'
+densities: '160'
+</pre>
+
+
+<h2 id=features-reference>Features Reference</h2>
+
+<p>The tables below provide reference information about hardware and software
+features and the permissions that can imply them on Android Market. </p>
+
+<h3 id="hw-features">Hardware features</h3>
+
+<p>The table below describes the hardware feature descriptors supported by the
+most current platform release. To signal that your application uses or requires
+a hardware feature, declare each value in a <code>android:name</code> attribute
+in a separate <code><uses-feature></code> element. </p>
+
+ <table>
+ <tr>
+ <th>Feature Type</th>
+ <th>Feature Descriptor</th>
+ <th>Description</th>
+ <th>Comments</th>
+ </tr>
+ <tr>
+ <td>Bluetooth</td>
+ <td><code>android.hardware.bluetooth</td>
+ <td>The application uses Bluetooth radio features in the device.</td>
+<td>
+</td>
+ </tr>
+ <tr>
+ <td rowspan="3">Camera</td>
+ <td><code>android.hardware.camera</code></td>
+ <td>The application uses the device's camera. If the device supports
+ multiple cameras, the application uses the camera that facing
+ away from the screen.</td>
+ <td></td>
+ </tr>
+<tr>
+ <td><code>android.hardware.camera.autofocus</code></td>
+ <td>Subfeature. The application uses the device camera's autofocus capability.</td>
+ <td rowspan="2">If declared with the <code>"android:required="true"</code>
+attribute, these subfeatures implicitly declare the
+<code>android.hardware.camera</code> parent feature. </td>
+</tr>
+<tr>
+ <td><code>android.hardware.camera.flash</code></td>
+ <td>Subfeature. The application uses the device camera's flash.</td>
+</tr>
+
+<tr>
+ <td rowspan="3">Location</td>
+ <td><code>android.hardware.location</code></td>
+ <td>The application uses one or more features on the device for determining
+location, such as GPS location, network location, or cell location.</td>
+ <td></td>
+</tr>
+<tr>
+ <td><code>android.hardware.location.network</code></td>
+ <td>Subfeature. The application uses coarse location coordinates obtained from
+a network-based geolocation system supported on the device.</td>
+ <td rowspan="2">If declared with the <code>"android:required="true"</code>
+attribute, these subfeatures implicitly declare the
+<code>android.hardware.location</code> parent feature. </td>
+</tr>
+<tr>
+ <td><code>android.hardware.location.gps</code></td>
+ <td>Subfeature. The application uses precise location coordinates obtained
+from a Global Positioning System receiver on the device. </td>
+</tr>
+
+<tr>
+ <td rowspan="4">Sensors</td>
+ <td><code>android.hardware.sensor.accelerometer</code></td>
+ <td>The application uses motion readings from an accelerometer on the
+device.</td>
+ <td></td>
+</tr>
+<tr>
+ <td><code>android.hardware.sensor.compass</code></td>
+ <td>The application uses directional readings from a magnetometer (compass) on
+the device.</td>
+ <td></td>
+</tr>
+<tr>
+ <td><code>android.hardware.sensor.light</code></td>
+ <td>The application uses the device's light sensor.</td>
+ <td></td>
+</tr>
+<tr>
+ <td><code>android.hardware.sensor.proximity</code></td>
+ <td>The application uses the device's proximity sensor.</td>
+ <td></td>
+</tr>
+<tr>
+ <td>Microphone</td>
+ <td><code>android.hardware.microphone</code></td>
+ <td>The application uses a microphone on the device.
+ </td>
+ <td></td>
+</tr>
+
+<tr>
+ <td rowspan="3">Telephony</td>
+ <td><code>android.hardware.telephony</code></td>
+ <td>The application uses telephony features on the device, such as telephony
+radio with data communication services.</td>
+ <td></td>
+</tr>
+<tr>
+ <td><code>android.hardware.telephony.cdma</code></td>
+ <td>Subfeature. The application uses CDMA telephony radio features on the
+device. </td>
+ <td rowspan="2">If declared with the <code>"android:required="true"</code>
+attribute, these subfeatures implicitly declare the
+<code>android.hardware.telephony</code> parent feature. </td>
+</tr>
+<tr>
+ <td><code>android.hardware.telephony.gsm</code></td>
+ <td>Subfeature. The application uses GSM telephony radio features on the
+device.</td>
+</tr>
+
+<tr>
+ <td rowspan="3">Touchscreen</td>
+ <td><code>android.hardware.touchscreen</code></td>
+ <td>The application uses touchscreen capabilities on the device.</td>
+ <td></td>
+</tr>
+<tr>
+ <td><code>android.hardware.touchscreen.multitouch</code></td>
+ <td>The application uses basic two-point multitouch capabilities on the device
+screen.</td>
+ <td>If declared with the <code>"android:required="true"</code> attribute, this
+subfeature implicitly declares the <code>android.hardware.touchscreen</code>
+parent feature. </td>
+</tr>
+<tr>
+ <td><code>android.hardware.touchscreen.multitouch.distinct</code></td>
+ <td>Subfeature. The application uses advanced multipoint multitouch
+capabilities on the device screen, such as for tracking two or more points fully
+independently.</td>
+ <td>If declared with the <code>"android:required="true"</code> attribute, this
+subfeature implicitly declares the
+<code>android.hardware.touchscreen.multitouch</code> parent feature. </td>
+</tr>
+
+<tr>
+ <td>Wifi</td>
+ <td><code>android.hardware.wifi</code></td>
+ <td>The application uses 802.11 networking (wifi) features on the device.</td>
+ <td></td>
+</tr>
+
+ </table>
+
+<h3 id="sw-features">Software features</h3>
+
+<p>The table below describes the software feature descriptors supported by the
+most current platform release. To signal that your application uses or requires
+a software feature, declare each value in a <code>android:name</code> attribute
+in a separate <code><uses-feature></code> element. </p>
+
+
+ <table>
+ <tr>
+ <th>Feature</th>
+ <th>Attribute Value</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>Live Wallpaper</td>
+ <td><code>android.software.live_wallpaper</code></td>
+ <td>The application uses or provides Live Wallpapers.
+ </td>
+ </tr>
+ </table>
+
+
+<h3 id="permissions">Permissions that Imply Feature Requirements</h3>
+
+<p>Some feature constants listed in the tables above were made available to
+applications <em>after</em> the corresponding API; for example, the
+<code>android.hardware.bluetooth</code> feature was added in Android 2.2 (API
+level 8), but the bluetooth API that it refers to was added in Android 2.0 (API
+level 5). Because of this, some apps were able to use the API before they had
+the ability to declare that they require the API via the
+<code><uses-feature></code> system. </p>
+
+<p>To prevent those apps from being made available unintentionally, Android
+Market assumes that certain hardware-related permissions indicate that the
+underlying hardware features are required by default. For instance, applications
+that use Bluetooth must request the <code>BLUETOOTH</code> permission in a
+<code><uses-permission></code> element — for legacy apps, Android
+Market assumes that the permission declaration means that the underlying
+<code>android.hardware.bluetooth</code> feature is required by the application
+and sets up filtering based on that feature. </p>
+
+<p>The table below lists permissions that imply feature requirements
+equivalent to those declared in <code><uses-feature></code> elements. Note
+that <code><uses-feature></code> declarations, including any declared
+<code>android:required</code> attribute, always take precedence over features
+implied by the permissions below. </p>
+
+<p>For any of the permissions below, you can disable filtering based on the
+implied feature by explicitly declaring the implied feature explicitly, in a
+<code><uses-feature></code> element, with an
+<code>android:required="false"</code> attribute. For example, to disable any
+filtering based on the <code>CAMERA</code> permission, you would add this
+<code><uses-feature></code> declaration to the manifest file:</p>
+
+<pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre>
+
+<table id="permissions-features" >
+ <tr>
+ <th>Category</th>
+ <th>This Permission...</th>
+ <th>Implies This Feature Requirement</th>
+ <!-- <th>Comments</th> -->
+ </tr>
+
+
+<tr>
+ <td rowspan="2">Bluetooth</td>
+ <td><code>BLUETOOTH</code></td>
+ <td><code>android.hardware.bluetooth</code>
+<p>(See <a href="#bt-permission-handling">Special handling for Bluetooth feature</a> for details.)</p></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>BLUETOOTH_ADMIN</code></td>
+ <td><code>android.hardware.bluetooth</code></td>
+<!-- <td></td> -->
+</tr>
+
+<tr>
+ <td>Camera</td>
+ <td><code>CAMERA</code></td>
+ <td><code>android.hardware.camera</code> <em>and</em>
+<br><code>android.hardware.camera.autofocus</code></td>
+<!-- <td></td> -->
+</tr>
+
+<tr>
+ <td rowspan="5">Location</td>
+ <td><code>ACCESS_MOCK_LOCATION</code></td>
+ <td><code>android.hardware.location</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>ACCESS_LOCATION_EXTRA_COMMANDS</code></td>
+ <td><code>android.hardware.location</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>INSTALL_LOCATION_PROVIDER</code></td>
+ <td><code>android.hardware.location</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>ACCESS_COARSE_LOCATION</code></td>
+ <td><code>android.hardware.location.network</code> <em>and</em>
+<br><code>android.hardware.location</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>ACCESS_FINE_LOCATION</code></td>
+ <td><code>android.hardware.location.gps</code> <em>and</em>
+<br><code>android.hardware.location</code></td>
+<!-- <td></td> -->
+</tr>
+
+<tr>
+ <td>Microphone</td>
+ <td><code>RECORD_AUDIO</code></td>
+ <td><code>android.hardware.microphone</code></td>
+<!-- <td></td> -->
+</tr>
+
+<tr>
+ <td rowspan="11">Telephony</td>
+ <td><code>CALL_PHONE</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>CALL_PRIVILEGED</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+
+<tr>
+ <td><code>MODIFY_PHONE_STATE</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>PROCESS_OUTGOING_CALLS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>READ_SMS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>RECEIVE_SMS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>RECEIVE_MMS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>RECEIVE_WAP_PUSH</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>SEND_SMS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>WRITE_APN_SETTINGS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>WRITE_SMS</code></td>
+ <td><code>android.hardware.telephony</code></td>
+<!-- <td></td> -->
+</tr>
+
+<tr>
+ <td rowspan="3">Wifi</td>
+ <td><code>ACCESS_WIFI_STATE</code></td>
+ <td><code>android.hardware.wifi</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>CHANGE_WIFI_STATE</code></td>
+ <td><code>android.hardware.wifi</code></td>
+<!-- <td></td> -->
+</tr>
+<tr>
+ <td><code>CHANGE_WIFI_MULTICAST_STATE</code></td>
+ <td><code>android.hardware.wifi</code></td>
+<!-- <td></td> -->
+</tr>
+</table>
\ No newline at end of file
diff --git a/docs/html/guide/topics/manifest/uses-permission-element.jd b/docs/html/guide/topics/manifest/uses-permission-element.jd
index aec765c..085b9f0 100644
--- a/docs/html/guide/topics/manifest/uses-permission-element.jd
+++ b/docs/html/guide/topics/manifest/uses-permission-element.jd
@@ -2,6 +2,38 @@
@jd:body
<dl class="xml">
+
+ <div class="sidebox-wrapper">
+ <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png">
+ <div id="qv-sub-rule">
+ <img src="{@docRoot}assets/images/icon_market.jpg" style="float:left;margin:0;padding:0;">
+ <p style="color:#669999;"><code style="color:#669999;"><uses-permission></code> and filtering on Android Market. </p>
+
+<p style="margin-top:1em;">In some cases, the permissions that you request
+through <code><uses-permission></code> can affect how
+your application is filtered by Android Market.</p>
+
+<p style="margin-top:1em;">If you request a hardware-related permission —
+<code>CAMERA</code>, for example — Android Market assumes that your
+application requires the underlying hardware feature and filters the application
+from devices that do not offer it.</p>
+
+<p style="margin-top:1em;">To control filtering, always explicitly declare
+hardware features in <code><uses-feature></code> elements, rather than
+relying on Android Market to "discover" the requirements in
+<code><uses-permission></code> elements. Then, if you want to disable
+filtering for a particular feature, you can add a
+<code>android:required="false"</code> attribute to the
+<code><uses-feature></code> declaration.</p>
+
+<p style="margin-top:1em;" class="caution">For a list of permissions that imply
+hardware features, see the documentation for the <a
+href="{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions-features">
+<code><uses-feature></code></a> element.</p>
+</div>
+</div>
+
+
<dt>syntax:</dt>
<dd><pre class="stx"><uses-permission android:<a href="#nm">name</a>="<i>string</i>" /></pre></dd>
@@ -10,7 +42,7 @@
<dt>description:</dt>
<dd>Requests a permission that the application must be granted in
-order for it to operate correctly. Permissions are granted when the
+order for it to operate correctly. Permissions are granted by the user when the
application is installed, not while it's running.
<p>
@@ -38,6 +70,11 @@
<dd>API Level 1</dd>
<dt>see also:</dt>
-<dd><code><a href="{@docRoot}guide/topics/manifest/permission-element.html"><permission></a></code></dd>
+<dd>
+<ul>
+ <li><code><a href="{@docRoot}guide/topics/manifest/permission-element.html"><permission></a></code></li>
+ <li><code><a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code></li>
+</ul>
+</dd>
</dl>
diff --git a/services/java/com/android/server/WindowManagerService.java b/services/java/com/android/server/WindowManagerService.java
index 55ebded..1cbc8324 100644
--- a/services/java/com/android/server/WindowManagerService.java
+++ b/services/java/com/android/server/WindowManagerService.java
@@ -687,7 +687,7 @@
}
}
if (touchedWin != null) {
- if (DEBUG_DRAG) {
+ if (false && DEBUG_DRAG) {
Slog.d(TAG, "sending DRAG_LOCATION to " + touchedWin);
}
DragEvent evt = DragEvent.obtain(DragEvent.ACTION_DRAG_LOCATION,