[Android各版本特性]Android 9.0 Pie

[Android各版本特性]專欄目錄：
01. Android API 版本對照表
02. Android 4.4以前版本特性
03. 爲什麼以Android4.4做分界線
04. Android 4.4 Kitkat
05. Android 5.0 Android Lollipop
06. Android 6.0 Marshmallow
07. Android 7.0 Nougat
08. Android 8.0 Oreo
09. Android 9.0 Pie
10. Android 10
11. 總結（推薦）

1.利用 Wi-Fi RTT 進行室內定位

Android 9 添加了對 IEEE 802.11mc Wi-Fi 協議（也稱爲 Wi-Fi Round-Trip-Time (RTT)）的平臺支持，從而讓您的應用可以利用室內定位功能。

在運行 Android 9 且具有硬件支持的設備上，應用可以使用 RTT API 來測量與附近支持 RTT 的 Wi-Fi 接入點 (AP) 的距離。

設備無需連接到接入點即可使用 RTT。 爲了保護隱私，只有手機可以確定與接入點的距離；接入點無此信息。

如果您的設備測量與 3 個或更多接入點的距離，您可以使用一個多點定位算法來預估與這些測量值最相符的設備位置。 結果通常精準至 1 至 2 米。

通過這種精確性，您可以打造新的體驗，例如樓內導航、基於精細位置的服務，如無歧義語音控制（例如，“打開這盞燈”），以及基於位置的信息（如 “此產品是否有特別優惠？”）。

2.顯示屏缺口支持

Android 9 支持最新的全面屏，其中包含爲攝像頭和揚聲器預留空間的屏幕缺口。 通過 DisplayCutout 類可確定非功能區域的位置和形狀，這些區域不應顯示內容。 要確定這些屏幕缺口區域是否存在及其位置，請使用 getDisplayCutout() 函數。

3.渠道設置、廣播和請勿打擾

Android 8.0 引入了通知渠道，允許您爲要顯示的每種通知類型創建可由用戶自定義的渠道。 Android 9 通過下列變更簡化通知渠道設置：

• 屏蔽渠道組：現在，用戶可以針對某個應用在通知設置中屏蔽整個渠道組。 您可以使用 isBlocked() 函數確定何時屏蔽一個渠道組，從而不會向該組中的渠道發送任何通知。

  此外，您的應用可以使用全新的 getNotificationChannelGroup() 函數查詢當前渠道組設置。

• 全新的廣播 Intent 類型：現在，當通知渠道和渠道組的屏蔽狀態發生變更時，Android 系統將發送廣播 Intent。 擁有已屏蔽的渠道或渠道組的應用可以偵聽這些 Intent 並做出相應的迴應。

• NotificationManager.Policy 有 3 種新的“請勿打擾”優先級類別：

  • PRIORITY_CATEGORY_ALARMS 優先處理警報。
  • PRIORITY_CATEGORY_MEDIA 優先處理媒體源的聲音，如媒體和語音導航。
  • PRIORITY_CATEGORY_SYSTEM 優先處理系統聲音。

• NotificationManager.Policy 還有 7 種新的“請勿打擾”常量，可以用來抑制視覺中斷：

  • SUPPRESSED_EFFECT_FULL_SCREEN_INTENT 防止通知啓動全屏 Activity。
  • SUPPRESSED_EFFECT_LIGHTS 屏蔽通知燈。
  • SUPPRESSED_EFFECT_PEEK 防止通知短暫進入視圖（“滑出”）。
  • SUPPRESSED_EFFECT_STATUS_BAR 防止通知顯示在支持狀態欄的設備的狀態欄中。
  • SUPPRESSED_EFFECT_BADGE 在支持標誌的設備上屏蔽標誌。 如需瞭解詳細信息，請參閱修改通知標誌。
  • SUPPRESSED_EFFECT_AMBIENT 在支持微光顯示的設備上屏蔽通知。
  • SUPPRESSED_EFFECT_NOTIFICATION_LIST 防止通知顯示在支持列表視圖（如通知欄或鎖屏）的設備的列表視圖中。

4.多攝像頭支持和攝像頭更新

在運行 Android 9 的設備上，您可以通過兩個或更多物理攝像頭來同時訪問多個視頻流。在配備雙前置攝像頭或雙後置攝像頭的設備上，您可以創建只配備單攝像頭的設備所不可能實現的創新功能，例如無縫縮放、背景虛化和立體成像。 通過該 API，您還可以調用邏輯或融合的攝像頭視頻流，該視頻流可在兩個或更多攝像頭之間自動切換。

