掌握 Android O 行為變更指南，參與互動贏收藏版 Android 公仔！

Android O 除了提供諸多新特性和功能外，還對系統和 API 行為做出了各種變更。本文重點介紹您應該瞭解並在開發應用時加以考慮的一些主要變更。

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

針對所有 API 級別的應用

這些行為變更適用於在 Android O 平臺上執行的所有應用，無論這些應用是針對哪個 API 級別構建。所有開發者都應檢視這些變更，並修改其應用以正確支援這些變更（如果適用）。

網路連線和 HTTP(S) 連線

Android O 對網路連線和 HTTP(S) 連線行為做出了以下變更：

1. 無正文的 OPTIONS 請求具有 Content-Length: 0 標頭。之前，這些請求沒有 Content-Length 標頭。

2. HttpURLConnection 在包含斜線的主機或頒發機構名稱後面附加一條斜線，使包含空路徑的網址規範化。例如，它將 http://example.com 轉化為 http://example.com/ 。

3. 通過 ProxySelector.setDefault ( ) 設定的自定義代理選擇器僅針對所請求的網址（架構、主機和埠）。因此，僅可根據這些值選擇代理。傳遞至自定義代理選擇器的網址不包含所請求的網址的路徑、查詢引數或片段。

4. URI 不能包含空白標籤。

5. 之前，平臺支援一種權宜方法，即允許主機名稱中包含空白標籤，但這是對 URI 的非法使用。此權宜方法只是為了確保與舊版 libcore 相容。開發者如果對 API 使用不當，將會看到一條 ADB 訊息：“URI example..com 的主機名包含空白標籤。此格式不正確，將不被未來的 Android 版本所接受。”Android O 廢除了此權宜方法；系統對格式錯誤的 URI 會返回 null。

6. Android O 在實現 HttpsURLConnection 時不會執行不安全的 TLS/SSL 協議版本回退。

7. 對隧道 HTTP(S) 連線處理進行了如下變更：

• 在通過連線建立隧道 HTTP(S) 連線時，系統會在 Host 行中正確放置埠號 (:443) 並將此資訊傳送至中間伺服器。之前，埠號僅出現在 CONNECT 行中

• 系統不再將隧道連線請求中的 user-agent 和 proxy-authorization 標頭髮送至代理伺服器。

• 在建立隧道時，系統不再將隧道 Http(s)URLConnection 中的 proxy-authorization 標頭髮送至代理。相反，由系統生成 proxy-authorization 標頭，在代理響應初始請求傳送 HTTP 407 後將其傳送至此代理。

• 同樣地，系統不再將 user-agent 標頭由隧道連線請求複製到建立隧道的代理請求。相反，庫為此請求生成 user-agent 標頭。

如果之前執行的 connect ( ) 函式失敗，send( java.net.DatagramPacket ) 函式將會引發 SocketException:

•  如果存在內部錯誤，DatagramSocket.connect ( ) 會引發 pendingSocketException。對於 Android O 之前的版本，即使 send ( ) 呼叫成功，後續的 recv ( ) 呼叫也會引發 SocketException。為確保一致性，現在這兩個呼叫均會引發 SocketException。

在回退到 TCP Echo 協議之前，InetAddress.isReachable ( ) 會嘗試執行 ICMP:

• 對於某些遮蔽埠 7 (TCP Echo) 的主機（例如 google.com），如果它們接受 ICMP Echo 協議，現在也許能夠訪問它們。

• 對於確實無法訪問的主機，此項變更意味著呼叫需要兩倍的時間才能返回結果。

集合的處理

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

記錄未捕獲的異常

如果某個應用安裝的 Thread.UncaughtExceptionHandler 未移交給預設的 Thread.UncaughtExceptionHandler，則當出現未捕獲的異常時，系統不會終止應用。從 Android O 開始，在此情況下系統將記錄異常堆疊跟蹤情況；在之前的平臺版本中，系統不會記錄異常堆疊跟蹤情況。

我們建議，自定義 Thread.UncaughtExceptionHandler 實現始終移交給預設處理程式處理；遵循此建議的應用不受 Android O 此項變更的影響。

輸入和導航

隨著 Android 應用出現在 Chrome 作業系統和平板電腦等其他大尺寸裝置上，我們看到，使用者在 Android 應用中又重新開始使用鍵盤導航。在 Android O 中，我們又再次使用鍵盤作為導航輸入裝置，從而為基於箭頭鍵和 Tab 鍵的導航構建了一種更可靠並且可預測的模型。

尤其要指出的是，我們對元素焦點行為做出以下變更：

