1. 程式人生 > >Android 9.0 功能和 API概覽(中文版)

Android 9.0 功能和 API概覽(中文版)

Android 9 功能和 API

官方搬運:

Android 9(API 級別 28)為使用者和開發者引入了眾多新特性和新功能。 本文重點介紹面向開發者的新功能。

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

全新 RTT API 支援在應用中進行室內定位。

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

在執行 Android 9 且具有硬體支援的裝置上,應用可以使用 RTT API 來測量與附近支援 RTT 的 Wi-Fi 接入點 (AP) 的距離。 裝置必須已啟用位置服務並開啟 Wi-Fi 掃描(在 Settings > Location

 下),同時您的應用必須具有 ACCESS_FINE_LOCATION 許可權。

裝置無需連線到接入點即可使用 RTT。 為了保護隱私,只有手機可以確定與接入點的距離;接入點無此資訊。

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

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

顯示屏缺口支援

顯示各種螢幕缺口尺寸的開發者選項介面

通過使用模擬器測試螢幕缺口。

Android 9 支援最新的全面屏,其中包含為攝像頭和揚聲器預留空間的螢幕缺口。 通過 

DisplayCutout 類可確定非功能區域的位置和形狀,這些區域不應顯示內容。 要確定這些螢幕缺口區域是否存在及其位置,請使用 getDisplayCutout() 函式。

全新的窗口布局屬性 layoutInDisplayCutoutMode 讓您的應用可以為裝置螢幕缺口周圍的內容進行佈局。 您可以將此屬性設為下列值之一:

可以按以下方法在任何執行 Android 9 的裝置或模擬器上模擬螢幕缺口:

  1. 啟用開發者選項
  2. 在 Developer options 螢幕中,向下滾動至 Drawing 部分並選擇 Simulate a display with a cutout
  3. 選擇螢幕缺口的大小。

注:我們建議您通過使用執行 Android 9 的裝置或模擬器測試螢幕缺口周圍的內容顯示。

通知

Android 9 引入了多個通知增強功能,可供以 API 級別 28 及以上版本作為目標平臺的開發者使用。

簡訊通知

附帶了照片的 MessagingStyle。

簡訊通知

含回覆和對話的 MessagingStyle。

提升簡訊體驗

從 Android 7.0(API 級別 24)開始,您可以新增一個操作以回覆簡訊或直接從通知中輸入其他文字。 Android 9 通過下列增強提升了該功能:

  • 簡化了針對對話參與者的支援:Person 類可用於識別參與對話的人員,包括他們的頭像和 URI。 現在,許多其他 API(如 addMessage())均可利用 [Person] 類而不是 CharSequence。 Person 類也支援構建器設計模式。

  • 支援影象:現在,Android 9 可在手機的“簡訊通知”中顯示影象。 您可以使用對簡訊使用 setData()來顯示影象。 以下程式碼段演示瞭如何建立 Person 和包含影象的簡訊。

KOTLIN

JAVA

// Create new Person.
val sender = Person()
        .setName(name)
        .setUri(uri)
        .setIcon(null)
        .build()
// Create image message.
val message = Message("Picture", time, sender)
        .setData("image/", imageUri)
val style = Notification.MessagingStyle(getUser())
        .addMessage("Check this out!", 0, sender)
        .addMessage(message)

  • 將回復另存為草稿:當用戶無意中關閉一個簡訊通知時,您的應用可以檢索系統傳送的 EXTRA_REMOTE_INPUT_DRAFT。 您可以使用此 extra 預填充應用中的文字欄位,以便使用者可以完成他們的回覆。

  • 為 Intent 設定語義操作:setSemanticAction()函式允許您為操作提供語義含義,如“標記為已讀”、“刪除”和“回覆”等。

  • SmartReply:Android 9 支援在您的簡訊應用中提供相同的建議回覆。 使用 RemoteInput.setChoices() 為使用者提供一組標準回覆。

渠道設定、廣播和請勿打擾

Android 8.0 引入了通知渠道,允許您為要顯示的每種通知型別建立可由使用者自定義的渠道。 Android 9 通過下列變更簡化通知渠道設定:

