一、Android5

1.ANDROID 5.0 行為變更：

聲音和振動

（1）如果您當前使用 Ringtone纵顾、MediaPlayer 或 Vibrator 類向通知中添加聲音和振動券犁，則移除此代碼驮吱，以便系統(tǒng)可以在“優(yōu)先”模式中正確顯示通知焕蹄。取而代之的是塔粒，使用 Notification.Builder 方法添加聲音和振動身冬。

（2）以前衅胀，Android 使用 STREAM_MUSIC 作為主流式傳輸來控制平板電腦設(shè)備上的音量。在 Android 5.0 中酥筝，手機和平板電腦設(shè)備的主音量流式傳輸現(xiàn)已合并滚躯，由 STREAM_RING 或 STREAM_NOTIFICATION 進行控制。

（3）媒體播放

? ? ? ?如果您要實現(xiàn)顯示媒體播放狀態(tài)或傳輸控件的通知，請考慮使用新的 Notification.MediaStyle 模板掸掏，而不是自定義 RemoteViews.Remote View 對象茁影。無論您選擇使用哪個方法，請務必將通知的可見性設(shè)為 VISIBILITY_PUBLIC丧凤，以便可通過鎖定屏幕訪問您的控件募闲。請注意，從 Android 5.0 開始愿待，系統(tǒng)不再將 RemoteControlClient 對象顯示在鎖定屏幕上浩螺。如需了解詳細信息，請參閱如果您的應用使用 RemoteControlClient.

（4）浮動通知 ? ? ?? ??? ? ?

現(xiàn)在呼盆，當設(shè)備處于活動狀態(tài)時（即年扩，設(shè)備未鎖定且其屏幕已打開），通知可以顯示在小型浮動窗口中（也稱為“浮動通知”）访圃。這些通知看上去類似于精簡版的通知厨幻，只是浮動通知還顯示操作按鈕。用戶可以在不離開當前應用的情況下處理或清除浮動通知腿时。

可能觸發(fā)浮動通知的條件示例包括：

用戶的 Activity 處于全屏模式中（應用使用 fullScreenIntent）

通知具有較高的優(yōu)先級并使用鈴聲或振動况脆。

（5）綁定到服務

Context.bindService() 方法現(xiàn)在需要顯式 Intent，如果提供隱式 intent批糟，將引發(fā)異常格了。為確保應用的安全性，請使用顯式 intent 啟動或綁定 Service徽鼎，且不要為服務聲明 intent 過濾器盛末。

（6）WebView

Android 5.0 更改了應用的默認行為。

如果您的應用是面向 API 級別 21 或更高級別：

默認情況下否淤，系統(tǒng)會阻止混合內(nèi)容和第三方 Cookie悄但。要允許混合內(nèi)容和第三方 Cookie，請分別使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法石抡。

系統(tǒng)現(xiàn)在可以智能地選擇要繪制的 HTML 文檔部分檐嚣。這個新的默認行為有助于減少內(nèi)存占用和提升性能。如果您要一次渲染整個文檔啰扛，可通過調(diào)用 enableSlowWholeDocumentDraw() 停用此優(yōu)化嚎京。

如果您的應用是面向低于 21 的 API 級別：系統(tǒng)允許混合內(nèi)容和第三方 Cookie，并始終一次渲染整個文檔隐解。

（7）自定義權(quán)限

從 Android 5.0 開始鞍帝，對于使用不同密鑰簽名的應用，系統(tǒng)會強制執(zhí)行新的自定義權(quán)限唯一性限制∩访＃現(xiàn)在帕涌，設(shè)備上只有一個應用可以定義給定的自定義權(quán)限（按其名稱確定）岩臣，除非定義此權(quán)限的其他應用使用相同密鑰簽名

（8）與服務器握手的 TLS/SSL 被錯誤地拒絕或出現(xiàn)停頓。首選的修復方法是升級服務器以符合 TLS/SSL 協(xié)議

二宵膨、ANDROID 6.0

1. 行為變更

(1)? 運行時權(quán)限

此版本引入了一種新的權(quán)限模式，如今炸宵，用戶可直接在運行時管理應用權(quán)限辟躏。這種模式讓用戶能夠更好地了解和控制權(quán)限，同時為應用開發(fā)者精簡了安裝和自動更新過程土全。用戶可為所安裝的各個應用分別授予或撤銷權(quán)限捎琐。

對于以 Android 6.0（API 級別 23）或更高版本為目標平臺的應用，請務必在運行時檢查和請求權(quán)限裹匙。要確定您的應用是否已被授予權(quán)限瑞凑，請調(diào)用新增的 checkSelfPermission() 方法。要請求權(quán)限概页，請調(diào)用新增的 requestPermissions() 方法籽御。即使您的應用并不以 Android 6.0（API 級別 23）為目標平臺，您也應該在新權(quán)限模式下測試您的應用惰匙。

如需了解有關(guān)在您的應用中支持新權(quán)限模式的詳情技掏，請參閱使用系統(tǒng)權(quán)限。如需了解有關(guān)如何評估新模式對應用的影響的提示项鬼，請參閱權(quán)限最佳做法哑梳。

(2)? 低電耗模式和應用待機模式

此版本引入了針對空閑設(shè)備和應用的最新節(jié)能優(yōu)化技術(shù)。這些功能會影響所有應用绘盟，因此請務必在這些新模式下測試您的應用鸠真。

低電耗模式：如果用戶拔下設(shè)備的電源插頭，并在屏幕關(guān)閉后的一段時間內(nèi)使其保持不活動狀態(tài)龄毡，設(shè)備會進入低電耗模式吠卷，在該模式下設(shè)備會嘗試讓系統(tǒng)保持休眠狀態(tài)。在該模式下稚虎，設(shè)備會定期短時間恢復正常工作撤嫩，以便進行應用同步，還可讓系統(tǒng)執(zhí)行任何掛起的操作蠢终。

應用待機模式：應用待機模式允許系統(tǒng)判定應用在用戶未主動使用它時處于空閑狀態(tài)序攘。當用戶有一段時間未觸摸應用時，系統(tǒng)便會作出此判定寻拂。如果拔下了設(shè)備電源插頭程奠，系統(tǒng)會為其視為空閑的應用停用網(wǎng)絡訪問以及暫停同步和作業(yè)。

要詳細了解這些節(jié)能變更祭钉，請參閱對低電耗模式和應用待機模式進行針對性優(yōu)化瞄沙。

(3)取消支持 Apache HTTP 客戶端

Android 6.0 版移除了對 Apache HTTP 客戶端的支持。如果您的應用使用該客戶端，并以 Android 2.3（API 級別 9）或更高版本為目標平臺距境，請改用 HttpURLConnection 類申尼。此 API 效率更高，因為它可以通過透明壓縮和響應緩存減少網(wǎng)絡使用垫桂，并可最大限度降低耗電量师幕。要繼續(xù)使用 Apache HTTP API，您必須先在 build.gradle 文件中聲明以下編譯時依賴項：

android {

? ? useLibrary 'org.apache.http.legacy'

}

(4)BoringSSL

Android 正在從使用 OpenSSL 庫轉(zhuǎn)向使用 BoringSSL 庫诬滩。如果您要在應用中使用 Android NDK霹粥，請勿鏈接到并非 NDK API 組成部分的加密庫，如 libcrypto.so 和 libssl.so疼鸟。這些庫并非公共 API后控，可能會在不同版本和設(shè)備上毫無征兆地發(fā)生變化或出現(xiàn)故障。此外空镜，您還可能讓自己暴露在安全漏洞的風險之下浩淘。請改為修改原生代碼，以通過 JNI 調(diào)用 Java 加密 API吴攒，或靜態(tài)鏈接到您選擇的加密庫馋袜。