攝像頭方面的其他改進還包括附加會話參數和 Surface 共享，前者有助於降低首次拍照期間的延遲，而後者則讓攝像頭客戶端能夠處理各種用例，而無需停止並啓動攝像頭視頻流。 我們還針對基於顯示屏的 flash 支持和 OIS 時間戳訪問新增了一些 API，用以實現應用級的圖像穩定化和特效。

5.適用於可繪製對象和位圖的 ImageDecoder

Android 9 引入了 ImageDecoder 類，可提供現代化的圖像解碼方法。 使用該類取代 BitmapFactory 和 BitmapFactory.Options API。

ImageDecoder 讓您可通過字節緩衝區、文件或 URI 來創建 Drawable 或 Bitmap。 要解碼圖像，請首先以編碼圖像的來源爲參數，調用 createSource()。 然後，通過傳遞 ImageDecoder.Source 對象來調用 decodeDrawable() 或 decodeBitmap()，從而創建 Drawable] 或 Bitmap。 要更改默認設置，請將 OnHeaderDecodedListener 傳遞給 decodeDrawable() 或 decodeBitmap()。 ImageDecoder 調用 onHeaderDecoded()，以圖像的默認寬度和高度（若已知）爲參數。 如果編碼圖像是動畫 GIF 或 WebP，decodeDrawable() 將返回 Drawable，它是 AnimatedImageDrawable 類的一個實例。

您可以使用不同的方法來設置圖像屬性：

• 要將解碼的圖像縮放到精確尺寸，請將目標尺寸傳遞給 setTargetSize()。 您也可以使用樣圖尺寸來縮放圖像。 將樣圖尺寸直接傳遞給 setTargetSampleSize()。
• 要在縮放圖像的範圍內裁剪圖像，請調用 setCrop()。
• 要創建可變位圖，請將 true 傳遞給 setMutableRequired()。

通過 ImageDecoder 還可以爲圓角或圓形遮罩之類的圖像添加複雜的定製效果。 以 PostProcessor 類的一個實例作爲參數使用 setPostProcessor()，執行您所需的任何繪圖命令。

注：對 AnimatedImageDrawable進行後處理時，效果會出現在動畫的所有幀中。

6.動畫

Android 9 引入了 AnimatedImageDrawable 類，用於繪製和顯示 GIF 和 WebP 動畫圖像。 AnimatedImageDrawable 的工作方式與 AnimatedVectorDrawable 的相似之處在於，都是渲染線程驅動 AnimatedImageDrawable 的動畫。 渲染線程還使用工作線程進行解碼，因此，解碼不會干擾渲染線程的其他操作。 這種實現機制允許您的應用在顯示動畫圖像時，無需管理其更新，也不會干擾應用界面線程上的其他事件。

可使用 ImageDecoder 的實例對 AnimatedImageDrawable 進行解碼。

7.JobScheduler 中的流量費用敏感度

從 Android 9 開始，JobScheduler 可以使用運營商提供的網絡狀態信號來改善與網絡有關的作業處理。

作業可以聲明其預估的數據大小、信號預提取，並指定具體的網絡要求。 JobScheduler 然後根據網絡狀態管理工作。 例如，當網絡顯示擁塞時，JobScheduler 可能會延遲較大的網絡請求。 如果使用的是不按流量計費的網絡，則 JobScheduler 可運行預提取作業以提升用戶體驗（例如預提取標題）。

添加作業時，確保使用 setEstimatedNetworkBytes()、setPrefetch() 和 setRequiredNetwork()（如果適用），以幫助 JobScheduler 正確處理工作。 在執行作業時，請確保使用 JobParameters.getNetwork() 返回的 Network 對象。 否則，您將隱式使用設備的默認網絡，其可能不符合您的要求，從而導致意外的流量消耗。

8.統一生物識別身份驗證對話框

在 Android 9 中，系統代表您的應用提供生物識別身份驗證對話框。 該功能可創建標準化的對話框外觀、風格和位置，讓用戶更加確信，他們在使用可信的生物識別憑據檢查程序進行身份驗證。

如果您的應用使用 FingerprintManager 向用戶顯示指紋身份驗證對話框，請切換到改用 BiometricPrompt。 BiometricPrompt 依賴系統來顯示身份驗證對話框。 它還會改變其行爲，以適應用戶所選擇的生物識別身份驗證類型。

注：在應用中使用 BiometricPrompt 之前，應該先使用 hasSystemFeature()函數以確保設備支持 FEATURE_FINGERPRINT、FEATURE_IRIS 或 FEATURE_FACE。