• 現在，如果您沒有為 View 物件（前景或背景圖片）定義任何焦點狀態顏色，框架會為 View 設定預設的焦點突出顯示顏色。此焦點突出顯示標誌是基於操作元件主題背景的漣漪圖片。

• 如果您不希望 View 物件在接收焦點時使用此預設突出顯示標誌，請在包含 View 的佈局 XML 檔案中將 android:defaultFocusHighlightEnabled 屬性設定為 false ，或者將 false 傳遞至應用介面邏輯中的 setDefaultFocusHighlightEnabled ( ) 。

• 要測試鍵盤輸入對介面元素焦點有何影響，您可以啟用 Drawing > Show layout bounds 開發者選項。在 Android O 中，此選項在當前具有焦點的元素上顯示一個 “X” 圖示。

另外，Android O 中的所有工具欄元素自動組成鍵盤導航鍵區，使用者可以更加輕鬆地導航進入和離開每個作為一個整體的工具欄。

如需詳細瞭解如何在您的應用中改善對鍵盤導航的支援，請閱讀以下連結中的支援鍵盤導航指南。

（https://developer.android.google.cn/training/keyboard-input/navigation.html）

安全性

Android O 包含以下與安全性有關的變更：

• 此平臺不再支援 SSLv3

• Android O 將使用安全計算 (SECCOMP) 過濾器來過濾所有應用。允許的系統呼叫列表僅限於通過 bionic 公開的系統呼叫。此外，還提供了其他幾個後向相容的系統呼叫，但我們不建議使用這些系統呼叫。
  

• 在與未正確實現 TLS 協議版本協商的伺服器建立 HTTPS 連線時，HttpsURLConnection 不再嘗試回退到之前的 TLS 協議版本並重試的權宜方法。

• 現在，您的應用的 WebView 物件將在多程式模式下執行。網頁內容在獨立的程式中處理，此程式與包含應用的程式相隔離，以提高安全性。

• 您無法再假定 APK 駐留在名稱以 -1 或 -2 結尾的目錄中。應用應使用 sourceDir 獲取此目錄，而不能直接使用目錄格式。

有關提升應用安全性的其他準則，請參閱以下連結中的面向 Android 開發者的安全性。

（https://developer.android.google.cn/topic/security/index.html）

後臺執行限制

Android O 為提高電池續航時間而引入的變更之一是，當您的應用進入已快取狀態時，如果沒有活動的元件，系統將解除應用具有的所有喚醒鎖。

此外，為提高裝置效能，系統會限制未在前臺執行的應用的某些行為。具體而言：

• 現在，在後臺執行的應用對後臺服務的訪問受到限制。

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

Android O 還對特定函式做出了以下變更：

• 如果針對 Android O 的應用嘗試在不允許其建立後臺服務的情況下使用 startService ( ) 函式，則該函式將引發一個 IllegalStateException。

• 新的 Context.startForegroundService ( ) 函式將啟動一個前臺服務。現在，即使應用在後臺執行，系統也允許其呼叫 Context.startForegroundService ( ) 。不過，應用必須在建立服務後的五秒內呼叫該服務的 startForeground ( ) 函式。

如需瞭解詳細資訊，請參閱以下連結中的後臺執行限制。

（https://developer.android.google.cn/preview/features/background.html）

隱私性

Android O 對平臺做出了以下與隱私性有關的變更：

1. 現在，平臺改變了識別符號的處理方式:

• 對於在 OTA 之前安裝到某個版本 Android O（API 級別 26）的應用，除非在 OTA 後解除安裝並重新安裝，否則 ANDROID_ID 的值將保持不變。要在 OTA 後在解除安裝期間保留值，開發者可以使用金鑰/值備份關聯舊值和新值。

• 對於安裝在執行 Android O 的裝置上的應用，ANDROID_ID 的值現在將根據應用簽署金鑰和使用者確定作用域。應用簽署金鑰、使用者和裝置的每個組合都具有唯一的 ANDROID_ID 值。因此，在相同裝置上執行但具有不同簽署金鑰的應用將不會再看到相同的 Android ID（即使對於同一使用者來說，也是如此）。

• 只要簽署金鑰相同（並且應用未在 OTA 之前安裝到某個版本的 O），ANDROID_ID 的值在軟體包解除安裝或重新安裝時就不會發生變化。

• 即使系統更新導致軟體包簽署金鑰發生變化，ANDROID_ID 的值也不會變化。

• 要藉助一個簡單的標準系統實現應用獲利，請使用廣告 ID。廣告 ID 是 Google Play 服務針對廣告服務提供的唯一 ID，此 ID 可由使用者重置。

查詢 net.hostname 系統屬性返回的結果為空。

針對 Android O 的應用

