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