Get rid of "stretched" UI: On tablets, single-pane layouts lead to awkward whitespace and excessive line lengths. Use padding to reduce the width of UI elements and consider using multi-pane layouts.
Before you publish an app on Google Play, it's important to make sure that the app meets the basic expectations of tablet users through compelling features and an intuitive, well-designed UI.
Tablets are a growing part of the Android installed base that offers new opportunities for user engagement and monetization. If your app is targeting tablet users, this document helps you focus on key aspects of quality, feature set, and UI that can have a significant impact on the app's success. Each focus area is given as checklist item, with each one comprising several smaller tasks or best practices.
Although the checklist tasks below are numbered for convenience, you can handle them in any order and address them to the extent that you feel is right for your app. In the interest of delivering the best possible product to your customers, follow the checklist recommendations to the greatest extent possible.
As you move through the checklist, you'll find links to support resources that can help you address the topics raised in each task.
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 and form factors that the app is targeting. For complete information, see the Core App Quality Guidelines.
Before publishing, also ensure that your app passes several basic technical checks and launch criteria, such as:
The sections that follow provide more information about these and other quality guidelines for tablet apps.
Android makes it easy to develop an app that runs well on a wide range of device screen sizes and form factors. This broad compatibility works in your favor, since it helps you design a single app that you can distribute widely to all of your targeted devices. However, to give your users the best possible experience on each screen configuration — in particular on tablets — you need to optimize your layouts and other UI components for each targeted screen configuration. On tablets, optimizing your UI lets you take full advantage of the additional screen available, such as to offer new features, present new content, or enhance the experience in other ways to deepen user engagement.
If you developed your app for handsets and now want to distribute it to tablets, you can start by making minor adjustments to your layouts, fonts, and spacing. In some cases — such as for 7-inch tablets or for a game with large canvas — these adjustments may be all you need to make your app look great. In other cases, such as for larger tablets, you can redesign parts of your UI to replace "stretched UI" with an efficient multipane UI, easier navigation, and additional content.
Here are some suggestions:
Get rid of "stretched" UI: On tablets, single-pane layouts lead to awkward whitespace and excessive line lengths. Use padding to reduce the width of UI elements and consider using multi-pane layouts.
large and
xlarge screens. You can also provide layouts that are loaded based
on the screen's shortest
dimension or the minimum
available width and height. 16dp padding around content near screen edges.In particular, make sure that your layouts do not appear "stretched" across the screen:
Multi-pane layouts result in a better visual balance on tablet screens, while offering more utility and legibility.
Tablet screens provide significantly more screen real estate to your app, especially when in landscape orientation. In particular, 10-inch tablets offer a greatly expanded area, but even 7-inch tablets give you more space for displaying content and engaging users.
As you consider the UI of your app when running on tablets, make sure that it is taking full advantage of extra screen area available on tablets. Here are some suggestions:
Compound views combine several single views from a handset UI (above) into a richer, more efficient UI for tablets (below).
large/xlarge) or minimum screen widths (such as
sw600dp/sw720).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. Specifically, you should create sets of alternative bitmap drawables for each density in the range commonly supported by tablets.
Table 1. Raw asset sizes for icon types.
| Density | Launcher | Action Bar | Small/Contextual | Notification |
|---|---|---|---|---|
mdpi |
48x48px | 32x32px | 16x16px | 24x24px |
hdpi |
72x72px | 48x48px | 24x24px | 36x36px |
tvdpi |
(use hdpi) | (use hdpi) | (use hdpi) | (use hdpi) |
xhdpi |
96x96px | 64x64px | 32x32px | 48x48px |
Other points to consider:
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 make sure your app is easy to use on tablets, take some time to adjust the font sizes and touch targets in your tablet UI, for all of the screen configurations you are targeting. You can adjust font sizes through styleable attributes or dimension resources, and you can adjust touch targets through layouts and bitmap drawables, as discussed above.
Here are some considerations:
If your app includes a home screen widget, here are a few points to consider to ensure a great user experience on tablet screens:
targetSdkVersion to 14 or higher, if
possible.Let your tablet users experience the best features of your app. Here are some recommendations:
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 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.
<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:
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" />
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.
<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, your app should
declare support for tablet screen sizes in the
<supports-screens>
element in the app manifest, as follows:
<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.
After you've done the work to create an rich, optimized UI for your tablet app, make sure that you let your customers know about it! Here are some key ways to promote your tablet app to users on Google Play.
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:
Many users view an app's promotional video to get an idea of what the app is like and whether they'll enjoy it. For tablet users, capitalize on this interest by highlighting your app's tablet UI in your promotional video. Here are some tips and guidelines:
Make sure to let tablet users know about your tablet UI in your promotional campaigns, web site, social posts, advertisements, and elsewhere. Here are some suggestions:
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 sizes (phones and tablets), with a single Google Play listing. This approach has several important advantages.
If necessary, you can alternatively choose to deliver your app using Multiple APK Support, although in most cases using a single APK to reach all devices is strongly recommended.
To assess the quality of your app on tablets — both for core app quality and tablet app quality — you need to set up a suitable hardware or emulator environment for testing.
The ideal test environment would include a small number of actual hardware devices that represent key form factors and hardware/software combinations currently available to consumers. It's not necessary to test on every device that's on the market — rather, you should focus on a small number of representative devices, even using one or two devices per form factor. The table below provides an overview of devices you could use for testing.
If you are not able to obtain actual hardware devices for testing, you should set up emulated devices (AVDs) to represent the most common form factors and hardware/software combinations. See the table below for suggestions on the emulator configurations to use.
To go beyond basic testing, you can add more devices, more form factors, or new hardware/software combinations to your test environment. For example, you could include mid-size tablets, tablets with more or fewer hardware/software features, and so on. You can also increase the number or complexity of tests and quality criteria.
Table 1. A typical tablet test environment might include one or two devices from each row in the table below, with one of the listed platform versions, screen configurations, and hardware feature configurations.
| Type | Size | Density | Version | AVD Skin |
|---|---|---|---|---|
| 7-inch tablet | large or-sw600 |
hdpi,tvdpi |
Android 4.0+ (API level 14 and higher) | WXGA800-7in |
| 10-inch tablet | xlarge or-sw800 |
mdpi,hdpi,xhdpi |
Android 3.2+ (API level 13 and higher) | WXGA800 |