這些行為變更專門應用於針對 O 平臺或更高平臺版本的應用。針對 Android O 或更高平臺版本進行編譯，或將 targetSdkVersion 設為 Android O 或更高版本的應用開發者必須修改其應用以正確支援這些行為（如果適用）。

內容變更通知

Android O 更改了 ContentResolver.notifyChange ( ) 和 registerContentObserver ( Uri, boolean, ContentObserver ) 在針對 Android O 的應用中的行為方式。

現在，這些 API 需要在所有 URI 中為頒發機構定義一個有效的 ContentProvider。使用相關許可權定義一個有效的 ContentProvider 可幫助您的應用防範來自惡意應用的內容變更，並防止將可能的私密資料洩露給惡意應用。

檢視焦點

可點選的 View 物件現在預設也可以成為焦點。如果您希望 View 物件可點選但不可成為焦點，請在包含 View 的佈局 XML 檔案中將 android:focusable 屬性設定為 false，或者將 false 傳遞至應用介面邏輯中的 setFocusable ( ) 。

許可權

在 Android O 之前，如果應用在執行時請求許可權並且被授予該許可權，系統會錯誤地將屬於同一許可權組並且在清單中註冊的其他許可權也一起授予應用。

對於針對 Android O 的應用，此行為已被糾正。系統只會授予應用明確請求的許可權。然而，一旦使用者為應用授予某個許可權，則所有後續對該許可權組中許可權的請求都將被自動批准。

例如: 

假設某個應用在其清單中列出 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE 。應用請求 READ_EXTERNAL_STORAGE ，並且使用者授予了該許可權。

如果該應用針對的是 API 級別 24 或更低階別，系統還會同時授予 WRITE_EXTERNAL_STORAGE ，因為該許可權也屬於同一 STORAGE 許可權組並且也在清單中註冊過。

如果該應用針對的是 Android O，則系統此時僅會授予 READ_EXTERNAL_STORAGE ；不過，如果該應用後來又請求 WRITE_EXTERNAL_STORAGE ，則系統會立即授予該許可權，而不會提示使用者。

集合的處理

在 Android O 中，Collections.sort ( ) 是在 List.sort ( )  的基礎上實現的。在 Android 7.x（API 級別 24 和 25）中，則恰恰相反。在過去，List.sort ( ) 的預設實現會呼叫 Collections.sort ( ) 。

此項變更使 Collections.sort ( ) 可以利用優化的 List.sort ( ) 實現，但具有以下限制：

• List.sort ( ) 的實現不能呼叫 Collections.sort ( )，因為這會導致堆疊因無限遞迴而溢位。相反，如果您需要 List 實現的預設行為，應避免重寫 sort()。

  如果父類以不適當的方法實現 sort ( ) ，通常最好使用在 List.toArray ( )、Arrays.sort ( ) 和 ListIterator.set ( ) 的基礎上構建的實現重寫 List.sort ( ) 。

例如：

在大多數情況下，您也可以使用根據 API 級別委託給其他預設實現的實現重寫 List.sort ( )  

例如：

如果您選擇後者只是因為您希望開發一種適用於所有 API 級別的 sort ( ) 函式，可以考慮賦予其一個唯一的名稱，例如 sortCompat ( )，而不是重寫  sort ( ) 。

• 現在，Collections.sort ( ) 只是對呼叫 sort ( ) 的 List 實現進行的一項結構性修改。例如，在 Android O 之前的平臺版本中，如果通過呼叫 List.sort ( ) 進行排序，則當迭代處理 ArrayList 以及在迭代過程中呼叫 sort ( ) 時，會引發 ConcurrentModificationException。而 Collections.sort ( ) 則不會引發異常。

此項變更使平臺行為更加一致：現在，兩種方法都會引發 ConcurrentModificationException 。

媒體

• 框架會執行音訊閃避。進行 AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK 時，應用不會失去焦點。新的 API 適用於需要暫停而不是閃避的應用。請注意，此行為無法在 Android O Developer Preview 1 版本中實現。

• 當使用者打電話時，活動的媒體流將在通話期間靜音。

• 所有與音訊相關的 API 都應使用 AudioAttributes 而不是音訊流型別來說明音訊播放用例。僅為音量控制繼續使用音訊流型別。流型別（例如，已棄用的 AudioTrack constructor）的其他用途仍然有效，但是系統會將其記錄為錯誤。

• 使用 AudioTrack 時，如果應用請求了足夠大的音訊緩衝區，則框架將嘗試使用深度緩衝區輸出（如果可用）。

• 在 Android O 中，媒體按鈕事件的處理有所不同：

1. 在介面操作元件中處理媒體按鈕未發生變化：前臺操作元件在處理媒體按鈕時仍然優先。