多攝像頭支援和攝像頭更新

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

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

在 Android 9 中,多攝像頭 API支援單色攝像頭,適用於具有 FULL 或  功能的裝置。 單色輸出通過  格式實現,Y 為灰度,U (Cb) 為 128,V (Cr) 為 128。

在受支援的裝置上,Android 9 還支援外接 USB/UVC 攝像頭

適用於可繪製物件和點陣圖的 ImageDecoder

ImageDecoder 讓您可通過位元組緩衝區、檔案或 URI 來建立 Drawable 或 Bitmap。 要解碼影象,請首先以編碼影象的來源為引數,呼叫 createSource()。 然後,通過傳遞 ImageDecoder.Source 物件來呼叫 decodeDrawable() 或 decodeBitmap(),從而建立 Drawable] 或 Bitmap。 要更改預設設定,請將 OnHeaderDecodedListener 傳遞給 decodeDrawable() 或 decodeBitmap()ImageDecoder 呼叫 onHeaderDecoded(),以影象的預設寬度和高度(若已知)為引數。 如果編碼影象是動畫 GIF 或 WebP,decodeDrawable() 將返回 Drawable,它是 AnimatedImageDrawable類的一個例項。

您可以使用不同的方法來設定影象屬性:

通過 ImageDecoder 還可以為圓角或圓形遮罩之類的影象新增複雜的定製效果。 以 PostProcessor類的一個例項作為引數使用 setPostProcessor(),執行您所需的任何繪圖命令。

動畫

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

可使用 ImageDecoder 的例項對 AnimatedImageDrawable 進行解碼。 以下程式碼段演示如何使用 ImageDecoder 來解碼 AnimatedImageDrawable

KOTLIN

JAVA

@Throws(IOException::class)
private fun decodeImage() {
    val decodedAnimation = ImageDecoder.decodeDrawable(
        ImageDecoder.createSource(resources, R.drawable.my_drawable))

    // Prior to start(), the first frame is displayed.
    (decodedAnimation as? AnimatedImageDrawable)?.start()
}

ImageDecoder 有幾個允許您進一步修改影象的函式。 例如,可使用 setPostProcessor() 函式來修改影象的外觀,如應用圓形遮罩或圓角。

HDR VP9 視訊、HEIF 影象壓縮和 Media API

Android 9 新增了對 High Dynamic Range (HDR) VP9 Profile 2 的內建支援,因此,現在您可以在支援 HDR 的裝置上為使用者提供來自 YouTube、Play Movies 和其他來源的採用 HDR 的影片。

Android 9 為平臺增加了對 HEIF (heic) 影象編碼的支援。 MediaMuxer 和 MediaExtractor 類中可支援 HEIF 靜態影象示例 HEIF 改進了壓縮,可節省儲存空間和網路資料流量。 藉助 Android 9 裝置上的平臺支援,從後端伺服器傳送和使用 HEIF 影象輕而易舉。 確保應用相容這種便於共享和顯示的資料格式後,嘗試在應用中使用 HEIF 作為影象儲存格式。 您可以使用 ImageDecoder 或 BitmapFactory 進行 jpeg 到 heicto 的轉換,以通過 jpeg 獲取點陣圖,並且可以使用 HeifWriter 寫入來自 YUV 位元組緩衝區、Surface 或 Bitmap 的 HEIF 靜態影象。

Android 9 向 MediaDRM 類添加了函式以獲取指標、高頻寬數字內容保護 (HDCP) 級別、安全級別和會話數,並對安全性級別和安全停止進行更多控制。 如需瞭解更多詳情,請參閱 API 差異報告

在 Android 9 中,AAudio API 包含 AAudioStream 屬性,用於 usagecontent type 和 input preset。 使用這些屬性可以建立針對 VoIP 或攝像機應用調整的流。 您還可以設定 SessionID將 AAudio 流與可包含音效的子混音相關聯。 使用  來控制音效。

Android 9 包含一個用於 DynamicsProcessing 的 AudioEffect API。 藉助該類,可以構建基於通道的音效,由各種型別(包括均衡、多頻帶壓縮和限幅器)的多個階段組成。 頻帶和活動階段的數量可配置,而且大多數引數可實時控制。

