Android 5.0 除了提供諸多新特性和功能外，還對系統和 API 行為做出了各種變更。本文重點介紹您應該了解並在開發應用時加以考慮的一些主要變更。

如果您之前發布過 Android 應用，請註意您的應用可能受到 Android 5.0 中這些變化的影響。

如需詳細了解新平臺功能，請參閱 Android Lollipop 重要內容。

Android Runtime (ART)

在 Android 5.0 中，ART 運行時取代 Dalvik 成為平臺默認設置。Android 4.4 中已引入處於實驗階段的 ART 運行時。

有關 ART 的新功能概述，請參閱 ART 簡介。部分主要的新功能包括：

• 預先 (AOT) 編譯
• 改進的垃圾回收 (GC)
• 改進的調試支持

大多數 Android 應用無需任何更改就可以在 ART 下工作。不過，部分適合 Dalvik 的技術並不適用於 ART。如需了解有關最重要問題的信息，請參閱在 Android Runtime (ART) 上驗證應用行為。如存在以下情況，應特別註意：

• 您的應用使用 Java 原生接口 (JNI) 運行 C/C++ 代碼。
• 您使用生成非標準代碼的開發工具（例如，一些代碼混淆工具）。
• 您使用與壓縮垃圾回收不兼容的技術。

通知

請確保您的通知考慮了上述 Android 5.0 變更。要詳細了解如何為 Android 5.0 及更高版本設計通知，請參閱通知設計指南。

Material Design 樣式

在白色（或非常淺）的背景上使用深色文本繪制通知，以便與新的 Material Design 小部件匹配。請確保您的所有通知都與新的配色方案協調一致。如果您的通知看上去不協調，請進行修正：

• 使用 setColor() 在您的圖標圖像後面的圓形中設置重點色彩。
• 更新或移除使用色彩的資源。系統在操作圖標和主要通知圖標中忽略所有非阿爾法通道。您應假設這些圖標僅支持阿爾法通道。系統用白色繪制通知圖標，用深灰色繪制操作圖標。

聲音和振動

如果您當前使用 Ringtone、MediaPlayer 或 Vibrator 類向通知中添加聲音和振動，則移除此代碼，以便系統可以在“優先”模式中正確顯示通知。取而代之的是，使用 Notification.Builder

將設備設為 RINGER_MODE_SILENT 可使設備進入新的優先模式。如果您將設備設為 RINGER_MODE_NORMAL 或 RINGER_MODE_VIBRATE，則設備將退出優先模式。

以前，Android 使用 STREAM_MUSIC 作為主流式傳輸來控制平板電腦設備上的音量。在 Android 5.0 中，手機和平板電腦設備的主音量流式傳輸現已合並，由 STREAM_RING 或 STREAM_NOTIFICATION 進行控制。

鎖定屏幕可見性

默認情況下，在 Android 5.0 中，通知現在顯示在用戶的鎖定屏幕上。用戶可以選擇保護敏感信息不被公開，在此情況下，系統會自動刪減通知顯示的文本。要自定義此刪減的通知，請使用 setPublicVersion()。

如果通知不包含個人信息，或者您想允許媒體播放控件顯示在通知上，則調用 setVisibility() 方法並將通知的可見性級別設為 VISIBILITY_PUBLIC。

媒體播放

如果您要實現顯示媒體播放狀態或傳輸控件的通知，請考慮使用新的 Notification.MediaStyle 模板，而不是自定義 RemoteViews.RemoteView 對象。無論您選擇使用哪個方法，請務必將通知的可見性設為 VISIBILITY_PUBLIC，以便可通過鎖定屏幕訪問您的控件。請註意，從 Android 5.0 開始，系統不再將 RemoteControlClient 對象顯示在鎖定屏幕上。如需了解詳細信息，請參閱如果您的應用使用 RemoteControlClient。

浮動通知

現在，當設備處於活動狀態時（即，設備未鎖定且其屏幕已打開），通知可以顯示在小型浮動窗口中（也稱為“浮動通知”）。這些通知看上去類似於精簡版的通知，只是浮動通知還顯示操作按鈕。用戶可以在不離開當前應用的情況下處理或清除浮動通知。

可能觸發浮動通知的條件示例包括：

