From 4d7bc65538c7cd9fbb1fbbcf22d1da47fcee1219 Mon Sep 17 00:00:00 2001 From: Dirk Dougherty Date: Fri, 27 Jan 2012 17:56:49 -0800 Subject: Doc change: String changes for Android Market Change-Id: I823812a4fd24021bec906ad856479c92a8d2a759 --- .../guide/topics/manifest/uses-feature-element.jd | 122 ++++++++++----------- 1 file changed, 61 insertions(+), 61 deletions(-) (limited to 'docs/html/guide/topics/manifest/uses-feature-element.jd') diff --git a/docs/html/guide/topics/manifest/uses-feature-element.jd b/docs/html/guide/topics/manifest/uses-feature-element.jd index 9f80638..9175566 100644 --- a/docs/html/guide/topics/manifest/uses-feature-element.jd +++ b/docs/html/guide/topics/manifest/uses-feature-element.jd @@ -9,7 +9,7 @@ parent.link=manifest-intro.html

In this document

    -
  1. Android Market and Feature-Based Filtering +
  2. Google Play and Feature-Based Filtering
    1. Filtering based on explicitly declared features
    2. Filtering based on implicit features
      3. @@ -45,26 +45,26 @@ href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest>
      - -

      Android Market and <uses-feature> elements

      -

      Android Market filters the applications that are visible to users, so + +

      Google Play and <uses-feature> elements

      +

      Google Play 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.

      +devices. One of the ways it filters applications is by feature compatibility.

      -

      To do this, Market checks the +

      To do this, Google Play checks the <uses-feature> elements in each application's manifest, to -establish the app's feature needs. Market then shows or hides the application to +establish the app's feature needs. Google Play then shows or hides the application to each user, based on a comparison with the features available on the user's device.

      By specifying the features that your application requires, -you enable Android Market to present your application only to users whose +you enable Google Play to present your application only to users whose devices meet the application's feature requirements, rather than presenting it to all users.

      For important information about how -Android Market uses features as the basis for filtering, please read Android Market and Feature-Based Filtering, +Google Play uses features as the basis for filtering, please read Google Play and Feature-Based Filtering, below.

      @@ -106,7 +106,7 @@ application requires.

      Declared <uses-feature> 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, other services -(such as Android Market) or applications may check your application's +(such as Google Play) or applications may check your application's <uses-feature> 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.

      @@ -207,22 +207,22 @@ can check at run-time whether a higher level of OpenGL ES is available.)

    3. {@link android.content.pm.FeatureInfo}
    4. {@link android.content.pm.ConfigurationInfo}
    5. <uses-permission>
      6. -
    6. Android Market Filters
      7. +
    7. Filters on Google Play
      8. -

      Android Market and Feature-Based Filtering

      +

      Google Play and Feature-Based Filtering

      -

      Android Market filters the applications that are visible to users, so that +

      Google Play 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 +their devices. One of the ways it filters applications is by feature compatibility.

      To determine an application's feature compatibility with a given user's -device, the Android Market service compares:

      +device, Google Play compares:

      • Features required by the application — an application declares features in @@ -238,14 +238,14 @@ are listed in the Features Reference tables at the bottom of this document, and in the class documentation for {@link android.content.pm.PackageManager}.

        -

        When the user launches the Market application, the application queries the +

        When the user launches Google Play, 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.

        +Store application then passes the features list up to Google Play +when establishing the session for the user.

        -

        Each time you upload an application to the Android Market Publisher Site, -Android Market scans the application's manifest file. It looks for +

        Each time you upload an application to the Google Play publisher site, +Google Play scans the application's manifest file. It looks for <uses-feature> elements and evaluates them in combination with other elements, in some cases, such as <uses-sdk> and <uses-permission> elements. After establishing the @@ -253,17 +253,17 @@ application's set of required features, it stores that list internally as metadata associated with the application .apk and the application version.

        -

        When a user searches or browses for applications using the Android Market +

        When a user searches or browses for applications using the Google Play 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 +features are present on the device, Google Play 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 +supported by the device, Google Play filters the application so that it is not visible to the user and not available for download.

        Because the features you declare in <uses-feature> -elements directly affect how Android Market filters your application, it's -important to understand how Android Market evaluates the application's manifest +elements directly affect how Google Play filters your application, it's +important to understand how Google Play evaluates the application's manifest and establishes the set of required features. The sections below provide more information.

        @@ -277,35 +277,35 @@ application absolutely requires the feature and cannot function properly without it ("true"), or whether the application prefers to use the feature if available, but is designed to run without it ("false").

        -

        Android Market handles explicitly declared features in this way:

        +

        Google Play handles explicitly declared features in this way:

          -
        • If a feature is explicitly declared as being required, Android Market adds +
        • If a feature is explicitly declared as being required, Google Play 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: 
          <uses-feature android:name="android.hardware.camera" android:required="true" />
          • -
        • If a feature is explicitly declared as not being required, Android -Market does not add the feature to the list of required features. For +
        • If a feature is explicitly declared as not being required, Google +Play does not add the feature to the list of required features. For that reason, an explicitly 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 +feature, Google Play will still consider the application compatible with the device and will show it to the user, unless other filtering rules apply. For example: 
          <uses-feature android:name="android.hardware.camera" android:required="false" />
        • If a feature is explicitly declared, but without an -android:required attribute, Android Market assumes that the feature +android:required attribute, Google Play assumes that the feature is required and sets up filtering on it.

        In general, if your application is designed to run on Android 1.6 and earlier versions, the android:required attribute is not available in the -API and Android Market assumes that any and all +API and Google Play assumes that any and all <uses-feature> declarations are required.

        Note: By declaring a feature explicitly and including an android:required="false" attribute, you can -effectively disable all filtering on Android Market for the specified feature. +effectively disable all filtering on Google Play for the specified feature.

        @@ -317,7 +317,7 @@ function properly, but which is not declared in a speaking, every application should always 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 +developers, Google Play looks for implicit features in each application and sets up filters for those features, just as it would do for an explicitly declared feature.

        @@ -337,25 +337,25 @@ element name or an unrecognized string value for the
      -

      To account for the cases above, Android Market attempts to discover an +

      To account for the cases above, Google Play attempts to discover an application's implied feature requirements by examining other elements declared in the manifest file, specifically, <uses-permission> elements.

      -

      If an application requests hardware-related permissions, Android Market +

      If an application requests hardware-related permissions, Google Play assumes that the application uses the underlying hardware features and therefore requires those features, even though there might be no corresponding to <uses-feature> declarations. For such -permissions, Android Market adds the underlying hardware features to the +permissions, Google Play adds the underlying hardware features to the metadata that it stores for the application and sets up filters for them.

      For example, if an application requests the CAMERA permission but does not declare a <uses-feature> element for -android.hardware.camera, Android Market considers that the +android.hardware.camera, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.

      -

      If you don't want Android Market to filter based on a specific implied +

      If you don't want Google Play to filter based on a specific implied feature, you can disable that behavior. To do so, declare the feature explicitly in a <uses-feature> element and include an android:required="false" attribute. For example, to disable @@ -366,30 +366,30 @@ the feature as shown below.

      It's important to understand that the permissions that you request in <uses-permission> elements can directly affect how -Android Market filters your application. The reference section Permissions that Imply Feature Requirements, below, lists the full set of permissions that imply feature requirements and therefore trigger filtering.

      Special handling for Bluetooth feature

      -

      Android Market applies slightly different rules than described above, when +

      Google Play applies slightly different rules than described above, when determining filtering for Bluetooth.

      If an application declares a Bluetooth permission in a <uses-permission> element, but does not explicitly declare -the Bluetooth feature in a <uses-feature> element, Android -Market checks the version(s) of the Android platform on which the application is +the Bluetooth feature in a <uses-feature> element, Google +Play checks the version(s) of the Android platform on which the application is designed to run, as specified in the <uses-sdk> element.

      -

      As shown in the table below, Android Market enables filtering for the +

      As shown in the table below, Google Play 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 +platform as Android 2.0 (API level 5) or higher. However, note that Google +Play applies the normal rules for filtering when the application explicitly declares the Bluetooth feature in a <uses-feature> element.

      -

      Table 1. How Android Market determines the +

      Table 1. How Google Play determines the Bluetooth feature requirement for an application that requests a Bluetooth permission but does not declare the Bluetooth feature in a <uses-feature> element.

      @@ -403,14 +403,14 @@ permission but does not declare the Bluetooth feature in a <=4 (or uses-sdk is not declared) <=4 -Android Market will not filter the application from any devices +Google Play will not filter the application from any devices based on their reported support for the android.hardware.bluetooth feature. <=4 >=5 -Android Market filters the application from any devices that +Google Play filters the application from any devices that do not support the android.hardware.bluetooth feature (including older releases). @@ -421,13 +421,13 @@ older releases).

      The examples below illustrate the different filtering effects, based on how -Android Market handles the Bluetooth feature.

      +Google Play handles the Bluetooth feature.

      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 <uses-feature> element.
      -
      Result: Android Market does not filter the application from any device.
      +
      Result: Google Play does not filter the application from any device.
      <manifest ...>
