Android 5.0 行為變更

API 級別：21

除了新功能之外，Android 5.0 版還包含各種系統變更和 API 行為變更。本文件特別介紹了一些您應該瞭解並在應用程式中應瞭解的重要異動。

如果您先前已發布 Android 應用程式，請注意，您的應用程式可能會受到 Android 5.0 中的異動影響。

如要概略瞭解新平台功能，請改為參閱 Android Lollipop 精選內容。

影片

Dev Byte：Android 5.0 新功能

開發人員位元組：通知

Android 執行階段 (ART)

在 Android 5.0 中，ART 執行階段會取代 Dalvik 做為平台預設值。ART 執行階段是在 Android 4.4 中以實驗功能為基礎。

如需 ART 新功能的總覽，請參閱 ART 簡介。主要的新功能包括：

• 預先 (AOT) 編譯
• 改善垃圾收集 (GC)
• 改善偵錯支援

大部分的 Android 應用程式應該都能在 ART 之下順利運作。不過，某些適用於 Dalvik 的技術不適用於 ART。如要瞭解最重要的問題，請參閱「在 Android 執行階段 (ART) 驗證應用程式行為」一文。遇到以下情況時，請特別留意：

• 應用程式會使用 Java Native Interface (JNI) 執行 C/C++ 程式碼。
• 請使用會產生非標準程式碼的開發工具 (例如某些模糊處理器)。
• 您使用的技術與壓縮垃圾收集不相容。

通知

請務必將這些 Android 5.0 異動納入考量。 如要進一步瞭解如何設計 Android 5.0 以上版本的通知，請參閱「通知設計指南」。

Material Design 樣式

通知會在白色 (或極淺色) 背景上繪製通知，以符合新的質感設計小工具。確保所有通知都能透過新的色彩配置正確顯示。如果通知看起來有誤，請修正問題：

• 使用 setColor() 可在圖示圖片下方的圓圈中設定強調色。
• 更新或移除涉及顏色的素材資源。系統會忽略動作圖示和主要通知圖示中的所有非 Alpha 管道。您應假設這些圖示僅為 Alpha 版。系統會以白色和動作圖示繪製白色和深灰色的通知圖示。

音效和震動

如果您目前使用 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」。

抬頭通知

當裝置處於啟用狀態時 (即裝置處於解鎖狀態且螢幕處於開啟狀態)，通知可能會以小型浮動視窗 (也稱為抬頭通知) 顯示。這些通知看起來會與精簡的通知形式相似，但抬頭通知也會顯示動作按鈕。使用者不必離開目前使用的應用程式，就能處理或關閉抬頭通知。

可能觸發抬頭通知的情況包括：

• 使用者的活動是以全螢幕模式進行 (應用程式使用 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 中，推出新的並行文件和活動工作功能 (請參閱下方「最近使用中的文件和活動」一節)，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 修訂版本 10c。如要進一步瞭解 NDK 的重大變更和錯誤修正，請參閱修訂版本 10c 版本資訊。

繫結至服務

Context.bindService() 方法現在需要明確的 Intent，並會根據隱含意圖擲回例外狀況。為確保應用程式安全無虞，請在啟動或繫結 Service 時使用明確意圖，切勿為該服務宣告意圖篩選器。

WebView

Android 5.0 會變更應用程式的預設行為。

• 如果應用程式指定的 API 級別為 21 以上：
  • 系統會預設封鎖混合內容和第三方 Cookie。如要允許複合型內容和第三方 Cookie，請分別使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法。
  • 系統現在能夠聰明地選擇要繪製的 HTML 文件部分。這個新的預設行為有助於減少記憶體用量及提高效能。如要一次轉譯整份文件，請呼叫 enableSlowWholeDocumentDraw() 來停用這項最佳化功能。
• 如果應用程式目標 API 級別低於 21：系統允許混合內容和第三方 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)/安全資料傳輸層 (TLS) 流量的預設傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 設定：

• TLSv1.2 和 TLSv1.1 通訊協定現已啟用，
• AES-GCM (AEAD) 加密套件現已啟用，
• MD5、3DES、匯出和靜態金鑰 ECDH 加密套件現已停用。
• 建議使用正向密碼加密套件 (ECDHE 和 DHE)。

在少數情況下，這些異動可能會導致 HTTPS 或 TLS/SSL 連線中斷。

請注意，Google Play 服務的安全性 ProviderInstaller 已在 Android 平台版本中提供這些變更至 Android 2.3 版本。