2. 如果前臺操作元件不處理媒體按鈕，系統會將媒體按鈕路由到最近在本地播放音訊的應用。在確定哪些應用接收媒體按鈕事件時，不再考慮活動狀態、標誌和媒體會話的播放狀態。即使在應用呼叫 setActive( false ) 後，媒體會話仍然可以接收媒體按鈕事件。

3. 如果應用的媒體會話已經釋放，系統會將媒體按鈕事件傳送到應用的 MediaButtonReceiver（如果有）。

4. 對於任何其他情況，系統都會捨棄媒體按鈕事件。與其開始播放錯誤的應用，不如不播放任何東西。

下圖彙總了新的媒體按鈕路由邏輯：

類載入行為

Android O 檢查確保類載入器在載入新類時不會違反執行時假設條件。不論類引用自 Java（來自 forName ( ) ）、Dalvik 位元組碼還是 JNI，都會執行這些檢查。平臺不會攔截 Java 對 loadClass ( ) 函式的直接呼叫，也不會檢查此類呼叫的結果。此行為不應影響執行良好的類載入器的正常執行。

平臺將檢查類載入器返回的類描述符是否與預期的描述符一致。如果返回的描述符與預期不符，平臺會引發 NoClassDefFoundError 錯誤，並在異常日誌中儲存一條註明不一致之處的詳細錯誤訊息。

平臺還檢查請求的類描述符是否有效。此檢查捕獲間接載入諸如 GetFieldID ( ) 等類的 JNI 呼叫，向這些類傳遞無效的描述符。例如，找不到包含 java/lang/String 簽名的欄位，是因為此簽名無效；它應為 Ljava/lang/String; 。

這與 JNI 對 FindClass ( ) 的呼叫不同，其中 java/lang/String 是一個有效的完全限定名稱。

Android O 不支援多個類載入器同時嘗試使用相同的 DexFile 物件來定義類。嘗試進行此操作，會導致 Android 執行時引發 InternalError 錯誤，同時顯示訊息 “Attempt to register dex file <filename> with multiple class loaders” 。

DexFile API 現已棄用，強烈建議您改為使用此平臺的類載入器之一，包括 PathClassLoader 或 BaseDexClassLoader。

注： 您可以建立多個引用檔案系統中同一個 APK 或 JAR 檔案容器的類載入器。這樣做通常不會佔用大量記憶體：如果儲存而不壓縮容器中的 DEX 檔案，平臺可以對此類檔案執行 mmap 操作，而不直接提取它們。但是，如果平臺必須從容器中提取 DEX 檔案，以這種方式引用 DEX 檔案可能佔用大量記憶體。

在 Android 中，所有類載入器都被視為支援並行執行。當多個執行緒爭用同一個類載入器載入相同的類時，第一個完成此操作的執行緒勝出，而操作結果將用於其他執行緒。無論類載入器是返回同一個類、返回不同的類還是引發異常，都將發生此行為。該平臺靜默忽略此類異常。

注意： 在低於 Android O 的平臺版本中，違反這些假設條件可能導致多次定義同一個類、由於類混淆造成堆損壞和其他不良影響。

贏取收藏版 Android 公仔

聊天的時候最怕什麼？

最怕沒有話題。

然而，對於廣大開發者們而言，卻是從來不缺話題的。近期 Android O 成為了開發者們最為關注的熱點話題之一。因此我們希望能夠進一步增強大家對此話題的討論，探索收集開發者們對 Android 最為關心的問題。

現在，機會來啦！不論您是想了解 Android O 還是其他的與 Android 相容性相關 的內容，都可以在文章下方留言與我們取得聯絡。同時，我們將會在下個月的 Android 開發者 FAQ 中對小夥伴們反饋的問題進行解答。

咳咳，還有一點要敲黑板提醒大家，為了鼓勵提問，我們將送出 3 個 來此谷歌官方認證的 Android 公仔 （ Android Mini Collections ）來獎勵提出最有價值問題的開發者，如果您已經對這款萌萌噠的 Android 公仔心動啦，那就趕快提問吧！

我們會把有價值的問題放到 “精選留言” 中，獲贊排名 前 3 的開發者將收到我們的禮品！活動截止日期 2017 年 8 月 31 日，我們將在隨後的微信文章中公佈獲獎的開發者！

“知之者不如好之者，好之者不如樂之者。”還有什麼事比提問更有趣更有收穫的呢？快點行動吧！

推薦閱讀：

Android Wear 2.0 - 連線未來

Android O官方版本即將到來, 先來看看DP4開發者預覽版

Android O 遷移應用官方指南

什麼？Android O 圖示能自適應了？！