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相關的，不懂就不翻譯了……