Android 5.0有哪些变化

Android 5.0 Changes

译自 http://developer.android.com/intl/zh-cn/about/versions/android-5.0-changes.html —— By NashLegend

原译文在Github上：https://github.com/NashLegend/ProjectBabel/blob/master/Android%205.0%20Changes.md

前排渣翻译预警，若是你能提供更好更专业的翻译或者提出修改意见就行了……

另外本篇只对Android 5.0特性做了说明，至于对应的API方面的变化，参考下一篇：Android 5.0 API的变化

API Level: 21

除了新增特性和功能以外，Android 5.0还包含了一系列的变化，包括API变化、行为变化，系统加强以及bug修复。这篇文档将重点阐述一些你应该知道并应用到你的app里面的关键的变化。

若是你以前已经发布过一个Android app，请注意您的app有可能会受到Android 5.0的这些新变化的影响。

若是想看一些新平台的更高级的特性，请看这里

Android Runtime (ART)

在Android 5.0中，ART运行时取代Dalvik成为默认运行环境，ART于Android 4.4时代做为试验特性引入

若是想看ART的新特性概述，请看这里，几个主要的特性以下：

• 提早编译（AOT）

• 加强的垃圾回收

• 加强的debug支持

多数Android应用地ART模式下运行是没有问题的，可是有些状况下却不能。要查看适配ART的注意事项，请看这里，尤为要注意的是下面的状况：

• 你的app使用了JNI来运行C/C++代码

• 你使用了产生非标准代码的（好比一些代码混淆工具）

• 你使用了不兼容compacting garbage collection的技术

通知

请确保你的通知将Android 5.0的最新变化考虑了进来，要获知更多如何为Android 5.0以及更高版本系统设计你的通知的信息，请看这里

Material design样式

通知使用深色文字以及白色（或者很浅色）的背景以适配material design样式的桌面插件。请确保你的全部通知样式统一，若是你的通知看起来有问题，请修正它们:

• 使用 setColor()设置通知图标的背景（基准）色。

• 修改或者移除包含颜色的资源。系统在action icons和通知栏图标中了忽略全部非透明通道。你应该认为这些图标只有alpha通道。系统会把通知图标绘制到白色背景，把action icons绘制到深灰色背景。

声音和震动

若是你如今在通知里经过Ringtone, MediaPlayer, or Vibrator 类添加了声音和震动，请移除这些代码以便系统可以在优先模式下正确的播放通知声和震动。你应该使用Notification.Builder方法添加声音和震动才对。

将设备设置为静音模式将使设备进入优先模式。若是你将设备设置为普通模式或者震动模式，设备将退出这种优先模式。

（注：优先模式指仅对于高优先级的通知播放通知声和振动，静音模式下自动开启——静音模式下仍然有声音听起来很烦人的样子——另外也能够手动直接开启）

之前Android使用STREAM_MUSIC做为master stream以控制平板设备的音量。在Android 5.0上，平板和手机设备的master volume stream已经统一了起来，由STREAM_RING 或者 STREAM_NOTIFICATION控制。

锁屏可见性

如今，默认状况下，通知将显示在用户的锁屏界面上，用户出于保护隐私能够选择不展现这些信息，系统会使用其余提示来表示通知的文字内容，若是想自定义这些隐私化的文字，请使用setPublicVersion()方法

若是通知不包含私人信息或者你想要容许在通知上控制媒体，请调用 setVisibility()方法并奖通知的可见级别设置为VISIBILITY_PUBLIC

媒体播放

若是你使用展现和控制媒体播放的通知，请考虑使用最新的Notification.MediaStyle模版以取代自定义的RemoteViews.RemoteView对象，不管你使用哪一种方法，确保通知的可见性为VISIBILITY_PUBLIC，这样你能够在锁屏界面进行控制。请注意，自Android 5.0之后，系统不会将RemoteControlClient对象展现在锁屏界面上，要获知更多信息，请查看若是你的app使用了RemoteControlClient（其实就在下面）

浮动通知

如今通知能够以一个悬浮小窗口的形式出现了，固然设备得是未锁屏且点亮屏幕状态。这些通知看起来像是你的通知的精简版同样，除了这些通知也可使用action buttons。用户能够在当前正在使用的app里面选择执行也能够忽略通知动做而没必要离开当前app。

下面是有可能触发浮动通知的状况。

• 用户的activity处于全屏状态。

• 通知具备高优先级而且使用了铃声或者震动。

这种状况下就要使用浮动通知。

媒体控制和 RemoteControlClient

RemoteControlClient类如今已经废弃，请尽快改用MediaSessionAPI.

Android 5.0的锁屏界面并不会显示你的MediaSession 或者 RemoteControlClient的控制界面。你的应用应该经过通知提供一个锁屏界面的控制界面，这样，在拥有锁屏和未锁屏状态下的连贯的用户体验的同时给予你的应用更多对于媒体按钮的控制权。