(5) 藍牙掃描需要定位權(quán)限 才能獲得MAC地址，硬件標識符訪問權(quán)

為給用戶提供更嚴格的數(shù)據(jù)保護舶斧，從此版本開始欣鳖，對于使用 WLAN API 和 Bluetooth API 的應用，Android 移除了對設(shè)備本地硬件標識符的編程訪問權(quán)茴厉。WifiInfo.getMacAddress() 方法和 BluetoothAdapter.getAddress() 方法現(xiàn)在會返回常量值 02:00:00:00:00:00泽台。

現(xiàn)在，要通過藍牙和 WLAN 掃描訪問附近外部設(shè)備的硬件標識符矾缓，您的應用必須擁有 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION 權(quán)限怀酷。

WifiManager.getScanResults()

BluetoothDevice.ACTION_FOUND

BluetoothLeScanner.startScan()

注：當運行 Android 6.0（API 級別 23）的設(shè)備發(fā)起后臺 WLAN 或藍牙掃描時，在外部設(shè)備看來嗜闻，該操作的發(fā)起來源是一個隨機化 MAC 地址蜕依。

(6)?通知

此版本移除了 Notification.setLatestEventInfo() 方法。請改用 Notification.Builder 類來構(gòu)建通知琉雳。要重復更新通知样眠，請重復使用 Notification.Builder 實例。調(diào)用 build() 方法可獲取更新后的 Notification 實例翠肘。

adb shell dumpsys notification 命令不再打印輸出您的通知文本檐束。請改用 adb shell dumpsys notification --noredact 命令打印輸出 notification 對象中的文本。

(7)音頻管理器變更

不再支持通過 AudioManager 類直接設(shè)置音量或?qū)⑻囟ㄒ纛l流靜音束倍。setStreamSolo() 方法已棄用被丧，您應該改為調(diào)用 requestAudioFocus() 方法盟戏。類似地，setStreamMute() 方法也已棄用甥桂，請改為調(diào)用 adjustStreamVolume() 方法并傳入方向值 ADJUST_MUTE 或 ADJUST_UNMUTE柿究。

(8)WLAN 和網(wǎng)絡連接變更

此版本對 WLAN API 和 Networking API 引入了以下行為變更。

現(xiàn)在黄选，您的應用只能更改由您創(chuàng)建的 WifiConfiguration 對象的狀態(tài)笛求。系統(tǒng)不允許您修改或刪除由用戶或其他應用創(chuàng)建的 WifiConfiguration 對象。

在之前的版本中糕簿，如果應用利用帶有 disableAllOthers=true 設(shè)置的 enableNetwork() 強制設(shè)備連接特定 WLAN 網(wǎng)絡，設(shè)備將會斷開與移動數(shù)據(jù)網(wǎng)絡等其他網(wǎng)絡的連接狡孔。在此版本中懂诗，設(shè)備不再斷開與上述其他網(wǎng)絡的連接。如果您的應用的 targetSdkVersion 為 “20” 或更低苗膝，則會固定連接所選 WLAN 網(wǎng)絡殃恒。如果您的應用的 targetSdkVersion 為 “21” 或更高，請使用多網(wǎng)絡 API（如 openConnection()辱揭、bindSocket() 和新增的 bindProcessToNetwork() 方法）來確保通過所選網(wǎng)絡傳送網(wǎng)絡流量离唐。

(9)相機服務變更

在此版本中，相機服務中共享資源的訪問模式已從之前的“先到先得”訪問模式更改為高優(yōu)先級進程優(yōu)先的訪問模式问窃。對服務行為的變更包括：

根據(jù)客戶端應用進程的“優(yōu)先級”授予對相機子系統(tǒng)資源的訪問權(quán)亥鬓，包括打開和配置相機設(shè)備。帶有對用戶可見 Activity 或前臺 Activity 的應用進程一般會被授予較高的優(yōu)先級域庇，從而使相機資源的獲取和使用更加可靠嵌戈；

當高優(yōu)先級的應用嘗試使用相機時，系統(tǒng)可能會“驅(qū)逐”正在使用相機客戶端的低優(yōu)先級應用听皿。在已棄用的 Camera API 中熟呛，這會導致系統(tǒng)為被驅(qū)逐的客戶端調(diào)用 onError()。在 Camera2 API 中尉姨，這會導致系統(tǒng)為被驅(qū)逐的客戶端調(diào)用 onDisconnected()庵朝；

在配備相應相機硬件的設(shè)備上，不同的應用進程可同時獨立打開和使用不同的相機設(shè)備又厉。但現(xiàn)在九府，如果在多進程用例中同時訪問相機會造成任何打開的相機設(shè)備的性能或能力嚴重下降，相機服務會檢測到這種情況并禁止同時訪問覆致。即使并沒有其他應用直接嘗試訪問同一相機設(shè)備昔逗，此變更也可能導致低優(yōu)先級客戶端被“驅(qū)逐”。

更改當前用戶會導致之前用戶帳戶擁有的應用內(nèi)活動相機客戶端被驅(qū)逐篷朵。對相機的訪問僅限于訪問當前設(shè)備用戶擁有的用戶個人資料勾怒。舉例來說婆排，這意味著，當用戶切換到其他帳戶后笔链，“來賓”帳戶實際上無法讓使用相機子系統(tǒng)的進程保持運行狀態(tài)

三段只、ANDROID 7.0

1.行為變更

?Android 7.0 包括旨在延長設(shè)備電池壽命和減少 RAM 使用的系統(tǒng)行為變更。這些變更可能會影響您的應用訪問系統(tǒng)資源鉴扫，以及您的應用通過特定隱式 intent 與其他應用交互的方式赞枕。

1.低電耗模式

Android 6.0（API 級別 23）引入了低電耗模式，當用戶設(shè)備未插接電源坪创、處于靜止狀態(tài)且屏幕關(guān)閉時炕婶，該模式會推遲 CPU 和網(wǎng)絡活動，從而延長電池壽命莱预。而 Android 7.0 則通過在設(shè)備未插接電源且屏幕關(guān)閉狀態(tài)下柠掂、但不一定要處于靜止狀態(tài)（例如用戶外出時把手持式設(shè)備裝在口袋里）時應用部分 CPU 和網(wǎng)絡限制，進一步增強了低電耗模式依沮。

2. Project Svelte：后臺優(yōu)化

Android 7.0 移除了三項隱式廣播涯贞，以幫助優(yōu)化內(nèi)存使用和電量消耗。此項變更很有必要危喉，因為隱式廣播會在后臺頻繁啟動已注冊偵聽這些廣播的應用宋渔。刪除這些廣播可以顯著提升設(shè)備性能和用戶體驗。

移動設(shè)備會經(jīng)歷頻繁的連接變更辜限，例如在 WLAN 和移動數(shù)據(jù)之間切換時皇拣。目前，可以通過在應用清單中注冊一個接收器來偵聽隱式 CONNECTIVITY_ACTION 廣播薄嫡，讓應用能夠監(jiān)控這些變更审磁。由于很多應用會注冊接收此廣播，因此單次網(wǎng)絡切換即會導致所有應用被喚醒并同時處理此廣播岂座。

