Android 5.0 Behavioral Changes

In addition to providing many new features and functionality, Android 5.0 also makes a variety of changes to system and API behavior. This article highlights some of the major changes you should be aware of and consider when developing your application.

If you've previously published Android apps, be aware that your app may be affected by these changes in Android 5.0.

For more information on the new platform features, see Android Lollipop important content.

Android Runtime (ART)

In Android 5.0, the ART runtime replaces Dalvik as the default setting for the platform. The ART runtime in the experimental phase has been introduced in Android 4.4.

For an overview of the new features of art, see Introduction to Art. Some of the major new features include:

• Pre-(AOT) compilation
• Improved garbage collection (GC)
• Improved debugging support

Most Android apps can work under ART without any changes. However, some techniques suitable for Dalvik are not applicable to ART. For information on the most important issues, see Verifying app behavior on Android Runtime (ART). Special attention should be paid to the following situations:

• Your app uses the Java Native Interface (JNI) to run C + + code.
• You use development tools that generate non-standard code (for example, some code obfuscation tools).
• You use a technology that is incompatible with compressed garbage collection.

Notice

Please make sure that your notification takes into account the above Android 5.0 changes. To learn more about designing notifications for Android 5.0 and later versions, see the Notification Design Guide.

Material Design Style

Use dark text to draw notifications on a white (or very light) background to match the new Material Design widget. Make sure that all of your notifications are aligned with the new color scheme. If your notifications appear to be uncoordinated, please fix them:

• Use the circle in the setColor() back of your icon image to set the accent color.
• Update or remove resources that use colors. The system ignores all non-alpha channels in the action icon and the main notification icon. You should assume that these icons only support alpha channels. The system draws the notification icon in white and draws the action icon in dark gray.

Sound and Vibration

If you are currently using Ringtone , MediaPlayer or the Vibrator class adds sound and vibration to the notification, remove the code so that the system can display the notification correctly in priority mode. Instead, use the Notification.Builder method to add sound and vibration.

Set the device to RINGER_MODE_SILENT allow the device to enter a new priority mode. If you set the device to RINGER_MODE_NORMAL or RINGER_MODE_VIBRATE , the device exits the priority mode.

Previously, Android was used STREAM_MUSIC as a mainstream transmission to control the volume on tablet devices. In Android 5.0, the master volume streaming of mobile phones and tablet devices is now merged, STREAM_RING or STREAM_NOTIFICATION controlled.

Lock screen Visibility

By default, in Android 5.0, notifications are now displayed on the user's lock screen. Users can choose to protect sensitive information from being exposed, in which case the text displayed by the notification is automatically truncated. To customize the notification of this limitation, use the setPublicVersion() .

If the notification does not contain personal information, or if you want to allow the media playback control to appear on the notification, the method is called setVisibility() and the notification's visibility level is set to VISIBILITY_PUBLIC .

Media playback

If you want to implement notifications that display media playback status or transport controls, consider using the new Notification.MediaStyle template instead of customizing the RemoteViews.RemoteView object. Regardless of which method you choose to use, be sure to set the visibility of the notification VISIBILITY_PUBLIC so that your control can be accessed through the lock screen. Please note that starting with Android 5.0, the system no longer RemoteControlClient displays objects on the lock screen. For more information, see if your app uses Remotecontrolclient.

Floating Notifications

Now, when the device is active (that is, the device is unlocked and its screen is turned on), the notification can be displayed in a small floating window (also known as a "floating notification"). These notifications look similar to the Lite version of the notification, but the floating notifications also show the action buttons. Users can process or clear floating notifications without leaving the current app.

Examples of conditions that may trigger floating notifications include:

• The user's Activity is in full-screen mode (app use fullScreenIntent )
• Notifications have a higher priority and use ringtones or vibrations

If your app implements notifications in any of these scenarios, make sure the system displays floating notifications correctly.

Media Controls and Remotecontrolclient

RemoteControlClientClass is now deprecated. Please switch to the new API as soon as possible MediaSession .

The lock screen in Android 5.0 does not MediaSession RemoteControlClient Show or display the transport controls. However, your app can provide a media playback control from the lock screen via a notification. This allows your app to have more control over the display of media buttons, while providing a consistent experience for users who use locked devices and unlocked devices.

To achieve this, Android 5.0 introduces a new Notification.MediaStyle template. Notification.MediaStyleconverts your use of Notification.Builder.addAction() the added notification action to a thin button, embedded in the app's media playback notification. Pass your session token to the setSession() method to tell the system that the notification controls the media session in progress.

Be sure to set the visibility of the notification to VISIBILITY_PUBLIC mark the notification as safe to display on any lock screen (in a safe way or otherwise). For more information, see Lock screen notifications.

To have your app display a media playback control when it's running on an Android TV or Wear platform, implement the MediaSession class. If your app needs to receive Media button events on Android devices, you should also implement MediaSession .

