最近項目要適配Android O，特地去官網上學習了下，得那個小本本記下來
針對所有的API級別的應用
這個就很好理解了，不管你項目中的應用是針對那個版本，都得要遵循現在O版本中的一些規則，沒有特殊性，這樣就要要求開發者着重注意了
1. 網絡連接和HTTPS連接
（1）無正文的OPTIONS請求具有Content-Length：0標頭。（之前是沒有的）請求這一塊的需要注意
（2）HttpURLConnection在包含斜線的主機或頒發機構名稱後面附加一條斜線，使包含空路徑的網址規範化。這個比較簡單了，舉個例子，http://zkhero.com需要轉換爲http://zkhero.com/ 。就好像我高中數學證明題，不管你會不會，你都要寫個解。
（3）通過ProxySelect.setDefault()設置自定義代理選擇器僅針對你選擇的網址（我從來沒試過，也沒法提供見解了）
（4）URL不能包含空白標籤，估計也是谷歌的程序員對冗餘代碼厭惡達到了一個新的高度了把
（5）系統對格式錯誤的URI會直接返回null，關於這塊URI的這一塊轉換的需要注意了
（6）Android O在實現HttpURLConnection時不會執行不安全的TLS/SSL協議版本回退，這個在App裏的自帶的H5頁面打開失敗很常見
（7）對隧道HTTPS連接處理
*****在通過連接建立隧道HTTPS連接時，系統會在host行中正確放置端口號443，並將此信息發送至中間服務器，因爲在此之前，端口號僅僅出現在CONNECT中
*****系統不再將隧道連接請求中的user-agent和proxy-authorization標頭髮送至代理服務器
*****https這用到的少，一般項目中都已經封裝好了自己的一些請求邏輯，咱們一般不去考慮
（8）如果執行connect（）函數失敗，那麼send函數就會引發SocketException，這個就得考慮了，不然一直掛
（9）在回退到TCP Echo協議之前，InetAddress.isReachable會嘗試ICMP.。我不懂，因爲之前沒碰過，知道的能不能下方留言？
2.集合的處理
主要Java中的AbstractCollection.removeAll()和AbstractCollection.retainAll() 始終會引發空指針異常，因爲之前集合爲空時不會引發空指針。再說，項目中也對Collection用的少，知道就行
3.記錄未捕獲的異常
如果某個應用安裝的Thread.UncaughtExceptionHandler沒有移交給默認的handler，則當出現未捕獲的異常時，不會終止應用。誒，該移交的移交，省的受此變更影響
4.輸入和導航
就是你點擊view的地方會出現一個指示點，提醒你觸摸的地方，如果你討厭這種效果，直接子啊xml佈局中設置相對應的佈局中的android:defaultFoucusHighlightEnable屬相爲false，剩下的是便於我們開發的，不知道還是比較好的
5.提高了安全性
不再支持SSLv3；
O版本將使用安全計算SECCOMP過濾器來過濾所有應用；
沒有正確實現TLS協議時不會像以前那樣遷就回退之前的協議，彷彿android增加了點小脾氣，哈哈；
webView的對象操作將在多進程下運行，在一個獨立的進程中處理邏輯，加大了隔離；
無法假定APK駐留在一以-1或-2結尾的目錄中；
6.後臺執行限制
提高電池續航，當應用進入已緩存的狀態，沒有其他活動組件，系統將解除應用具有的所有喚醒鎖；
代碼中，應用無法使用其清單註冊的大部分隱式廣播；
在後臺運行的app對後臺服務的訪問收到限制；
O版本中的應用在嘗試在不允許其創建後臺服務的情況下使用startService函數，直接會引發一個IllegalStateException；
新的Context.startForegroundService函數將啓動一個前臺服務。不過，應用必須在創建服務後5s內調用該服務的startForeground函數；
7.隱私性
對於安裝在運行 Android O 的設備上的應用，ANDROID_ID 的值現在將根據應用簽署密鑰和用戶確定作用域。應用簽署密鑰、用戶和設備的每個組合都具有唯一的 ANDROID_ID 值。因此，在相同設備上運行但具有不同簽署密鑰的應用將不會再看到相同的 Android ID（即使對於同一用戶來說，也是如此）
對於在 OTA 之前安裝到某個版本 Android O（API 級別 26）的應用，除非在 OTA 後卸載並重新安裝，否則 ANDROID_ID 的值將保持不變。要在 OTA 後在卸載期間保留值，開發者可以使用密鑰/值備份關聯舊值和新值。
只要簽署密鑰相同（並且應用未在 OTA 之前安裝到某個版本的 O），ANDROID_ID 的值在軟件包卸載或重新安裝時就不會發生變化。
要藉助一個簡單的標準系統實現應用獲利，請使用廣告 ID。廣告 ID 是 Google Play 服務針對廣告服務提供的唯一 ID，此 ID 可由用戶重置。
注意點，以上都是對於版本的，現在針對上面的應用了，注意注意
針對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 ( ) 。
例如：
@Override
public void sort(Comparator<? super E> c) {
Object[] elements = toArray();
Arrays.sort(elements, c);
ListIterator<E> iterator = (ListIterator<Object>) listIterator();
for (Object element : elements) {
iterator.next();
iterator.set((E) element);
}
}
在大多數情況下，您也可以使用根據 API 級別委託給其他默認實現的實現重寫 List.sort ( )
例如：
@Override
public void sort(Comparator<? super E> comparator) {
if (Build.VERSION.SDK_INT <= 25) {
Collections.sort(this);
} else {
super.sort(comparator);
}
}
現在，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 中，媒體按鈕事件的處理有所不同：
在界面操作組件中處理媒體按鈕未發生變化：前臺操作組件在處理媒體按鈕時仍然優先。
如果前臺操作組件不處理媒體按鈕，系統會將媒體按鈕路由到最近在本地播放音頻的應用。在確定哪些應用接收媒體按鈕事件時，不再考慮活動狀態、標誌和媒體會話的播放狀態。即使在應用調用 setActive( false ) 後，媒體會話仍然可以接收媒體按鈕事件。
如果應用的媒體會話已經釋放，系統會將媒體按鈕事件發送到應用的 MediaButtonReceiver（如果有）。
對於任何其他情況，系統都會捨棄媒體按鈕事件。與其開始播放錯誤的應用，不如不播放任何東西。
類加載行爲
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 中，所有類加載器都被視爲支持並行運行。當多個線程爭用同一個類加載器加載相同的類時，第一個完成此操作的線程勝出，而操作結果將用於其他線程。無論類加載器是返回同一個類、返回不同的類還是引發異常，都將發生此行爲。該平臺靜默忽略此類異常。
誒，想的也累，看的也累，知道就好了，畢竟國內廠商有專門的人才去弄這個，我只是站在巨人的肩膀上遠看風景，真叫我上還不行咧