同理态蒂，在之前版本的 Android 中，應用可以注冊接收來自其他應用（例如相機）的隱式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 廣播费什。當用戶使用相機應用拍攝照片時钾恢，這些應用即會被喚醒以處理廣播。

為緩解這些問題鸳址，Android 7.0 應用了以下優(yōu)化措施：

面向 Android 7.0 開發(fā)的應用不會收到 CONNECTIVITY_ACTION 廣播瘩蚪，即使它們已有清單條目來請求接受這些事件的通知。在前臺運行的應用如果使用 BroadcastReceiver 請求接收通知稿黍，則仍可以在主線程中偵聽 CONNECTIVITY_CHANGE疹瘦。

應用無法發(fā)送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 廣播。此項優(yōu)化會影響所有應用巡球，而不僅僅是面向 Android 7.0 的應用言沐。

如果您的應用使用任何 intent邓嘹，您仍需要盡快移除它們的依賴關(guān)系，以正確適配 Android 7.0 設(shè)備险胰。Android 框架提供多個解決方案來緩解對這些隱式廣播的需求汹押。例如，JobScheduler API 提供了一個穩(wěn)健可靠的機制來安排滿足指定條件（例如連入無限流量網(wǎng)絡）時所執(zhí)行的網(wǎng)絡操作起便。您甚至可以使用 JobScheduler 來適應內(nèi)容提供程序變化棚贾。

如需了解有關(guān) Android N 中后臺優(yōu)化以及如何改寫應用的詳細信息，請參閱后臺優(yōu)化榆综。

3. ?權(quán)限更改

Android 7.0 做了一些權(quán)限更改妙痹，這些更改可能會影響您的應用。

系統(tǒng)權(quán)限更改

為了提高私有文件的安全性鼻疮，面向 Android 7.0 或更高版本的應用私有目錄被限制訪問　(0700)怯伊。此設(shè)置可防止私有文件的元數(shù)據(jù)泄漏，如它們的大小或存在性陋守。此權(quán)限更改有多重副作用：

私有文件的文件權(quán)限不應再由所有者放寬，為使用 MODE_WORLD_READABLE 和/或 MODE_WORLD_WRITEABLE 而進行的此類嘗試將觸發(fā) SecurityException蛋哭。

注：迄今為止冕碟，這種限制尚不能完全執(zhí)行趾断。應用仍可能使用原生 API 或 File API 來修改它們的私有目錄權(quán)限。但是中燥，我們強烈反對放寬私有目錄的權(quán)限。

傳遞軟件包網(wǎng)域外的 file:// URI 可能給接收器留下無法訪問的路徑塘偎。因此疗涉，嘗試傳遞 file:// URI 會觸發(fā) FileUriExposedException。分享私有文件內(nèi)容的推薦方法是使用 FileProvider吟秩。

DownloadManager 不再按文件名分享私人存儲的文件咱扣。

舊版應用在訪問 COLUMN_LOCAL_FILENAME 時可能出現(xiàn)無法訪問的路徑。

面向 Android 7.0 或更高版本的應用在嘗試訪問 COLUMN_LOCAL_FILENAME 時會觸發(fā) SecurityException涵防。

通過使用 DownloadManager.Request.setDestinationInExternalFilesDir() 或 DownloadManager.Request.setDestinationInExternalPublicDir() 將下載位置設(shè)置為公共位置的舊版應用仍可以訪問 COLUMN_LOCAL_FILENAME 中的路徑闹伪，但是我們強烈反對使用這種方法。對于由 DownloadManager 公開的文件壮池，首選的訪問方式是使用ContentResolver.openFileDescriptor()偏瓤。

4.在應用間共享文件

對于面向 Android 7.0 的應用，Android 框架執(zhí)行的 StrictMode API 政策禁止在您的應用外部公開 file:// URI椰憋。如果一項包含文件 URI 的 intent 離開您的應用厅克，則應用出現(xiàn)故障，并出現(xiàn) FileUriExposedException 異常橙依。

要在應用間共享文件证舟，您應發(fā)送一項 content:// URI硕旗，并授予 URI 臨時訪問權(quán)限。進行此授權(quán)的最簡單方式是使用 FileProvider 類褪储。如需了解有關(guān)權(quán)限和共享文件的詳細信息卵渴，請參閱共享文件。

5.屏幕縮放

Android 7.0 支持用戶設(shè)置顯示尺寸鲤竹，以放大或縮小屏幕上的所有元素浪读，從而提升設(shè)備對視力不佳用戶的可訪問性。用戶無法將屏幕縮放至低于最小屏幕寬度 sw320dp辛藻，該寬度是 Nexus 4 的寬度碘橘，也是常規(guī)中等大小手機的寬度。

6.無障礙改進

為提高平臺對于視力不佳或視力受損用戶的易用性吱肌，Android 7.0 做出了一些更改痘拆。這些更改一般并不要求更改您的應用代碼，不過您應仔細檢查并使用您的應用測試這些功能氮墨，以評估它們對用戶體驗的潛在影響.

7.NDK 應用鏈接至平臺庫

從 Android 7.0 開始纺蛆，系統(tǒng)將阻止應用動態(tài)鏈接非公開 NDK 庫，這種庫可能會導致您的應用崩潰规揪。此行為變更旨在為跨平臺更新和不同設(shè)備提供統(tǒng)一的應用體驗桥氏。即使您的代碼可能不會鏈接私有庫，但您的應用中的第三方靜態(tài)庫可能會這么做猛铅。因此字支，所有開發(fā)者都應進行相應檢查，確保他們的應用不會在運行 Android 7.0 的設(shè)備上崩潰奸忽。如果您的應用使用原生代碼堕伪，則只能使用公開 NDK API。

8.Android for Work

Android 7.0 包含一些針對面向 Android for Work 的應用的變更栗菜，包括對證書安裝欠雌、密碼重置、二級用戶管理疙筹、設(shè)備標識符訪問權(quán)限的變更桨昙。如果您是要針對 Android for Work 環(huán)境開發(fā)應用，則應仔細檢查這些變更并相應地修改您的應用

四腌歉、Android 8.0

1.行為變更

Android 8.0 除了提供諸多新特性和功能外蛙酪，還對系統(tǒng)和 API 行為做出了各種變更。本文重點介紹您應該了解并在開發(fā)應用時加以考慮的一些主要變更翘盖。

其中大部分變更會影響所有應用桂塞，而不論應用針對的是何種版本的 Android。不過馍驯，有幾項變更僅影響針對 Android 8.0 的應用阁危。為清楚起見玛痊，本頁面分為兩個部分：針對所有 API 級別的應用和針對 Android 8.0 的應用。

針對所有 API 級別的應用

這些行為變更適用于 在 Android 8.0 平臺上運行的 所有應用狂打，無論這些應用是針對哪個 API 級別構(gòu)建擂煞。所有開發(fā)者都應查看這些變更，并修改其應用以正確支持這些變更（如果適用）趴乡。

一. ?后臺執(zhí)行限制

Android 8.0 為提高電池續(xù)航時間而引入的變更之一是对省，當您的應用進入已緩存狀態(tài)時，如果沒有活動的組件晾捏，系統(tǒng)將解除應用具有的所有喚醒鎖蒿涎。

此外，為提高設(shè)備性能惦辛，系統(tǒng)會限制未在前臺運行的應用的某些行為劳秋。具體而言：

