兩個官方連結：
1. 官方推薦的相容測試方式
2. Android8.0行為變更說明
Android 8.0 行為變更包括兩個部分：針對所有 API 級別的應用和針對 Android 8.0 的應用（8.0專屬部分大部分用不到，所以沒專門列出），當然，全域性API級改變在專案中的使用場景也很少。

針對所有 API 級別的應用

一、後臺執行限制

1. 解釋說明
   
   • 為提高裝置效能，系統會限制未在前臺執行的應用的某些行為。具體而言：
     現在，在後臺執行的應用對後臺服務的訪問受到限制。
     應用無法使用其清單註冊大部分隱式廣播（即，並非專門針對此應用的廣播）。
   • 如果針對 Android 8.0 的應用嘗試在不允許其建立後臺服務的情況下使用 startService() 函式，則該函式將引發一個 IllegalStateException。
   • 新的 Context.startForegroundService() 函式將啟動一個前臺服務。現在，即使應用在後臺執行，系統也允許其呼叫 Context.startForegroundService()。不過，應用必須在建立服務後的五秒內呼叫該服務的 startForeground() 函式。

2. 檢視應用中可能的潛在問題及解決方案

   1. 看一下manifest清單裡面有沒有註冊系統的廣播接收者，用來監聽系統廣播處理業務的場景？

      • 官方說明裡，這些廣播android O上失效了，如果有，需要重新規劃業務處理。

      • 專案程式碼中使用瞭如下程式碼：開啟啟動推送的服務

        <receiver
            android:name="com.gieseckedevrient.android.cpclientdemoapp.PushBroadCastReceiver"
            android:process=":push" >
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED" />
            </intent-filter>
        </receiver>
        

      • 這一塊，系統改了沒有別的辦法，看看我們接入的推送是否支援各廠商系統級的推送（如果支援，改為這種方式，不支援，不用改動）

   2. 8.0中不允許執行startService會報異常，保險起見，加try-catch(沒理解，哪裡不能呼叫startService)
   3. 8.0中Context.startForegroundService()，在建立5s內必須執行startForeground() 函式，否則無效。

二、Android 後臺位置限制

1. 解釋說明

   現在一般都是用百度或者高德地圖定位，不會手動寫這些定位的邏輯，保持jar包更新就行，有沒有後臺定位的場景，如果有，測試是否符合預期結果，不符合的話更新lib包，再測試。（前臺定位不算：進應用定位、進業務定位）
   

2. 檢視應用中可能的潛在問題及解決方案

   見上一條
   

三、應用快捷鍵

1. 解釋說明

   應用中未用到，pass，用到再研究
   

2. 檢視應用中可能的潛在問題及解決方案

   應用中未用到，pass，用到再研究
   

四、語言區域和國際化

1. 解釋說明
   

   • 在 Android 8.0 中，以下函式使用 Locale.getDefault(Category.DISPLAY) 來代替 Locale.getDefault()
     

   不過不用擔心，官方有做相容處理：當為 Locale 引數指定的 displayScript 值不可用時，Locale.getDisplayScript(Locale) 同樣回退到 Locale.getDefault()。

2. 另外的幾個api可能會異常或者資料與之前版本不一致，請按照官方文件來做8.0的適配。

3. 檢視應用中可能的潛在問題及解決方案

   未用到。
   

五、提醒視窗

1. 解釋說明
   如果應用使用 SYSTEM_ALERT_WINDOW 許可權並且嘗試使用以下視窗型別之一來在其他應用和系統視窗上方顯示提醒視窗：
   TYPE_PHONE
   TYPE_PRIORITY_PHONE
   TYPE_SYSTEM_ALERT
   TYPE_SYSTEM_OVERLAY
   TYPE_SYSTEM_ERROR
   …那麼，這些視窗將始終顯示在使用 TYPE_APPLICATION_OVERLAY 視窗型別的視窗下方。如果應用針對的是 Android 8.0，則應用會使用 TYPE_APPLICATION_OVERLAY 視窗型別來顯示提醒視窗。

2. 檢視應用中可能的潛在問題及解決方案

   顯示方式改變，專案未用到，pass，用到再研究
   

六、輸入和導航

1. 解釋說明

   • 元素焦點行為做出以下變更：
     
     • 現在，如果您沒有為 View 物件（前景或背景圖片）定義任何焦點狀態顏色，框架會為 View 設定預設的焦點突出顯示顏色。此焦點突出顯示標誌是基於操作元件主題背景的漣漪圖片。
     • 如果您不希望 View 物件在接收焦點時使用此預設突出顯示標誌，請在包含 View 的佈局 XML 檔案中將 android:defaultFocusHighlightEnabled 屬性設定為 false，或者將 false 傳遞至應用介面邏輯中的 setDefaultFocusHighlightEnabled()。
     • 要測試鍵盤輸入對介面元素焦點有何影響，您可以啟用 Drawing > Show layout bounds 開發者選項。在 Android 8.0 中，此選項在當前具有焦點的元素上顯示一個“X”圖示。

   • 新增鍵盤導航鍵區

     • 具體例子（焦點切換順序：button1->button2->editText1）：

       <RelativeLayout ...>
           <Button
               android:id="@+id/button1"
               android:layout_alignParentTop="true"
               android:layout_alignParentRight="true"
               android:nextFocusForward="@+id/editText1"
               ... />
           <Button
               android:id="@+id/button2"
               android:layout_below="@id/button1"
               android:nextFocusForward="@+id/button1"
               ... />
           <EditText
               android:id="@id/editText1"
               android:layout_alignBottom="@+id/button2"
               android:layout_toLeftOf="@id/button2"
               android:nextFocusForward="@+id/button2"
               ...  />
           ...
       

