Before publishing, make sure that your app and it's store listing meet the - core quality guidlines below.
- -The first step in delivering a great tablet app experience is making sure that it meets the core app quality criteria for all of the devices @@ -60,68 +55,22 @@ and form factors that the app is targeting. For complete information, see the Core App Quality Guidelines.
-- Before publishing, you should also ensure that your app passes several basic - technical checks, such as: + Before publishing, also ensure that your app passes several basic + technical checks and launch criteria, such as:
- For details, see Basic Technical - Checks. -
+The sections that follow provide more information about these and other +quality guidelines for tablet apps.
-Make sure that you upload screenshots of your tablet UI to the - Developer Console and highlight your tablet experience in your app description, - video, and promotional campaigns. For details, see Showcase your - tablet UI in Google Play.
- -- To assess the quality of your app on tablets, you need to set up a suitable - hardware or emulator environment for testing. For more information, see - Setting Up a Test Environment. -
-- Note that a successful tablet app will go well beyond the core and tablet - app quality criteria to offer a custom tablet experience to users. Read - the sections below for ideas on how to plan and develop a great tablet UI for - your app. -
- - -So that your app looks its best, make sure to use icons and other bitmap assets that are created specifically for the densities used by tablet screens. @@ -362,6 +312,8 @@ resource qualifiers to ensure that the proper set of alternative resources gets loaded.
At a minimum, your app should supply custom drawables and assets for common tablet screen densities, tagged with the qualifiers hdpi, xhdpi, or xxhdpi.
To 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:
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.Handsets and tablets typically offer slightly different hardware support for sensors, camera, telephony, and other features. For example, many tablets are @@ -579,13 +547,13 @@ run-time checking for the hardware capability that it needs and handle as needed
<uses-feature>—Description
+ "{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature>—Description
and reference documentation for the <uses-feature>
manifest element.
To ensure that you can distribute your app to a broad range of tablets, -declare all the screen sizes that your app supports in its manifest:
+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:
<supports-screens> element
-with appropriate attributes, as needed. For details, see Basic Technical Checks
-later in this document.<compatible-screens> element in the
-manifest, the element must include attributes that specify all of the size and
-density combinations for tablet screens that the app supports. Note that, if possible,
-you should avoid using this element in your app.<supports-screens>
+ element, if declared, must not specify android:largeScreens="false"
+ or android:xlargeScreens="false".minSdkVersion value less than 13, a
+ <supports-screens>
+ element must be declared with both android:largeScreens="true" and
+ android:xlargeScreens="true".If the app declares a
+<compatible-screens>
+element in the manifest, the element should include attributes that specify
+all of the size and density combinations for tablet screens that the
+app supports. Note that, if possible, you should avoid using the
+<supports-screens>
+element in your app.
<supports-screens>—Description
- and reference documentation for the <supports-screens>
- manifest element.
- After you've done the work to create an rich, optimized UI for your tablet @@ -659,10 +623,9 @@ you should avoid using this element in your app.
Tablet users want to know what your app is like on a tablet device, not on a - phone. Capitalize on their interest by showing them screenshots of your - tablet UI on your app's store listing page. You can upload tablet screenshots - from the Developer Console. Here are some tips and guidelines: -
+ phone. If you developed a tablet app, make sure to upload screenshots + of your tablet UI to the Developer Console. Here are some guidelines: +Make sure that your app follows key best practices that ensure broad - distribution to tablet devices.
+Here are some best practices to consider when publishing a tablet app on Google Play. -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 @@ -841,7 +793,7 @@ you should avoid using this element in your app.
If necessary, you can alternatively choose to deliver your app using Multiple APK Support, + "{@docRoot}google/play/publishing/multiple-apks.html">Multiple APK Support, although in most cases using a single APK to reach all devices is strongly recommended.
@@ -858,189 +810,6 @@ you should avoid using this element in your app. -- This section lists specific details on basic technical checks that you should - perform before publishing. The checks ensure that your app is properly targeted to a - broad range of tablet devices. Make sure that the app meets all of the checks - listed below. -
- -- To verify the basic technical checks, follow the Test - Procedures listed below. Before you start, you need to obtain need the - application source code. -
- -| - Area - | -- ID - | -- Description - | -- Tests - | -
|---|---|---|---|
| Android Versions | -- TB-R1 - | -
- App does target minimum Android versions - that support tablets: -
|
- TA-1 | -
| - TB-R2 - | -
- App does not limit targeting to - exclude Android versions that support tablets: -
Note that, in most cases, the use of |
- TA-1 | -|
| Feature Dependencies | -- TB-R3 - | -
- App does not limit distribution to - tablets by requiring hardware features not normally available on tablets, - whether or implied by - permissions. - -
For details, see Hardware Requirements - earlier in this document. - |
- TA-1 | -
| Screens Support | -- TB-R4 - | -
- App does not limit distribution to common - tablet screen sizes: -
|
- TA-1 | -
| - TB-R5 - | -
- App does supply custom drawables and - assets for common tablet screen densities. Specifically, the APK must include - corresponding resource directories tagged with these qualifiers: -
For details, see Icons and Other Assets - earlier in this document. - |
- TA-2 | -
If you use multiple APK - support to deliver size- or version-specific APKs, the APKs and their - characteristics must meet all of the criteria listed above, either individually - or as a cumulative set.
- -| - Procedure - | - Description - | -- TA-1 - | -
- Obtain the APK and inspect the manifest.xml file. Check for the required attribute values. - |
-
-
|---|---|
| - TA-2 - | -
- Obtain the APK and inspect the resources - directories. Make sure that the app includes custom drawables and assets - directories tagged with the required qualifiers. - |
-