前言
本文主要針對(duì)Android O的適配，文中大部分內(nèi)容將來自官網(wǎng)，本文只是總結(jié)提取出適配需要的注意點(diǎn)，關(guān)于Android O的一些新Feature不會(huì)提及。總的來說，Android O基本是純后臺(tái)應(yīng)用的噩夢(mèng)，此類應(yīng)用的適配多數(shù)要面臨重構(gòu)、大改的窘境，而對(duì)于前臺(tái)應(yīng)用適配則相對(duì)輕松。
適配要點(diǎn)
總體而言Android O的適配主要注意以下三點(diǎn)：
1、后臺(tái)服務(wù)訪問受限，Android O不允許后臺(tái)應(yīng)用創(chuàng)建后臺(tái)服務(wù)
2、諸多隱式廣播被砍，清單文件靜態(tài)注冊(cè)無效，只能動(dòng)態(tài)注冊(cè)
3、運(yùn)行時(shí)權(quán)限授權(quán)機(jī)制修改，只授權(quán)申請(qǐng)的權(quán)限，而非整個(gè)權(quán)限組的權(quán)限
后臺(tái)服務(wù)訪問受限
前文提及，Android O不允許后臺(tái)應(yīng)用創(chuàng)建后臺(tái)服務(wù)，所以先來看看Android系統(tǒng)是如何區(qū)分前臺(tái)與后臺(tái)應(yīng)用的。
1、前、后臺(tái)應(yīng)用區(qū)分
系統(tǒng)可以區(qū)分 前臺(tái) 和 后臺(tái) 應(yīng)用。 （用于服務(wù)限制目的的后臺(tái)定義與內(nèi)存管理使用的定義不同；一個(gè)應(yīng)用按照內(nèi)存管理的定義可能處于后臺(tái)，但按照Android 8上能夠啟動(dòng)服務(wù)的定義又處于前臺(tái)。）如果滿足以下任意條件，應(yīng)用將被視為處于前臺(tái)：
1、具有可見 Activity（不管該 Activity 已啟動(dòng)還是已暫停）
2、具有前臺(tái)服務(wù)
3、另一個(gè)前臺(tái)應(yīng)用已關(guān)聯(lián)到該應(yīng)用（不管是通過綁定到其中一個(gè)服務(wù)，還是通過使用其中一個(gè)內(nèi)容提供程序）。 例如，如果另一個(gè)應(yīng)用綁定到該應(yīng)用的服務(wù)，那么該應(yīng)用處于前臺(tái)：
IME
壁紙服務(wù)
通知偵聽器
語音或文本服務(wù)
如果以上條件均不滿足，應(yīng)用將被視為處于后臺(tái)。
以上內(nèi)容摘自官網(wǎng)，首次閱讀你可能不太理解“一個(gè)應(yīng)用按照內(nèi)存管理的定義可能處于后臺(tái)，但按照能夠啟動(dòng)服務(wù)的定義又處于前臺(tái)”，即此處的后臺(tái)定義與后臺(tái)進(jìn)程定義稍有出入。
內(nèi)存管理中對(duì)后臺(tái)進(jìn)程的定義如下：
包含目前對(duì)用戶不可見的 Activity 的進(jìn)程（已調(diào)用 Activity 的 onStop()方法。這些進(jìn)程對(duì)用戶體驗(yàn)沒有直接影響，系統(tǒng)可能隨時(shí)終止它們，以回收內(nèi)存供前臺(tái)進(jìn)程、可見進(jìn)程或服務(wù)進(jìn)程使用。
Android 8上能夠啟動(dòng)服務(wù)定義中的后臺(tái)：
即不滿足上文所述三點(diǎn)中的任何一點(diǎn)應(yīng)用被視為后臺(tái)應(yīng)用，留意第三點(diǎn)中的“不管是通過綁定到其中一個(gè)服務(wù)，還是通過使用其中一個(gè)內(nèi)容提供程序”，在內(nèi)存管理中并未關(guān)聯(lián)ContentProvider來分類進(jìn)程。
假設(shè)我們有一個(gè)后臺(tái)進(jìn)程，此時(shí)有個(gè)前臺(tái)應(yīng)用關(guān)聯(lián)訪問了我們ContentProvider，那么此時(shí)，我們的后臺(tái)進(jìn)程將不會(huì)被系統(tǒng)判定為后臺(tái)應(yīng)用，而是前臺(tái)應(yīng)用。這就是“一個(gè)應(yīng)用按照內(nèi)存管理的定義可能處于后臺(tái)，但按照能夠啟動(dòng)服務(wù)的定義又處于前臺(tái)”的一個(gè)具體場(chǎng)景。
結(jié)論：一個(gè)后臺(tái)進(jìn)程，在Android O上不一定被判定為后臺(tái)應(yīng)用。
2、后臺(tái)服務(wù)限制
在了解Android O如何區(qū)分前、后臺(tái)應(yīng)用后，接下來看看如果后臺(tái)應(yīng)用強(qiáng)行創(chuàng)建后臺(tái)服務(wù)會(huì)如何。
如果針對(duì) Android O 的應(yīng)用嘗試在不允許其創(chuàng)建后臺(tái)服務(wù)的情況下使用 startService() 函數(shù)，則該函數(shù)將引發(fā)一個(gè) IllegalStateException。
新的 Context.startForegroundService() 函數(shù)將啟動(dòng)一個(gè)前臺(tái)服務(wù)。現(xiàn)在，即使應(yīng)用在后臺(tái)運(yùn)行，系統(tǒng)也允許其調(diào)用 Context.startForegroundService()。不過，應(yīng)用必須在創(chuàng)建服務(wù)后的五秒內(nèi)調(diào)用該服務(wù)的 startForeground() 函數(shù)。
當(dāng)應(yīng)用處于前臺(tái)時(shí)，應(yīng)用可以自由創(chuàng)建和運(yùn)行前臺(tái)服務(wù)與后臺(tái)服務(wù)。 進(jìn)入后臺(tái)時(shí)，在一個(gè)持續(xù)數(shù)分鐘的時(shí)間窗內(nèi)，應(yīng)用仍可以創(chuàng)建和使用服務(wù)。
在該時(shí)間窗結(jié)束后，應(yīng)用將被視為處于 空閑 狀態(tài)。 此時(shí)，系統(tǒng)將停止應(yīng)用的后臺(tái)服務(wù)，就像應(yīng)用已經(jīng)調(diào)用服務(wù)的Service.stopSelf()方法。
在這些情況下，后臺(tái)應(yīng)用將被置于一個(gè)臨時(shí)白名單中并持續(xù)數(shù)分鐘。 位于白名單中時(shí)，應(yīng)用可以無限制地啟動(dòng)服務(wù)，并且其后臺(tái)服務(wù)也可以運(yùn)行。
處理對(duì)用戶可見的任務(wù)時(shí)，應(yīng)用將被置于白名單中，例如：
1、處理一條高優(yōu)先級(jí)Firebase 云消息傳遞 (FCM)消息。
2、接收廣播，例如短信/彩信消息
3、從通知執(zhí)行PendingIntent
在很多情況下，您的應(yīng)用都可以使用 JobScheduler作業(yè)替換后臺(tái)服務(wù)。 例如，CoolPhotoApp 需要檢查用戶是否已經(jīng)從朋友那里收到共享的照片，即使該應(yīng)用未在前臺(tái)運(yùn)行。
使用JobScheduler需要實(shí)現(xiàn)一個(gè)JobService，那么問題來了，JobService也是一個(gè)Service為何它能幸免于難呢？
這就與JobService的工作機(jī)制相關(guān)，簡單而言，系統(tǒng)進(jìn)程的JobSchedulerService會(huì)綁定到我們自己實(shí)現(xiàn)的JobService，根據(jù)上文前臺(tái)應(yīng)用的判別，此時(shí)我們的應(yīng)用會(huì)被判定為前臺(tái)應(yīng)用。
隱式廣播限制
Android O 的應(yīng)用無法繼續(xù)在其清單中為隱式廣播注冊(cè)廣播接收器。 隱式廣播是一種不專門針對(duì)該應(yīng)用的廣播。 例如，ACTION_PACKAGE_REPLACED 就是一種隱式廣播，因?yàn)樗鼘l(fā)送到注冊(cè)的所有偵聽器，讓后者知道設(shè)備上的某些軟件包已被替換。
不過，ACTION_MY_PACKAGE_REPLACED 不是隱式廣播，因?yàn)椴还芤褳樵搹V播注冊(cè)偵聽器的其他應(yīng)用有多少，它都會(huì)只發(fā)送到軟件包已被替換的應(yīng)用。
應(yīng)用可以繼續(xù)在它們的清單中注冊(cè)顯式廣播。
應(yīng)用可以在運(yùn)行時(shí)使用 Context.registerReceiver() 為任意廣播（不管是隱式還是顯式）注冊(cè)接收器。
需要簽名權(quán)限的廣播不受此限制所限，因?yàn)檫@些廣播只會(huì)發(fā)送到使用相同證書簽名的應(yīng)用，而不是發(fā)送到設(shè)備上的所有應(yīng)用。
在許多情況下，之前注冊(cè)隱式廣播的應(yīng)用使用 JobScheduler 作業(yè)可以獲得類似的功能。
注：很多隱式廣播當(dāng)前均已不受此限制所限。 應(yīng)用可以繼續(xù)在其清單中為這些廣播注冊(cè)接收器，不管應(yīng)用針對(duì)哪個(gè) API 級(jí)別。 有關(guān)已豁免廣播的列表，請(qǐng)參閱隱式廣播例外。
注意：
如果目標(biāo)平臺(tái)targetSdk設(shè)置為26，靜態(tài)注冊(cè)的Receiver將收不到隱式廣播，即使這個(gè)隱式廣播是應(yīng)用自身發(fā)出的。
如果非要通過靜態(tài)注冊(cè)的Receiver來接受廣播，則需要為Receiver注冊(cè)簽名權(quán)限，發(fā)送隱式廣播需要使用帶權(quán)限的API，如下圖所示：
運(yùn)行時(shí)權(quán)限修改
在 Android O 之前，如果應(yīng)用在運(yùn)行時(shí)請(qǐng)求權(quán)限并且被授予該權(quán)限，系統(tǒng)會(huì)錯(cuò)誤地將屬于同一權(quán)限組并且在清單中注冊(cè)的其他權(quán)限也一起授予應(yīng)用。
對(duì)于針對(duì) Android O 的應(yīng)用，此行為已被糾正。系統(tǒng)只會(huì)授予應(yīng)用明確請(qǐng)求的權(quán)限。然而，一旦用戶為應(yīng)用授予某個(gè)權(quán)限，則所有后續(xù)對(duì)該權(quán)限組中權(quán)限的請(qǐng)求都將被自動(dòng)批準(zhǔn)。
例如，假設(shè)某個(gè)應(yīng)用在其清單中列出 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE。應(yīng)用請(qǐng)求 READ_EXTERNAL_STORAGE，并且用戶授予了該權(quán)限。如果該應(yīng)用針對(duì)的是 API 級(jí)別 24 或更低級(jí)別，系統(tǒng)還會(huì)同時(shí)授予 WRITE_EXTERNAL_STORAGE，因?yàn)樵摍?quán)限也屬于同一 STORAGE 權(quán)限組并且也在清單中注冊(cè)過。如果該應(yīng)用針對(duì)的是 Android O，則系統(tǒng)此時(shí)僅會(huì)授予 READ_EXTERNAL_STORAGE；不過，如果該應(yīng)用后來又請(qǐng)求 WRITE_EXTERNAL_STORAGE，則系統(tǒng)會(huì)立即授予該權(quán)限，而不會(huì)提示用戶。
關(guān)于如何優(yōu)雅的進(jìn)行權(quán)限的適配，請(qǐng)參考：
Android8.0運(yùn)行時(shí)權(quán)限策略變化和適配方案
內(nèi)容變更通知
Android 8.0 更改了 ContentResolver.notifyChange()和 registerContentObserver(Uri, boolean, ContentObserver)在針對(duì) Android 8.0 的應(yīng)用中的行為方式。
現(xiàn)在，這些 API 需要在所有 URI 中為頒發(fā)機(jī)構(gòu)定義一個(gè)有效的 ContentProvider
。使用相關(guān)權(quán)限定義一個(gè)有效的 ContentProvider可幫助您的應(yīng)用防范來自惡意應(yīng)用的內(nèi)容變更，并防止將可能的私密數(shù)據(jù)泄露給惡意應(yīng)用。
單看官方文檔介紹，這條是看的云里霧里，經(jīng)過實(shí)踐踩坑后，總結(jié)如下：
1.registerContentObserver(Uri, boolean, ContentObserver)與ContentResolver.notifyChange()，在Android O上，若程序需要監(jiān)聽或者通知的provider申明了權(quán)限，而執(zhí)行程序并沒有相應(yīng)權(quán)限，則會(huì)拋出異常，導(dǎo)致程序崩潰。之前的版本，若沒有權(quán)限不會(huì)拋出異常，只是會(huì)注冊(cè)或者通知失敗。
以通話記錄與聯(lián)系人為例，若示例代碼執(zhí)行時(shí)，程序不具備如下權(quán)限：
android.permission.READ_CALL_LOG
android.permission.READ_CONTACTS
則會(huì)拋出權(quán)限異常，導(dǎo)致程序崩潰。
- 如果你要監(jiān)聽或者通知的provider不存在，同樣會(huì)拋出異常，導(dǎo)致程序崩潰。
應(yīng)用快捷鍵
Android 8.0 對(duì)應(yīng)用快捷方式做出了以下變更：
com.android.launcher.action.INSTALL_SHORTCUT
廣播不再會(huì)對(duì)您的應(yīng)用有任何影響，因?yàn)樗F(xiàn)在是私有的隱式廣播。相反，您應(yīng)使用 ShortcutManager類中的 requestPinShortcut函數(shù)創(chuàng)建應(yīng)用快捷方式。
現(xiàn)在，ACTION_CREATE_SHORTCUTIntent 可以創(chuàng)建可使用 ShortcutManager
類進(jìn)行管理的應(yīng)用快捷方式。此 Intent 還可以創(chuàng)建不與 ShortcutManager
交互的舊版啟動(dòng)器快捷方式。在以前，此 Intent 只能創(chuàng)建舊版啟動(dòng)器快捷方式。
現(xiàn)在，使用 requestPinShortcut()創(chuàng)建的快捷方式和在處理 ACTION_CREATE_SHORTCUT
Intent 的操作組件中創(chuàng)建的快捷方式均已轉(zhuǎn)換為功能齊全的應(yīng)用快捷方式。因此，應(yīng)用現(xiàn)在可以使用 ShortcutManager中的函數(shù)來更新這些快捷方式。
舊版快捷方式仍然保留了它們?cè)谂f版 Android 中的功能，但您必須在應(yīng)用中手動(dòng)將它們轉(zhuǎn)換成應(yīng)用快捷方式。
如需了解有關(guān)應(yīng)用快捷方式變更的更多信息，請(qǐng)參閱固定快捷方式和微件預(yù)覽功能指南。
小結(jié)：
在Android O上，之前舊的創(chuàng)建快捷方式的方法將失效。
在8.0上，AMS直接不會(huì)轉(zhuǎn)發(fā)隱式廣播：
com.android.launcher.action.INSTALL_SHORTCUT
即使將targetSdkVersion設(shè)置為26以下，創(chuàng)建快捷方式必須使用新的API。
7.1上舊的創(chuàng)建快捷方式的方法依舊有效，但是所以針對(duì)非Launcher開發(fā)者而言，只需要使用新的API來創(chuàng)建快捷方式即可，對(duì)于Launcher開發(fā)者，要做的工作就蠻多的了，需要適配ShortcutManger及相關(guān)UI。
PS:本文只是針對(duì)主要適配點(diǎn)進(jìn)行闡述，除了上述三點(diǎn)，Android O還有一些其他小細(xì)節(jié)需要適配如：
1、Android 后臺(tái)位置限制（定位APP需要考慮）
2、提醒窗口（使用了SYSTEM_ALERT_WINDOW的應(yīng)用需要適配）
3、記錄未捕獲的異常
4、隱私性（Android ID生成機(jī)制改變，一般需要統(tǒng)計(jì)SDK適配）
......
具體細(xì)節(jié)請(qǐng)參考官方文檔Android O行為變更
