API Level: 17
Android 4.2 ({@link android.os.Build.VERSION_CODES#JELLY_BEAN_MR1}) is an update to the Jelly Bean release that offers new features for users and app developers. This document provides an introduction to the most notable and useful new APIs for developers.
As an app developer, you should download the Android 4.2 system image and SDK platform from the SDK Manager as soon as possible. If you don’t have a device running Android 4.2 on which to test your app, use the Android 4.2 system image to test your app on the Android emulator. Then build your apps against the Android 4.2 platform to begin using the latest APIs.
To better optimize your app for devices running Android {@sdkPlatformVersion},
you should set your {@code targetSdkVersion} to
"{@sdkPlatformApiLevel}", install it on an Android {@sdkPlatformVersion} system image,
test it, then publish an update with this change.
You can use APIs in Android {@sdkPlatformVersion} while also supporting older versions by adding conditions to your code that check for the system API level before executing APIs not supported by your {@code minSdkVersion}. To learn more about maintaining backward-compatibility, read Creating Backward-Compatible UIs.
More information about how API levels work is available in What is API Level?
If you have previously published an app for Android, be aware of the following changes that might affect your app’s behavior:
This change takes effect only if you set either {@code android:targetSdkVersion} or {@code android:minSdkVersion} to 17 or higher. Otherwise, the default value is still {@code “true"} even when running on Android 4.2 and higher.
To meet the privacy expectations of users when your app requests permission for coarse location (and not fine location), the system will not provide a user location estimate that’s more accurate than a city block.
Even if your value for {@code android:targetSdkVersion} and {@code android:minSdkVersion} is lower than 17, your app is not able to modify the settings that have moved to {@link android.provider.Settings.Global} when running on Android 4.2 and higher.
Read more about binding JavaScript code to Android code.
Daydream is a new interactive screensaver mode for Android devices. It activates automatically when the device is inserted into a dock or when the device is left idle while plugged in to a charger (instead of turning the screen off). Daydream displays one dream at a time, which may be a purely visual, passive display that dismisses upon touch, or may be interactive and responsive to the full suite of input events. Your dreams run in your app’s process and have full access to the Android UI toolkit, including views, layouts, and animations, so they are more flexible and powerful than either live wallpapers or app widgets.
You can create a dream for Daydream by implementing a subclass of {@link android.service.dreams.DreamService}. The {@link android.service.dreams.DreamService} APIs are designed to be similar to those of {@link android.app.Activity}. To specify the UI for your dream, pass a layout resource ID or {@link android.view.View} to {@link android.service.dreams.DreamService#setContentView setContentView()} at any point after you have a window, such as from the {@link android.service.dreams.DreamService#onAttachedToWindow()} callback.
The {@link android.service.dreams.DreamService} class provides other important lifecycle callback methods on top of the base {@link android.app.Service} APIs, such as {@link android.service.dreams.DreamService#onDreamingStarted()}, {@link android.service.dreams.DreamService#onDreamingStopped()}, and {@link android.service.dreams.DreamService#onDetachedFromWindow()}. You cannot initiate a {@link android.service.dreams.DreamService} from your app—it is launched automatically by the system.
If your dream is interactive, you can start an activity from the dream to send the user into your app’s full UI for more detail or control. You can use {@link android.service.dreams.DreamService#finish()} to end the dream so the user can see the new Activity.
To make your daydream available to the system, declare your {@link android.service.dreams.DreamService} with a {@code <service>} element in your manifest file. You must then include an intent filter with the action {@code "android.service.dreams.DreamService"}. For example:
<service android:name=".MyDream" android:exported="true"
android:icon="@drawable/dream_icon" android:label="@string/dream_label" >
<intent-filter>
<action android:name="android.service.dreams.DreamService" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</service>
There are some other useful methods in {@link android.service.dreams.DreamService} to be aware of:
For more information, see the {@link android.service.dreams.DreamService} documentation.
Android now allows your app to display unique content on additional screens that are connected to the user’s device over either a wired connection or Wi-Fi. To create unique content for a secondary display, extend the {@link android.app.Presentation} class and implement the {@link android.app.Presentation#onCreate onCreate()} callback. Within {@link android.app.Presentation#onCreate onCreate()}, specify your UI for the secondary display by calling {@link android.app.Presentation#setContentView setContentView()}. As an extension of the {@link android.app.Dialog} class, the {@link android.app.Presentation} class provides the region in which your app can display a unique UI on the secondary display.
To detect secondary displays where you can display your {@link android.app.Presentation}, use either the {@link android.hardware.display.DisplayManager} or {@link android.media.MediaRouter} APIs. While the {@link android.hardware.display.DisplayManager} APIs allow you to enumerate multiple displays that may be connected at once, you should usually use {@link android.media.MediaRouter} instead to quickly access the system’s default display for presentations.
To get the default display for your presentation, call {@link android.media.MediaRouter#getSelectedRoute MediaRouter.getSelectedRoute()} and pass it {@link android.media.MediaRouter#ROUTE_TYPE_LIVE_VIDEO}. This returns a {@link android.media.MediaRouter.RouteInfo} object that describes the system’s currently selected route for video presentations. If the {@link android.media.MediaRouter.RouteInfo} is not null, call {@link android.media.MediaRouter.RouteInfo#getPresentationDisplay()} to get the {@link android.view.Display} representing the connected display.
You can then display your presentation by passing the {@link android.view.Display} object to a constructor for your {@link android.app.Presentation} class. Your presentation will now appear on the secondary display.
To detect at runtime when a new display has been connected, create an instance of {@link android.media.MediaRouter.SimpleCallback} in which you implement the {@link android.media.MediaRouter.SimpleCallback#onRoutePresentationDisplayChanged onRoutePresentationDisplayChanged()} callback method, which the system will call when a new presentation display is connected. Then register the {@link android.media.MediaRouter.SimpleCallback} by passing it to {@link android.media.MediaRouter#addCallback MediaRouter.addCallback()} along with the {@link android.media.MediaRouter#ROUTE_TYPE_LIVE_VIDEO} route type. When you receive a call to {@link android.media.MediaRouter.SimpleCallback#onRoutePresentationDisplayChanged onRoutePresentationDisplayChanged()}, simply call {@link android.media.MediaRouter#getSelectedRoute MediaRouter.getSelectedRoute()} as mentioned above.
To further optimize the UI in your {@link android.app.Presentation} for secondary screens, you can apply a different theme by specifying the {@link android.R.attr#presentationTheme android:presentationTheme} attribute in the {@code <style>} that you’ve applied to your application or activity.
Keep in mind that screens connected to the user’s device often have a larger screen size and likely a different screen density. Because the screen characteristics may different, you should provide resources that are optimized specifically for such larger displays. If you need to request additional resources from your {@link android.app.Presentation}, call {@link android.app.Presentation#getContext()}{@link android.content.Context#getResources .getResources()} to get the {@link android.content.res.Resources} object corresponding to the display. This provides the appropriate resources from your app that are best suited for the secondary display's screen size and density.
For more information and some code samples, see the {@link android.app.Presentation} class documentation.
Android now allows users to add app widgets to the lock screen. To make your App Widget available for use on the lock screen, add the {@link android.appwidget.AppWidgetProviderInfo#widgetCategory android:widgetCategory} attribute to your XML file that specifies the {@link android.appwidget.AppWidgetProviderInfo}. This attribute supports two values: {@code home_screen} and {@code keyguard}. By default, the attribute is set to {@code home_screen} so users can add your app widget to the Home screen. If you want your app widget to be also available on the lock screen, add the {@code keyguard} value:
<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
...
android:widgetCategory="keyguard|home_screen">
</appwidget-provider>
You should also specify an initial layout for your app widget when on the lock screen with the {@link android.appwidget.AppWidgetProviderInfo#initialKeyguardLayout android:initialKeyguardLayout} attribute. This works the same way as the {@link android.appwidget.AppWidgetProviderInfo#initialLayout android:initialLayout}, in that it provides a layout that can appear immediately until your app widget is initialized and able to update the layout.
For more information about building app widgets for the lock screen, including to properly size your app widget when on the lock screen, see the App Widgets guide.
Android now allows multiple user spaces on shareable devices such as tablets. Each user on a device has his or her own set of accounts, apps, system settings, files, and any other user-associated data.
As an app developer, there’s nothing different you need to do in order for your app to work properly with multiple users on a single device. Regardless of how many users may exist on a device, the data your app saves for a given user is kept separate from the data your app saves for other users. The system keeps track of which user data belongs to the user process in which your app is running and provides your app access to only that user’s data and does not allow access to other users’ data.
Whenever your app saves user preferences, creates a database, or writes a file to the user’s internal or external storage space, that data is accessible only while running as that user.
To be certain that your app behaves properly in a multi-user environment, do not refer to your internal app directory or external storage location using hard-coded paths and instead always use the appropriate APIs:
No matter which of these APIs you use to save data for a given user, the data will not be accessible while running as a different user. From your app’s point of view, each user is running on a completely separate device.
If your app wants to identify unique users such as to gather analytics or create other account associations, you should follow the recommended practices for identifying unique installations. By creating a new {@link java.util.UUID} when your app starts for the first time, you’re certain to obtain a unique ID for tracking each user, regardless of how many users install your app on a single device. Alternatively, you can save a local token fetched from your server or use the registrations ID provided by Google Cloud Messaging.
Beware that if your app requests one of the hardware device identifiers (such as the WiFi MAC address or the {@link android.os.Build#SERIAL} number), they will provide the same value for each user because these identifiers are tied to the hardware and not the user. Not to mention the other problems these identifiers introduce as discussed in the Identifying App Installations blog post.
The system settings have been updated to support multiple users with the addition of {@link android.provider.Settings.Global}. This collection of settings is similar to {@link android.provider.Settings.Secure} settings because they are read-only, but applies globally across all user spaces on the device.
Several existing settings were relocated here from either {@link android.provider.Settings.System} or {@link android.provider.Settings.Secure}. If your app is currently making changes to settings previously defined in {@link android.provider.Settings.System} (such as {@link android.provider.Settings.System#AIRPLANE_MODE_ON}), then you should expect that doing so will no longer work on a device running Android 4.2 or higher if those settings were moved to {@link android.provider.Settings.Global}. You can continue to read settings that are in {@link android.provider.Settings.Global}, but because the settings are no longer considered safe for apps to change, attempting to do so will fail silently and the system will write a warning to the system log when running your app on Android 4.2 or higher.
Android now offers several APIs that allow you to build user interfaces that gracefully transform layout orientation to support languages that use right-to-left (RTL) UIs and reading direction, such as Arabic and Hebrew.
To begin supporting RTL layouts in your app, set the {@link android.R.attr#supportsRtl android:supportsRtl} attribute to the {@code <application>} element in your manifest file and set it {@code “true"}. Once you enable this, the system will enable various RTL APIs to display your app with RTL layouts. For instance, the action bar will show the icon and title on the right side and action buttons on the left, and any layouts you’ve created with the framework-provided {@link android.view.View} classes will also be reversed.
If you need to further optimize the appearance of your app when displayed with an RTL layout, there are two basic levels of optimization:
For example, use {@link android.R.attr#layout_marginStart android:layout_marginStart} in place of {@code android:layout_marginLeft} and {@link android.R.attr#layout_marginEnd android:layout_marginEnd} in place of {@code android:layout_marginRight}.
The {@link android.widget.RelativeLayout} class also provides the corresponding layout attributes to replace left/right positions, such as {@code android:layout_alignParentStart} to replace {@code android:layout_alignParentLeft} and {@code android:layout_toStartOf} instead of {@code android:layout_toLeftOf}.
The {@code ldrtl} qualifier is great for drawable resources, so that you can provide graphics that are oriented in the direction corresponding to the reading direction.
Various other APIs are available across the framework to support RTL layouts, such as in the {@link android.view.View} class so that you can implement the proper behaviors for custom views and in {@link android.content.res.Configuration} to query the current layout direction.
Note: If you are using SQlite and have tables or column names that are “number only," be careful: using {@code String.format(String, Object...)} can lead to errors where the numbers have been converted to their Arabic equivalents if your device has been set to the Arabic locale. You must use {@code String.format(Locale,String,Object...)} to ensure numbers are preserved as ASCII. Also use {@code String.format("%d", int)} instead of using {@code String.valueOf(int)} for formatting numbers.
You can now embed fragments inside fragments. This is useful for a variety of situations in which you want to place dynamic and re-usable UI components into a UI component that is itself dynamic and re-usable. For example, if you use {@link android.support.v4.view.ViewPager} to create fragments that swipe left and right and consume a majority of the screen space, you can now insert fragments into each fragment page.
To nest a fragment, simply call {@link android.app.Fragment#getChildFragmentManager()} on the {@link android.app.Fragment} in which you want to add a fragment. This returns a {@link android.app.FragmentManager} that you can use like you normally do from the top-level activity to create fragment transactions. For example, here’s some code that adds a fragment from within an existing {@link android.app.Fragment} class:
Fragment videoFragment = new VideoPlayerFragment(); FragmentTransaction transaction = getChildFragmentManager().beginTransaction(); transaction.add(R.id.video_fragment, videoFragment).commit();
From within a nested fragment, you can get a reference to the parent fragment by calling {@link android.app.Fragment#getParentFragment()}.
The Android Support Library also now supports nested fragments, so you can implement nested fragment designs on Android 1.6 and higher.
Note: You cannot inflate a layout into a fragment when that layout includes a {@code <fragment>}. Nested fragments are only supported when added to a fragment dynamically.
Renderscript computation functionality has been enhanced with the following features:
You can use Renderscript's built-in script intrinsics that implement common operations for you such as:
To use a script intrinsic, call the static create() method of each instrinsic
to create an instance of the script. You then call the available set()
methods of each script intrinsic to set any necessary inputs and options.
Finally, call the {@link android.renderscript.ScriptC#forEach forEach()}
method to execute the script.
{@link android.renderscript.ScriptGroup}s allow you to chain together related Renderscript scripts and execute them with one call.
Use a {@link android.renderscript.ScriptGroup.Builder} to add all of the scripts to the group by calling {@link android.renderscript.ScriptGroup.Builder#addKernel addKernel()}. Once you add all the scripts, create the connections between the scripts by calling {@link android.renderscript.ScriptGroup.Builder#addConnection addConnection()}. When you are done adding the connections, call {@link android.renderscript.ScriptGroup.Builder#create create()} to create the script group. Before executing the script group, specify the input {@link android.renderscript.Allocation} and initial script to run with the {@link android.renderscript.ScriptGroup#setInput} method and provide the output {@link android.renderscript.Allocation} where the result will be written to and final script to run with {@link android.renderscript.ScriptGroup#setOutput setOutput()}. Finally, call {@link android.renderscript.ScriptGroup#execute execute()} to run the script group.
Filterscript defines constraints on the existing Renderscript APIs that allow the resulting code to run
on a wider variety of processors (CPUs, GPUs, and DSPs). To create Filterscript files, create .fs
files instead of .rs files, and specify #pragma rs_fp_relaxed to
tell the Renderscript runtime your scripts do not require strict IEEE 754-2008 floating point precision.
This precision allows flush-to-zero for denorms and round-towards-zero. In addition, your Filterscript
scripts must not use 32-bit built-in types and must specify a custom root function by using the
__attribute__((kernel)) attribute because Filterscript does not support pointers, which
the default signature of the root() function defines.
Note: Although Filterscript support is in the platform, developer support will be available in ADT and SDK Tools Release 21.0.1.
For a detailed view of all API changes in Android 4.2, see the API Differences Report.