Android 5.0 行為變更

API 級別：21

除了新功能和新能力之外，Android 5.0 還包含多項系統變更和 API 行為變更。本文將說明一些您應瞭解並在應用程式中納入考量的重大變更。

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

如要大致瞭解新平台功能，請參閱 Android Lollipop 重點。

影片

開發人員 Bytes：Android 5.0 的新功能

開發人員 Bytes：通知

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 版管道。您應假設這些圖示只會顯示為半透明。系統會以白色繪製通知圖示，以深灰色繪製動作圖示。

音效和震動

如果您目前使用 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 的版本資訊。

繫結至服務

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 2.3 以下的各個 Android 平台版本中提供這些變更。

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

舉例來說，伺服器可能只支援 3DES 或 MD5 加密套件。建議的修正方式是改善伺服器設定，啟用更強大、更現代的加密套件和通訊協定。理想情況下，應啟用 TLSv1.2 和 AES-GCM，並啟用並優先使用前向保密加密套件 (ECDHE、DHE)。

另一種做法是修改應用程式，以便使用自訂 SSLSocketFactory 與伺服器通訊。工廠應設計為建立 SSLSocket 例項，除了預設加密套件外，還包含伺服器啟用的部分加密套件。

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

舉例來說，部分應用程式含有自訂 X509TrustManager，但該自訂 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 已移除對鎖定畫面小工具的支援，但仍支援主畫面上的小工具。