JobScheduler 中的流量費用敏感度

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

作業可以宣告其預估的資料大小、訊號預提取,並指定具體的網路要求。 JobScheduler 然後根據網路狀態管理工作。 例如,當網路顯示擁塞時,JobScheduler 可能會延遲較大的網路請求。 如果使用的是不按流量計費的網路,則 JobScheduler 可執行預提取作業以提升使用者體驗(例如預提取標題)。

Neural Networks API 1.1

Android 8.1(API 級別 27)中引入了 Neural Networks API 以加快 Android 裝置上機器學習的速度。 Android 9 擴充套件和改進了該 API,增加了對九種新運算的支援:

自動填充框架

Android 9 引入了多項改進,自動填充服務可以利用這些改進進一步增強使用者填寫表單時的體驗。 如需詳細瞭解如何在您的應用中使用自動填充功能,請參閱自動填充框架指南。

安全增強功能

Android 9 引入了若干安全功能,詳見以下各節摘要說明:

Android Protected Confirmation

執行 Android 9 或更高版本的受支援裝置賦予您使用 Android Protected Confirmation 的能力。 使用該工作流時,您的應用會向用戶顯示提示,請他們批准一個簡短的宣告。 應用可以通過這個宣告再次確認,使用者確實想完成一項敏感事務,例如付款。

如果使用者接受該宣告,Android 金鑰庫會收到並存儲由金鑰雜湊訊息身份驗證程式碼 (HMAC) 保護的加密簽名。 Android 金鑰庫確認訊息的有效性之後,您的應用可以使用在可信執行環境 (TEE) 下通過 trustedConfirmationRequired 生成的金鑰來簽署使用者已接受的訊息。 該簽名具有很高的可信度,它表示使用者已看過宣告並同意其內容。

注意:Android Protected Confirmation 不會為使用者提供安全資訊通道。 應用無法承擔 Android 平臺所提供機密性保證之外的任何其他保證。 尤其是,請勿使用該工作流顯示您通常不會顯示在使用者裝置上的敏感資訊。

如需獲得 Android Protected Confirmation 新增支援方面的指導,請參閱 Android Protected Confirmation 指南。

統一生物識別身份驗證對話方塊

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

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

注:在應用中使用 BiometricPrompt 之前,應該先使用 hasSystemFeature()函式以確保裝置支援 FEATURE_FINGERPRINTFEATURE_IRIS 或 FEATURE_FACE

硬體安全性模組

執行 Android 9 或更高版本的受支援裝置可擁有 StrongBox Keymaster,它是位於硬體安全性模組中的 Keymaster HAL 的一種實現。 該模組包含以下組成部分:

  • 自己的 CPU。
  • 安全儲存空間。
  • 真實隨機數生成器。
  • 可抵禦軟體包篡改和未經授權線刷應用的附加機制。

檢查儲存在 StrongBox Keymaster 中的金鑰時,系統會通過可信執行環境 (TEE) 證實金鑰的完整性。

如需瞭解有關使用 Strongbox Keymaster 的更多資訊,請參閱硬體安全性模組

保護對金鑰庫進行的金鑰匯入

Android 9 通過利用 ASN.1‑編碼金鑰格式將已加密金鑰安全匯入金鑰庫的功能,提高了金鑰解密的安全性。 Keymaster 隨後會在金鑰庫中將金鑰解密,因此金鑰的內容永遠不會以明文形式出現在裝置的主機記憶體中。

注:只有附帶 Keymaster 4 或更高版本的裝置才支援該功能。

具有金鑰輪轉的 APK 簽名方案

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

注:執行 Android 8.1(API 級別 27)或更低版本的裝置不支援更改簽名證書。 如果應用的 minSdkVersion 為 27 或更低,除了新簽名之外,可使用舊簽名證書來簽署應用。

只允許在未鎖定裝置上進行金鑰解密的選項

Android 9 引入了 unlockedDeviceRequired 標誌。 此選項確定在允許使用指定金鑰對任何正在傳輸或儲存的資料進行解密之前,金鑰庫是否要求螢幕解鎖。 這些型別的金鑰非常適合用於加密要儲存在磁碟上的敏感資料,例如健康或企業資料。 該標誌為使用者提供了更高的保證,即使手機丟失或被盜,在裝置鎖定的情況下,無法對資料進行解密。

