API Level: 12
For developers, the Android 3.1 platform
HONEYCOMB_MR1) 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. The downloadable platform includes no external libraries.
For developers, the Android 3.1 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.1, use the Android SDK Manager to download the platform into your SDK.
The sections below provide a technical overview of what's new for developers in Android 3.1, including new features and changes in the framework API since the previous version.
Android 3.1 introduces powerful new APIs for integrating connected peripherals with applications running on the platform. The APIs are based on a USB (Universal Serial Bus) stack and services that are built into the platform, including support for both USB host and device interactions. Using the APIs, developers can create applications that are able to discover, communicate with, and manage a variety of device types connected over USB.
The stack and APIs distinguish two basic types of USB hardware, based on whether the Android-powered device is acting as host or the external hardware is acting as host:
For both types — USB devices and USB accessories — the platform's USB APIs support discovery by intent broadcast when attached or detached, as well as standard interfaces, endpoints, and transfer modes (control, bulk, and interrupt).
The USB APIs are available in the package
central class is
UsbManager, which provides
helper methods for identifying and communicating with
both USB devices and USB accessories. Applications can acquire an instance of
UsbManager and then query for the list of attached
devices or accessories and then communicate with or manage them.
UsbManager also declares intent actions that the
system broadcasts, to announce when a USB device or accessory is attached or
Other classes include:
UsbDevice, a class representing external hardware connected as a USB device (with the Android-powered device acting as host).
UsbAccessory, representing external hardware connected as the USB host (with the Android-powered device acting as a USB device).
UsbEndpoint, which provide access to standard USB interfaces and endpoints for a device.
UsbRequest, for sending and receiving data and control messages to or from a USB device, sychronously and asynchronously.
UsbConstants, which provides constants for declaring endpoint types, device classes, and so on.
Note that although the USB stack is built into the platform, actual support for USB host and open accessory modes on specific devices is determined by their manufacturers. In particular, host mode relies on appropriate USB controller hardware in the Android-powered device.
Additionally, developers can request filtering on Google Play, such that their applications are not availabe to users whose devices do not provide the appropriate USB support. To request filtering, add one or both of the elements below to the application manifest, as appropriate:
For complete information about how to develop applications that interact with USB accessories, please see the developer documentation.
Android 3.1 exposes a new MTP API that lets applications interact directly with connected cameras and other PTP devices. The new API makes it easy for an application to receive notifications when devices are attached and removed, manage files and storage on those devices, and transfer files and metadata to and from them. The MTP API implements the PTP (Picture Transfer Protocol) subset of the MTP (Media Transfer Protocol) specification.
The MTP API is available in the
android.mtp package and provides
MtpDeviceencapsulates an MTP device that is connected over the USB host bus. An application can instantiate an object of this type and then use its methods to get information about the device and objects stored on it, as well as opening the connection and transferring data. Some of the methods include:
getObjectHandles()returns a list of handles for all objects on the device that match a specified format and parent. To get information about an object, an application can pass a handle to
importFile()lets an application copy data for an object to a file in external storage. This call may block for an arbitrary amount of time depending on the size of the data and speed of the devices, so should be made from a spearate thread.
open()lets an application open a connected MTP/PTP device.
getThumbnail()returns the thumbnail of the object as a byte array.
MtpStorageInfoholds information about about a storage unit on an MTP device, corresponding to the StorageInfo Dataset described in section 5.2.2 of the MTP specification. Methods in the class let an application get a storage unit’s description string, free space, maximum storage capacity, storage ID, and volume identifier.
MtpDeviceInfoholds information about an MTP device corresponding to the DeviceInfo Dataset described in section 5.1.1 of the MTP specification. Methods in the class let applications get a device’s manufacturer, model, serial number, and version.
MtpObjectInfoholds information about an object stored on an MTP device, corresponding to the ObjectInfo Dataset described in section 5.3.1 of the MTP specification. Methods in the class let applications get an object’s size, data format, association type, creation date, and thumbnail information.
MtpConstantsprovides constants for declaring MTP file format codes, association type, and protection status.
Android 3.1 extends the input subsystem to support new input devices and new types of motion events, across all views and windows. Developers can build on these capabilities to let users interact with their applications using mice, trackballs, joysticks, gamepads, and other devices, in addition to keyboards and touchscreens.
For handling mouse, scrollwheel, and trackball input, the platform supports two new motion event actions:
ACTION_SCROLL, which describes the pointer location at which a non-touch scroll motion, such as from a mouse scroll wheel, took place. In the MotionEvent, the value of the
AXIS_VSCROLLaxes specify the relative scroll movement.
ACTION_HOVER_MOVE, reports the current position of the mouse when no buttons are pressed, as well as any intermediate points since the last
HOVER_MOVEevent. Hover enter and exit notifications are not yet supported.
To support joysticks and gamepads, the
includes these new input device sources:
SOURCE_CLASS_JOYSTICK— the source device has joystick axes.
SOURCE_CLASS_BUTTON— the source device has buttons or keys.
SOURCE_GAMEPAD— the source device has gamepad buttons such as
SOURCE_JOYSTICK— the source device has joystick axes. Implies SOURCE_CLASS_JOYSTICK.
To describe motion events from these new sources, as well as those from mice
and trackballs, the platform now defines axis codes on
MotionEvent, similar to how it defines key codes on
KeyEvent. New axis codes for joysticks
and game controllers include
AXIS_THROTTLE, and many others.
MotionEvent axes are represented by
MotionEvent defines a number of generic
axis codes that are used when the framework does not know how to map a
particular axis. Specific devices can use the generic axis codes to pass custom
motion data to applications. For a full list of axes and their intended
interpretations, see the
MotionEvent class documentation.
The platform provides motion events to applications in batches, so a single
event may contain a current position and multiple so-called historical movements.
Applications should use
getHistorySize() to get
the number of historical samples, then retrieve and process all historical
samples in order using
getHistoricalAxisValue(). After that, applications should process the current
Some axes can be retrieved using special accessor methods. For example,
instead of calling
getAxisValue(), applications can call
getX(). Axes that have built-in accessors include
Each input device has a unique, system-assigned ID and may also provide
multiple sources. When a device provides multiple sources, more than one source
can provide axis data using the same axis. For example, a touch event coming
from the touch source uses the X axis for screen position data, while a joystick
event coming from the joystick source will use the X axis for the stick position
instead. For this reason, it's important for applications to interpret axis
values according to the source from which they originate. When handling a motion
event, applications should use methods on the
class to determine the axes supported by a device or source. Specifically,
applications can use
getMotionRanges() to query for all axes of a device or all axes of a given
source of the device. In both cases, the range information for axes returned in
InputDevice.MotionRange object specifies the source for
each axis value.
Finally, since the motion events from joysticks, gamepads, mice, and
trackballs are not touch events, the platform adds a new callback method for
passing them to a
View as "generic" motion events.
Specifically, it reports the non-touch motion events to
Views through a call to
onGenericMotionEvent(), rather than to
The platform dispatches generic motion events differently, depending on the
event source class.
go to the
View under the pointer, similar to how touch
events work. All others go to the currently focused
For example, this means a
View must take focus in order to
receive joystick events. If needed, applications can handle these events at the
level of Activity or Dialog by implementing
onGenericMotionEvent() there instead.
Android 3.1 exposes an API to its built-in RTP (Real-time Transport Protocol) stack, which applications can use to manage on-demand or interactive data streaming. In particular, apps that provide VOIP, push-to-talk, conferencing, and audio streaming can use the API to initiate sessions and transmit or receive data streams over any available network.
The RTP API is available in the
android.net.rtp package. Classes
RtpStream, the base class of streams that send and receive network packets with media payloads over RTP.
AudioStream, a subclass of
RtpStreamthat carries audio payloads over RTP.
AudioGroup, a local audio hub for managing and mixing the device speaker, microphone, and
AudioCodec, which holds a collection of codecs that you define for an
To support audio conferencing and similar usages, an application instantiates two classes as endpoints for the stream:
AudioStreamspecifies a remote endpoint and consists of network mapping and a configured
AudioGrouprepresents the local endpoint for one or more
AudioGroupmixes all the
AudioStreams and optionally interacts with the device speaker and the microphone at the same time.
The simplest usage involves a single remote endpoint and local endpoint.
For more complex usages, please refer to the limitations described for
To use the RTP API, applications must request permission from the user by
in their manifest files. To acquire the device microphone, the
android:name="android.permission.RECORD_AUDIO"> permission is also required.
Starting in Android 3.1, developers can make their homescreen widgets resizeable — horizontally, vertically, or on both axes. Users touch-hold a widget to show its resize handles, then drag the horizontal and/or vertical handles to change the size on the layout grid.
Developers can make any Home screen widget resizeable by defining a
resizeMode attribute in the widget's
AppWidgetProviderInfo metadata. Values for the
resizeMode attribute include "horizontal", "vertical", and "none".
To declare a widget as resizeable horizontally and vertically, supply the value
Here's an example:
<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android" android:minWidth="294dp" android:minHeight="72dp" android:updatePeriodMillis="86400000" android:previewImage="@drawable/preview" android:initialLayout="@layout/example_appwidget" android:configure="com.example.android.ExampleAppWidgetConfigure" android:resizeMode="horizontal|vertical" > </appwidget-provider>
For more information about Home screen widgets, see the App Widgets documentation.
ViewPropertyAnimatorclass provides a convenient way for developers to animate select properties on
Viewobjects. The class automaties and optimizes the animation of the properties and makes it easier to manage multiple simulataneous animations on a
ViewPropertyAnimator is straightforward. To animate properties for
ViewPropertyAnimator object for that
View. Use the
methods on the
ViewPropertyAnimator to specify what property to
animate and how to animate it. For example, to fade the
View to transparent,
handles the details of configuring the underlying
Animator class and starting it, then rendering the
buildLayer()method lets an application force a View's layer to be created and the View rendered into it immediately. For example, an application could use this method to render a View into its layer before starting an animation. If the View is complex, rendering it into the layer before starting the animation will avoid skipping frames.
setCameraDistance(float)to set the distance from the camera to a View. This gives applications improved control over 3D transformations of the View, such as rotations.
setOnBreadCrumbClickListener(), provides a hook to let applications intercept fragment-breadcrumb clicks and take any action needed before going to the backstack entry or fragment that was clicked.
onInflate(attrs, savedInstanceState)is deprecated. Please use
onInflate(activity, attrs, savedInstanceState)instead.
setHasAlpha(boolean)lets an app indicate that all of the pixels in a Bitmap are known to be opaque (false) or that some of the pixels may contain non-opaque alpha values (true). Note, for some configs (such as RGB_565) this call is ignored, since it does not support per-pixel alpha values. This is meant as a drawing hint, as in some cases a bitmap that is known to be opaque can take a faster drawing case than one that may have non-opaque per-pixel alpha values.
getByteCount()gets a Bitmap's size in bytes.
getGenerationId()lets an application find out whether a Bitmap has been modified, such as for caching.
sameAs(android.graphics.Bitmap)determines whether a given Bitmap differs from the current Bitmap, in dimension, configuration, or pixel data.
TrafficStats. Applications can use the methods to get UDP stats, packet count, TCP transmit/receive payload bytes and segments for a given UID.
setNotificationVisibility()method of the a request object.
addCompletedDownload(), lets an application add a file to the downloads database, so that it can be managed by the Downloads application.
Starting from Android 3.1, the system's package manager keeps track of applications that are in a stopped state and provides a means of controlling their launch from background processes and other applications.
Note that an application's stopped state is not the same as an Activity's stopped state. The system manages those two stopped states separately.
The platform defines two new intent flags that let a sender specify whether the Intent should be allowed to activate components in stopped application.
FLAG_INCLUDE_STOPPED_PACKAGES— Include intent filters of stopped applications in the list of potential targets to resolve against.
FLAG_EXCLUDE_STOPPED_PACKAGES— Exclude intent filters of stopped applications from the list of potential targets.
When neither or both of these flags is defined in an intent, the default behavior is to include filters of stopped applications in the list of potential targets.
Note that the system adds
FLAG_EXCLUDE_STOPPED_PACKAGES to all broadcast
intents. It does this to prevent broadcasts from background services from
inadvertently or unnecessarily launching components of stoppped applications.
A background service or application can override this behavior by adding the
FLAG_INCLUDE_STOPPED_PACKAGES flag to broadcast
intents that should be allowed to activate stopped applications.
Applications are in a stopped state when they are first installed but are not yet launched and when they are manually stopped by the user (in Manage Applications).
The platform adds improved notification of application first launch and upgrades through two new intent actions:
ACTION_PACKAGE_FIRST_LAUNCH— Sent to the installer package of an application when that application is first launched (that is, the first time it is moved out of a stopped state). The data contains the name of the package.
ACTION_MY_PACKAGE_REPLACED— Notifies an application that it was updated, with a new version was installed over an existing version. This is only sent to the application that was replaced. It does not contain any additional data. To receive it, declare an intent filter for this action. You can use the intent to trigger code that helps get your application back in proper running shape after an upgrade.
This intent is sent directly to the application, but only if the application was upgraded while it was in started state (not in a stopped state).
LruCacheclass lets your applications benefit from efficient caching. Applications can use the class to reduce the time spent computing or downloading data from the network, while maintaining a sensible memory footprint for the cached data.
LruCacheis a cache that holds strong references to a limited number of values. Each time a value is accessed, it is moved to the head of a queue. When a value is added to a full cache, the value at the end of that queue is evicted and may become eligible for garbage collection.
CookieManagernow supports cookies that use the
file:URI scheme. You can use
setAcceptFileSchemeCookies()to enable/disable support for file scheme cookies, before constructing an instance of
CookieManager. In a
CookieManagerinstance, you can check whether file scheme cookies is enabled by calling
onReceivedLoginRequest()notifies the host application that an autologin request for the user was processed.
The Browser application adds the following features to support web applications:
<video>tag. Playback is hardware-accelerated where possible.
The platform adds new hardware feature constants that developers can declare
in their application manifests, to inform external entities such as Google
Play of the application's requirement for new hardware capabilities supported
in this version of the platform. Developers declare these and other feature
<uses-feature> manifest elements.
android.hardware.usb.accessory— The application uses the USB API to communicate with external hardware devices connected over USB and function as hosts.
android.hardware.usb.host— The application uses the USB API to communicate with external hardware devices connected over USB and function as devices.
For a detailed view of all API changes in Android 3.1 (API Level 12), see the API Differences Report.
The Android 3.1 platform delivers an updated version of the framework API. The Android 3.1 API is assigned an integer identifier — 12 — 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.1 in your application,
you need compile the application against the Android library that is provided in
the Android 3.1 SDK platform. Depending on your needs, you
also need to add an
attribute to the
<uses-sdk> element in the application's
For more information, read What is API Level?