Screen Layout and Resolution (Fire Tablets)

Fire tablets come in a variety of screen sizes, pixel densities, and aspect ratios. As an app developer, it can be challenging to create an app that runs and looks good on many different form factors, especially if you are porting your app from another tablet or from a phone. This document provides an overview of options and techniques for managing different Fire tablet screens in your app.

• Keeping Your Icons Looking Sharp
• Use Flexible Layout
• Provide Multiple Layouts for Different Screens
• Provide Multiple Graphics Resources
• Declare Support for Screen Sizes in Your Manifest
• Declare Support for Split-Screen (Multi-Window)
  • How to Enable / Disable Split-Screen
• Understand How Fullscreen Modes Affect Layout

Keeping Your Icons Looking Sharp

For increased commonality with Android, the launcher on Fire OS 5 and Fire OS 6 displays the app icon that you provide within your APK. This is a change from earlier versions of Fire OS, where the launcher used the app icon that you uploaded to the developer portal when submitting your app. See Launcher Icon Guidelines for information about required icon resolution and dimensions.

Test your icon across the range of devices where you want your app to run. Ensure that the icon provides a clear and identifiable image that positively represents your brand.

The following video provides guidance on managing how your app displays on Fire Tablets. For additional information about the concepts presented in the video, see the Use Flexible Layout, Provide Multiple Layouts for Different Screens, and Provide Multiple Graphics Resources sections in this topic.

Use Flexible Layout

If you design your app for a specific device's screen, it may both look and behave differently than you expect when it runs on a device with a different screen size, aspect ratio, or pixel density. Specifically:

• Text and images designed for a device with a specific screen size may not properly scale to different screen sizes, or may look distorted or pixelated when scaled.
• Text and images designed for a device with a specific aspect ratio may have distorted or overlapping screen elements on screens with different aspect ratios.
• Text and images designed for a device with a specific screen density may have larger or smaller elements than you expect, which can affect both the appearance and behavior of your app.

To address these issues, design your app to use a flexible layout. A flexible layout enables your app's user interface (UI) to dynamically scale to different screen sizes, densities, and aspect ratios at runtime.

You can follow the Android best practices for designing an app for multiple different screen types, including:

• Create layouts by using density-independent pixels (dp) rather than absolute pixels. The dp units have a baseline of 1 dp per pixel on a 160PPI (mdpi) device, but are automatically scaled at runtime for devices with higher screen densities. Also, use scale-independent pixels (sp) for text. For more information, see Use Density-Independent Pixels.
• Use the ConstraintLayout Android class to build your UI so that elements can be placed and sized relative to other elements. Avoid AbsoluteLayout, which has been deprecated since Android 1.5 (API Level 3). Absolute layouts do not scale across different screens. See Use Constraint Layout for more information.
• Within your XML layout elements, do not specify width and height explicitly; use the Android attribute values wrap_content and match_parent to dynamically size an element based on its content and its parent. See Use "wrap_content" and "match_parent" for more information.

In addition, when porting an app from a smaller screen to a larger one, consider redesigning your app's user interface altogether. You can take advantage of the larger screen size by, for example, including more content or by making better use of portrait and landscape modes.

Provide Multiple Layouts for Different Screens

Another way to provide an app that looks good on different screen types is to define multiple XML layout resources for different screen configurations. At runtime, the device reports its configuration, and Android chooses the appropriate matching layout resources for that screen. Defining multiple sets of layout resources enables you to create a single app with a flexible and adaptable interface for different screen configurations.

Screen configurations can be defined by:

• General screen size. Android provides four generalized size qualifiers: small, medium, large, and xlarge. All of the Fire tablets are considered large or xlarge devices.
• Smallest screen width. The smallest width qualifier, added in Android 3.2 (Honeycomb), defines the width of the smallest side of a tablet in dp units. This qualifier takes the form swXXXdp where XXX is the given width. Smallest width is preferable to the general screen size qualifiers as it enables you to more specifically target a given screen type. All of the Fire tablets support smallest width, except for Kindle Fire (1st Generation/2011), which is based on Android 2.3.3. See Use the Smallest-width Qualifier for more information on these qualifiers.

To define multiple layouts for different screen types, create layout directories within the res/ directory with suffixes that indicate either the general size or a smallest width qualifier. Place your layout XML files specific to those form factors within those directories. For example, you could create a default layout and a custom layout for "large" screen sizes within these two directories:

res/layout res/layout-large

Layout directories for smallest width follow the same convention. Smallest width qualifiers are in dp units, which are scaled to the density of the device. For example, Kindle Fire HDX 7" (3rd Generation/2013) has a physical pixel width of 1200 pixels. Its xhdpi density qualifier equates to a scale factor of 2.0. In dp units the width is scaled (divided by) 2.0, resulting in a smallest width qualifier of sw600dp. For layouts optimized for Kindle Fire HDX 7" (or other similar devices), you would use the following directory:

res/layout-sw600dp

For each of the Fire tablets, the following table shows the actual screen resolution, general size qualifier, scale factor, and smallest width qualifier. For more information about Fire tablet screen sizes, see the Fire Tablet Device and Feature Specifications.

Note that smallest width is not available for Kindle Fire (1st Generation/2011), which is based on an older version of Android. Use a default layout or layout-large to specify a layout for this device.

Provide Multiple Graphics Resources