現(xiàn)在，在后臺運行的應用對后臺服務的訪問受到限制胖齐。

應用無法使用其清單注冊大部分隱式廣播（即玻淑，并非專門針對此應用的廣播）。

默認情況下呀伙，這些限制僅適用于針對 O 的應用补履。不過，用戶可以從 Settings 屏幕為任意應用啟用這些限制区匠，即使應用并不是以 O 為目標平臺干像。

1. Android 8.0 還對特定函數(shù)做出了以下變更：

如果針對 Android 8.0 的應用嘗試在不允許其創(chuàng)建后臺服務的情況下使用 startService() 函數(shù)帅腌，則該函數(shù)將引發(fā)一個 IllegalStateException驰弄。

新的 Context.startForegroundService() 函數(shù)將啟動一個前臺服務。現(xiàn)在速客，即使應用在后臺運行戚篙，系統(tǒng)也允許其調(diào)用 Context.startForegroundService()。不過溺职，應用必須在創(chuàng)建服務后的五秒內(nèi)調(diào)用該服務的 startForeground() 函數(shù)岔擂。

如需了解詳細信息，請參閱后臺執(zhí)行限制浪耘。

多個 Android 應用和服務可以同時運行乱灵。 例如，用戶可以在一個窗口中玩游戲七冲，同時在另一個窗口中瀏覽網(wǎng)頁痛倚，并使用第三個應用播放音樂。

同時運行的應用越多澜躺，對系統(tǒng)造成的負擔越大蝉稳。 如果還有應用或服務在后臺運行抒蚜，這會對系統(tǒng)造成更大負擔，進而可能導致用戶體驗下降耘戚；例如嗡髓，音樂應用可能會突然關(guān)閉。

(1)在很多情況下收津，您的應用都可以使用 JobScheduler 作業(yè)替換后臺服務饿这。 例如，CoolPhotoApp 需要檢查用戶是否已經(jīng)從朋友那里收到共享的照片朋截，即使該應用未在前臺運行蛹稍。

(2)在 Android 8.0 之前，創(chuàng)建前臺服務的方式通常是先創(chuàng)建一個后臺服務部服，然后將該服務推到前臺唆姐。

Android 8.0 有一項復雜功能；系統(tǒng)不允許后臺應用創(chuàng)建后臺服務廓八。 因此奉芦，Android 8.0 引入了一種全新的方法，即 Context.startForegroundService()剧蹂，以在前臺啟動新服務声功。

在系統(tǒng)創(chuàng)建服務后，應用有五秒的時間來調(diào)用該服務的 startForeground() 方法以顯示新服務的用戶可見通知宠叼。

如果應用在此時間限制內(nèi)未調(diào)用 startForeground()先巴，則系統(tǒng)將停止服務并聲明此應用為 ANR。

2.廣播限制

如果應用注冊為接收廣播冒冬，則在每次發(fā)送廣播時伸蚯，應用的接收器都會消耗資源。 如果多個應用注冊為接收基于系統(tǒng)事件的廣播简烤，這會引發(fā)問題剂邮；觸發(fā)廣播的系統(tǒng)事件會導致所有應用快速地連續(xù)消耗資源，從而降低用戶體驗横侦。

為了緩解這一問題挥萌，Android 7.0（API 級別 25）對廣播施加了一些限制，如后臺優(yōu)化中所述枉侧。

Android 8.0 讓這些限制更為嚴格引瀑。

針對 Android 8.0 的應用無法繼續(xù)在其清單中為隱式廣播注冊廣播接收器。 隱式廣播是一種不專門針對該應用的廣播榨馁。 例如憨栽，ACTION_PACKAGE_REPLACED 就是一種隱式廣播，因為它將發(fā)送到注冊的所有偵聽器，讓后者知道設(shè)備上的某些軟件包已被替換徒像。

不過黍特，ACTION_MY_PACKAGE_REPLACED 不是隱式廣播，因為不管已為該廣播注冊偵聽器的其他應用有多少锯蛀，它都會只發(fā)送到軟件包已被替換的應用灭衷。

應用可以繼續(xù)在它們的清單中注冊顯式廣播。

應用可以在運行時使用 Context.registerReceiver() 為任意廣播（不管是隱式還是顯式）注冊接收器旁涤。

需要簽名權(quán)限的廣播不受此限制所限翔曲，因為這些廣播只會發(fā)送到使用相同證書簽名的應用，而不是發(fā)送到設(shè)備上的所有應用劈愚。

在許多情況下瞳遍，之前注冊隱式廣播的應用使用 JobScheduler 作業(yè)可以獲得類似的功能。

例如菌羽，一款社交照片應用可能需要不時地執(zhí)行數(shù)據(jù)清理掠械，并且傾向于在設(shè)備連接到充電器時執(zhí)行此操作。

之前注祖，應用已經(jīng)在清單中為 ACTION_POWER_CONNECTED 注冊了一個接收器猾蒂；當應用接收到該廣播時，它會檢查清理是否必要是晨。 為了遷移到 Android 8.0肚菠，應用將該接收器從其清單中移除。

應用將清理作業(yè)安排在設(shè)備處于空閑狀態(tài)和充電時運行罩缴。

注：很多隱式廣播當前均已不受此限制所限蚊逢。 應用可以繼續(xù)在其清單中為這些廣播注冊接收器，不管應用針對哪個 API 級別箫章。 有關(guān)已豁免廣播的列表烙荷，請參閱隱式廣播例外。

3.遷移指南

默認情況下炉抒，這些更改僅影響針對 O 的應用奢讨。 不過稚叹，用戶可以從 Settings 屏幕為任意應用啟用這些限制焰薄，即使應用并不是以 O 為目標平臺。

您可能需要更新應用扒袖，使其符合新限制塞茅。

了解您的應用如何使用服務。 如果您的應用依賴某些在它處于空閑時于后臺運行的服務季率，您需要替換這些服務野瘦。

可能的解決方法包括：

如果處于后臺時您的應用需要創(chuàng)建一個前臺服務，請使用新的 NotificationManager.startServiceInForeground()

方法，而不是創(chuàng)建一個后臺服務鞭光，然后嘗試將其推到前臺吏廉。

如果服務容易被用戶注意，請將其設(shè)為前臺服務惰许。 例如席覆，播放音頻的服務始終應為前臺服務。

使用 NotificationManager.startServiceInForeground()

而不是 startService() 創(chuàng)建服務汹买。

尋找一種使用計劃作業(yè)實現(xiàn)服務功能的方式佩伤。 如果服務未在執(zhí)行容易立即被用戶注意到的操作，一般情況下晦毙，您都能夠使用計劃作業(yè)生巡。

發(fā)生網(wǎng)絡事件時，請使用 FCM 選擇性地喚醒您的應用见妒，而不是在后臺輪詢孤荣。

在應用正常處于前臺之前，請推遲后臺工作须揣。

檢查在您應用的清單中定義的廣播接收器垃环。 如果您的清單為顯式廣播聲明了接收器，您必須予以替換返敬。 可能的解決方法包括：

通過調(diào)用 Context.registerReceiver() 而不是在清單中聲明接收器的方式在運行時創(chuàng)建接收器遂庄。

使用計劃作業(yè)檢查條件是否會觸發(fā)隱式廣播。

4. Android 后臺位置限制

為降低功耗劲赠，無論應用的目標 SDK 版本為何涛目，Android 8.0 都會對后臺應用檢索用戶當前位置的頻率進行限制。

