北京時間2018年8月7日上午,Google 發佈了 Android 9.0 操做系統。並宣佈系統版本 Android P 被正式命名爲代號「Pie」。html
Android 9.0 利用人工智能技術,讓手機變得更智能、更快,而且還能夠隨着用戶的使用習慣進行調整。android
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 米。api
經過這種精確性,您能夠打造新的體驗,例如樓內導航、基於精細位置的服務,如無歧義語音控制(例如,「打開這盞燈」),以及基於位置的信息(如 「此產品是否有特別優惠?」)。數組
Android 9 支持最新的全面屏,其中包含爲攝像頭和揚聲器預留空間的屏幕缺口。 經過 DisplayCutout 類可肯定非功能區域的位置和形狀,這些區域不該顯示內容。 要肯定這些屏幕缺口區域是否存在及其位置,請使用 getDisplayCutout() 函數。緩存
全新的窗口布局屬性 layoutInDisplayCutoutMode 讓您的應用能夠爲設備屏幕缺口周圍的內容進行佈局。 您能夠將此屬性設爲下列值之一:安全
能夠按如下方法在任何運行 Android 9 的設備或模擬器上模擬屏幕缺口:服務器
1.啓用開發者選項。
2.在 Developer options 屏幕中,向下滾動至 Drawing 部分並選擇 Simulate a display with a cutout。
選擇屏幕缺口的大小。
注示:咱們建議您經過使用運行 Android 9 的設備或模擬器測試屏幕缺口周圍的內容顯示。
Android 9 引入了多個通知加強功能,可供以 API 級別 28 及以上版本做爲目標平臺的開發者使用。
從 Android 7.0(API 級別 24)開始,您能夠添加一個操做以回覆短信或直接從通知中輸入其餘文本。 Android 9 經過下列加強提高了該功能:
// Create new Person. Person sender = new Person() .setName(name) .setUri(uri) .setIcon(null) .build(); // Create image message. Message message = new Message("Picture", time, sender) .setData("image/", imageUri); Notification.MessagingStyle style = new Notification.MessagingStyle(getUser()) .addMessage("Check this out!", 0, sender) .addMessage(message);
圖1-1 附帶了照片的 MessagingStyle
圖2-2 含回覆和對話的 MessagingStyle
Android 8.0 引入了通知渠道,容許您爲要顯示的每種通知類型建立可由用戶自定義的渠道。 Android 9 經過下列變動簡化通知渠道設置:
屏蔽渠道組:如今,用戶能夠針對某個應用在通知設置中屏蔽整個渠道組。 您可使用 isBlocked() 函數肯定什麼時候屏蔽一個渠道組,從而不會向該組中的渠道發送任何通知。此外,您的應用可使用全新的 getNotificationChannelGroup() 函數查詢當前渠道組設置。
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 防止通知顯示在支持列表視圖(如通知欄或鎖屏)的設備的列表視圖中。
在運行 Android 9 的設備上,您能夠經過兩個或更多物理攝像頭來同時訪問多個視頻流。] 在配備雙前置攝像頭或雙後置攝像頭的設備上,您能夠建立只配備單攝像頭的設備所不可能實現的創新功能,例如無縫縮放、背景虛化和立體成像。 經過該 API,您還能夠調用邏輯或融合的攝像頭視頻流,該視頻流可在兩個或更多攝像頭之間自動切換。
攝像頭方面的其餘改進還包括附加會話參數和 Surface 共享,前者有助於下降首次拍照期間的延遲,然後者則讓攝像頭客戶端可以處理各類用例,而無需中止並啓動攝像頭視頻流。 咱們還針對基於顯示屏的 flash 支持和 OIS 時間戳訪問新增了一些 API,用以實現應用級的圖像穩定化和特效。
在 Android 9 中,多攝像頭 API支持單色攝像頭,適用於具備 FULL 或 LIMITED 功能的設備。 單色輸出經過 YUV_420_888 格式實現,Y 爲灰度,U (Cb) 爲 128,V (Cr) 爲 128。
在受支持的設備上,Android 9 還支持外置 USB/UVC 攝像頭。
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 類的一個實例。
您可使用不一樣的方法來設置圖像屬性:
經過 ImageDecoder 還能夠爲圓角或圓形遮罩之類的圖像添加複雜的定製效果。 以 PostProcessor 類的一個實例做爲參數使用 setPostProcessor(),執行您所需的任何繪圖命令。
注:對 AnimatedImageDrawable進行後處理時,效果會出如今動畫的全部幀中。
Android 9 引入了 AnimatedImageDrawable 類,用於繪製和顯示 GIF 和 WebP 動畫圖像。 AnimatedImageDrawable 的工做方式與 AnimatedVectorDrawable 的類似之處在於,都是渲染線程驅動 AnimatedImageDrawable 的動畫。 渲染線程還使用工做線程進行解碼,所以,解碼不會干擾渲染線程的其餘操做。 這種實現機制容許您的應用在顯示動畫圖像時,無需管理其更新,也不會干擾應用界面線程上的其餘事件。
可以使用 ImageDecoder的實例對AnimatedImageDrawable進行解碼。如下代碼段演示如何使用ImageDecoder來解碼AnimatedImageDrawable:
private void decodeImage() throws IOException { Drawable decodedAnimation = ImageDecoder.decodeDrawable( ImageDecoder.createSource(getResources(), R.drawable.my_drawable)); if (decodedAnimation instanceof AnimatedImageDrawable) { // Prior to start(), the first frame is displayed. ((AnimatedImageDrawable) decodedAnimation).start(); } }
ImageDecoder 有幾個容許您進一步修改圖像的函數。 例如,可以使用 setPostProcessor() 函數來修改圖像的外觀,如應用圓形遮罩或圓角。
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 靜態圖像。
還可經過 AudioTrack、AudioRecord 和 MediaDrm 類獲取媒體指標。
Android 9 向 MediaDRM 類添加了函數以獲取指標、高帶寬數字內容保護 (HDCP) 級別、安全級別和會話數,並對安全性級別和安全中止進行更多控制。 如需瞭解更多詳情,請參閱 API 差別報告。
在 Android 9 中,AAudio API 包含 AAudioStream 屬性,用於 usage、content type 和 input preset。 使用這些屬性能夠建立針對 VoIP 或攝像機應用調整的流。 您還能夠設置 SessionID將 AAudio 流與可包含音效的子混音相關聯。 使用 AudioEffect API 來控制音效。
Android 9 包含一個用於 DynamicsProcessing 的 AudioEffect API。 藉助該類,能夠構建基於通道的音效,由各類類型(包括均衡、多頻帶壓縮和限幅器)的多個階段組成。 頻帶和活動階段的數量可配置,並且大多數參數可實時控制。
從 Android 9 開始,JobScheduler 可使用運營商提供的網絡狀態信號來改善與網絡有關的做業處理。
做業能夠聲明其預估的數據大小、信號預提取,並指定具體的網絡要求。 JobScheduler 而後根據網絡狀態管理工做。 例如,當網絡顯示擁塞時,JobScheduler 可能會延遲較大的網絡請求。 若是使用的是不按流量計費的網絡,則 JobScheduler 可運行預提取做業以提高用戶體驗(例如預提取標題)。
添加做業時,確保使用 setEstimatedNetworkBytes()、setPrefetch() 和 setRequiredNetwork()(若是適用),以幫助 JobScheduler 正確處理工做。 在執行做業時,請確保使用 JobParameters.getNetwork() 返回的 Network 對象。 不然,您將隱式使用設備的默認網絡,其可能不符合您的要求,從而致使意外的流量消耗。
Android 8.1(API 級別 27)中引入了 Neural Networks API 以加快 Android 設備上機器學習的速度。 Android 9 擴展和改進了該 API,增長了對九種新運算的支持:
元素級數學運算:
ANEURALNETWORKS_DIV
ANEURALNETWORKS_SUB
數組運算:
ANEURALNETWORKS_BATCH_TO_SPACE_ND
ANEURALNETWORKS_SPACE_TO_BATCH_ND
ANEURALNETWORKS_SQUEEZE
ANEURALNETWORKS_STRIDED_SLICE
ANEURALNETWORKS_TRANSPOSE
ANEURALNETWORKS_PAD
ANEURALNETWORKS_MEAN
此外,API 還引入了一個新函數,即 ANeuralNetworksModel_relaxComputationFloat32toFloat16(),容許您指定是否計算範圍和精度低至 IEEE 754 16 位浮點格式的 ANEURALNETWORKS_TENSOR_FLOAT32。
Android 9 引入了多項改進,自動填充服務能夠利用這些改進進一步加強用戶填寫表單時的體驗。 如需詳細瞭解如何在您的應用中使用自動填充功能,請參閱自動填充框架指南。
Android 9 引入了若干安全功能,詳見如下各節摘要說明。
運行 Android 9 或更高版本的受支持設備賦予您使用 Android Protected Confirmation 的能力。 使用該工做流時,您的應用會向用戶顯示提示,請他們批准一個簡短的聲明。 應用能夠經過這個聲明再次確認,用戶確實想完成一項敏感事務,例如付款。
若是用戶接受該聲明,Android 密鑰庫會收到並存儲由密鑰哈希消息身份驗證代碼 (HMAC) 保護的加密簽名。 Android 密鑰庫確認消息的有效性以後,您的應用可使用在可信執行環境 (TEE) 下經過 trustedConfirmationRequired 生成的密鑰來簽署用戶已接受的消息。 該簽名具備很高的可信度,它表示用戶已看過聲明並贊成其內容。
在 Android 9 中,系統表明您的應用提供生物識別身份驗證對話框。 該功能可建立標準化的對話框外觀、風格和位置,讓用戶更加確信,他們在使用可信的生物識別憑據檢查程序進行身份驗證。
若是您的應用使用 FingerprintManager 向用戶顯示指紋身份驗證對話框,請切換到改用 BiometricPrompt。 BiometricPrompt 依賴系統來顯示身份驗證對話框。 它還會改變其行爲,以適應用戶所選擇的生物識別身份驗證類型。
注:在應用中使用 BiometricPrompt 以前,應該先使用 hasSystemFeature()函數以確保設備支持 FEATURE_FINGERPRINT、FEATURE_IRIS 或 FEATURE_FACE。
若是設備不支持生物識別身份驗證,能夠回退爲使用 createConfirmDeviceCredentialIntent() 函數驗證用戶的 PIN 碼、圖案或密碼。
運行 Android 9 或更高版本的受支持設備可擁有 StrongBox Keymaster,它是位於硬件安全性模塊中的 Keymaster HAL 的一種實現。 該模塊包含如下組成部分:
檢查存儲在 StrongBox Keymaster 中的密鑰時,系統會經過可信執行環境 (TEE) 證明密鑰的完整性。
Android 9 經過利用 ASN.1‑編碼密鑰格式將已加密密鑰安全導入密鑰庫的功能,提升了密鑰解密的安全性。 Keymaster 隨後會在密鑰庫中將密鑰解密,所以密鑰的內容永遠不會以明文形式出如今設備的主機內存中。
注:只有附帶 Keymaster 4 或更高版本的設備才支持該功能。
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 9 新增了與備份和還原有關的功能和開發者選項。 這些更改的詳細信息如以部分下所示。
Android 9 新增了對使用客戶端密鑰加密 Android 備份的支持。 知足下列條件時會自動啓用該支持功能:
該隱私措施啓用以後,從用戶設備製做的備份還原數據時,會要求提供設備的 PIN 碼、圖案或密碼。 如需詳細瞭解該項功能背後的技術,請參閱 Google 雲密鑰保險櫃服務白皮書。
若是您的應用數據包含敏感信息或偏好,Android 9 可以讓您定義設備條件(例如在客戶端加密已啓用或者正在進行本地設備到設備傳輸時),數據將依據該條件包括在用戶的備份中。
Android 9 讓您能夠在應用同時重繪多個窗口時,更輕鬆地跟蹤應用窗口的更新。 當發生 TYPE_WINDOWS_CHANGED 事件時,可以使用 getWindowChanges() API 來肯定窗口發生的變動。 在多窗口更新期間,每一個窗口都會生成本身的一組事件。 getSource() 函數返回與每一個事件相關聯的窗口的根視圖。
若是應用已爲其 View 對象定義無障礙功能窗格標題,您的 Service 將能夠識別應用界面什麼時候進行更新。 TYPE_WINDOW_STATE_CHANGED 事件發生時,可以使用 getContentChangeTypes() 所返回的類型來肯定窗口發生的變動。 例如,框架能夠檢測窗格什麼時候有新標題或者窗格什麼時候消失。
Android 9 爲平臺提供瞭如下與文本相關的功能:
在運行 Android 9 或更高版本的設備上,Android 運行時 (ART) 提早編譯器經過將應用軟件包中的 DEX 文件轉換爲更緊湊的表示形式,進一步優化了壓縮的 Dalvik Executable 格式 (DEX) 文件。 此項變動可以讓您的應用啓動更快並消耗更少的磁盤空間和內存。
這種改進特別有利於磁盤 I/O 速度較慢的低端設備。
Android 9 容許您經過設備記錄系統跟蹤記錄,而後與您的開發團隊分享這些記錄的報告。 該報告支持多種格式,包括 HTML。
經過收集這些跟蹤記錄,您能夠獲取與應用進程和線程相關的計時數據,並查看其餘類型的具備全局意義的設備狀態。
注:您無需設置您的代碼來記錄跟蹤記錄,但這樣作能夠幫助您查看應用代碼的哪些部分可能會致使線程掛起或界面卡頓。
本文內容來自google中文官網:
https://developer.android.google.cn/about/versions/pie/android-9.0
若是你想第一時間看個人後期文章,掃碼關注公衆號,長期推送Android開發文章、最新動態、開源項目,讓你各類漲姿式。
Android開發666 - 安卓開發技術分享 掃描二維碼加關注