Android N is still in active development, but you can try it now as part of the N Developer Preview. The sections below highlight some of the new features for developers.
Make sure to check out the Behavior Changes to learn about areas where platform changes may affect your apps, take a look at the developer guides to learn more about key features, and download theAPI Reference for details on new APIs.
Multi-window support
In Android N, we're introducing a new and much-requested multitasking feature into the platform — multi-window support.
Users can now pop open two apps on the screen at once.
- On phones and tablets running Android N, users can run two apps side-by-side or one-above-the-other in splitscreen mode. Users can resize the apps by dragging the divider between them.
- On Android TV devices, apps can put themselves in picture-in-picture mode, allowing them to continue showing content while the user browses or interacts with other apps.
Figure 1. Apps running in split-screen mode.
Especially on tablets and other larger-screen devices, multi-window support gives you new ways to engage users. You can even enable drag-and-drop in your app to let users conveniently drag content to or from your app — a great way to enhance your user experience.
It's straightforward to add multi-window support to your app and configure how it handles multi-window display. For example, you can specify your activity's minimum allowable dimensions, preventing users from resizing the activity below that size. You can also disable multi-window display for your app, which ensures that the system will only show your app in full-screen mode.
For more information, see the Multi-Window Support developer documentation.
Notification enhancements
In Android N we've redesigned notifications to make them easier and faster to use. Some of the changes include:
- Template updates: We're updating notification templates to put a new emphasis on hero image and avatar. Developers will be able to take advantage of the new templates with minimal adjustments in their code.
- Bundled notifications: The system can group messages together, for example by message topic, and display the group. A user can take actions, such as Dismiss or Archive, on them in place. If you’ve implemented notifications for Android Wear, you’ll already be familiar with this model.
- Direct reply: For real-time communication apps, the Android system supports inline replies so that users can quickly respond to an SMS or text message directly within the notification interface.
- Custom views: Two new APIs enable you to leverage system decorations, such as notification headers and actions, when using custom views in notifications.
Figure 2. Bundled notifications and direct reply.
To learn how to implement the new features, see t he Notifications guide.
Profile-guided JIT/AOT compilation
In Android N, we've added a Just in Time (JIT) compiler with code profiling to ART, which lets it constantly improve the performance of Android apps as they run. The JIT compiler complements ART's current Ahead of Time (AOT) compiler and helps improve runtime performance, save storage space, and speed up app updates and system updates.
Profile-guided compilation lets ART manage the AOT/JIT compilation for each app according to its actual usage, as well as conditions on the device. For example, ART maintains a profile of each app's hot methods and can precompile and cache those methods for best performance. It leaves other parts of the app uncompiled until they are actually used.
Besides improving performance for key parts of the app, profile-guided compilation helps reduce an app's overall RAM footprint, including associated binaries. This feature is especially important on low-memory devices.
ART manages profile-guided compilation in a way that minimizes impact on the device battery. It does precompilation only when then the device is idle and charging, saving time and battery by doing that work in advance.
Quick path to app install
One of the most tangible benefits of ART's JIT compiler is the speed of app installs and system updates. Even large apps that required several minutes to optimize and install in Android 6.0 can now install in just a matter of seconds. System updates are also faster, since there's no more optimizing step.
Doze on the go...
Android 6.0 introduced Doze, a system mode that saves battery by deferring apps' CPU and network activities when the device is idle, such as when it's sitting on a table or in a drawer.
Now in Android N, Doze takes a step further and saves battery while on the go. Any time the screen is off for a period of time and the device is unplugged, Doze applies a subset of the familiar CPU and network restrictions to apps. This means users can save battery even when carrying their devices in their pockets.
Figure 3. Doze now applies restrictions to improve battery life even when the device is not stationary.
A short time after the screen turns off while the device is on battery, Doze restricts network access and defers jobs and syncs. During brief maintenance windows, applications are allowed network access and any of their deferred jobs/syncs are executed. Turning the screen on or plugging in the device brings the device out of Doze.
When the device is stationary again, with screen off and on battery for a period of time, Doze applies the full CPU and network restrictions on
PowerManager.WakeLock, AlarmManager alarms, and GPS/Wi-Fi scans.
The best practices for adapting your app to Doze are the same whether the device is moving or not, so if you already updated your app to gracefully handle Doze, you're all set. If not, start adapting your app to Doze now.
Project Svelte: Background optimizations
Project Svelte is an ongoing effort to minimize RAM use by system and apps across the range of Android devices in the ecosystem. In Android N, Project Svelte is focused on optimizing the way apps run in the background.
Background processing is an essential part of most apps. When handled right, it can make your user experience amazing — immediate, fast, and context-aware. When not handled right, background processing can needlessly consume RAM (and battery) and affect system performance for other apps.
Since Android 5.0,
JobScheduler has been the preferred way of performing background work in a way that's good for users. Apps can schedule jobs while letting the system optimize based on memory, power, and connectivity conditions. JobScheduler offers control and simplicity, and we want all apps to use it.
Another good option is
GCMNetworkManager, part of Google Play Services, which offers similar job scheduling with compatibility across legacy versions of Android.
We're continuing to extend
JobScheduler and GCMNetworkManager to meet more of your use cases — for example, in Android N you can now schedule background work based on changes in Content Providers. At the same time we're starting to deprecate some of the older patterns that can reduce system performance, especially on low-memory devices.
In Android N we're removing three commonly-used implicit broadcasts —
CONNECTIVITY_ACTION,ACTION_NEW_PICTURE, and ACTION_NEW_VIDEO — since those can wake the background processes of multiple apps at once and strain memory and battery. If your app is receiving these, take advantage of the N Developer Preview to migrate to JobScheduler and related APIs instead.
Take a look at the Background Optimizations documentation for details.
Data Saver
Figure 4. Data Saver in Settings.
Over the life of a mobile device, the cost of a cellular data plan typically exceeds the cost of the device itself. For many users, cellular data is an expensive resource that they want to conserve.
Android N introduces Data Saver mode, a new system service that helps reduce cellular data use by apps, whether roaming, near the end of the billing cycle, or on a small prepaid data pack. Data Saver gives users control over how apps use cellular data and lets developers provide more efficient service when Data Saver is on.
When a user enables Data Saver in Settings and the device is on a metered network, the system blocks background data usage and signals apps to use less data in the foreground wherever possible — such as by limiting bit rate for streaming, reducing image quality, deferring optimistic precaching, and so on. Users can whitelist specific apps to allow background metered data usage even when Data Saver is turned on.
Android N extends the
ConnectivityManager to provide apps a way to retrieve the user's Data Saver preferences and monitor preference changes. All apps should check whether the user has enabled Data Saver and make an effort to limit foreground and background data usage.Vulkan API
Android N integrates Vulkan™, a new 3D rendering API, into the platform. Like OpenGL™ ES, Vulkan is an open standard for 3D graphics and rendering maintained by the Khronos Group.
Vulkan is designed from the ground up to minimize CPU overhead in the driver, and allow your application to control GPU operation more directly. Vulkan also enables better parallelization by allowing multiple threads to perform work such as command buffer construction at once.
Vulkan development tools and libraries are rolled into the Android NDK. They include:
- Headers
- Validation layers (debug libraries)
- SPIR-V shader compiler
- SPIR-V runtime shader compilation library
Vulkan is only available to apps on devices with Vulkan-capable hardware, such as Nexus 5X and Nexus 6P. We're working closely with our partners to bring Vulkan to more devices as soon as possible.
For more information, see the the API documentation.
Quick Settings Tile API
Figure 5. Quick Settings tiles in the notification shade.
Quick Settings is a popular and simple way to expose key settings and actions, directly from the notification shade. In Android N, we've expanded the scope of Quick Settings to make it even more useful and convenient.
We've added more room for additional Quick Settings tiles, which users can access across a paginated display area by swiping left or right. We've also given users control over what Quick Settings tiles appear and where they are displayed — users can add or move tiles just by dragging and dropping them.
For developers, Android N also adds a new API that lets you define your own Quick Settings tiles to give users easy access to key controls and actions in your app.
Quick Settings tiles are reserved for controls or actions that are either urgently required or frequently used, and should not be used as shortcuts to launching an app.
Once you’ve defined your tiles, you can surface them to users, who can add them to Quick Settings just by drag and drop.
For information about creating an app tile, see the
android.service.quicksettings.Tile in the downloadableAPI Reference.Number-blocking
Android N now supports number-blocking in the platform and provides a framework API to let service providers maintain a blocked-number list. The default SMS app, the default phone app, and carrier apps can read from and write to the blocked-number list. The list is not accessible to other apps.
By making number-blocking a standard feature of the platform, Android provides a consistent way for apps to support number-blocking across a wide range of devices. Among the other benefits that apps can take advantage of are:
- Numbers blocked on calls are also blocked on texts
- Blocked numbers can persist across resets and devices through the Backup & Restore feature
- Multiple apps can use the same blocked numbers list
Additionally, carrier app integration through Android means that carriers can read the blocked numbers list on the device and perform service-side blocking for the user in order to stop unwanted calls and texts from reaching the user through any medium, such as a VOIP endpoint or forwarding phones.
For more information, see
android.provider.BlockedNumberContract in the downloadable API Reference.Call screening
Android N allows the default phone app to screen incoming calls. The phone app does this by implementing the new
CallScreeningService, which allows the phone app to perform a number of actions based on an incoming call's Call.Details, such as:- Reject the incoming call
- Do not allow the call to the call log
- Do not show the user a notification for the call
For more information, see
android.telecom.CallScreeningService in the downloadable API Reference.Multi-locale support, more languages
Android N now lets users select multiple locales in Settings, to better support bilingual use-cases. Apps can use a new API to get the user's selected locales and then offer more sophisticated user experiences for multi-locale users — such as showing search results in multiple languages and not offering to translate webpages in a language the user already knows.
Along with multi-locale support, Android N also expands the range of languages available to users. It offers more than 25 variants each for commonly used languages such as English, Spanish, French, and Arabic. It also adds partial support for more than 100 new languages.
Apps can get the list of locales set by the user by calling
LocaleList.GetDefault(). To support the expanded number of locales, Android N is changing the way that it resolves resources. Make sure that you test and verify that your apps working as expected with the new resource resolution logic.
To learn about the new resource-resolution behavior and the best practices you should follow, see Multilingual Support.
ICU4J APIs in Android
Android N now offers a subset of ICU4J APIs in the Android framework under the
android.icu package. Migration is easy, and mostly entails simply changing from the com.java.icu namespace to android.icu. If you are already using an ICU4J bundle in your apps, switching to the android.icu APIs provided in the Android framework can produce substantial savings in APK size.
To learn more about the Android ICU4J APIs, see ICU4J Support.
OpenGL™ ES 3.2 API
Android N adds framework interfaces and platform support for OpenGL ES 3.2, including:
- All extensions from the Android Extension Pack (AEP) except for
EXT_texture_sRGB_decode. - Floating-point framebuffers for HDR and deferred shading.
- BaseVertex draw calls to enable better batching and streaming.
- Robust buffer access control to reduce WebGL overhead.
The framework API for OpenGL ES 3.2 on Android N is provided with the
GLES32 class. When using OpenGL ES 3.2, be sure to declare the requirement in your manifest file, using the <uses-feature> tag and theandroid:glEsVersion attribute.
For information about using OpenGL ES, including how to check a device's supported OpenGL ES version at runtime, see the OpenGL ES API guide.
Android TV recording
Android N adds the ability to record and playback content from Android TV input services via new recording APIs. Building on top of existing time-shifting APIs, TV input services can control what channel data can be recorded, how recorded sessions are saved, and manage user interaction with recorded content.
For more information, see Android TV Recording APIs.
Android for Work
Android for Work adds many new features and APIs for devices running Android N. Some highlights are below — for a complete list of changes, see Android for Work Updates.
Work profile security challenge
Profile owners targeting the N SDK can specify a separate security challenge for apps running in the work profile. The work challenge is shown when a user attempts to open any work apps. Successful completion of the security challenge unlocks the work profile and decrypts it if necessary. For profile owners,
ACTION_SET_NEW_PASSWORD prompts the user to set a work challenge, andACTION_SET_NEW_PARENT_PROFILE_PASSWORD prompts the user to set a device lock.
Profile owners can set distinct passcode policies for the work challenge (such as how long the PIN needs to be, or whether a fingerprint can be used to unlock the profile) using the
setPasswordQuality(),setPasswordMinimumLength() and related methods. The profile owner can also set the device lock using theDevicePolicyManager instance returned by the new getParentProfileInstance() method. Additionally, profile owners can customize the credentials screen for the work challenge using the newsetOrganizationColor() and setOrganizationName() methods.Turn off work
On a device with a work profile, users can toggle work mode. When work mode is off the managed user is temporarily shut down, which disables work profile apps, background sync, and notifications. This includes the profile owner application. When work mode is off, the system displays a persistent status icon to remind the user that they can't launch work apps. The launcher indicates that work apps and widgets are not accessible.
Always on VPN
Device owners and profile owners can ensure that work apps always connect through a specified VPN. The system automatically starts that VPN after the device boots.
New
DevicePolicyManager methods are setAlwaysOnVpnPackage() and getAlwaysOnVpnPackage().
Because VPN services can be bound directly by the system without app interaction, VPN clients need to handle new entry points for Always on VPN. As before, services are indicated to the system by an intent filter matching action
android.net.VpnService.
Users can also manually set Always on VPN clients that implement
VPNService methods in the primary user using Settings>More>Vpn.Customized provisioning
An application can customize the profile owner and device owner provisioning flows with corporate colors and logos.
DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR customizes flow color.DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI customizes the flow with a corporate logo.Accessibility enhancements
Android N now offers Vision Settings directly on the Welcome screen for new device setup. This makes it much easier for users to discover and configure accessibility features on their devices, including magnification gesture, font size, display size, and TalkBack.
With these accessibility features getting more prominent placement, your users are more likely to try your app with them enabled. Make sure you test your apps early with these settings enabled. You can enable them from Settings > Accessibility.
Also in Android N, accessibility services can now help users with motor impairments to touch the screen. The new API allows building services with features such as face-tracking, eye-tracking, point scanning, and so on, to meet the needs of those users.
For more information, see
android.accessibilityservice.GestureDescription in the downloadable API Reference.Direct boot
Direct boot improves device startup times and lets registered apps have limited functionality even after an unexpected reboot. For example, if an encrypted device reboots while the user is sleeping, registered alarms, messages and incoming calls can now continue notify the user as normal. This also means accessibility services can also be available immediately after a restart.
Direct boot takes advantage of file based encryption in Android N to enable fine grained encryption policies for both system and app data. The system uses a device-encrypted store for select system data and explicitly registered app data. By default a credential-encrypted store is used for all other system data, user data, apps, and app data.
At boot, the system starts in a restricted mode with access to device-encrypted data only, and without general access to apps or data. If you have components that you want to run in this mode, you can register them by setting a flag in the manifest. After restart, the system activates registered components by broadcasting the
For more information, see Direct Boot.LOCKED_BOOT_COMPLETED intent. The system ensures registered device-encrypted app data is available before unlock. All other data is unavailable until the User confirms their lock screen credentials to decrypt it.Key Attestation
Hardware-backed keystores provide a much safer method to create, store, and use cryptographic keys on Android devices. They protect keys from the Linux kernel, potential Android vulnerabilities, and extraction from rooted devices.
To make it easier and more secure to use hardware-backed keystores, Android N introduces Key Attestation. Apps and off-devices can use Key Attestation to strongly determine whether an RSA or EC key pair is hardware-backed, what the properties of the key pair are, and what constraints are applied to its usage and validity.
Apps and off-device services can request information about a key pair through an X.509 attestation certificate which must be signed by a valid attestation key. The attestation key is an ECDSA signing key which is injected into the device’s hardware-backed keystore at the factory. Therefore, an attestation certificate signed by a valid attestation key confirms the existence of a hardware-backed keystore, along with details of key pairs in that keystore.
To ensure that the device is using a secure, official Android factory image, Key Attestation requires that the device bootloader provide the following information to the Trusted Execution Environment (TEE):
- The OS version and patch level installed on the device
- The Verified Boot public key and lock status
For more information about the hardware-backed keystore feature, see the guide for Hardware-backed Keystore.
In addition to Key Attestation, Android N also introduces fingerprint-bound keys that are not revoked on fingerprint enrollment.
Network Security Config
In Android N, apps can customize the behavior of their secure (HTTPS, TLS) connections safely, without any code modification, by using the declarative Network Security Config instead of using the conventional error-prone programmatic APIs (e.g. X509TrustManager).
Supported features:
- Custom trust anchors. Lets an application customize which Certificate Authorities (CA) are trusted for its secure connections. For example, trusting particular self-signed certificates or a restricted set of public CAs.
- Debug-only overrides. Lets an application developer safely debug secure connections of their application without added risk to the installed base.
- Cleartext traffic opt-out. Lets an application protect itself from accidental usage of cleartext traffic.
- Certificate pinning. An advanced feature that lets an application limit which server keys are trusted for secure connections.
For more information, see Network Security Config.
Default Trusted Certificate Authority
By default, apps that target Android N only trust system-provided certificates and no longer trust user-added Certificate Authorities (CA). Apps targeting Android N that wish to trust user-added CAs should use the Network Security Config to specify how user CAs should be trusted.
APK signature scheme v2
The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.
To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.
APK signature scheme v2 support will be available later in the N Developer Preview.
Scoped directory access
In Android N, apps can use new APIs to request access to specific external storage directories, including directories on removable media such as SD cards. The new APIs greatly simplify how your application accesses standard external storage directories, such as the
Pictures directory. Apps like photo apps can use these APIs instead of using READ_EXTERNAL_STORAGE, which grants access to all storage directories, or the Storage Access Framework, which makes the user navigate to the directory.
Additionally, the new APIs simplify the steps a user takes to grant external storage access to your app. When you use the new APIs, the system uses a simple permissions UI that clearly details what directory the application is requesting access to.
For more information, see the Scoped Directory Access developer documentation.
Launcher shortcuts
Android N allows apps to define action-specific shortcuts which can be displayed in the launcher. These launcher shortcuts let your users quickly start common or recommended tasks within your app. Each shortcut contains anintent, which links the shortcut to a specific action in your app. Examples of these actions include:
- Navigating users to a particular location in a mapping app.
- Sending messages to a friend in a communication app.
- Playing the next episode of a TV show in a media app.
- Loading the last save point in a gaming app.
Your app can create up to five dynamic shortcuts. When users perform a gesture over your app's launcher icon, these shortcuts appear. By dragging the shortcuts onto the launcher, users can make persistent copies of the shortcuts, called pinned shortcuts. Users can create an unlimited number of pinned shortcuts for each app.
Note: Although other apps can't access your shortcut data, the launcher does have access to this data. Therefore, the shortcuts you create should conceal sensitive user information.
You can use this command to view your app's shortcuts:
$ adb shell dumpsys shortcut
To update all shortcuts and to delete dynamic shortcuts, use the appropriate methods that the Launcher Shortcut API provides. For more details about this API, see
android.content.pm.ShortcutManager in the downloadable API Reference.Print Service Enhancements
In Android N, print service developers can now surface additional information about individual printers and print jobs.
When listing individual printers, a print service can now set per-printer icons in two ways:
- You can set an icon from a resource ID by calling
PrinterInfo.Builder.setResourceIconId() - You can show an icon from the network by calling
PrinterInfo.Builder.setHasCustomPrinterIcon(), and setting a callback for when the icon is requested usingandroid.printservice.PrinterDiscoverySession.onRequestCustomPrinterIcon()
In addition, you can provide a per-printer activity to display additional information by calling
PrinterInfo.Builder.setInfoIntent().
You can indicate the progress and status of print jobs in the print job notification by calling
android.printservice.PrintJob.setProgress() and android.printservice.PrintJob.setStatus(), respectively.
For more information about these methods, see the downloadable API Reference.
Virtual Files
In previous versions of Android, your app could use the Storage Access Framework to allow users to select files from their cloud storage accounts, such as Google Drive. However, there was no way to represent files that did not have a direct bytecode representation; every file was required to provide an input stream.
Android N adds the concept of virtual files to the Storage Access Framework. The virtual files feature allows your
DocumentsProvider to return document URIs that can be used with an ACTION_VIEW intent even if they don't have a direct bytecode representation. Android N also allows you to provide alternate formats for user files, virtual or otherwise.
To get a URI for a virtual document in your app, first you create an
Intent to open the file picker UI. Since an app cannot directly open a virtual file by using the openInputStream() method, your app does not receive any virtual files if you include the CATEGORY_OPENABLE category.
After the user has made a selection, the system calls the
onActivityResult() method. Your app can retrieve the URI of the virtual file and get an input stream, as demonstrated in the code snippet below. // Other Activity code ...
final static private int REQUEST_CODE = 64;
// We listen to the OnActivityResult event to respond to the user's selection.
@Override
public void onActivityResult(int requestCode, int resultCode,
Intent resultData) {
try {
if (requestCode == REQUEST_CODE &&
resultCode == Activity.RESULT_OK) {
Uri uri = null;
if (resultData != null) {
uri = resultData.getData();
ContentResolver resolver = getContentResolver();
// Before attempting to coerce a file into a MIME type,
// check to see what alternative MIME types are available to
// coerce this file into.
String[] streamTypes =
resolver.getStreamTypes(uri, "*/*");
AssetFileDescriptor descriptor =
resolver.openTypedAssetFileDescriptor(
uri,
streamTypes[0],
null);
// Retrieve a stream to the virtual file.
InputStream inputStream = descriptor.createInputStream();
}
}
} catch (Exception ex) {
Log.e("EXCEPTION", "ERROR: ", ex);
}
}
For more information about accessing user files, see the Storage Access Frameworks guide.
No comments:
Post a Comment