為節(jié)約電池電量凛澎、保持良好的用戶體驗和確保系統(tǒng)健康運行霹肝，在運行 Android 8.0 的設(shè)備上使用后臺應用時，降低了后臺應用接收位置更新的頻率塑煎。此行為變更會影響包括 Google Play 服務在內(nèi)的所有接收位置更新的應用沫换。

為降低功耗，無論應用的目標 SDK 版本為何最铁，Android 8.0 都會對后臺應用檢索用戶當前位置的頻率進行限制讯赏。

（1）系統(tǒng)會對前臺應用和后臺應用進行區(qū)分。應用滿足以下任一條件即視為前臺應用：

它具有可見的 Activity冷尉，無論 Activity 處于啟動還是暫停狀態(tài)漱挎。

它具有前臺服務。

另一個前臺應用通過綁定到應用的其中一個服務或使用應用的其中一個內(nèi)容提供程序與應用相連雀哨。

如果以上所有條件均不滿足磕谅，應用即視為后臺應用私爷。

（2）優(yōu)化應用的位置行為

考慮在您的應用接收位置更新不頻繁的情況下其后臺運行用例是否根本無法成功。如果屬于這種情況膊夹，您可以通過執(zhí)行下列操作之一提高位置更新的檢索頻率：

將您的應用轉(zhuǎn)至前臺衬浑。

使用應用中的某個前臺服務。激活此服務時放刨，您的應用必須在通知區(qū)顯示一個持續(xù)性的通知嚎卫。

使用 Geofencing API 的元素（例如 GeofencingApi 接口），這些元素針對最大限度減少耗電進行了專門優(yōu)化宏榕。

使用被動位置偵聽器拓诸，它可以在后臺應用加快位置請求頻率時提高位置更新的接收頻率。

注：如果您的應用需要訪問的位置歷史記錄包含時間頻繁更新麻昼，請使用批處理版本的 Fused Location Provider API 元素奠支，例如 FusedLocationProviderApi 接口。當您的應用運行于后臺時抚芦，此 API 會以高于非批處理版本 API 的頻率接收用戶的位置倍谜。但切記，您的應用批量接收更新的頻率仍僅為每小時幾次叉抡。

（3）受影響的 API

對后臺應用位置檢索行為的更改影響下列 API：

Fused Location Provider (FLP)

如果您的應用運行在后臺尔崔，位置系統(tǒng)服務只會根據(jù) Android 8.0 行為變更中定義的間隔，按每小時幾次的頻率為其計算新位置褥民。即使您的應用請求進行更頻繁的位置更新季春，也仍是如此。

如果您的應用運行在前臺消返，與 Android 7.1.1（API 級別 25）相比载弄，在位置采樣率上不會有任何變化。

Geofencing

后臺應用可以高于接收 Fused Location Provider 更新的頻率接收地理圍欄轉(zhuǎn)換事件撵颊。

地理圍欄事件的平均響應時間是大約每兩分鐘一次宇攻。

GNSS Measurements 和 GNSS Navigation Messages

當您的應用位于后臺時，注冊用于接收 GnssMeasurement 和 GnssNavigationMessage 輸出的回調(diào)會停止執(zhí)行倡勇。

Location Manager

提供給后臺應用的位置更新只會根據(jù) Android 8.0 行為變更中定義的間隔逞刷，按每小時幾次的頻率提供。

注：如果運行您的應用的設(shè)備安裝了 Google Play 服務妻熊，強烈建議您改用 Fused Location Provider (FLP)夸浅。

WLAN 管理器

startScan() 方法對后臺應用執(zhí)行完整掃描的頻率僅為每小時數(shù)次。如果不久之后后臺應用再次調(diào)用此方法固耘， WifiManager 類將提供上次掃描所緩存的結(jié)果题篷。

五词身、Android 9.0

行為變更

Android 9 利用人工智能技術(shù)厅目，讓手機可以為您提供更多幫助。現(xiàn)在，手機變得更智能损敷、更快葫笼，并且還可以隨著您的使用進行調(diào)整

1. ?利用 Wi-Fi RTT 進行室內(nèi)定位

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

在運行 Android 9 且具有硬件支持的設(shè)備上路星，應用可以使用 RTT API 來測量與附近支持 RTT 的 Wi-Fi 接入點 (AP) 的距離。 設(shè)備必須已啟用位置服務并開啟 Wi-Fi 掃描（在 Settings > Location 下）诱桂，同時您的應用必須具有 ACCESS_FINE_LOCATION 權(quán)限洋丐。

設(shè)備無需連接到接入點即可使用 RTT。 為了保護隱私挥等，只有手機可以確定與接入點的距離友绝；接入點無此信息。

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

通過這種精確性辞槐，您可以打造新的體驗掷漱，例如樓內(nèi)導航、基于精細位置的服務榄檬，如無歧義語音控制（例如卜范，“打開這盞燈”），以及基于位置的信息（如 “此產(chǎn)品是否有特別優(yōu)惠鹿榜？”）先朦。

2. 顯示屏缺口支持

顯示各種屏幕缺口尺寸的開發(fā)者選項界面

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

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

全新的窗口布局屬性 layoutInDisplayCutoutMode 讓您的應用可以為設(shè)備屏幕缺口周圍的內(nèi)容進行布局枝恋。 您可以將此屬性設(shè)為下列值之一：

LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT

LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES

LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER

可以按以下方法在任何運行 Android 9 的設(shè)備或模擬器上模擬屏幕缺口：

啟用開發(fā)者選項创倔。

在 Developer options 屏幕中，向下滾動至 Drawing 部分并選擇 Simulate a display with a cutout焚碌。

選擇屏幕缺口的大小畦攘。

注：我們建議您通過使用運行 Android 9 的設(shè)備或模擬器測試屏幕缺口周圍的內(nèi)容顯示

3. 通知

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

將回復另存為草稿：當用戶無意中關(guān)閉一個短信通知時十电，您的應用可以檢索系統(tǒng)發(fā)送的 EXTRA_REMOTE_INPUT_DRAFT知押。 您可以使用此 extra 預填充應用中的文本字段叹螟，以便用戶可以完成他們的回復。

確定對話是否為群組對話台盯。您可以使用 setGroupConversation() 以明確確定對話是否為群組對話罢绽。

為 Intent 設(shè)置語義操作：setSemanticAction() 函數(shù)允許您為操作提供語義含義，如“標記為已讀”静盅、“刪除”和“回復”等良价。

SmartReply：Android 9 支持在您的短信應用中提供相同的建議回復。 使用 RemoteInput.setChoices() 為用戶提供一組標準回復蒿叠。

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

在運行 Android 9 的設(shè)備上明垢，您可以通過兩個或更多物理攝像頭來同時訪問多個視頻流。] 在配備雙前置攝像頭或雙后置攝像頭的設(shè)備上市咽，您可以創(chuàng)建只配備單攝像頭的設(shè)備所不可能實現(xiàn)的創(chuàng)新功能袖外，例如無縫縮放、背景虛化和立體成像魂务。 通過該 API粘姜，您還可以調(diào)用邏輯或融合的攝像頭視頻流，該視頻流可在兩個或更多攝像頭之間自動切換。

攝像頭方面的其他改進還包括附加會話參數(shù)和 Surface 共享蔑歌，前者有助于降低首次拍照期間的延遲雳刺，而后者則讓攝像頭客戶端能夠處理各種用例，而無需停止并啟動攝像頭視頻流涌穆。 我們還針對基于顯示屏的 flash 支持和 OIS 時間戳訪問新增了一些 API朱监，用以實現(xiàn)應用級的圖像穩(wěn)定化和特效奋隶。

