The sections that follow provide more information about these and other -quality guidelines for tablet apps.
+If your app is already uploaded to the Google Play Developer Console, you + can see how it is doing against these checks + by visiting the Optimization + Tips page.
At a minimum, your app should supply custom drawables and assets for common tablet screen densities, tagged with the qualifiers hdpi, xhdpi, or xxhdpi.
At a minimum, your app should supply sets of + custom drawables and assets for common tablet screen densities, + tagged with these qualifiers as appropriate:
+ +hdpi, ORxhdpi, ORxxhdpiTo ensure the broadest possible distribution to tablets, make sure that your
-app is targeting the Android versions that support tablets. You can declare
-the targeted range of Android versions in the
-<uses-sdk>
-element in the app manifest.
At a minimum, your app's
-<uses-sdk>
-should declare support for Android versions as follows:
You can set the app's
+range of targeted Android versions in the manifest file, in the
+<uses-sdk> element. In most cases, you can target Android versions properly by setting the element's targetSdkVersion attribute to the highest API level available.
targetSdkVersion attribute is declared, it should have a value of 11 or higher, ORminSdkVersion attribute is declared, it should have a value of 11 or higher.maxSdkVersion attribute is declared, it must have a value of 12 or higher. Note that, in most cases, the use of maxSdkVersion is not recommended.At a minimum, check the <uses-sdk>
+ element to make sure that:
targetSdkVersion is declared with value 11 or higher (14 or higher is recommended), ORminSdkVersion is declared with value 11 or higher.maxSdkVersion attribute is declared, it must have a value of 11 or higher. Note that, in general, the use of maxSdkVersion is not recommended.Handsets and tablets typically offer slightly different hardware support for -sensors, camera, telephony, and other features. For example, many tablets are -available in a "Wi-Fi" configuration that does not include telephony support.
++ Handsets and tablets typically offer slightly different hardware support for + sensors, camera, telephony, and other features. For example, many tablets are + available in a "Wi-Fi" configuration that does not include telephony support. +
-To ensure that you can deliver a single APK broadly across the -your full customer base, make sure that your app does not have built-in -requirements for hardware features that aren't commonly available on tablets. +
+ So that you can distribute a single APK broadly across your full customer + base of phones and tablets, make sure that your app doesn't declare + requirements for hardware features that aren't commonly available on tablets. + Instead, properly declare the hardware features as not required in the app + manifest, as described below.
<uses-feature>
-elements for hardware features or capabilities that might not be
-available on tablets, except when they are declared with the
-android:required=”false” attribute. For example, your app should
-not require features such as:
+<uses-feature>
+elements. In particular, look for hardware features that might not be
+available on some tablets, such as:
+
android.hardware.telephonyandroid.hardware.camera (refers to back camera), orandroid.hardware.camera.front<permission> elements that imply
-feature requirements that might not be appropriate for tablets, except when
-accompanied by a corresponding <uses-feature> element
-declared with the android:required=”false” attribute.
-Here's an example of a dependency that's properly declared as "not required", so that -it does not limit distribution to devices that do not support the dependency:
-<uses-feature android:name="android.hardware.telephony"
-android:required="false" />
<uses-feature>
+elements as not required by including the android:required=”false”
+attribute.
+
+
+ For example, here's the proper way to declare a dependency on
+ android.hardware.telephony, such that you can still
+ distribute the app broadly, even to devices that don't offer telephony:
+
<uses-feature android:name="android.hardware.telephony" android:required="false" />
<permission> elements that
+imply hardware
+feature requirements that not be appropriate for tablets. If you find such
+permissions, make sure to explicitly declare a corresponding
+<uses-feature> element for the features and includes the
+android:required=”false” attribute.In all cases, the app must function normally when the hardware features it -uses are not available and should offer "graceful degradation" and alternative -functionality where appropriate. For example, if GPS is not supported on the device, -your app could let the user set their location manually. The app should do -run-time checking for the hardware capability that it needs and handle as needed.
+ ++ After declaring hardware features as not required, make sure to test + your app on a variety of devices. The app should function normally when the + hardware features it uses are not available, and it should offer "graceful + degradation" and alternative functionality where appropriate. +
+ ++ For example, if an app normally uses GPS to set the location but GPS is not + supported on the device, the app could let the user set the location manually + instead. The app can check for device hardware capabilities at runtime and handle + as needed. +
To ensure that you can distribute your app to a broad range of tablets, your app should
-declare support for tablet screen sizes in the
-<supports-screens>
-element in the app manifest, as follows:
Tablet users want to know what your app is like on a tablet device, not on a phone. If you developed a tablet app, make sure to upload screenshots - of your tablet UI to the Developer Console. Here are some guidelines: + of your tablet UI to the Google Play Developer Console. Here are some guidelines:
Many users view an app's promotional video to get an idea of what the app is @@ -698,9 +747,9 @@ element in your app.
-Make sure to let tablet users know about your tablet UI in your promotional @@ -759,15 +808,59 @@ element in your app.
Here are some best practices for delivering a successful tablet app on Google Play.
-The Google Play Developer Console now offers an Optimization Tips page that +lets you quickly check how your app is doing against basic guidelines for tablet app +distribution and quality. To visit the page, sign into the Developer Console, +load the app from All Applications, and click Optimization Tips in +the left navigation.
+ +Please use the link below to send +feedback or request a manual review of your Optimization Tips.
+ +Make sure to read the relevant sections of the Tablet App Quality +Guidelines prior to sending feedback.
+ + +The Developer Console creates your app's Optimization Tips page +by running a series of checks to verify basic quality +criteria. If it finds any issues, it alerts you to them as "To Do" +items in the Optimization Tips page.
+ +If you've developed a tablet experience for your app, make sure +to visit the Optimization Tips page to see how your app is doing +against the basic checks. If there are any issues listed, we +recommend addressing them in your app and uploading a new binary for +distribution, if needed.
+ +If the Optimization Tips page lists "To Do" issues that you feel don't +apply to your app or affect its quality on tablets, please notify us +using the Tablet Optimization +Tips Feedback Form. We +will review your app and update your Optimization Tips page as +appropriate.
+ + +After you've uploaded the app to the Developer Console, check the APK's Supported Devices list to make sure that the app is not filtered from tablet devices that you want to target.
-It's recommended that you publish your app as a single APK for all screen