如果設備不支持生物識別身份驗證，可以回退爲使用 createConfirmDeviceCredentialIntent() 函數驗證用戶的 PIN 碼、圖案或密碼。

9.具有密鑰輪轉的 APK 簽名方案

Android 9 新增了對 APK Signature Scheme v3 的支持。該架構提供的選擇可以在其簽名塊中爲每個簽名證書加入一條輪轉證據記錄。 利用此功能，應用可以通過將 APK 文件過去的簽名證書鏈接到現在簽署應用時使用的證書，從而使用新簽名證書來簽署應用。

注：運行 Android 8.1（API 級別 27）或更低版本的設備不支持更改簽名證書。 如果應用的 minSdkVersion 爲 27 或更低，除了新簽名之外，可使用舊簽名證書來簽署應用。

10.後臺對傳感器的訪問受限

Android 9 限制後臺應用訪問用戶輸入和傳感器數據的能力。 如果您的應用在運行 Android 9 設備的後臺運行，系統將對您的應用採取以下限制：

• 您的應用不能訪問麥克風或攝像頭。
• 使用連續報告模式的傳感器（例如加速度計和陀螺儀）不會接收事件。
• 使用變化或一次性報告模式的傳感器不會接收事件。

如果您的應用需要在運行 Android 9 的設備上檢測傳感器事件，請使用前臺服務。

11.限制訪問

1. 限制訪問電話號碼
2. 限制訪問通話記錄
3. 限制訪問 Wi-Fi 位置和連接信息
4. 在應用處於空閒狀態時，不能再訪問相機、麥克風或 SensorManager 傳感器。

Android 9 引入 CALL_LOG 權限組並將 READ_CALL_LOG、WRITE_CALL_LOG 和 PROCESS_OUTGOING_CALLS 權限移入該組。 在之前的 Android 版本中，這些權限位於 PHONE 權限組。

在 Android 9 中，應用進行 Wi-Fi 掃描的權限要求比之前的版本更嚴格。

12.Java UTF 解碼器

UTF-8 是 Android 中的默認字符集。 UTF-8 字節序列可由 String(byte[] bytes) 之類的 String 構造函數解碼。

Android 9 中的 UTF-8 解碼器遵循比以前版本中更嚴格的 Unicode 標準： 這些變更包括：

• 非最短形式的 UTF-8（例如 <C0, AF>）被視爲格式不正確。
• 替代形式的 UTF-8（例如 U+D800…U+DFFF）被視爲格式不正確。
• 最大的子部分被單個 U+FFFD 取代。 例如，在字節序列“41 C0 AF 41 F4 80 80 41”中，最大子部分爲“C0”、“AF”和“F4 80 80”。其中“F4 80 80”可以是“F4 80 80 80”的初始子序列，但“C0”不能是任何形式正確的代碼單位序列的初始子序列。 因此，輸出應爲“A\ufffd\ufffdA\ufffdA”。
• 要在 Android 9 或更高版本中解碼修改後的 UTF-8/CESU-8 序列，請使用 DataInputStream.readUTF() 函數或 NewStringUTF() JNI 函數。

13.枚舉相機

在 Android 9 設備上運行的應用可以通過調用 getCameraIdList() 發現每個可用的攝像頭。 應用不應假定設備只有一個後置攝像頭或只有一個前置攝像頭。

例如，如果您的應用有一個用來切換前置和後置攝像頭的按鈕，則設備可能有多個前置或後置攝像頭可供選擇。 您應瀏覽一下攝像頭列表，檢查每個攝像頭的特徵，然後決定向用戶顯示哪些攝像頭。

14.前臺服務

如果應用以 Android 9 或更高版本爲目標平臺並使用前臺服務，則必須請求 FOREGROUND_SERVICE 權限。這是普通權限，因此，系統會自動爲請求權限的應用授予此權限。

如果以 Android 9 或更高版本爲目標平臺的應用嘗試創建前臺服務且未請求 FOREGROUND_SERVICE，則系統會拋出 SecurityException。

15.Apache HTTP 客戶端棄用

在 Android 6.0 中，我們移除了對 Apache HTTP 客戶端的支持。從 Android 9 開始，該內容庫已從 bootclasspath 中移除，且默認情況下應用無法使用它。

要繼續使用 Apache HTTP 客戶端，以 Android 9 及更高版本爲目標平臺的應用可以向其 AndroidManifest.xml 添加以下內容：

<uses-library android:name="org.apache.http.legacy" android:required="false"/>