在 Android 9 中搬味，多攝像頭 API支持單色攝像頭悦析，適用于具有 FULL 或 LIMITED 功能的設(shè)備。 單色輸出通過 YUV_420_888 格式實現(xiàn)道媚，Y 為灰度羡宙，U (Cb) 為 128，V (Cr) 為 128僧凰。

在受支持的設(shè)備上怀大，Android 9 還支持外置 USB/UVC 攝像頭。

5. 動畫

Android 9 引入了 AnimatedImageDrawable 類淫奔，用于繪制和顯示 GIF 和 WebP 動畫圖像

6.HDR VP9 視頻鳞溉、HEIF 圖像壓縮和 Media API

Android 9 新增了對 High Dynamic Range (HDR) VP9 Profile 2 的內(nèi)置支持于颖，因此冒晰，現(xiàn)在您可以在支持 HDR 的設(shè)備上為用戶提供來自 YouTube竟块、Play Movies 和其他來源的采用 HDR 的影片秫逝。

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

從 Android 9 開始金蜀，JobScheduler 可以使用運營商提供的網(wǎng)絡狀態(tài)信號來改善與網(wǎng)絡有關(guān)的作業(yè)處理刷后。

作業(yè)可以聲明其預估的數(shù)據(jù)大小、信號預提取渊抄，并指定具體的網(wǎng)絡要求尝胆。 JobScheduler 然后根據(jù)網(wǎng)絡狀態(tài)管理工作。 例如护桦，當網(wǎng)絡顯示擁塞時含衔，JobScheduler 可能會延遲較大的網(wǎng)絡請求。 如果使用的是不按流量計費的網(wǎng)絡二庵，則 JobScheduler 可運行預提取作業(yè)以提升用戶體驗（例如預提取標題）贪染。

添加作業(yè)時，確保使用 setEstimatedNetworkBytes()催享、setPrefetch() 和 setRequiredNetwork()（如果適用）杭隙，以幫助 JobScheduler 正確處理工作。 在執(zhí)行作業(yè)時因妙，請確保使用 JobParameters.getNetwork() 返回的 Network 對象痰憎。 否則，您將隱式使用設(shè)備的默認網(wǎng)絡攀涵，其可能不符合您的要求铣耘，從而導致意外的流量消耗。

8.自動填充框架

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

9.安全增強功能

Android 9 引入了若干安全功能鳄乏，詳見以下各節(jié)摘要說明：

Android Protected Confirmation

運行 Android 9 或更高版本的受支持設(shè)備賦予您使用 Android Protected Confirmation 的能力跷车。 使用該工作流時，您的應用會向用戶顯示提示橱野，請他們批準一個簡短的聲明朽缴。 應用可以通過這個聲明再次確認，用戶確實想完成一項敏感事務水援，例如付款密强。

如果用戶接受該聲明，Android 密鑰庫會收到并存儲由密鑰哈希消息身份驗證代碼 (HMAC) 保護的加密簽名蜗元。 Android 密鑰庫確認消息的有效性之后或渤，您的應用可以使用在可信執(zhí)行環(huán)境 (TEE) 下通過 trustedConfirmationRequired 生成的密鑰來簽署用戶已接受的消息。 該簽名具有很高的可信度奕扣，它表示用戶已看過聲明并同意其內(nèi)容薪鹦。

注意：Android Protected Confirmation 不會為用戶提供安全信息通道。 應用無法承擔 Android 平臺所提供機密性保證之外的任何其他保證惯豆。 尤其是池磁，請勿使用該工作流顯示您通常不會顯示在用戶設(shè)備上的敏感信息。

如需獲得 Android Protected Confirmation 新增支持方面的指導楷兽，請參閱 Android Protected Confirmation 指南地熄。

統(tǒng)一生物識別身份驗證對話框

在 Android 9 中，系統(tǒng)代表您的應用提供生物識別身份驗證對話框芯杀。 該功能可創(chuàng)建標準化的對話框外觀端考、風格和位置，讓用戶更加確信揭厚，他們在使用可信的生物識別憑據(jù)檢查程序進行身份驗證却特。

如果您的應用使用 FingerprintManager 向用戶顯示指紋身份驗證對話框，請切換到改用 BiometricPrompt棋弥。 BiometricPrompt 依賴系統(tǒng)來顯示身份驗證對話框核偿。 它還會改變其行為，以適應用戶所選擇的生物識別身份驗證類型顽染。

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

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

硬件安全性模塊

運行 Android 9 或更高版本的受支持設(shè)備可擁有 StrongBox Keymaster捅儒，它是位于硬件安全性模塊中的 Keymaster HAL 的一種實現(xiàn)。 該模塊包含以下組成部分：

自己的 CPU。

安全存儲空間巧还。

真實隨機數(shù)生成器鞭莽。

可抵御軟件包篡改和未經(jīng)授權(quán)線刷應用的附加機制。

檢查存儲在 StrongBox Keymaster 中的密鑰時麸祷，系統(tǒng)會通過可信執(zhí)行環(huán)境 (TEE) 證實密鑰的完整性澎怒。

如需了解有關(guān)使用 Strongbox Keymaster 的更多信息，請參閱硬件安全性模塊阶牍。

10.無障礙功能

Android 9 引入了針對無障礙功能框架的增強功能喷面，讓您能夠更輕松地為應用的用戶提供更好的體驗。

11.DEX 文件的 ART 提前轉(zhuǎn)換

在運行 Android 9 或更高版本的設(shè)備上走孽，Android 運行時 (ART) 提前編譯器通過將應用軟件包中的 DEX 文件轉(zhuǎn)換為更緊湊的表示形式惧辈，進一步優(yōu)化了壓縮的 Dalvik Executable 格式 (DEX) 文件。 此項變更可讓您的應用啟動更快并消耗更少的磁盤空間和內(nèi)存磕瓷。

這種改進特別有利于磁盤 I/O 速度較慢的低端設(shè)備

12.設(shè)備端系統(tǒng)跟蹤

Android 9 允許您通過設(shè)備記錄系統(tǒng)跟蹤記錄盒齿，然后與您的開發(fā)團隊分享這些記錄的報告。 該報告支持多種格式生宛，包括 HTML县昂。

通過收集這些跟蹤記錄肮柜，您可以獲取與應用進程和線程相關(guān)的計時數(shù)據(jù)陷舅，并查看其他類型的具有全局意義的設(shè)備狀態(tài)。

注：您無需設(shè)置您的代碼來記錄跟蹤記錄审洞，但這樣做可以幫助您查看應用代碼的哪些部分可能會導致線程掛起或界面卡頓莱睁。

Android 9.0行為變更：所有應用

1. 后臺對傳感器的訪問受限

Android 9 限制后臺應用訪問用戶輸入和傳感器數(shù)據(jù)的能力。 如果您的應用在運行 Android 9 設(shè)備的后臺運行芒澜，系統(tǒng)將對您的應用采取以下限制：

您的應用不能訪問麥克風或攝像頭仰剿。

使用連續(xù)報告模式的傳感器（例如加速度計和陀螺儀）不會接收事件。

使用變化或一次性報告模式的傳感器不會接收事件痴晦。

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

2.限制訪問通話記錄