2. 檢視應用中可能的潛在問題及解決方案

   專案中未用到，用到參考官方說明。

七、網頁表單自動填充

1. 解釋說明

   Android8.0內建支援網頁表單自動填充，以前的部分api失效。

   • WebSettings
     getSaveFormData() 函式現在返回 false。之前，此函式返回 true。
     呼叫 setSaveFormData() 不再有任何效果。
   • WebViewDatabase
     呼叫 clearFormData() 不再有任何效果。
     hasFormData() 函式現在返回 false。之前，當表單包含資料時，此函式返回 true。

2. 檢視應用中可能的潛在問題及解決方案

   未用到，如果用到也沒關係（刪除與否自動填充功能都可以正常使用）

八、無障礙功能

1. 解釋說明

   在Android8.0中，能識別應用的 TextView 物件內部的所有 ClickableSpan 例項。（更智慧了？）

2. 檢視應用中可能的潛在問題及解決方案

   我們參考需求，按照UI切圖開發就可以，無障礙功能提示這類東西也許我們用不著的。

九、網路連線和 HTTP(S) 連線

1. 解釋說明

   1. 無正文的 OPTIONS 請求具有 Content-Length: 0 標頭。之前，這些請求沒有 Content-Length 標頭。
   2. HttpURLConnection 在包含斜線的主機或頒發機構名稱後面附加一條斜線，使包含空路徑的網址規範化。例如，它將 http://example.com 轉化為 http://example.com/。（早都不用他了）
   3. 通過 ProxySelector.setDefault() 設定的自定義代理選擇器僅針對所請求的網址（架構、主機和埠）。因此，僅可根據這些值選擇代理。傳遞至自定義代理選擇器的網址不包含所請求的網址的路徑、查詢引數或片段。
   4. URI 不能包含空白標籤。
   5. Android 8.0 在實現 HttpsURLConnection 時不會執行不安全的 TLS/SSL 協議版本回退。
      等等。。

   主要是一些api的引數等變更，攜帶引數修改，對於現有應用沒有多大影響

2. 檢視應用中可能的潛在問題及解決方案

   目前的專案中無需修改
   

十、藍芽

1. 解釋說明
   Android 8.0 對 ScanRecord.getBytes() 函式檢索的資料長度做出以下變更

   1. getBytes() 函式對於所接收的位元組數不作任何假定。因此，應用不應受所返回的任何最小或最大位元組數的影響。相反，應用應當計算所返回陣列的長度。（api改了）
   2. 相容藍芽 5 的裝置返回的資料長度可能會超出之前最大約 60 個位元組的限制。
   3. 如果遠端裝置未提供掃描響應，則也可能返回少於 60 個位元組的資料。

2. 檢視應用中可能的潛在問題及解決方案

   應用中未直接使用，使用的三方的藍芽key，如果有更新替換即可。 
   

十一、無縫連線

1. 解釋說明
   Android 8.0 對 WLAN 設定進行了多項改進，這樣可以更輕鬆地選擇能夠提供最佳使用者體驗的 WLAN 網路。具體變更包括：

   1. 穩定性和可靠性改進。
   2. 更加直觀的介面。
   3. 一個合併的 WLAN 首選項選單。
   4. 當附近存在優質的已儲存網路時在相容裝置上自動啟用 WLAN。

2. 檢視應用中可能的潛在問題及解決方案

   在編碼上沒有體現，只是在系統層有網路的優化
   

十二、安全性

1. 解釋說明

   1. 不再支援 SSLv3（歷史悠久，而且漏洞多）
   2. 應用的 WebView 物件將在多程序模式下執行。網頁內容在獨立的程序中處理，此程序與包含應用的程序相隔離，以提高安全性。
   3. 無法再假定 APK 駐留在名稱以 -1 或 -2 結尾的目錄中。應用應使用 sourceDir 獲取此目錄，而不能直接使用目錄格式。
   4. Android 8.0 將使用安全計算 (SECCOMP) 過濾器來過濾所有應用。允許的系統呼叫列表僅限於通過 bionic 公開的系統呼叫。此外，還提供了其他幾個後向相容的系統呼叫，但我們不建議使用這些系統呼叫。
   5. 在與未正確實現 TLS 協議版本協商的伺服器建立 HTTPS 連線時，HttpsURLConnection 不再嘗試回退到之前的 TLS 協議版本並重試的權宜方法。