Getrecenttasks ()

With the introduction of the new concurrent documents and Activity Tasks feature in Android 5.0 (see Concurrent documents and activity in the most recently used apps screen below), the method is now deprecated to improve the security of user privacy ActivityManager.getRecentTasks() . For backward compatibility, this method still returns a small portion of its data, including invoking the application's own tasks and possibly some other non-sensitive tasks such as the home page. If your app uses this method to retrieve its own tasks, getAppTasks() retrieve that information instead.

64-bit support in the Android NDK

Android 5.0 introduces support for 64-bit systems. 64-bit enhancements increase address space and improve performance while still fully supporting existing 32-bit applications. 64-bit support can also improve the performance of OpenSSL for encryption. In addition, this release introduces the new native media NDK API, as well as native OpenGL ES (GLES) 3.1 support.

To use the 64-bit support available in Android 5.0, download and install the NDK Revision 10c from the Android NDK page. For more information about important changes and bug fixes for the NDK, see the Revision 10c release notes.

Binding to a service

Context.bindService()The method now needs to Intent be explicit and throws an exception if an implicit intent is provided. To ensure the security of your app, use an explicit intent to start or bind Service , and do not declare intent filters for the service.

WebView

Android 5.0 changed the default behavior of the app.

• If your app is targeted at API level 21 or higher:
  • By default, mixed content and third-party cookies are blocked. To allow mixed content and third-party cookies, use setMixedContentMode() the and setAcceptThirdPartyCookies() methods separately.
  • The system can now intelligently select the portion of the HTML document to be drawn. This new default behavior helps to reduce memory consumption and improve performance. If you want to render the entire document at once, you can enableSlowWholeDocumentDraw() deactivate this optimization by calling.
• If your app is targeted at an API level below 21: The system allows mixed content and third-party cookies, and always renders the entire document at once.

Custom Permission Uniqueness Requirements

As described in the permissions overview, Android Apps can define custom permissions to manage component access in a proprietary way without using platform-predefined system permissions. The application defines custom permissions in the elements declared in its manifest file <permission> .

In rare cases, defining custom permissions is a compliant and secure approach. However, creating custom permissions is sometimes not necessary, and may even pose a potential risk to your app, depending on the level of protection assigned to the permission.

Android 5.0 One of the behavioral changes ensures that only one app can define a given custom permission, unless it is signed with the same key as other apps that define permissions.

Apps that use duplicate custom permissions

Any app can define any custom permissions it needs, so there may be situations where multiple apps define the same custom permissions . For example, if two apps provide similar functionality, they might derive the same logical name for their custom permissions. The app may also include a common common library or code sample that itself contains the same custom permission definitions.

In Android 4.4 and earlier, users can install multiple such apps on a given device, but the system assigns the protection level specified by the first installed app.

Starting with Android 5.0, new custom permission uniqueness Restrictions are enforced for apps that use different key signatures. Now, only one app on the device can define a given custom permission (determined by its name), unless the other app that defines the permission uses the same key signature. If a user tries to install an app that has duplicate custom permissions and the signing key differs from the resident app that defines this permission, the installation will be blocked.

Things to keep in mind for your application

In Android 5.0 and later, apps can continue to define their own custom permissions as before, and <uses-permission> request custom permissions from other apps through the mechanism. However, for the new requirements introduced in Android 5.0, you should carefully evaluate the impact that may be on your application.

Here are a few things to consider:

• Does your app declare any elements in its manifest file <permission> ? If so, are these permissions really necessary for your app or service to work? Or, can you replace them with system default permissions?
• If you have elements in your app <permission> , do you know where they come from?
• Are you actually going to let other apps <uses-permission> ask for your custom permissions?
• Do you <permission> use boilerplate files or sample code in an app that contains elements? Are those permission elements really necessary?
• Does your custom permission use a simple name or a generic term that may be shared by other apps?

New Installation and Updates

As mentioned above, new installations and updates to your app on devices running Android 4.4 or earlier will not be affected, and there is no change in behavior. When new installations and updates are made on a device running Android 5.0 or later, if the app defines a custom permission that has been defined by an existing resident app, your app will be blocked from being installed.

Existing installation with Android 5.0 System update

If your app uses custom updates and is widely distributed and installed, your app may be affected when users receive an update to upgrade their device to Android 5.0. After the system update is installed, the system re-verifies the installed apps, including checking their custom permissions. If your app defines a custom permission that has been defined by another verified app, and your app does not sign with the same key as the app, your app will not be reinstalled .

Suggestions

On devices running Android 5.0 or later, we recommend that you check your app immediately, make any adjustments you want, and post an updated version to your users as soon as possible.