伺服器不支援任何已啟用的加密套件

舉例來說，伺服器可能僅支援 3DES 或 MD5 加密套件。我們建議的修正方式是改善伺服器的設定，以便啟用功能更強大、更現代化的加密套件和通訊協定。在理想情況下，應啟用 TLSv1.2 和 AES-GCM，且應啟用並建議啟用正向密碼加密套件 (ECDHE、DHE)。

另一種做法則是修改應用程式，使用自訂 SSLSocketFactory 與伺服器通訊。這個工廠應設計為建立 SSL 通訊端執行個體，除了預設加密套件之外，還會一併啟用伺服器所需的部分加密套件。

應用程式對用於連線至伺服器的加密套件做出錯誤假設

舉例來說，某些應用程式包含自訂 X509TrustManager，因為會預期 authType 參數為 RSA，但遇到 ECDHE_RSA 或 DHE_RSA。

伺服器對 TLSv1.1、TLSv1.2 或新的 TLS 擴充功能不具容忍度

舉例來說，與伺服器的傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 握手程序錯誤地遭到拒絕或停止運作。我們建議的修正方式是升級伺服器，使其符合 TLS/SSL 通訊協定。這樣一來，伺服器就能成功協商這些較新的通訊協定，或交涉 TLSv1 或較舊的通訊協定，並忽略無法辨識的 TLS 擴充功能。在某些情況下，停用伺服器上的 TLSv1.1 和 TLSv1.2 可能會做為權宜之計，直到伺服器軟體升級為止。

另一種做法則是修改應用程式，使用自訂 SSLSocketFactory 與伺服器通訊。這個工廠應設計為只建立啟用伺服器正確支援的通訊協定的 SSLSocket 執行個體。

支援受管理的設定檔

裝置管理員可以將受管理的設定檔新增至裝置。這個設定檔為管理員所擁有，管理員可以控管受管理的設定檔，同時讓使用者能自行控管個人設定檔及其儲存空間。這項變更可能會對現有應用程式的行為造成以下影響。

處理意圖

裝置管理員可以限制透過受管理設定檔存取系統應用程式。在這種情況下，如果應用程式從原本由該應用程式處理的受管理設定檔觸發意圖，而且代管設定檔上沒有適合該意圖的處理常式，意圖就會造成例外狀況。舉例來說，裝置管理員可以限制受管理設定檔上的應用程式存取系統的相機應用程式。如果應用程式在受管理的設定檔上執行，並對 MediaStore.ACTION_IMAGE_CAPTURE 呼叫 startActivityForResult()，且受管理的設定檔中沒有可以處理意圖的應用程式，則會導致 ActivityNotFoundException。

若要避免這種情況發生，請在觸發前，檢查意圖是否至少有一個處理常式。如要檢查有效的處理常式，請呼叫 Intent.resolveActivity()。如需相關範例，請參閱拍攝相片 Simply：使用相機應用程式拍照。

跨設定檔分享檔案

每個設定檔都有專屬的檔案儲存空間。由於檔案 URI 是指檔案儲存空間中的特定位置，因此在其中一個設定檔上有效的檔案 URI 在另一個設定檔上無效。這並不通常是應用程式的問題，而且通常只會存取應用程式建立的檔案。不過，如果應用程式將檔案附加至意圖，附加檔案 URI 並不安全，因為在某些情況下，意圖可能需要在其他設定檔上處理。舉例來說，裝置管理員可能會指定拍照事件應由個人資料夾中的相機應用程式處理。如果受管理設定檔上的應用程式觸發了該意圖，相機就必須能將圖片寫入受管理設定檔的應用程式讀取該位置。

為了安全起見，當您需要將檔案附加至可能與其他設定檔相交的意圖時，請為該檔案建立並使用內容 URI。如要進一步瞭解如何使用內容 URI 共用檔案，請參閱「共用檔案」。舉例來說，裝置管理員可能會允許個人資料夾中的攝影機處理 ACTION_IMAGE_CAPTURE。觸發意圖的 EXTRA_OUTPUT 應包含內容 URI，以指定相片的儲存位置。相機應用程式可以將圖片寫入該 URI 指定的位置，而觸發意圖的應用程式也能讀取該檔案，即使該應用程式位於另一個設定檔中也一樣。

支援螢幕鎖定畫面小工具

Android 5.0 版不再支援螢幕鎖定小工具，並會繼續支援主畫面上的小工具。