• 用戶的 Activity 處於全屏模式中（應用使用 fullScreenIntent）
• 通知具有較高的優先級並使用鈴聲或振動

如果您的應用在以上任何情形下實現通知，請確保系統正確顯示浮動通知。

媒體控件和 RemoteControlClient

RemoteControlClient 類現已棄用。請盡快切換到新的 MediaSession API。

Android 5.0 中的鎖定屏幕不會為 MediaSession 或 RemoteControlClient 顯示傳輸控件。不過，您的應用可以通過一個通知從鎖定屏幕提供媒體播放控件。這讓您的應用可以對媒體按鈕的顯示進行更多控制，同時為使用鎖定設備和未鎖定設備的用戶提供一致的體驗。

為實現此目的，Android 5.0 引入了一個新的 Notification.MediaStyle 模板。Notification.MediaStyle 將您使用 Notification.Builder.addAction() 添加的通知操作轉換為精簡按鈕，嵌入到應用的媒體播放通知中。將您的會話令牌傳遞到 setSession() 方法以告知系統該通知控制進行中的媒體會話。

請務必將通知的可見性設為 VISIBILITY_PUBLIC，以將通知標記為安全，從而顯示在任何鎖定屏幕上（以安全方式或其他方式）。如需了解詳細信息，請參閱鎖定屏幕通知。

要讓應用在 Android TV 或 Wear 平臺上運行時顯示媒體播放控件，則實現 MediaSession 類。如果您的應用需要在 Android 設備上接收媒體按鈕事件，您還應實現 MediaSession。

getRecentTasks()

Android 5.0 中引入新的“並發文檔和 Activity 任務”功能後（請參閱下文最近使用的應用屏幕中的並發文檔和 Activity），為提升用戶隱私的安全性，現已棄用 ActivityManager.getRecentTasks() 方法。對於向後兼容性，此方法仍會返回它的一小部分數據，包括調用應用自己的任務和可能的一些其他非敏感任務（如首頁）。如果您的應用使用此方法檢索它自己的任務，則改用 getAppTasks() 檢索該信息。

Android NDK 中的 64 位支持

Android 5.0 引入了對 64 位系統的支持。64 位增強功能可增加地址空間和提升性能，同時仍完全支持現有的 32 位應用。64 位支持也可改進用於加密的 OpenSSL 的性能。此外，該版本還引入了新的原生媒體 NDK API，以及原生 OpenGL ES (GLES) 3.1 支持。

要使用 Android 5.0 中提供的 64 位支持，請從 Android NDK 頁面下載和安裝 NDK Revision 10c。有關對 NDK 進行的重要變更和問題修復的更多信息，請參閱 Revision 10c 版本說明。

綁定到服務

Context.bindService() 方法現在需要顯式 Intent，如果提供隱式 intent，將引發異常。為確保應用的安全性，請使用顯式 intent 啟動或綁定 Service，且不要為服務聲明 intent 過濾器。

WebView

Android 5.0 更改了應用的默認行為。

• 如果您的應用是面向 API 級別 21 或更高級別：
  • 默認情況下，系統會阻止混合內容和第三方 Cookie。要允許混合內容和第三方 Cookie，請分別使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法。
  • 系統現在可以智能地選擇要繪制的 HTML 文檔部分。這個新的默認行為有助於減少內存占用和提升性能。如果您要一次渲染整個文檔，可通過調用 enableSlowWholeDocumentDraw() 停用此優化。
• 如果您的應用是面向低於 21 的 API 級別：系統允許混合內容和第三方 Cookie，並始終一次渲染整個文檔。

自定義權限唯一性要求

根據權限概述中所述，Android 應用可以定義以專有方式管理組件訪問權限的自定義權限，無需使用平臺預定義的系統權限。應用在其清單文件中聲明的 <permission> 元素中定義自定義權限。

少數情況下定義自定義權限是合規且安全的方法。不過，創建自定義權限有時並無必要，甚至可能會給應用帶來潛在風險，具體取決於分配給權限的保護級別。

Android 5.0 其中一項行為變更確保只有一個應用可以定義給定自定義權限，除非使用與定義權限的其他應用相同的密鑰進行簽名。

使用重復的自定義權限的應用

任何應用都可以定義它需要的任何自定義權限，因此，可能會出現多個應用定義相同的自定義權限的情況。例如，如果兩個應用提供相似的功能，它們可能會為其自定義權限派生出相同的邏輯名稱。應用可能還納入了本身包含相同自定義權限定義的通用公共庫或代碼示例。

在 Android 4.4 和更早的版本中，用戶可以在給定設備上安裝多個此類應用，不過系統會分配由第一個安裝的應用指定的保護級別。

從 Android 5.0 開始，對於使用不同密鑰簽名的應用，系統會強制執行新的自定義權限唯一性限制。現在，設備上只有一個應用可以定義給定的自定義權限（按其名稱確定），除非定義此權限的其他應用使用相同密鑰簽名。如果用戶嘗試安裝的應用具有重復自定義權限且簽名密鑰不同於定義此權限的駐留應用，則系統將阻止安裝。

您的應用需要註意的事項

在 Android 5.0 和更新的版本中，應用可以和以前一樣繼續定義自己的自定義權限，並通過 <uses-permission> 機制請求其他應用的自定義權限。不過，對於 Android 5.0 中引入的新要求，您應仔細評估可能給您的應用帶來的影響。

下面是一些需要考慮的因素：

• 您的應用是否在其清單文件中聲明任何 <permission> 元素？如果是，那麽這些權限是否確實是您的應用或服務正常運行不可或缺的？或者，能否使用系統默認權限代替它們？
• 如果您的應用中具有 <permission> 元素，您是否知道它們來自哪裏？
• 您實際上是否打算讓其他應用通過 <uses-permission> 請求您的自定義權限？
• 您是否在您包含 <permission> 元素的應用中使用樣板文件或示例代碼？那些權限元素確實是不可或缺的嗎？
• 您的自定義權限使用的名稱是簡單名稱還是基於其他應用可能共享的通用術語？

新安裝和更新

如上所述，在運行 Android 4.4 或更早版本的設備上新安裝和更新您的應用不會受影響，且行為沒有任何變化。在運行 Android 5.0 或更新版本的設備上進行新安裝和更新時，如果應用定義一個已由現有駐留應用定義的自定義權限，則系統會阻止安裝您的應用。

使用 Android 5.0 系統更新的現有安裝

如果您的應用使用自定義更新且已廣泛分發和安裝，那麽，當用戶收到將設備升級到 Android 5.0 的更新時，您的應用可能會受影響。在安裝系統更新後，系統重新驗證已安裝的應用，包括檢查它們的自定義權限。如果您的應用定義一個已由另一個通過驗證的應用定義的自定義權限，且您的應用沒有使用與該應用相同的密鑰簽名，則系統不會重新安裝您的應用。

建議

在運行 Android 5.0 或更新版本的設備上，我們建議您立即檢查您的應用，進行任何所需的調整，並盡快向您的用戶發布更新版本。

• 如果您在應用中使用自定義權限，則考慮它們的來源以及您是否確實需要它們。從您的應用中移除所有 <permission> 元素，除非您確定它們是應用正常運行所必需的元素。
• 盡可能考慮使用系統默認權限替代您的自定義權限。
• 如果您的應用需要自定義權限，則重命名您的自定義權限，使其成為您的應用獨有的權限，例如，將它們追加到應用的完整軟件包名稱。
• 如果您有一組使用不同密鑰簽名的應用，且這些應用通過自定義權限訪問共享組件，則確保此自定義權限在共享組件中僅定義一次。使用共享組件的應用不應自己定義自定義權限，而應通過 <uses-permission> 機制請求訪問權限。
• 如果您有一組使用相同密鑰簽名的應用，則每個應用都可以根據需要定義相同的 自定義權限， 系統允許以常規方式安裝這些應用。

TLS/SSL 默認配置變更

Android 5.0 針對 HTTPS 和其他 TLS/SSL 通信引入了對應用使用的默認 TLS/SSL 配置的變更：

• TLSv1.2 和 TLSv1.1 協議現已啟用，
• AES-GCM (AEAD) 加密套件現已啟用，
• MD5、3DES、導出和靜態密鑰 ECDH 加密套件現已停用，
• 首選使用 Forward Secrecy 加密套件（ECDHE 和 DHE）。

在下面列出的少數情況下，這些變更可能會導致 HTTPS 或 TLS/SSL 連接斷開。

請註意，來自 Google Play 服務的安全性 ProviderInstaller 自 Android 2.3 開始就已在 Android 平臺版本上提供這些變更。

服務器不支持任何已啟用的加密套件

例如，服務器可能僅支持 3DES 或 MD5 加密套件。首選的修復方法是改進服務器的配置，以啟用更強更現代的加密套件和協議。理想情況下，應啟用 TLSv1.2 和 AES-GCM 以及 Forward Secrecy 加密套件（ECDHE、DHE），且最好使用後者。

也可以修改應用以使用自定義 SSLSocketFactory 與服務器通信。出廠時應精心設計以創建 SSLSocket 實例，除默認加密套件外，此實例還應啟用服務器所需的部分加密套件。

應用對用於連接服務器的加密套件做出錯誤的假設

例如，某些應用包含中斷的自定義 X509TrustManager，因為它預計 authType 參數將成為 RSA，但出現了 ECDHE_RSA 或 DHE_RSA。

服務器不支持 TLSv1.1、TLSv1.2 或新的 TLS 擴展

例如，與服務器握手的 TLS/SSL 被錯誤地拒絕或出現停頓。首選的修復方法是升級服務器以符合 TLS/SSL 協議。這使服務器可以成功地協商這些更新的協議或協商 TLSv1 或更早的協議，並忽略它不理解的傳輸層安全協議擴展程序。在某些情況下，在服務器上禁用 TLSv1.1 和 TLSv1.2 可以作為權宜之計，直到升級服務器軟件。

也可以修改應用以使用自定義 SSLSocketFactory 與服務器通信。出廠時應精心設計以創建 SSLSocket 實例，該實例僅包含已啟用且服務器可以正確為其提供支持的協議。

支持托管配置文件

設備管理員可以向設備添加托管配置文件。此配置文件由管理員所有，讓管理員控制托管配置文件的同時，允許由用戶控制其自己的個人配置文件及其存儲空間。此變更會通過下列方式影響您的現有應用的行為。

處理 Intent

設備管理員可以從托管配置文件限制對系統應用的訪問權限。在此情況下，如果應用從托管文件觸發一個通常由該應用處理的 intent，且托管文件上沒有適合此 intent 的處理程序，則此 intent 會引發異常。例如，設備管理員可以限制托管配置文件上的應用訪問系統的相機應用。如果您的應用在托管配置文件上運行，並為 MediaStore.ACTION_IMAGE_CAPTURE調用 startActivityForResult()，且托管配置文件上沒有可以處理此 intent 的應用，則會導致 ActivityNotFoundException。

為防止出現此情況，您可以在觸發任何 intent 之前檢查是否至少有一個適合此 intent 的處理程序。要檢查是否存在有效的處理程序，請調用 Intent.resolveActivity()。您可以在輕松拍照：使用相機應用拍攝照片中查看執行上述操作的示例。

在各個配置文件中共享文件

每個配置文件都有自己的文件存儲空間。文件 URI 指的是文件存儲空間中的特定位置，這意味著在一個配置文件上有效的文件 URI 在另一個文件上是無效的。對於只訪問自己創建的文件的應用而言，這通常不是什麽問題。不過，如果應用向某個 intent 附加文件，則附加文件 URI 並不安全，因為在某些情況下，可能會在其他配置文件上處理該 intent。例如，設備管理員可能會指定圖像采集事件應由個人配置文件上的相機應用處理。如果此 intent 由托管配置文件上的應用觸發，則相機需要能夠將圖像寫入托管配置文件的應用可以讀取的位置。

為安全起見，如果您需要將文件附加到某個可能會從一個配置文件移動到另一個配置文件的 intent，您應為該文件創建並使用內容 URI。有關共享文件及內容 URI 的更多信息，請參閱共享文件。例如，設備管理員可能會制定將由個人配置文件中的相機處理的 ACTION_IMAGE_CAPTURE 白名單。觸發的 intent 的 EXTRA_OUTPUT 應包含指定照片應存儲在何處的內容 URI。相機應用可以將圖像寫入該 URI 指定的位置，觸發 intent 的應用將能夠讀取該文件，即使應用位於其他配置文件上。

已移除鎖定屏幕小部件支持

Android 5.0 移除了對鎖定屏幕小部件的支持；它繼續為主屏幕上的小組件提供支持。

Android 5.0 行為變更