• If you use custom permissions in your app, consider their origins and whether you really need them. Remove all elements from your app <permission> unless you determine that they are necessary for the app to function properly.
• Consider overriding your custom permissions with system default permissions whenever possible.
• If your app requires custom permissions, rename your custom permissions to make them unique to your app, such as appending them to the app's full package name.
• If you have a set of apps that are signed with a different key, and those apps access the shared component through custom permissions, make sure that this custom permission is defined only once in the shared component. Apps that use shared components should not define custom permissions themselves, but should <uses-permission> request access through mechanisms.
• If you have a set of apps that are signed with the same key, each app can define the same custom permissions as needed, and the system allows them to be installed in a regular manner.

Tls/ssl Default configuration changes

Android 5.0 introduces changes to the default Tls/ssl configuration used by the app for HTTPS and other TLS/SSL traffic:

• The TLSv1.2 and TLSv1.1 protocols are now enabled,
• AES-GCM (Aead) encryption suite is now enabled,
• MD5, 3DES, export, and static key ECDH Encryption Suite is now deactivated,
• Preferred to use the Forward Secrecy Encryption Suite (ECDHE and DHE).

In the few cases listed below, these changes may cause HTTPS or TLS/SSL connections to be broken.

Please note that the security Providerinstaller from the Google Play service has been available on the Android platform version since Android 2.3.

The server does not support any encryption suites that are enabled

For example, the server may only support 3DES or MD5 cipher suites. The preferred fix is to improve the configuration of the server to enable stronger and more modern cryptographic suites and protocols. Ideally, you should enable TLSv1.2 and AES-GCM and the Forward Secrecy Encryption Suite (ECDHE, DHE), preferably using the latter.

You can also modify the app to communicate with the server using a custom sslsocketfactory. The factory should be carefully designed to create a sslsocket instance that, in addition to the default encryption suite, should enable some of the cryptographic suites required by the server.

Apply an error hypothesis to the cryptographic suite used to connect to the server

For example, some apps contain broken custom X509trustmanager because it expects the AuthType parameter to become RSA, but there is ecdhe_rsa or Dhe_rsa.

The server does not support TLSv1.1, TLSv1.2, or new TLS extensions

For example, the TLS/SSL with the server handshake was incorrectly rejected or stalled. The preferred fix is to upgrade the server to comply with the TLS/SSL protocol. This enables the server to successfully negotiate these updated protocols or negotiate TLSV1 or earlier protocols, and to ignore the Transport Layer Security Protocol extender that it does not understand. In some cases, disabling TLSv1.1 and TLSv1.2 on the server can be a stopgap until the server software is upgraded.

You can also modify the app to communicate with the server using a custom sslsocketfactory. The factory should be carefully designed to create an Sslsocket instance that contains only the protocols that are enabled and that the server can properly support them.

Support for managed configuration files

A device administrator can add a managed profile to a device. This profile is owned by the administrator and allows the administrator to control the managed profile while allowing users to control their own personal profiles and their storage space. This change affects the behavior of your existing app in the following ways.

Handling Intent

Device administrators can restrict access to system apps from a managed profile. In this case, this intent throws an exception if the app triggers a intent that is normally handled by the app from the managed file, and there is no handler for this intent on the managed file. For example, a device administrator can restrict application access to a system's camera app on a managed profile. If your app is running on a managed profile and is MediaStore.ACTION_IMAGE_CAPTURE called, and startActivityForResult() there are no apps on the managed profile that can handle this intent, it will cause ActivityNotFoundException .

To prevent this, you can check for at least one handler that is appropriate for this intent before triggering any intent. To check if a valid handler exists, call Intent.resolveActivity() . You can take photos with ease: see examples of how to do this using the camera app.

Share files in individual configuration files

Each configuration file has its own file storage space. The file URI refers to a specific location in the file storage space, which means that the file URI that is valid on one profile is invalid on another file. This is usually not a problem for apps that only access files that they create. However, attaching a file URI is not secure if the app attaches a file to a intent, because in some cases the intent may be processed on a different configuration file. For example, a device administrator might specify that an image acquisition event should be handled by the camera app on the personal profile. If this intent is triggered by an app on the managed profile, the camera needs to be able to write the image to a location that the app can read to the managed profile.

For security reasons, if you need to attach a file to a intent that might move from one profile to another, you should create and use a content URIfor that file. For more information about sharing files and content URIs, see sharing files. For example, a device administrator might develop a whitelist that will be processed by the camera in the personal profile ACTION_IMAGE_CAPTURE . The intent that is triggered EXTRA_OUTPUT should contain the content URI where the specified photo should be stored. The camera app can write the image to the location specified by the URI, and the app that triggers intent will be able to read the file even if the app is on a different configuration file.

Lock Screen Widget support removed

Android 5.0 removes support for the lock screen widget, and it continues to support widgets on the main screen.

Android 5.0 Behavioral Changes