Android 5.0 Changes

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

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的資訊。

Binding to a 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，系統将禁止安裝。

Considerations for your 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 Default Configuration Changes

Android 5.0 introduces changes the default TLS/SSL configuration used by apps for HTTPS and other TLS/SSL traffic:

• TLSv1.2 and TLSv1.1 protocols are now enabled,
• AES-GCM (AEAD) cipher suites are now enabled,
• MD5, 3DES, export, and static key ECDH cipher suites are now disabled,
• Forward Secrecy cipher suites (ECDHE and DHE) are preferred.

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.