@@ -439,7 +439,7 @@ declares a Bluetooth permission, but does not declare the Bluetooth feature in a
 
      
 
      In the second example, below, the same application also declares a target
 API level of "5". 
      
-
      Result: Android Market now assumes that the feature is required and
+
      Result: Google Play 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. 
      
 
      
@@ -465,7 +465,7 @@ including devices running older versions of the platform. 
 
      
 
      Finally, in the case below, the same application adds an
 android:required="false" attribute.
      
-
      Result: Android Market disables filtering based on Bluetooth
+
      Result: Google Play disables filtering based on Bluetooth
 feature support, for all devices.
      
 
      
 
@@ -481,10 +481,10 @@ feature support, for all devices.
 
      Testing the features required by your application
      
 
 
      You can use the aapt tool, included in the Android SDK, to
-determine how Android Market will filter your application, based on its declared
+determine how Google Play will filter your application, based on its declared
 features and permissions. To do so, run  aapt with the dump
 badging command. This causes aapt to parse your
-application's manifest and apply the same rules as used by Android Market to
+application's manifest and apply the same rules as used by Google Play to
 determine the features that your application requires. 
      
 
 
      To use the tool, follow these steps: 
      
@@ -529,7 +529,7 @@ densities: '160'
 
      Features Reference
      
 
 
      The tables below provide reference information about hardware and software
-features and the permissions that can imply them on Android Market. 
      
+features and the permissions that can imply them on Google Play. 
      
 
 
      Hardware features
      
 
@@ -873,12 +873,12 @@ 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
 <uses-feature> system. 
      
 
-
      To prevent those apps from being made available unintentionally,  Android
-Market assumes that certain hardware-related permissions indicate that the
+
      To prevent those apps from being made available unintentionally,  Google
+Play 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 BLUETOOTH permission in a
-<uses-permission> element — for legacy apps, Android
-Market assumes that the permission declaration means that the underlying
+<uses-permission> element — for legacy apps, Google
+Play assumes that the permission declaration means that the underlying
 android.hardware.bluetooth feature is required by the application
 and sets up filtering based on that feature. 
      
 
-- 
cgit v1.1