Android 5.0提供了一个新的Notification.MediaStyle模版以实现上述目的。你能够在Notification.Builder.addAction()为Notification.MediaStyle添加动做。经过setSettion()方法告诉系统这个通知控制一个媒体播放会话。

请确保将通知的可见性设置为VISIBILITY_PUBLIC以确保能显示在通知界面。要查看更多信息，请看锁屏界面通知。

若是你的app运行在Androdi TV或者可穿戴设备上，若要展现媒体控制，请使用MediaSession类，若是你的应用要接收Android设备的媒体按钮事件的话，请使用MediaSession类。

getRecentTasks()

随着Android 5.0 concurrent documents and activities tasks特性的引入，ActivityManager.getRecentTasks()方法被废弃以保护用户隐私。为了后向兼容性，这个方法仍而后返回一小部分结果，好比调用此方法的应用的的task以及一些非敏感任务（好比桌面）。若是你的app使用这个方法得到自身的task的话，请使用getAppTasks()

Android NDK的64位支持

Android 5.0引入了64位支持，增长了寻址空间和系统表现的同时完美兼容如今的32位系统。64位支持一样加强了OpenSSL的加密性能。此外，这个版本还增长了新的多媒体NDK API以及OpenGL ES3.1支持。

要使用64位支持，到这里下载NDK Revision 10c，查看这里以获取更多此版NDK的信息。

绑定Service

Context.bindService()方法如今须要指定explicit Intent。若是implicit intent的话将抛出一个错误。为确保app安全性，请在启动或者绑定service的时候使用explicit intent，不要为service定义intent filters。

WebView

Android 5.0 改变了app的默认行为。

若是你的系统target api为21以上:

• 系统默认禁止了mixed content和第三方cookie。可使用setMixedContentMode() 和 setAcceptThirdPartyCookies()以分别启用。

• 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 enableSlowWholeDocumentDraw().

• 系统如今能够智能选择HTML文档的portion来绘制。这种新特性能够减小内存footprint并改进性能。若要一次性渲染整个HTML文档，能够调用这个方法enableSlowWholeDocumentDraw()

**若是你的app的target api低于21: **系统容许mixed content和第三方cookie，而且老是一次性渲染整个HTML文档。

自定义Permissions的惟一性要求

如Permissions文档所述，Android应用能够自定义permissions以限定调用某个组件的方式。应用在manifest文件中定义这此自定义permissions。

只有少数状况下咱们才须要自定义permissions，不少状况下使用自定义permissions是没有必要且容易引起潜在危险的，这取决于这些permossioms的保护级别。

Android系统同时引入了一种新特性以确保一个特定的自定义permissions只能被一个app定义，除非其余app有相同的签名。

对于那些使用相同的自定义permissions的APP们

任何app均可以自定义任何permissions，因此有可能不一样的app正好使用了重名的自定义permissions。好比两个有类似功能的app就有可能这么干，或者App们可能会引入拥有相同的自定义权限的公共库或者代码示例。

在Android 4.4以前这样作是没有问题的。从Android 5.0开始，系统加入了不一样签名的应用的自定义权限必有具备惟一性的限制，若是用户想要安装一个拥有和某个已安装app有相同自定义权限可是签名不一样的app，系统将禁止安装。

对你的应用的一些建议

Android 5.0之后，app仍然能够像之前同样自定义permissions和经过请求其余app的权限。可是有了如今的限制以后，你应该认真考虑一下这些变化对你的app的影响。

下面几点是你要考虑的:

• 你的应用是否在manifest声明了元素。若是是的话，它们是否对于你的app或者service是必须的，或者，是否能够用系统默认permissions代替。

• 若是你使用了元素，你知道它们是哪里来的吗。

• 你是否真的但愿别人经过请求你的自定义权限。

• 你是否只是复制粘贴了别人的包含元素的代码，这些permissions是否必须。

• 你的app是否使用了别人有可能使用的permissions名字。

安装和升级软件

如上所述，Android 5.0之后的设备对于哪些有相同自定义permissions却没有相同签名的app是禁止安装的（文档真啰嗦，这里直接省了，具体看上面）

一些建议

在运行Android 5.0或者更高版本的设备上，咱们建议您当即检查、做出修改、发布新版……

• 若是你使用了你没必要须的自定义permissions，删除它们。

• 若是你的app必须使用自定义permissions的话，请修改它们以确保权限名的惟一性，好比能够以包名开头。

• 若是你有一套的不一样签名的app使用一个自定义permissions以共用一个组件，请确保这个自定义permissions只被定义了一次。

• 若是你的一套app重命名相同，那么随意，同名无所谓。

下面有一段TLS/SSL相关的，不懂就不翻译了……