Screen compatibility overview

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.

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

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.

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
device 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).

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.

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.

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.

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.