注:unlockedDeviceRequired 標誌啟用之後,仍然可以隨時進行加密和簽名驗證。 該標誌可防止在裝置解鎖時“僅解密”資料。

在裝置鎖定時要確保金鑰安全不被解密,可通過將 true 傳遞給 setUnlockedDeviceRequired() 函式啟用該標誌。 完成該步驟之後,當用戶的螢幕被鎖定時,使用該金鑰進行解密或簽署資料的任何嘗試都會失敗。 鎖定裝置在可以訪問之前,需要 PIN 碼、密碼、指紋或者一些其他可信因素。

舊版加密支援

附帶 Keymaster 4 的 Android 9 裝置支援三重資料加密演算法(簡稱三重 DES)。 如果您的應用與需要三重 DES 的舊版系統進行互操作,請使用這種加密來加密敏感憑據。

如需詳細瞭解如何讓您的應用更加安全,請參閱 Android 開發者的安全性

該隱私措施啟用之後,從使用者裝置製作的備份還原資料時,會要求提供裝置的 PIN 碼、圖案或密碼。 如需詳細瞭解該項功能背後的技術,請參閱 Google 雲金鑰保險櫃服務白皮書。

定義備份所需的裝置條件

如果您的應用資料包含敏感資訊或偏好,Android 9 可讓您定義裝置條件(例如在客戶端加密已啟用或者正在進行本地裝置到裝置傳輸時),資料將依據該條件包括在使用者的備份中。

如需瞭解有關在 Android 裝置上備份資料的詳細資訊,請參閱資料備份概覽

無障礙功能

Android 9 引入了針對無障礙功能框架的增強功能,讓您能夠更輕鬆地為應用的使用者提供更好的體驗。

導航語義

Android 9 中的新增屬性讓您可以更輕鬆地定義無障礙服務(尤其是螢幕閱讀器)如何從螢幕的某個部分導航到另一個部分。 這些屬性可幫助視力受損使用者在應用介面的文字之間快速移動,並允許他們進行選擇。

例如,在購物應用中,螢幕閱讀器可以幫助使用者從某個交易類別直接導航至下一個交易類別,在轉到下一個類別之前,螢幕閱讀器無需讀取當前類別中的所有交易。

無障礙功能窗格標題

在 Android 8.1(API 級別 27)和更低版本中,無障礙服務有時無法確定螢幕的某個窗格是何時更新的,例如某個 Activity 將一個 Fragment 替換為另一個 Fragment 的時候。 窗格由按照邏輯關係分組、視覺上相關的介面元素組成,其中通常包含一個 Fragment。

在 Android 9 中,可為這些窗格提供 無障礙功能窗格標題,即可單獨識別的標題。 如果某個窗格具有無障礙功能窗格標題,當窗格改變時,無障礙服務可接收更詳細的資訊。 依靠這種功能,服務可以為使用者提供有關介面變化的更精細資訊。

基於標題的導航

如果您的應用顯示的文字內容包含邏輯標題,則對於表示這些標題的 View 例項,請將android:accessibilityHeading 屬性設定為 true。 通過新增這些標題,無障礙服務可幫助使用者直接從一個標題導航至下一個標題。 任何無障礙服務都可以使用這種功能,以改善使用者介面的導航體驗。

群組導航和輸出

傳統上,螢幕閱讀器一直使用 android:focusable 屬性來確定何時應該將 ViewGroup 或一系列 View 物件作為一個整體進行讀取。 這樣,使用者就可以瞭解,這些檢視在邏輯上彼此相關。

在 Android 8.1 和更低版本中,您需要將 ViewGroup 中的每個 View 物件標記為不可聚焦,並將 ViewGroup 本身標記為可聚焦。 這種安排導致 View 的某些例項被標記為可聚焦,從而使得鍵盤導航變得更為繁瑣。

