Skip to content

Most visited

Recently visited

navigation

Android 3.2 APIs

API Level: 13

Android 3.2 (HONEYCOMB_MR2) is an incremental platform release that adds new capabilities for users and developers. The sections below provide an overview of the new features and developer APIs.

For developers, the Android 3.2 platform is available as a downloadable component for the Android SDK. The downloadable platform includes an Android library and system image, as well as a set of emulator skins and more. To get started developing or testing against Android 3.2, use the Android SDK Manager to download the platform into your SDK.

Platform Highlights

New user features

New developer features

API Overview

Screens Support APIs

Android 3.2 introduces new screens support APIs that give you more control over how their applications are displayed across different screen sizes. The API builds on the existing screens-support API, including the platform's generalized screen density model, but extends it with the ability to precisely target specific screen ranges by their dimensions, measured in density-independent pixel units (such as 600dp or 720dp wide), rather than by their generalized screen sizes (such as large or xlarge)

When designing an application's UI, you can still rely on the platform to provide density abstraction, which means that applications do not need to compensate for the differences in actual pixel density across devices. You can design the application UI according to the amount of horizontal or vertical space available. The platform expresses the amount of space available using three new characteristics: smallestWidth, width, and height.

The new screens support API is designed to let you manage application UI according to the smallestWidth of the current screen. You can also manage the UI according to current width or height, as needed. For those purposes, the API provides these tools:

Additionally, applications can still query the system and manage UI and resource loading at runtime, as in the previous versions of the platform.

Since the new API lets you target screens more directly through smallestWidth, width, and height, it's helpful to understand the typical characteristics of the different screen types. The table below provides some examples, measured in "dp" units.

Table 1. Typical devices, with density and size in dp.

Type Density (generalized) Dimensions (dp) smallestWidth (dp)
Baseline phone mdpi 320x480 320
Small tablet/large phone mdpi 480x800 480
7-inch tablet mdpi 600x1024 600
10-inch tablet mdpi 800x1280 800

The sections below provide more information about the new screen qualifiers and manifest attributes. For complete information about how to use the screen support API, see Supporting Multiple Screens.

New resource qualifiers for screens support

The new resource qualifiers in Android 3.2 let you better target your layouts for ranges of screen sizes. Using the qualifiers, you can create resource configurations designed for a specific minimum smallestWidth, current width, or current height, measured in density-independent pixels.

The new qualifiers are:

You can also create multiple overlapping resource configurations if needed. For example, you could tag some resources for use on any screen wider than 480 dp, others for wider than 600 dp, and others for wider than 720 dp. When multiple resource configurations are qualified for a given screen, the system selects the configuration that is the closest match. For precise control over which resources are loaded on a given screen, you can tag resources with one qualifier or combine several new or existing qualifiers.

Based on the typical dimensions listed earlier, here are some examples of how you could use the new qualifiers:

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

Older versions of the platform will ignore the new qualifiers, so you can mix them as needed to ensure that your app looks great on any device. Here are some examples:

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

For complete information about how to use the new qualifiers, see Using new size qualifiers.

New manifest attributes for screen-size compatibility

The framework offers a new set of <supports-screens> manifest attributes that let you manage your app's support for different screen sizess. Specifically, you can specify the largest and smallest screens on which your app is designed to run, as well as the largest screen on which it is designed run without needing the system's new screen compatibility mode. Like the resource qualifiers described above, the new manifest attributes specify the range of screens that the application supports, as specified by the smallestWidth.

The new manifest attributes for screen support are:

Note: Google Play does not currently filter apps based on any of the attributes above. Support for filtering will be added in a later platform release. Applications that require filtering based on screen size can use the existing <supports-screens> attributes.

For complete information about how to use the new attributes, see Declaring screen size support.

Screen compatibility mode

Android 3.2 provides a new screen compatibility mode for applications explicitly declaring that they do not support screens as large as the one on which they are running. This new "zoom" mode is a pixel-scaled — it renders the application in a smaller screen area and then scales the pixels to fill the current screen.

By default, the system offers screen compatibility mode as an user option, for apps that require it. Users can turn the zoom mode on and off using a control available in the system bar.

Because the new screen compatibility mode may not be appropriate for all applications, the platform allows the application to disable it using manifest attributes. When disabled by the app, the system does not offer "zoom" compatibility mode as an option for users when the app is running.

Note: For important information about how to control compatibility mode in your applications, please review the New Mode for Apps on Large Screens article on the Android Developers Blog.

New screen density for 720p televisions and similar devices

To meet the needs of applications running on 720p televisions or similar with moderate density screens, Android 3.2 introduces a new generalized density, tvdpi, with an approximate dpi of 213. Applications can query for the new density in densityDpi and can use the new tvdpi qualifier to tag resources for televisions and similar devices. For example:

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

In general, applications should not need to work with this density. For situations where output is needed for a 720p screen, the UI elements can be scaled automatically by the platform.

UI framework

Media framework

Graphics

IME framework

USB framework

Network

Telephony

Core utilities

New feature constants

The platform adds new hardware feature constants that you can declare in their application manifests, to inform external entities such as Google Play of required hardware and software capabilities. You declare these and other feature constants in <uses-feature> manifest elements.

Google Play filters applications based on their <uses-feature> attributes, to ensure that they are available only to devices on which their requirements are met.

API Differences Report

For a detailed view of all API changes in Android 3.2 (API Level 13), see the API Differences Report.

API Level

The Android 3.2 platform delivers an updated version of the framework API. The Android 3.2 API is assigned an integer identifier — 13 — that is stored in the system itself. This identifier, called the "API Level", allows the system to correctly determine whether an application is compatible with the system, prior to installing the application.

To use APIs introduced in Android 3.2 in your application, you need compile the application against the Android library that is provided in the Android 3.2 SDK platform. Depending on your needs, you might also need to add an android:minSdkVersion="13" attribute to the <uses-sdk> element in the application's manifest.

For more information, read What is API Level?

This site uses cookies to store your preferences for site-specific language and display options.

Hooray!

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.