Android 9 引入 CALL_LOG 權(quán)限組并將 READ_CALL_LOG誊酌、WRITE_CALL_LOG 和 PROCESS_OUTGOING_CALLS 權(quán)限移入該組部凑。 在之前的 Android 版本中，這些權(quán)限位于 PHONE 權(quán)限組碧浊。

對于需要訪問通話敏感信息（如讀取通話記錄和識別電話號碼）的應用涂邀，該 CALL_LOG 權(quán)限組為用戶提供了更好的控制和可見性辫塌。

如果您的應用需要訪問通話記錄或者需要處理去電椅邓，則您必須向 CALL_LOG 權(quán)限組明確請求這些權(quán)限合瓢。 否則會發(fā)生 SecurityException夭拌。

注：因為這些權(quán)限已變更組并在運行時授予即硼，用戶可以拒絕您的應用訪問通話記錄信息。 在這種情況下祟昭，您的應用應該能夠妥善處理無法訪問信息的狀況咧栗。

如果您的應用已經(jīng)遵循運行時權(quán)限最佳做法，則可以處理權(quán)限組的變更

3.限制訪問電話號碼

在未首先獲得 READ_CALL_LOG 權(quán)限的情況下衣洁，除了應用的用例需要的其他權(quán)限之外嫂便，運行于 Android 9 上的應用無法讀取電話號碼或手機狀態(tài)。

與來電和去電關(guān)聯(lián)的電話號碼可在手機狀態(tài)廣播（比如來電和去電的手機狀態(tài)廣播）中看到闸与，并可通過 PhoneStateListener 類訪問毙替。 但是，如果沒有 READ_CALL_LOG 權(quán)限践樱，則 PHONE_STATE_CHANGED 廣播和 PhoneStateListener 提供的電話號碼字段為空厂画。

要從手機狀態(tài)中讀取電話號碼，請根據(jù)您的用例更新應用以請求必要的權(quán)限：

要通過 PHONE_STATE Intent 操作讀取電話號碼拷邢，同時需要 READ_CALL_LOG 權(quán)限和 READ_PHONE_STATE 權(quán)限袱院。

要從 onCallStateChanged() 中讀取電話號碼，只需要 READ_CALL_LOG 權(quán)限瞭稼。 不需要 READ_PHONE_STATE 權(quán)限忽洛。

4.對使用非 SDK 接口的限制

為幫助確保應用穩(wěn)定性和兼容性，此平臺對某些非 SDK 函數(shù)和字段的使用進行了限制环肘；無論您是直接訪問這些函數(shù)和字段欲虚，

還是通過反射或 JNI 訪問，這些限制均適用悔雹。 在 Android 9 中复哆，

您的應用可以繼續(xù)訪問這些受限的接口；該平臺通過 toast 和日志條目提醒您注意這些接口腌零。 如果您的應用顯示這樣的 toast梯找，

則必須尋求受限接口之外的其他實現(xiàn)策略。 如果您認為沒有可行的替代策略益涧，您可以提交錯誤以請求重新考慮此限制

5.現(xiàn)在強制執(zhí)行 FLAG_ACTIVITY_NEW_TASK 要求

在 Android 9 中锈锤，您不能從非 Activity 環(huán)境中啟動 Activity，除非您傳遞 Intent 標志 FLAG_ACTIVITY_NEW_TASK闲询。 如果您嘗試在不傳遞此標志的情況下啟動 Activity久免，則該 Activity 不會啟動，系統(tǒng)會在日志中輸出一則消息嘹裂。

6.屏幕旋轉(zhuǎn)變更

從 Android 9 開始妄壶，對縱向旋轉(zhuǎn)模式做出了重大變更。 在 Android 8.0（API 級別 26）中寄狼，用戶可以使用 Quicksettings 圖塊或 Display 設(shè)置在自動屏幕旋轉(zhuǎn)和縱向旋轉(zhuǎn)模式之間切換丁寄。 縱向模式已重命名為旋轉(zhuǎn)鎖定氨淌，它會在自動屏幕旋轉(zhuǎn)關(guān)閉時啟用。 自動屏幕旋轉(zhuǎn)模式?jīng)]有任何變更伊磺。

當設(shè)備處于旋轉(zhuǎn)鎖定模式時盛正，用戶可將其屏幕鎖定到頂層可見 Activity 所支持的任何旋轉(zhuǎn)。 Activity 不應假定它將始終以縱向呈現(xiàn)屑埋。 如果頂層 Activity 可在自動屏幕旋轉(zhuǎn)模式下以多種旋轉(zhuǎn)呈現(xiàn)豪筝，則應在旋轉(zhuǎn)鎖定模式下提供相同的選項，根據(jù) Activity 的 screenOrientation 設(shè)置摘能，允許存在一些例外情況（見下表）续崖。

請求特定屏幕方向（例如，screenOrientation=landscape）的 Activity 會忽略用戶鎖定首選項团搞，并且行為與 Android 8.0 中的行為相同严望。

可在 Android Manifest 中，或以編程方式通過 setRequestedOrientation() 在 Activity 級別設(shè)置屏幕方向首選項逻恐。

旋轉(zhuǎn)鎖定模式通過設(shè)置 WindowManager 在處理 Activity 旋轉(zhuǎn)時使用的用戶旋轉(zhuǎn)首選項來發(fā)揮作用像吻。 用戶旋轉(zhuǎn)首選項可能在下列情況下發(fā)生變更。 請注意复隆，恢復設(shè)備的自然旋轉(zhuǎn)存在偏差拨匆，對于外形與手機類似的設(shè)備通常設(shè)置為縱向：

當用戶接受旋轉(zhuǎn)建議時，旋轉(zhuǎn)首選項變?yōu)榻ㄗh方向挽拂。

當用戶切換到強制縱向應用（包括鎖定屏幕或啟動器）時惭每，旋轉(zhuǎn)首選項變?yōu)榭v向。

下表總結(jié)了常見屏幕方向的旋轉(zhuǎn)行為：

屏幕方向?? ?行為

未指定轻局、user?? ?在自動屏幕旋轉(zhuǎn)和旋轉(zhuǎn)鎖定下洪鸭，Activity 可以縱向或橫向（以及顛倒縱向或橫向）呈現(xiàn)。 預期同時支持縱向和橫向布局仑扑。

userLandscape?? ?在自動屏幕旋轉(zhuǎn)和旋轉(zhuǎn)鎖定下，Activity 可以橫向或顛倒橫向呈現(xiàn)置鼻。 預期只支持橫向布局镇饮。

userPortrait?? ?在自動屏幕旋轉(zhuǎn)和旋轉(zhuǎn)鎖定下，Activity 可以縱向或顛倒縱向呈現(xiàn)箕母。 預期只支持縱向布局储藐。

fullUser?? ?在自動屏幕旋轉(zhuǎn)和旋轉(zhuǎn)鎖定下，Activity 可以縱向或橫向（以及顛倒縱向或橫向）呈現(xiàn)嘶是。 預期同時支持縱向和橫向布局钙勃。

旋轉(zhuǎn)鎖定用戶將可選擇鎖定到顛倒縱向，通常為 180o聂喇。

sensor辖源、fullSensor蔚携、sensorPortrait、sensorLandscape?? ?忽略旋轉(zhuǎn)鎖定模式首選項克饶，視為自動屏幕旋轉(zhuǎn)已啟用酝蜒。 請僅在例外情況下并經(jīng)過仔細的用

