Screen compatibility overview

Stay organized with collections Save and categorize content based on your preferences.

Android runs on a variety of devices that have different screen sizes and pixel densities. The system performs basic scaling and resizing to adapt your user interface to different screens, but there is more work you should do to ensure your UI gracefully adapts for each type of screen.

This page provides an overview of these topics and the features available on Android to help your app adapt accordingly. For more specific instructions about how to build your app for these screen variations, see the following pages:

Screen sizes

The screen size is the visible space provided for your app UI. The screen size as it's known to your app is not the actual size of the device screen—it takes into account the screen orientation, system decorations (such as the navigation bar), and window configuration changes (such as when the user enables multi-window mode).

Flexible layouts

By default, Android resizes your app layout to fit the current screen. To ensure your layout resizes well for even small variations in screen size, you need to implement your layout with flexibility in mind. The core principle you must follow is to avoid hard-coding the position and size of your UI components. Instead, allow view sizes to stretch and specify view positions relative to the parent view or other sibling views so your intended order and relative sizes remain the same as the layout grows.

Learn more about flexible layouts.

Alternative layouts

A flexible layout is very important, but you should also design different layouts that optimize the user experience for the available space on different devices such as phones and tablets. So Android allows you to provide alternative layout files that the system applies at runtime based on the current device's screen size.

Figure 1. The same app uses a different layout for different screen sizes

Learn how to create alternative layouts.

Stretchable images

Because your layout should stretch to fit the current screen, so too should the bitmaps that you attach to any of the layout views. However, stretching an ordinary bitmap in arbitrary directions can result in strange scaling artifacts and skewed images.

To solve this, Android supports nine-patch bitmaps in which you specify small pixel regions that are stretchable—the rest of the image remain unscaled.

Learn more about nine-patch bitmaps.

Pixel densities

The pixel density is the number of pixels within a physical area of the screen and is referred to as dpi (dots per inch). This is different from the resolution, which is the total number of pixels on a screen.

Figure 2. An exaggeration of two devices that are the same size but have different pixel densities

Density independence

Your app achieves "density independence" when it preserves the physical size (from the user's point of view) of your UI design when displayed on screens with different pixel densities (as shown in figure 2). Maintaining density independence is important because, without it, a UI element (such as a button) might appear larger on a low-density screen and smaller on a high-density screen (because when the pixels are larger—as shown in figure 2—a few pixels can go a long way).

The Android system helps you achieve density independence by providing density-independent pixels (dp or dip) as a unit of measurement that you should use instead of pixels (px).

Learn more about density independent pixels.

Alternative bitmaps

To ensure your images appear at their best on all screens, you should provide alternative bitmaps to match each screen density. For example, if your app provides bitmaps only for medium density (mdpi) screens, Android scales them up when on a high-density screen so that the image occupies the same physical space on the screen. This can cause visible scaling artifacts in bitmaps. So your app should include alternative bitmaps at a higher resolution.

Learn how to provide alternative bitmaps.

Vector graphics

For simple types of images (usually icons), you can avoid creating separate images for each density by using vector graphics. Because vector graphics define the illustration with geometric line paths instead of pixels, they can be drawn at any size without scaling artifacts.

Learn more about using vector graphics.

Wear OS, TV, Auto, and Chrome OS

The recommendations above apply to all Android form factors, but if you want to build an app for Wear OS, Android TV, Android Auto, or Chrome OS devices, you need to do a bit more work.

Each of these devices have their own user interaction model that your app should accommodate. In some cases, such as for Wear OS, you should re-think your app's user experience and build an app that's specialized for that device. And to support Chrome OS devices (such as the Google Pixelbook), you might need only slight modifications to your existing app to support keyboard/mouse interaction and a much larger screen.

To support these devices, refer to the following developer guides:


Foldable devices typically have multiple displays with different displays (or even combinations of displays) becoming active for different states of the device folding. Following the guidelines on this page will help your app to adapt to those changing configurations. However, some configurations may have unusual aspect ratios, so it is worth testing how your app behaves on a variety of devices.

Figure 3. Folding and unfolding

Usually, an app that works well in multi-window mode for various window sizes will also behave well on foldable devices.

Learn more about building apps for foldables

Screen incompatibility

Although the Android framework and tools provide everything you need to make an app available to all screen configurations, you still might decide you don't want your app available on some screen configurations due to some sort of incompatibility. In that case, you can declare your app supports only specific screens.