Bitmap drawables, including icons, background images and other graphics, pose a particularly confounding problem for managing the appearance of your app across screens with differing densities or aspect ratios. If you provide a single set of bitmap resources for one screen size or type, Android automatically scales those graphics to fit the device — potentially with less-than-ideal results. Automatic scaling can result in distorted, fuzzy, or jaggy-looking graphics, or unreadable text.

As with layouts, you can create multiple drawable directories within the res/ directory for your graphics resources, and optimize your graphics specific to those configurations. You can name those drawable directories as you would layouts, for both generalized and smallest-width qualifiers (for example, res/drawable-large). In addition, Android provides qualifiers for specific screen densities (dots per inch) that may be more useful for bitmaps.

For screen densities, Android provides five qualifiers: ldpi, mdpi, hdpi, xhdpi, and tvdpi (low, medium, high, extra high, and TV). For example, to provide both default set of drawables as well as drawables optimized for high-density screens, use these directory names:

res/drawable res/drawable-hdpi

You can also mix and match density qualifiers for drawables or layout with size or smallest width:

res/layout-large-hdpi res/drawable-sw800dp-hdpi

As with layouts and screen sizes, Android chooses the appropriate set of resources based on the configuration the device reports at runtime.

Note that Android's generalized density qualifiers group similar devices together, which makes it easier for you to create layouts and graphics for devices in the same class. Keep in mind, however, that the density qualifiers indicate approximate densities — 160DPI for mdpi, and 240DPI for hdpi — the actual densities of each device may vary slightly. If you use these generalized densities, but build your user interface elements to have precise physical dimensions, you can still encounter unexpected results. For example, layout elements may be the wrong size, or become misaligned on the screen. Be sure to test your app on specific devices to ensure compatibility. The generalized densities correspond to the following DPI values:

• mdpi: 160
• hdpi: 240
• xhdpi: 320
• tvdpi: 213

Declare Support for Screen Sizes in Your Manifest

Even if you follow the previous guidelines for defining a flexible layout and providing alternate layout and graphics resources, you should also declare the supported screen sizes in your Android manifest with the element.

For example, to explicitly indicate that your app supports only tablets ("large" and "xlarge" screens), and those with a minimum width of 533dp, use this code:

   <supports-screens
	android:smallScreens="false"
	android:normalScreens="false"
	android:largeScreens="true"
	android:xlargeScreens="true"
	android:requiresSmallestWidthDp="533"/>

Note: As with the smallest width qualifiers for resource directories, the requiresSmallestWidthDp attribute is only available on Android 3.2 or higher. Therefore, it is not available on Kindle Fire (1st Generation).

See supports-screens for more information on the element.

Declare Support for Split-Screen (Multi-Window)

Split-screen mode, also called multi-window, is a feature where two apps can be run side-by-side, or one over the other, simultaneously. This allows you to watch a video, while checking your email, for instance.

How to Enable / Disable Split-Screen

Set this attribute in your manifest's <activity> or <application> element (AndroidManifest.xml) to enable or disable multi-window display:

android:resizeableActivity=["true" | "false"]

• True: The activity can be launched in split-screen and freeform modes.
• False: The activity does not support multi-window mode. If the user attempts to launch the activity in multi-window mode then the activity takes over the full screen.

This value defaults to “true” in Fire OS 7 (API 28) or higher, unless it has been purposely disabled.

For more information on configuration, such as how to specify minimum dimensions allowed, see the Multi-Window Support page.

Understand How Fullscreen Modes Affect Layout

On the Fire tablets, your app can operate in one of three screen modes:

• Standard mode, in which a status bar and a soft key bar are visible on the screen.
• Fullscreen mode, which hides the status bar and minimizes the soft key bar. Only a small "fullscreen handle" is displayed. Users can view both toolbars by tapping the fullscreen handle or swiping up from the bottom of the screen. The following example shows the flag for fullscreen mode:

@Override
    protected void onCreate(final Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        getWindow().addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);
    }

• Super fullscreen mode (Android 4.0, Ice Cream Sandwich, API 14), which also hides the fullscreen handle. No toolbars are visible on the screen. As with fullscreen mode, users can display both toolbars by tapping the screen. The following example shows the flag for super fullscreen mode.

@Override
    protected void onCreate(final Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        getWindow().addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN);

        // This flag is only available in API level 14 and later.
        getWindow().getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION);
    }

The visibility of the status bar and soft key bar may have different effects on your layout, especially if you design your app for fullscreen mode. Specifically:

• In standard mode the status bar and soft key bar displace your layout by the height or width of the bar. If you query the size of the layout (with View.getWidth() or View.getHeight()), those values are smaller than the overall display because the layout takes both toolbars into account.
• In fullscreen mode, the fullscreen handle draws on top of your layout. In super fullscreen mode no toolbars or handles are visible.
• In both fullscreen modes, when the user taps the screen to display the toolbars, both the status bar and soft key bar draw on top of your layout and obscure any elements beneath them. The size of your layout does not change. In this instance, if you query the dimensions of the layout, the Fire tablet returns the overall dimensions of the screen.

Your app cannot control whether the toolbars are displayed in fullscreen mode; that behavior is up to the user. If your app layout depends on the full screen being visible at all times, including when the toolbars are displayed, you should adjust your layout to take the size of the toolbars into account. You can find the size of the status bar and soft key bar for each Kindle Fire tablet in User Experience Specifications.

Last updated: Apr 27, 2021