7.Apache HTTP 客戶端棄用影響采用非標準 ClassLoader 的應用

在 Android 6.0 中，我們?nèi)∠藢?Apache HTTP 客戶端的支持矾湃。

此變更對大多數(shù)不以 Android 9 或更高版本為目標的應用沒有任何影響亡脑。 不過，此變更會影響使用非標準 ClassLoader 結(jié)構(gòu)的某些應用邀跃，即使這些應用不以 Android 9 或更高版本為目標平臺霉咨。

如果應用使用顯式委托到系統(tǒng) ClassLoader 的非標準 ClassLoader，則應用會受到影響拍屑。

?在 org.apache.http.* 中查找類時躯护，這些應用需要委托給應用 ClassLoader。 如果它們委托給系統(tǒng) ClassLoader丽涩，則應用在 Android 9 或更高版本上將失敗并顯示 NoClassDefFoundError棺滞，因為系統(tǒng) ClassLoader 不再識別這些類。 為防止將來出現(xiàn)類似問題矢渊，一般情況下继准，應用應通過應用 ClassLoader 加載類，而不是直接訪問系統(tǒng) ClassLoader矮男。

?8.枚舉相機

在 Android 9 設(shè)備上運行的應用可以通過調(diào)用 getCameraIdList() 發(fā)現(xiàn)每個可用的攝像頭移必。 應用不應假定設(shè)備只有一個后置攝像頭或只有一個前置攝像頭。

例如毡鉴，如果您的應用有一個用來切換前置和后置攝像頭的按鈕崔泵，則設(shè)備可能有多個前置或后置攝像頭可供選擇。 您應瀏覽一下攝像頭列表猪瞬，檢查每個攝像頭的特征憎瘸，然后決定向用戶顯示哪些攝像頭。

Android Q(Android 10)

行為變更：所有應用

Android Q 平臺包含一些行為變更陈瘦，這些變更可能會影響您的應用幌甘。以下行為變更將影響在 Android Q 上運行的所有應用，無論其采用哪種?targetSdkVersion?都不例外痊项。您應該測試您的應用锅风，然后根據(jù)需要進行更改以適當?shù)刂С诌@些變更（如果適用）。

非 SDK 接口限制

為了幫助確保應用穩(wěn)定性和兼容性鞍泉，Android 平臺開始限制您的應用可在 Android 9（API 級別 28）中使用哪些非 SDK 接口皱埠。Android Q 包含更新后的受限非 SDK 接口列表（基于與 Android 開發(fā)者之間的協(xié)作以及最新的內(nèi)部測試）。我們的目標是在限制使用非 SDK 接口之前確保有可用的公開替代方案咖驮。

如果您不打算以 Android Q 為目標平臺边器，那么其中一些變更可能不會立即對您產(chǎn)生影響训枢。雖然您目前可以使用灰名單中的一些非 SDK 接口（取決于您應用的目標 API 級別），但如果您使用任何非 SDK 方法或字段饰抒，則應用無法運行的風險終歸較高肮砾。

如果您不確定自己的應用是否使用了非 SDK 接口，則可以測試該應用進行確認袋坑。如果您的應用依賴于非 SDK 接口仗处，則應該開始計劃遷移到 SDK 替代方案。不過枣宫，我們知道某些應用具有使用非 SDK 接口的有效用例婆誓。如果您無法為應用中的某項功能找到使用非 SDK 接口的替代方案，則應該請求新的公共 API也颤。

要了解詳情洋幻，請參閱非 SDK 接口在 Android Q 中的受限情況出現(xiàn)變化以及對非 SDK 接口的限制。

手勢導航（這個國內(nèi)廠商早都有了）

從 Android Q 開始翅娶，用戶可以在設(shè)備中啟用手勢導航文留。如果用戶啟用手勢導航，則會影響設(shè)備上的所有應用竭沫，無論應用是否以 Android Q 為目標平臺燥翅，都是如此。例如蜕提，如果用戶從屏幕邊緣向內(nèi)滑動森书，系統(tǒng)會將該手勢解讀為“返回”導航，除非應用針對屏幕的相應部分明確替換該手勢谎势。

為了確保您的應用與手勢導航兼容凛膏，您需要將應用內(nèi)容擴展到屏幕邊緣，并適當?shù)靥幚泶嬖跊_突的手勢脏榆。有關(guān)信息猖毫，請參閱手勢導航文檔。

NDK

Android Q 包含以下 NDK 方面的變更姐霍。

共享對象不得包含文本重定位

Android 6.0（API 級別 23）已禁止在共享對象中使用文本重定位鄙麦。代碼必須按原樣加載，且不得修改镊折。此變更可以縮短應用的加載時間并提高安全性。

在 Android Q 測試版 1 和 2 中介衔，SELinux 對以 Android 8.0（API 級別 26）及更高版本為目標平臺的應用強制執(zhí)行此限制恨胚。從 Android Q 測試版 3 開始，將對以 Android Q（API 級別 29）及更高版本為目標平臺的應用強制執(zhí)行此限制炎咖。如果這些應用繼續(xù)使用包含文本重定位的共享對象赃泡，則出現(xiàn)故障的風險較高寒波。

安全性

Android Q 包含以下安全性方面的變更。

移除了應用主目錄的執(zhí)行權(quán)限

以 Android Q 為目標平臺的不受信任的應用無法再針對應用主目錄中的文件調(diào)用?exec()升熊。這種從可寫應用的主目錄執(zhí)行文件的行為違反了 W^X俄烁。應用應該僅加載嵌入到應用的 APK 文件中的二進制代碼。

此外级野，以 Android Q 為目標平臺的應用無法針對已執(zhí)行?dlopen()?的文件中的可執(zhí)行代碼進行內(nèi)存中修改页屠。這包括含有文本重定位的所有共享對象 (.so) 文件。

WLAN 直連廣播

在 Android Q 中蓖柔，以下與?WLAN 直連相關(guān)的廣播不再具有粘性辰企。

WIFI_P2P_CONNECTION_CHANGED_ACTION

WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

如果您的應用依賴于在注冊時接收這些廣播（因為其之前一直具有粘性），請在初始化時使用適當?shù)?get()?方法獲取信息况鸣。

WLAN 感知功能

Android Q 擴大了支持范圍牢贸，現(xiàn)在可以使用 WLAN 感知數(shù)據(jù)路徑輕松創(chuàng)建 TCP/UDP 套接字。要創(chuàng)建連接到?ServerSocket?的 TCP/UDP 套接字镐捧，客戶端設(shè)備需要知道服務器的 IPv6 地址和端口潜索。這在之前需要通過頻外方式進行通信（例如使用 BT 或 WLAN 感知第 2 層消息傳遞），或者使用其他協(xié)議（例如 mDNS）通過頻內(nèi)方式發(fā)現(xiàn)懂酱。而借助 Android Q竹习，可以將此類消息作為網(wǎng)絡設(shè)置的一部分進行傳遞。

服務器可以執(zhí)行以下任一操作：

初始化?ServerSocket?并設(shè)置或獲取要使用的端口玩焰。

將端口信息指定為 WLAN 感知網(wǎng)絡請求的一部分由驹。

————————————————

版權(quán)聲明：本文為CSDN博主「冉航--小蝦米」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議昔园，轉(zhuǎn)載請附上原文出處鏈接及本聲明蔓榄。

原文鏈接：https://blog.csdn.net/gaoxiaoweiandy/java/article/details/83216001