From df4c4ac540269bbb2b6f133dddb038ef5188c24e Mon Sep 17 00:00:00 2001 From: Dirk Dougherty Date: Fri, 31 Oct 2014 16:14:29 -0700 Subject: Doc change: update behavior changes and move to separate doc. Add nogotofail to SSL best practices. Change-Id: Ib4c0b0d442b1ef879cb01b3972845ef93360c5b8 --- docs/html/about/about_toc.cs | 1 + docs/html/about/versions/android-5.0-changes.jd | 527 ++++++++++++++++++++++++ docs/html/about/versions/android-5.0.jd | 260 ++---------- 3 files changed, 551 insertions(+), 237 deletions(-) create mode 100644 docs/html/about/versions/android-5.0-changes.jd (limited to 'docs/html/about') diff --git a/docs/html/about/about_toc.cs b/docs/html/about/about_toc.cs index c025b61..9033d69 100644 --- a/docs/html/about/about_toc.cs +++ b/docs/html/about/about_toc.cs @@ -11,6 +11,7 @@ Lollipop
  • diff --git a/docs/html/about/versions/android-5.0-changes.jd b/docs/html/about/versions/android-5.0-changes.jd new file mode 100644 index 0000000..c1b9f09 --- /dev/null +++ b/docs/html/about/versions/android-5.0-changes.jd @@ -0,0 +1,527 @@ +page.title=Android 5.0 Changes +excludeFromSuggestions=true +sdk.platform.version=5.0 +sdk.platform.apiLevel=21 +@jd:body + + + + +

    API Level: {@sdkPlatformApiLevel}

    +

    Along with new features and capabilities, Android 5.0 includes a variety of changes +API changes, +behavior changes, system enhancements, and bug fixes. This document highlights +some of the key changes that you should be understand and account for in your apps.

    + +

    f 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.

    + + + +

    Android Runtime (ART)

    + +

    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:

    + + + + +

    Notifications

    + +

    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. +

    + +

    Material design style

    +

    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:

    + + + +

    Sound and vibration

    +

    If you are currently adding sounds and vibrations to your notifications by +using the {@link android.media.Ringtone}, {@link android.media.MediaPlayer}, +or {@link android.os.Vibrator} classes, remove this code so that +the system can present notifications correctly in +priority mode. Instead, use +{@link android.app.Notification.Builder} methods to add sounds and +vibration.

    + +

    Setting the device to +{@link android.media.AudioManager#RINGER_MODE_SILENT RINGER_MODE_SILENT} causes +the device to enter the new priority mode. The device leaves priority +mode if you set it to +{@link android.media.AudioManager#RINGER_MODE_NORMAL RINGER_MODE_NORMAL} or +{@link android.media.AudioManager#RINGER_MODE_NORMAL RINGER_MODE_VIBRATE}.

    + +

    Previously, Android used {@link android.media.AudioManager#STREAM_MUSIC STREAM_MUSIC} +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 {@link android.media.AudioManager#STREAM_RING STREAM_RING} or +{@link android.media.AudioManager#STREAM_NOTIFICATION STREAM_NOTIFICATION}.

    + +

    Lock screen visibility

    +

    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 +{@link android.app.Notification.Builder#setPublicVersion(android.app.Notification) + setPublicVersion()}.

    +

    If the notification does not contain personal information, or if you want to +allow media playback control on the notification, call the +{@link android.app.Notification.Builder#setVisibility(int) setVisibility()} +method and set the notification's visibility level to +{@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC}. +

    + +

    Media playback

    +

    If you are implementing notifications that present media playback +status or transport controls, consider using the new +{@link android.app.Notification.MediaStyle} template instead of a custom +{@link android.widget.RemoteViews.RemoteView} object. Whichever approach you +choose, make sure to set the notification's visibility to +{@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC} so that +your controls are accessible from the lock screen. Note that beginning in +Android 5.0, the system no longer shows +{@link android.media.RemoteControlClient} objects on the lock screen. For more +information, see +If your app uses RemoteControlClient.

    + +

    Heads-up notification

    +

    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.

    + +

    Media Controls and RemoteControlClient

    +

    The {@link android.media.RemoteControlClient} class is now deprecated. Switch + to the new {@link android.media.session.MediaSession} API as + soon as possible.

    + +

    Lock screens in Android 5.0 do not show transport controls for +your {@link android.media.session.MediaSession} or +{@link android.media.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 +unlocked devices.

    + +

    Android 5.0 introduces a new +{@link android.app.Notification.MediaStyle} template for this purpose. +{@link android.app.Notification.MediaStyle} converts notification +actions that you added with +{@link android.app.Notification.Builder#addAction(int, java.lang.CharSequence, + android.app.PendingIntent) +Notification.Builder.addAction()} into compact buttons embedded in your app's +media playback notifications. Pass your session token to the +{@link android.app.Notification.MediaStyle#setMediaSession(android.media.session.MediaSession.Token) + setSession()} method to inform the system that this notification controls an + ongoing media session.

    + +

    Make sure to set the notification's visibility to + {@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC} + 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 +{@link android.media.session.MediaSession} class. You should also implement +{@link android.media.session.MediaSession} if your app needs to receive media +button events on Android devices.

    + +

    getRecentTasks()

    + +

    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), +the {@link android.app.ActivityManager#getRecentTasks +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 {@link android.app.ActivityManager#getAppTasks() getAppTasks()} +instead to retrieve that information.

    + +

    64-Bit Support in the Android NDK

    + +

    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.

    + +

    Binding to a Service

    + +

    The + {@link android.content.Context#bindService(android.content.Intent, android.content.ServiceConnection, int) Context.bindService()} + method now requires an explicit {@link android.content.Intent}, +and throws an exception if given an implicit intent. +To ensure your app is secure, use an explicit intent when starting or binding +your {@link android.app.Service}, and do not declare intent filters for the service.

    + +

    WebView

    + +

    Android 5.0 changes the default behavior for your app.

    + + +

    Uniqueness Requirement for Custom Permissions

    + +

    + 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. +

    + +

    + Apps using duplicate custom permissions +

    + +

    + 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. +

    + +

    + Considerations for your app +

    + +

    + 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 + through the <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: +

    + + + +

    + New installs and updates +

    + +

    + 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. +

    + +

    + Existing installs with Android 5.0 system update +

    + +

    + 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. +

    + +

    + Recommendations +

    + +

    + 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. +

    + + + + +

    + TLS/SSL Default Configuration Changes +

    + +

    + 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. +

    + +

    + Server does not support any of the enabled ciphers suites +

    + +

    + 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. +

    + +

    + App is making wrong assumptions about cipher suites used to connect to server +

    + +

    + 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. +

    + +

    + Server is intolerant to TLSv1.1, TLSv1.2 or new TLS extensions +

    + +

    + 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. +

    \ No newline at end of file diff --git a/docs/html/about/versions/android-5.0.jd b/docs/html/about/versions/android-5.0.jd index a438420..756b75f 100644 --- a/docs/html/about/versions/android-5.0.jd +++ b/docs/html/about/versions/android-5.0.jd @@ -15,17 +15,10 @@ sdk.platform.apiLevel=21
    1. Update your target API level
      2. -
    2. Important Behavior Changes -
        -
      1. If you haven't tested your app against the new Android Runtime (ART)...
        2. -
      2. If your app implements notifications...
        3. -
      3. If your app uses RemoteControlClient...
        4. -
      4. If your app uses getRecentTasks()...
        5. -
      5. If you are using the Android Native Development Kit (NDK)...
        6. -
      6. If your app binds to a Service...
        7. -
      7. If your app uses a WebView...
        8. -
      -
      3. + + + +
    3. User Interface
      1. Material design support
        2. @@ -113,6 +106,13 @@ sdk.platform.apiLevel=21
      2. L Developer Preview to 21 »
      +

      See Also

      +
        +
      1. Android 5.0 Behavior Changes
        2. +
      2. Android Lollipop Highlights
        3. +
      + + @@ -122,12 +122,19 @@ sdk.platform.apiLevel=21 offers new features for users and app developers. This document provides an introduction to the most notable new APIs.

      +

      + If you have a published app, make sure to check out the Android 5.0 Behavior + Changes that you should account for in your app. These behavior changes + may affect your app on Android 5.0 devices, even if you are not using new APIs + or targeting new functionality. +

      +

      For a high-level look at the new platform features, instead see the Android Lollipop highlights.

      -

      Start developing

      To start building apps for Android 5.0, you must first get @@ -143,8 +150,6 @@ to download the Android 5.0 SDK Platform and System Images.

      ">To test your apps on a real device, flash a Nexus 5 or Nexus 7 with the
      ANDROID PREVIEW SYSTEM IMAGE.

      - -

      Update your target API level

      To better optimize your app for devices running Android {@sdkPlatformVersion}, @@ -166,237 +171,18 @@ Different Platform Versions.

      href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">What is API Level?

      -

      Important Behavior Changes

      +

      Important behavior changes

      -

      If you have previously published an app for Android, be aware that your app - might be affected by changes in Android 5.0.

      +

      If you have previously published an app for Android, be aware that your app might be affected by changes in Android 5.0.

      -

      If you haven't tested your app against the new Android Runtime (ART)...

      - -

      The 4.4 release introduced a new, experimental Android runtime, ART. Under -4.4, ART was optional, and the default runtime remained Dalvik. With Android -5.0, ART is now the default runtime.

      - -

      For an overview of ART's new features, see -Introducing -ART. Some of the major new features are:

      - -
        -
      • Ahead-of-time (AOT) compilation
        • -
      • Improved garbage collection (GC)
        • -
      • Improved debugging support
        • -
      +

      Please see Android 5.0 Changes for complete information.

      -

      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:

      - -
        -
      • Your app uses Java Native Interface (JNI) to run C/C++ code.
        • -
      • You use development tools that generate non-standard code (such as some - obfuscators).
        • -
      • You use techniques that are incompatible with compacting garbage - collection. (ART does not currently implement compacting GC, but - compacting GC is under development in the Android Open Source - Project.)
        • -
      - -

      If your app implements notifications...

      - -

      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. -

      - -

      Material design style

      -

      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:

      - -
        -
      • Use {@link android.app.Notification.Builder#setColor(int) setColor()} - to set an accent color in a circle behind your icon image.
        • -
      • Update or remove assets that involve color. The system ignores all - non-alpha channels in action icons and in the main notification icon. You - should assume that these icons will be alpha-only. The system draws - notification icons in white and action icons in dark gray.
        • -
      - -

      Sound and vibration

      -

      If you are currently adding sounds and vibrations to your notifications by -using the {@link android.media.Ringtone}, {@link android.media.MediaPlayer}, -or {@link android.os.Vibrator} classes, remove this code so that -the system can present notifications correctly in -priority mode. Instead, use -{@link android.app.Notification.Builder} methods to add sounds and -vibration.

      - -

      Setting the device to -{@link android.media.AudioManager#RINGER_MODE_SILENT RINGER_MODE_SILENT} causes -the device to enter the new priority mode. The device leaves priority -mode if you set it to -{@link android.media.AudioManager#RINGER_MODE_NORMAL RINGER_MODE_NORMAL} or -{@link android.media.AudioManager#RINGER_MODE_NORMAL RINGER_MODE_VIBRATE}.

      - -

      Previously, Android used {@link android.media.AudioManager#STREAM_MUSIC STREAM_MUSIC} -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 {@link android.media.AudioManager#STREAM_RING STREAM_RING} or -{@link android.media.AudioManager#STREAM_NOTIFICATION STREAM_NOTIFICATION}.

      - -

      Lock screen visibility

      -

      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 -{@link android.app.Notification.Builder#setPublicVersion(android.app.Notification) - setPublicVersion()}.

      -

      If the notification does not contain personal information, or if you want to -allow media playback control on the notification, call the -{@link android.app.Notification.Builder#setVisibility(int) setVisibility()} -method and set the notification's visibility level to -{@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC}. -

      - -

      Media playback

      -

      If you are implementing notifications that present media playback -status or transport controls, consider using the new -{@link android.app.Notification.MediaStyle} template instead of a custom -{@link android.widget.RemoteViews.RemoteView} object. Whichever approach you -choose, make sure to set the notification's visibility to -{@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC} so that -your controls are accessible from the lock screen. Note that beginning in -Android 5.0, the system no longer shows -{@link android.media.RemoteControlClient} objects on the lock screen. For more -information, see -If your app uses RemoteControlClient.

      - -

      Heads-up notification

      -

      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:

      - -
        -
      • The user's activity is in fullscreen mode (the app uses -{@link android.app.Notification#fullScreenIntent})
        • -
      • The notification has high priority and uses ringtones or vibrations
        • -
      - -

      If your app implements notifications under any of those scenarios, make sure -that heads-up notifications are presented correctly.

      - -

      If your app uses RemoteControlClient...

      -

      The {@link android.media.RemoteControlClient} class is now deprecated. Switch - to the new {@link android.media.session.MediaSession} API as - soon as possible.

      - -

      Lock screens in Android 5.0 do not show transport controls for -your {@link android.media.session.MediaSession} or -{@link android.media.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 -unlocked devices.

      - -

      Android 5.0 introduces a new -{@link android.app.Notification.MediaStyle} template for this purpose. -{@link android.app.Notification.MediaStyle} converts notification -actions that you added with -{@link android.app.Notification.Builder#addAction(int, java.lang.CharSequence, - android.app.PendingIntent) -Notification.Builder.addAction()} into compact buttons embedded in your app's -media playback notifications. Pass your session token to the -{@link android.app.Notification.MediaStyle#setMediaSession(android.media.session.MediaSession.Token) - setSession()} method to inform the system that this notification controls an - ongoing media session.

      - -

      Make sure to set the notification's visibility to - {@link android.app.Notification#VISIBILITY_PUBLIC VISIBILITY_PUBLIC} - 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 -{@link android.media.session.MediaSession} class. You should also implement -{@link android.media.session.MediaSession} if your app needs to receive media -button events on Android devices.

      - -

      If your app uses getRecentTasks()...

      - -

      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), -the {@link android.app.ActivityManager#getRecentTasks -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 {@link android.app.ActivityManager#getAppTasks() getAppTasks()} -instead to retrieve that information.

      - -

      If you are using the Android Native Development Kit (NDK)...

      - -

      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.

      - -

      If your app binds to a Service...

      - -

      The - {@link android.content.Context#bindService(android.content.Intent, android.content.ServiceConnection, int) Context.bindService()} - method now requires an explicit {@link android.content.Intent}, -and throws an exception if given an implicit intent. -To ensure your app is secure, use an explicit intent when starting or binding -your {@link android.app.Service}, and do not declare intent filters for the service.

      - -

      If your app uses WebView...

      - -

      Android 5.0 changes the default behavior for your app.

      -
        -
      • If your app targets API level 21 or higher: -
          -
        • The system - blocks mixed content and third party cookies by default. To allow mixed - content and third party cookies, use the - {@link android.webkit.WebSettings#setMixedContentMode(int) setMixedContentMode()} -and {@link android.webkit.CookieManager#setAcceptThirdPartyCookies(android.webkit.WebView, boolean) setAcceptThirdPartyCookies()} -methods respectively.
          • -
        • The system now intelligently chooses portions of the HTML - document to draw. This new default behavior helps to reduce memory - footprint and increase performance. If you want to - render the whole document at once, disable this optimization by calling - {@link android.webkit.WebView#enableSlowWholeDocumentDraw()}.
          • -
        -
        • -
      • If your app targets API levels lower than 21: The system - allows mixed content and third party cookies, and always renders the whole - document at once.
        • -

      User Interface

      Material design support

      -

      The upcoming release adds support for Android's new material design +

      Android 5.0 adds support for Android's new material design style. You can create apps with material design that are visually dynamic and have UI element transitions that feel natural to users. This support includes:

      -- cgit v1.1