From eab2d05db42418becd0f60499d2b2acd806fea9a Mon Sep 17 00:00:00 2001 From: Andrew Solovay Date: Wed, 30 Dec 2015 12:12:56 -0800 Subject: [PATCH] docs: Fixing typos Fixed a reported typo (see bug), and while I had the file open, fixed a few other typos and formatting problems. I'll go ahead and build and stage this (see first comment for stage location) to make sure I didn't break anything, but if it looks okay I'll +2 it myself and submit it. bug: 26356168 Change-Id: I57727cecd671ab877c0da27e487fa058d95914c5 --- docs/html/guide/practices/compatibility.jd | 54 ++++++---------------- 1 file changed, 14 insertions(+), 40 deletions(-) diff --git a/docs/html/guide/practices/compatibility.jd b/docs/html/guide/practices/compatibility.jd index db1642e8aaca3..83e841c39b7b6 100644 --- a/docs/html/guide/practices/compatibility.jd +++ b/docs/html/guide/practices/compatibility.jd @@ -74,15 +74,12 @@ users who install your app from Google Play Store are using an Android compatibl

However, you do need to consider whether your app is compatible with each potential -device configuration. Because Android runs on a wide range of device configurations, some features are not -available on all devices. For example, some devices may not include a +device configuration. Because Android runs on a wide range of device configurations, some features +are not available on all devices. For example, some devices may not include a compass sensor. If your app's core functionality requires the use of a compass sensor, then your app is compatible only with devices that include a compass sensor.

- - -

Controlling Your App's Availability to Devices

Android supports a variety of features your app can leverage through platform APIs. Some @@ -91,7 +88,6 @@ widgets), and some are dependent on the platform version. Not every device suppo so you may need to control your app's availability to devices based on your app's required features.

-

To achieve the largest user-base possible for your app, you should strive to support as many device configurations as possible using a single APK. In most situations, you can do so by disabling optional features at runtime and

  • Screen configuration -

    Device features

    In order for you to manage your app’s availability based on device features, @@ -127,11 +122,11 @@ file.

    you can declare the compass sensor as required with the following manifest tag:

    -<manifest ... >
+<manifest ... >
     <uses-feature android:name="android.hardware.sensor.compass"
-                  android:required="true" />
+                  android:required="true" />
     ...
-</manifest>
+</manifest>

    Google Play Store compares the features your app requires to the features available on @@ -157,7 +152,7 @@ if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {

    For information about all the filters you can -use to control the availability of your app to users through Google Play Store, see the +use to control the availability of your app to users through Google Play Store, see the Filters on Google Play document.

    @@ -174,12 +169,6 @@ For more information about implicitly required device features, read Permissions that Imply Feature Requirements.

    - - - - - -

    Platform version

    Different devices may run different versions of the Android platform, @@ -191,7 +180,9 @@ Android 1.0 is API level 1 and Android 4.4 is API level 19.

    The API level allows you to declare the minimum version with which your app is compatible, using the {@code -<uses-sdk>} manifest tag and its {@code minSdkVersion} attribute.

    +<uses-sdk>} manifest tag and its +{@code minSdkVersion} +attribute.

    For example, the Calendar Provider APIs were added in Android 4.0 (API level 14). If your app cannot function without @@ -199,10 +190,10 @@ these APIs, you should declare API level 14 as your app's minimum supported version like this:

    -<manifest ... >
-    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
+<manifest ... >
+    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
     ...
-</manifest>
+</manifest>

    The {@code @@ -212,7 +203,7 @@ targetSdkVersion} attribute declares the highest version on which you've opt your app.

    Each successive version of Android provides compatibility for apps that were built using -the APIs from previous platform versions, so your app should always be compitible with future +the APIs from previous platform versions, so your app should always be compatible with future versions of Android while using the documented Android APIs.

    Note: @@ -241,18 +232,13 @@ codename constants in {@link android.os.Build.VERSION_CODES} that corresponds to API level you want to check. For example:

    -if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
+if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
     // Running on something older than API level 11, so disable
     // the drag/drop features that use {@link android.content.ClipboardManager} APIs
     disableDragAndDrop();
 }
    - - - - -

    Screen configuration

    Android runs on devices of various sizes, from phones to tablets and TVs. @@ -279,13 +265,6 @@ and how to restrict your app to certain screen sizes when necessary, read Supporting Different Screens.

    - - - - - - -

    Controlling Your App's Availability for Business Reasons

    In addition to restricting your app's availability based on device characteristics, @@ -301,11 +280,6 @@ is always based on information contained within your APK file. But filtering for non-technical reasons (such as geographic locale) is always handled in the Google Play developer console.

    - - - - -

    Continue reading about: