Android 5.0 行為變更

標籤：平板電腦   包名   控制項   浮動   app   context   draw   檔案中   注意   

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 行為變更