Dev Byte: What's New in Android 5.0
Dev Byte: Notifications
API Level: 21
Along with new features and capabilities, Android 5.0 includes a variety of system changes and API behavior changes. This document highlights some of the key changes that you should be understand and account for in your apps.
If you have previously published an app for Android, be aware that your app might be affected by these changes in Android 5.0.
For a high-level look at the new platform features, instead see the Android Lollipop highlights.
In Android 5.0 the ART runtime replaces Dalvik as the platform default. The ART runtime was introduced in Android 4.4 on an experimental basis.
For an overview of ART's new features, see Introducing ART. Some of the major new features are:
Most Android apps should just work without any changes under ART. However, some techniques that work on Dalvik do not work on ART. For information about the most important issues, see Verifying App Behavior on the Android Runtime (ART). Pay particular attention if:
Make sure your notifications take these Android 5.0 changes into account. To learn more about designing your notifications for Android 5.0 and higher, see the notifications design guide.
Notifications are drawn with dark text atop white (or very light) backgrounds to match the new material design widgets. Make sure that all your notifications look right with the new color scheme. If your notifications look wrong, fix them:
setColor()to set an accent color in a circle behind your icon image.
If you are currently adding sounds and vibrations to your notifications by
Vibrator classes, remove this code so that
the system can present notifications correctly in
priority mode. Instead, use
Notification.Builder methods to add sounds and
Previously, Android used
as the master stream to control volume on tablet devices. In Android 5.0, the
master volume stream for both phone and tablet devices is now unified, and
is controlled by
By default, notifications now appear on the user's lock screen in Android 5.0.
Users can choose to protect sensitive information from being exposed, in which
case the system automatically redacts the text displayed by the notification. To
customize this redacted notification, use
If the notification does not contain personal information, or if you want to
allow media playback control on the notification, call the
method and set the notification's visibility level to
If you are implementing notifications that present media playback
status or transport controls, consider using the new
Notification.MediaStyle template instead of a custom
RemoteViews.RemoteView object. Whichever approach you
choose, make sure to set the notification's visibility to
VISIBILITY_PUBLIC so that
your controls are accessible from the lock screen. Note that beginning in
Android 5.0, the system no longer shows
RemoteControlClient objects on the lock screen. For more
If your app uses RemoteControlClient.
Notifications may now appear in a small floating window (also called a heads-up notification) when the device is active (that is, the device is unlocked and its screen is on). These notifications appear similar to the compact form of your notification, except that the heads-up notification also shows action buttons. Users can act on, or dismiss, a heads-up notification without leaving the current app.
Examples of conditions that may trigger heads-up notifications include:
If your app implements notifications under any of those scenarios, make sure that heads-up notifications are presented correctly.
Lock screens in Android 5.0 do not show transport controls for
RemoteControlClient. Instead, your app can provide
media playback control from the lock screen through a notification. This
gives your app more control over the presentation of media buttons, while
providing a consistent experience for users across locked and
Android 5.0 introduces a new
Notification.MediaStyle template for this purpose.
Notification.MediaStyle converts notification
actions that you added with
Notification.Builder.addAction() into compact buttons embedded in your app's
media playback notifications. Pass your session token to the
setSession() method to inform the system that this notification controls an
ongoing media session.
Make sure to set the notification's visibility to
to mark the notification as safe to show on any lock screen (secure or
otherwise). For more information, see
Lock screen notifications.
To display media playback controls if your app is running on the
Android TV or
Wear platform, implement the
MediaSession class. You should also implement
MediaSession if your app needs to receive media
button events on Android devices.
With the introduction of the new concurrent documents and activities
tasks feature in Android 5.0 (see Concurrent
documents and activities in the recents screen below),
ActivityManager.getRecentTasks() method is now deprecated to improve user
privacy. For backward compatibility, this method still returns a small subset of
its data, including the calling application’s own tasks and possibly some other
non-sensitive tasks (such as Home). If your app is using this method to retrieve
its own tasks, use
instead to retrieve that information.
Android 5.0 introduces support for 64-bit systems. The 64-bit enhancement increases address space and improves performance, while still supporting existing 32-bit apps fully. The 64-bit support also improves the performance of OpenSSL for cryptography. In addition, this release introduces new native media NDK APIs, as well as native OpenGL ES (GLES) 3.1 support.
To use the 64-bit support provided in Android 5.0, download and install NDK Revision 10c from the Android NDK page. Refer to the Revision 10c release notes for more information about important changes and bug fixes to the NDK.
method now requires an explicit
and throws an exception if given an implicit intent.
To ensure your app is secure, use an explicit intent when starting or binding
Service, and do not declare intent filters for the service.
Android 5.0 changes the default behavior for your app.
As documented in the Permissions
overview, Android apps can define custom permissions as a means of managing
access to components in a proprietary way, without using the platform’s
pre-defined system permissions. Apps define custom permissions in
<permission> elements declared in their manifest files.
There are a small number of scenarios where defining custom permissions is a legitimate and secure approach. However, creating custom permissions is sometimes unnecessary and can even introduce potential risk to an app, depending on the protection level assigned to the permissions.
Android 5.0 includes a behavior change to ensure that only one app can define a given custom permission, unless signed with the same key as other apps defining the permission.
Any app can define any custom permission it wants, so it can happen that multiple apps might define the same custom permission. For example, if two apps offer a similar capability, they might derive the same logical name for their custom permissions. Apps might also incorporate common public libraries or code examples that themselves include the same custom permission definitions.
In Android 4.4 and earlier, users were able to install multiple such apps on a given device, although the system assigned the protection level specified by the first-installed app.
Starting in Android 5.0, the system enforces a new uniqueness restriction on custom permissions for apps that are signed with different keys. Now only one app on a device can define a given custom permission (as determined by its name), unless the other app defining the permission is signed with the same key. If the user tries to install an app with a duplicate custom permission and is not signed with the same key as the resident app that defines the permission, the system blocks the installation.
In Android 5.0 and later, apps can continue to define their own custom
permissions just as before and to request custom permissions from other apps
<uses-permission> mechanism. However with the
new requirement introduced in Android 5.0, you should carefully assess
possible impacts on your app.
Here are some points to consider:
<permission>elements in its manifest? If so, are they actually necessary to the proper function of your app or service? Or could you use a system default permission instead?
<permission>elements in your app, do you know where they came from?
<permission>elements? Are those permission elements actually necessary?
As mentioned above, for new installs and updates of your app on devices running Android 4.4 or earlier are unaffected and there is no change in behavior. For new installs and updates on devices running Android 5.0 or later, the system prevents installation of your app if it defines a custom permission that is already defined by an existing resident app.
If your app uses custom permissions and is widely distributed and installed, there’s a chance that it will be affected when users receive update their devices to Android 5.0. After the system update is installed, the system revalidates installed apps, including a check of their custom permissions. If your app defines a custom permission that is already defined by another app that has already been validated, and your app is not signed with the same key as the other app, the system does not re-install your app.
On devices running Android 5.0 or later, we recommend that you examine your app immediately, make any adjustments needed, and publish the updated version as soon as possible to your users.
<permission>elements from your app, unless you are certain that they are required for proper function of your app.
Android 5.0 introduces changes the default TLS/SSL configuration used by apps for HTTPS and other TLS/SSL traffic:
These changes may lead to breakages in HTTPS or TLS/SSL connectivity in a small number of cases listed below.
Note that the security ProviderInstaller from Google Play services already offers these changes across Android platform versions back to Android 2.3.
For example, a server might support only 3DES or MD5 cipher suites. The preferred fix is to improve the server’s configuration to enable stronger and more modern cipher suites and protocols. Ideally, TLSv1.2 and AES-GCM should be enabled, and Forward Secrecy cipher suites (ECDHE, DHE) should be enabled and preferred.
An alternative is to modify the app to use a custom SSLSocketFactory to communicate with the server. The factory should be designed to create SSLSocket instances which have some of the cipher suites required by the server enabled in addition to default cipher suites.
For example, some apps contain a custom X509TrustManager that breaks because it expects the authType parameter to be RSA but encounters ECDHE_RSA or DHE_RSA.
For example, the TLS/SSL handshake with a server is erroneously rejected or stalls. The preferred fix is to upgrade the server to comply with the TLS/SSL protocol. This will make the server successfully negotiate these newer protocols or negotiate TLSv1 or older protocols and ignore TLS extensions it does not understand. In some cases disabling TLSv1.1 and TLSv1.2 on the server may work as a stopgap measure until the server software is upgraded.
An alternative is to modify the app to use a custom SSLSocketFactory to communicate with the server. The factory should be designed to create SSLSocket instances with only those protocols enabled which are correctly supported by the server.
Device administrators can add a managed profile to a device. This profile is owned by the administrator, giving the administrator control over the managed profile while leaving the user's personal profile, and its storage space, under the user's control. This change can affect the behavior of your existing app in the following ways.
Device administrators can restrict access to system applications from the
managed profile. In this case, if an app fires an intent from the managed
profile that would ordinarily be handled by that application, and there is no
suitable handler for the intent on the managed profile,
the intent causes an exception. For example, the
device administrator can restrict apps on the managed profile from accessing
the system's camera application. If your app is running on the managed profile
MediaStore.ACTION_IMAGE_CAPTURE, and there is no app on the managed profile
that can handle the intent, this results in an
You can prevent this by checking
that there is at least one handler for any intent
before firing it. To check for a valid handler, call
Intent.resolveActivity(). You can see
an example of this being done in Take Photos
Simply: Take a Photo with the Camera App.
Each profile has its own file storage. Since a file URI refers to a specific location in the file storage, this means that a file URI that is valid on one profile is not valid on the other one. This is not ordinarily a problem for an app, which usually just accesses the files it creates. However, if an app attaches a file to an intent, it is not safe to attach a file URI, since in some circumstances, the intent might be handled on the other profile. For example, a device administrator might specify that image capture events should be handled by the camera app on the personal profile. If the intent is fired by an app on the managed profile, the camera needs to be able to write the image to a location where the managed profile's apps can read it.
To be safe, when
you need to attach a file to an intent that might cross from one profile to the
other, you should create and use a content URI for the file. For more
information about sharing files with content URIs, see Sharing Files.
For example, the device administrator might whitelist
ACTION_IMAGE_CAPTURE to be
handled by the camera in the personal profile. The firing intent's
EXTRA_OUTPUT should contain a content
URI specifying where the photo should be stored. The camera app can write the
image to the location specified by that URI, and the app that fired the intent
would be able to read that file, even if the app is on the other profile.
Android 5.0 removes support for lockscreen widgets; it continues to support widgets on the home screen.