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 樣式

通知會以深色文字繪製在白色 (或非常亮) 的背景上，與新的 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() 方法現已淘汰，以提升使用者隱私。為了提供回溯相容性，這個方法仍會傳回其一小部分的資料，包括呼叫應用程式自己的工作，以及某些非敏感的工作 (例如 Home)。如果應用程式使用這個方法擷取自身工作，請改用 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 版本資訊。

繫結至 Service

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

WebView

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

  • 如果應用程式指定的 API 級別為 21 以上：
  • 如果應用程式指定的 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/SSL 流量的預設 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 與伺服器通訊。工廠應設計出 SSLSocket 執行個體，除了預設的加密套件之外，還具備伺服器所需的部分加密套件。

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

舉例來說，部分應用程式內含的自訂 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()。您可以查看「輕鬆拍照：使用相機應用程式拍照」一文的範例。

跨設定檔共用檔案

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

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

停止支援螢幕鎖定小工具

Android 5.0 停止支援螢幕鎖定小工具，但仍支援主畫面的小工具。