2. 檢視應用中可能的潛在問題及解決方案

   目前來說，如果有上面第三點的話，需要修改，其他無需處理。
   

十三、隱私性

1. 解釋說明
   安卓改變了識別符號的處理方式：

   1. 對於在 OTA 之前安裝到某個版本 Android 8.0（API 級別 26）的應用，除非在 OTA 後解除安裝並重新安裝，否則 ANDROID_ID 的值將保持不變。要在 OTA 後在解除安裝期間保留值，開發者可以使用金鑰/值備份關聯舊值和新值。（也就是說，Android8.0中Android_Id演算法和之前不一樣，需要相容處理）
   2. 對於安裝在執行 Android 8.0 的裝置上的應用，ANDROID_ID 的值現在將根據應用簽署金鑰和使用者確定作用域。應用簽署金鑰、使用者和裝置的每個組合都具有唯一的 ANDROID_ID 值。因此，在相同裝置上執行但具有不同簽署金鑰的應用將不會再看到相同的 Android ID（即使對於同一使用者來說，也是如此）。 （每個手機獲取的Android_Id都不會一樣了）
   3. 只要簽署金鑰相同（並且應用未在 OTA 之前安裝到某個版本的 O），ANDROID_ID 的值在軟體包解除安裝或重新安裝時就不會發生變化。（安卓8.0以後才安卓的應用，只要應用的簽名祕鑰不變不會影響Android_Id，下次獲取的值還是一樣的）
   4. 即使系統更新導致軟體包簽署金鑰發生變化，ANDROID_ID 的值也不會變化。
   5. 要藉助一個簡單的標準系統實現應用獲利，請使用廣告 ID。廣告 ID 是 Google Play 服務針對廣告服務提供的唯一 ID，此 ID 可由使用者重置。

2. 檢視應用中可能的潛在問題及解決方案

   跟應用可能有關係的就是Android_Id，8.0之前的Android_Id和和8.0之後的Android_Id不一致了，需要做相容處理。

十四、記錄未捕獲的異常

1. 解釋說明

   如果某個應用安裝的 Thread.UncaughtExceptionHandler 未移交給預設的 Thread.UncaughtExceptionHandler，則當出現未捕獲的異常時，系統不會終止應用。從 Android 8.0 開始，在此情況下系統將記錄異常堆疊跟蹤情況；在之前的平臺版本中，系統不會記錄異常堆疊跟蹤情況。
   我們建議，自定義 Thread.UncaughtExceptionHandler 實現始終移交給預設處理程式處理；遵循此建議的應用不受 Android 8.0 此項變更的影響。

2. 檢視應用中可能的潛在問題及解決方案

   產品中是預設將異常轉交給預設處理程式處理，該改動沒有影響。
   

十五、聯絡人提供程式使用情況統計方法的變更

1. 解釋說明
   在之前版本的 Android 中，聯絡人提供程式元件允許開發者獲取每個聯絡人的使用情況資料。此使用情況資料揭示了與某個聯絡人相關聯的每個電子郵件地址和每個電話號碼的資訊，包括與該聯絡人聯絡的次數以及上次聯絡該聯絡人的時間。請求 READ_CONTACTS 許可權的應用可以讀取此資料。
   如果應用請求 READ_CONTACTS 許可權，它們仍可以讀取此資料。從 Android 8.0 開始，使用情況資料查詢會返回近似值，而不是精確值。不過，Android 系統內部仍然會保留精確值，因此，此變更不會影響 auto-complete API。
   此行為變更會影響以下查詢引數：
   TIMES_CONTACTED
   TIMES_USED
   LAST_TIME_CONTACTED
   LAST_TIME_USED

2. 檢視應用中可能的潛在問題及解決方案

   這個改變只會影響到獲取聯絡人的詳細資訊的情況，只是值並不精確了，還是能返回資料。沒用到的話就忽略~
   

十六、集合的處理

1. 解釋說明
   現在，AbstractCollection.removeAll() 和 AbstractCollection.retainAll() 始終引發 NullPointerException；之前，當集合為空時不會引發 NullPointerException。此項變更使行為符合文件要求。

2. 檢視應用中可能的潛在問題及解決方案

   檢視專案中是否使用了AbstractCollection.removeAll() 和 AbstractCollection.retainAll()了，需要做容錯，判空處理。
   

十七、企業版

1. 解釋說明
   Android 8.0 更改了企業應用（包括裝置規範控制器 (DPC)）的某些 API 和功能的行為。這些變更包括：

   1. 新增多種行為，幫助應用支援完全託管裝置中的工作資料。
   2. 變更系統更新處理、應用驗證和身份驗證方式，以提高裝置和系統的完整性。
   3. 改進使用者在配置、通知、“最近使用的應用”螢幕和 Always on VPN 方面的體驗。

2. 檢視應用中可能的潛在問題及解決方案

   使用不到企業版，忽略咯。