注意：擁有的最低 SDK 爲 23 或更低的應用需要有 android:required=“false” 屬性，因爲在 API 級別低於 24 的設備上，org.apache.http.legacy 庫不可用。（在這些設備上，Apache HTTP 類在 bootclasspath 中提供。）

除了使用運行時 Apache 庫，應用還可以將自己的 org.apache.http 庫版本打包到其 APK 中。如果要進行此操作，您必須重新打包該庫（使用一個類似於 Jar Jar 的實用程序），以避免運行時中提供的類存在類兼容性問題。

16.電源管理

Android 9（API 級別 28）引入了一些新功能來改進設備電源管理。 這些變化，連同先前版本中已經存在的功能，有助於確保將系統資源提供給最需要它們的應用。

電源管理功能可以分爲兩個類別：

應用待機羣組
系統將根據用戶的使用模式限制應用對 CPU 或電池等設備資源的訪問。 這是 Android 9 中新增的一項功能。
省電模式改進
開啓省電模式後，系統會對所有應用施加限制。 這是一項已有的功能，但在 Android 9 中得到了改進。

注：這些變化適用於所有應用，無論它們是否以 Android 9 爲目標。

應用待機羣組

Android 9 引入了一項新的電池管理功能，即應用待機羣組。 應用待機羣組可以基於應用最近使用時間和使用頻率，幫助系統排定應用請求資源的優先級。 根據使用模式，每個應用都會歸類到五個優先級羣組之一中。 系統將根據應用所屬的羣組限制每個應用可以訪問的設備資源。

五個羣組按照以下特性將應用分組：

活躍
如果用戶當前正在使用應用，應用將被歸到“活躍”羣組中，例如：

• 應用已啓動一個 Activity
• 應用正在運行前臺服務
• 應用的同步適配器與某個前臺應用使用的 content provider 關聯
• 用戶在應用中點擊了某個通知

如果應用處於“活躍”羣組，系統不會對應用的作業、報警或 FCM 消息施加任何限制。

工作集
如果應用經常運行，但當前未處於活躍狀態，它將被歸到“工作集”羣組中。 例如，用戶在大部分時間都啓動的某個社交媒體應用可能就屬於“工作集”羣組。 如果應用被間接使用，它們也會被升級到“工作集”羣組中 。

如果應用處於“工作集”羣組，系統會對它運行作業和觸發報警的能力施加輕度限制。 如需瞭解詳細信息，請參閱電源管理限制。

常用
如果應用會定期使用，但不是每天都必須使用，它將被歸到“常用”羣組中。 例如，用戶在健身房運行的某個鍛鍊跟蹤應用可能就屬於“常用”羣組。

如果應用處於“常用”羣組，系統將對它運行作業和觸發報警的能力施加較強的限制，也會對高優先級 FCM 消息的數量設定限制。 如需瞭解詳細信息，請參閱電源管理限制。

極少使用
如果應用不經常使用，那麼它屬於“極少使用”羣組。 例如，用戶僅在入住酒店期間運行的酒店應用就可能屬於“極少使用”羣組。

如果應用處於“極少使用”羣組，系統將對它運行作業、觸發警報和接收高優先級 FCM 消息的能力施加嚴格限制。系統還會限制應用連接到網絡的能力。 如需瞭解詳細信息，請參閱電源管理限制。

從未使用
安裝但是從未運行過的應用會被歸到“從未使用”羣組中。 系統會對這些應用施加極強的限制。

系統會動態地將每個應用歸類到某個優先級羣組，並根據需要重新歸類。 系統可能會依靠某個使用機器學習的預加載應用確定每個應用的使用可能性，並將應用歸類到合適的羣組。 如果設備上不存在系統應用，系統默認將基於應用的最近使用時間對它們進行排序。 更爲活躍的應用將被歸類到爲應用提供更高優先級的羣組，從而讓應用可以使用更多系統資源。 具體而言，羣組決定應用運行作業的頻率，應用可以觸發報警的頻率，以及應用可以接收高優先級 Firebase 雲信息傳遞 (FCM) 消息的頻率。 這些限制僅在設備使用電池電量時適用，如果設備正在充電，系統不會對應用施加這些限制。

每個製造商都可以設定自己的標準來歸類非活躍應用。 您不應當嘗試影響應用所屬的羣組。 相反，您應當將精力放在確保應用在所屬的羣組內良好運行上。 您的應用可以通過調用新函數 UsageStatsManager.getAppStandbyBucket() 查找當前屬於哪個羣組。

注：位於 低電耗模式白名單中的應用不適用基於應用待機羣組的限制。