從 Android 9 開始,如果將 View 物件標記為可聚焦會產生不良後果,則可以使用android:screenReaderFocusable 屬性代替 android:focusable 屬性。 螢幕閱讀器聚焦在所有將 android:screenReaderFocusable 或 android:focusable 設定為 true 的元素上。

便捷操作

Android 9 新增了一些方便使用者執行操作的支援功能:

視窗變更詳情

Android 9 讓您可以在應用同時重繪多個視窗時,更輕鬆地跟蹤應用視窗的更新。 當發生 TYPE_WINDOWS_CHANGED 事件時,可使用 getWindowChanges() API 來確定視窗發生的變更。 在多視窗更新期間,每個視窗都會生成自己的一組事件。 getSource() 函式返回與每個事件相關聯的視窗的根檢視。

如果應用已為其 View 物件定義無障礙功能窗格標題,您的 Service 將可以識別應用介面何時進行更新。 TYPE_WINDOW_STATE_CHANGED 事件發生時,可使用 getContentChangeTypes() 所返回的型別來確定視窗發生的變更。 例如,框架可以檢測窗格何時有新標題或者窗格何時消失。

Google 致力於為所有 Android 使用者改善無障礙功能,提供增強功能以便讓您構建 Service,如話語提示螢幕閱讀器,供需要無障礙功能的使用者使用。 如需瞭解有關如何讓您的應用更便於訪問以及如何構建無障礙 Service 的更多資訊,請參閱無障礙功能

旋轉

為避免無意的旋轉,我們新增了一種模式,哪怕裝置位置發生變化,也會固定在當前螢幕方向上。 必要時使用者可以通過按系統欄上的一個按鈕手動觸發旋轉。

大多數情況下,對應用的相容性影響微不足道。 不過,如果您的應用有任何自定義旋轉行為,或使用了任何非常規的螢幕方向設定,則可能會遇到以前使用者旋轉首選項始終設定為縱向時被忽視的問題。 我們鼓勵您審視一下您的應用所有關鍵 Activity 中的旋轉行為,並確保您的所有螢幕方向設定仍可提供最佳體驗。

如需瞭解更多詳情,請參閱相關的行為變更

一個新的旋轉模式允許使用者在必要時利用系統欄上的一個按鈕手動觸發旋轉。

文字

Android 9 為平臺提供了以下與文字相關的功能:

  • 文字預先計算:PrecomputedText 類使您能提前計算和快取所需資訊,改善了文字渲染效能。 它還使您的應用可以在主執行緒之外執行文字佈局。

  • 放大器:Magnifier 類是一種可提供放大器 API 的微件,可在所有應用中實現一致的放大器功能體驗。

  • Smart Linkify:Android 9 增強了 TextClassifier 類,該類可利用機器學習在選定文字中識別一些實體並建議採取相應的操作。 例如,TextClassifier 可以讓您的應用檢測到使用者選擇了電話號碼。 然後,您的應用可以建議使用者使用該號碼撥打電話。 TextClassifier 中的功能取代了 Linkify 類的功能。

  • 文字佈局:藉助幾種便捷函式和屬性,可以更輕鬆地實現介面設計。 如需瞭解詳細資訊,請參閱 TextView 參考文件。

DEX 檔案的 ART 提前轉換

在執行 Android 9 或更高版本的裝置上,Android 執行時 (ART) 提前編譯器通過將應用軟體包中的 DEX 檔案轉換為更緊湊的表示形式,進一步優化了壓縮的 Dalvik Executable 格式 (DEX) 檔案。 此項變更可讓您的應用啟動更快並消耗更少的磁碟空間和記憶體。

這種改進特別有利於磁碟 I/O 速度較慢的低端裝置。

裝置端系統跟蹤

Android 9 允許您通過裝置記錄系統跟蹤記錄,然後與您的開發團隊分享這些記錄的報告。 該報告支援多種格式,包括 HTML。

通過收集這些跟蹤記錄,您可以獲取與應用程序和執行緒相關的計時資料,並檢視其他型別的具有全域性意義的裝置狀態。

注:您無需設定您的程式碼來記錄跟蹤記錄,但這樣做可以幫助您檢視應用程式碼的哪些部分可能會導致執行緒掛起或介面卡頓。