Ⅰ android8.0新特性【轉】
1.通知渠道
2.通知角標
3.通知圓點
4.通知延後
5.消息樣式
6.通知超時
7.後台執行限制
8.畫中畫模式
9.自適應圖標
10.藍牙體驗提升
11.智能文本選擇與智能共享
12.WLAN感知
13.取消屏幕縱橫比限制
14.其他
盡管 Android 刷版本號的步伐年年加快，但每年帶給用戶的驚喜從未減少。經歷了四個開發者預覽版的洗禮後，Android 8.0 終於在今天凌晨迎來了正式版發布。
如果你還不清楚 Android O 有哪些關鍵的新特性，不妨讓我們通過這篇文章快速為你梳理一遍。
代號「奧利奧」
和發布會前幾天外媒傳出的消息一樣，Android 8.0 的甜品代號果然是「奧利奧」（Oreo）。
而昨晚的發布會碰巧趕上了美國日全食，為此 Google 也准備了一段應景的揭曉視頻：
從奇巧板到牛軋糖再到這次的奧利奧，不得不說近幾個 Android 版本所選擇的甜品都非常可口。在開始新功能介紹之前，我們不妨通過下面這張長圖回顧一下 Android 歷代甜品代號：
通知——往往是 Android 系統的信息過載的「重災區」，也是近三個大版本以來 Google 不斷在優化和改進的重點。在 Android 8.0 中，通知系統有了如下改進：
Android 8.0 引入了通知渠道特性，將應用的通知進行分門別類，用戶可以針對不同的通知類別單獨設置通知優先順序別和提醒方式。
Google 的時鍾應用提供了 4 個通知渠道
假想一下（這不可能），適配了這一特性的淘寶客戶端，我們可以屏蔽那些直播通知和促銷推薦，物流信息、秒殺提醒則可以適當「放行」。
在早前的 Android 版本中，我們只能藉助第三方啟動器和通知讀取工具（比如 Nova Launcher+Telsa）來實現通知角標效果。
Android 8.0 開始，應用可以在啟動器圖標上顯示通知圓點來提示用戶，但這個圓點角標和 iOS 上那個有所不同——它僅提示用戶該應用有通知，不會顯示具體的通知數量。考慮到部分用戶的「紅點強迫症」，這算是一種折衷的設計了……
通常，當一條通知出現在通知欄，除了點擊查看、劃掉不理以外，我們就只剩下「放任不管」這種處理方式了。這顯然不太優雅，太多的通知駐留不僅會讓通知欄擁擠不堪，回過頭進行處理的時候也很不方便。
所以，Android 8.0 引入了另一種通知處理操作——通知延後。當我們暫時不便處理某條應用通知時，只需要在該條通知上清掃，點擊出現的時鍾圖標，即可讓這條通知暫時從通知欄消失，在設定好的時間後再回來。
通知延後功能演示
理論上來說，如果開發者在開發應用時沒有進行特殊限制，所有的非常駐通知（比如媒體通知）都可以被延後。
Android 8.0 提供了新的通知背景著色方式，除了大家可能已經見過的多彩媒體通知以外，一些常駐高優先順序通知也可以利用這種背景著色方式來讓自己更加引人注目，比如駕駛導航和後台通話通知。
目前，一些使用原生通知樣式的應用已經可以在 Android 8.0 上正確調用新的通知背景著色機制了，效果也十分討人喜愛。
原生 Android 系統的消息通知向來好用——我們不僅可以通過消息通知進行快速回復，還能通過擴展試圖看到多條消息通知並逐條回復（詳情請參閱 Android Nougat 的通知改進詳解）。
在 Android 8.0 中，消息通知樣式得到了進一步完善。開發者可以通過新的通知函數來為消息通知的擴展視圖增加消息歷史，讓用戶在快速處理通知的過程中更加熟悉回話上下文。
除了上面提到的通知延後功能以外，Android 8.0 還面向開發者提供了通知超時特性，允許特定通知在設定時間後自行清除；進而，系統還能區分某條應用的清除操作是由用戶還是應用發出。
利用這些特性，應用開發者能夠探索設計出對用戶造成打擾程度最小的通知方式。
系統級自動填充框架
不管是在手機上注冊賬號、登錄賬號還是輸入其他常用個人信息，過程都相當繁瑣且容易出錯，選擇第三方密碼管理和自動填寫工具又不得不額外考慮安全和隱私問題。
因而在 Android 8.0 中，Google 首次整合了一個系統級的全局自動填寫功能。開啟後，當我們在第一次進行應用設置、登錄時，系統就會幫我們快速填寫好對應的個人信息和密碼。
系統級自動填寫使用起來非常方便
當然，如果不想使用 Google 提供的密碼保存服務，也可以等待 1Password、LastPass 等服務商跟進這一特性，到時我們就可以在「系統->語言和輸入法->輸入幫助」自由選擇想要使用的自動填充服務。
未來會有更多應用適配這一特性
優秀的多任務處理能力一直以來都是 Android 系統的魅力所在，但同時運行的應用太多肯定會為系統造成不小的負擔。如果還有應用或服務在後台運行，而用戶正在使用其他需要大量系統資源的應用（例如玩游戲或觀看視頻），就會因為硬體性能不足導致卡頓，部分應用可能還需要重新載入。
為此，Android 8.0 對應用在後台運行時可以執行的操作施加了限制，面向 Android 8.0 進行開發的應用將在兩個方面受到限制：
後台服務限制：處於空閑狀態時，應用可以使用的後台服務存在限制。
廣播限制：除了有限的例外情況，應用無法為隱式廣播注冊接收器。
不清楚何為「服務」何為「廣播」也沒關系，只需要知道：當一個面向 Android 8.0 開發或被用戶手動開啟了後台限制的應用被放到後台運行時，系統在為它分配各項系統資源時就會「酌情考慮」了。
這個後台執行限制此前也存在缺陷和不足，好在經過綠色守護開發者 @oasisfeng 和部分熱心 Android 用戶的熱心反饋，Google 已於第四個開發者預覽版（DP4）中修復了後台服務管控漏洞。即便是那些頑固的國產毒瘤，在 Android 8.0 中也不得不收斂了。
Android Nougat 引入了應用「分屏」功能，允許用戶將任意兩個（適配了該特性）的應用或窗口在屏幕上進行上下分屏，提升了應用間的協作和使用效率。
而從 Android 8.0 開始，系統將支持更加自由、靈活的「畫中畫」模式。這個通常用於視頻播放的特性早已在部分 OEM 廠商的定製 ROM 和 Android TV 當中的實現，但加入原生 Android 8.0 依然令人驚喜。
一邊看視頻一邊瀏覽其他內容
如果你訂閱了 YouTube Red 並開啟了「後台播放功能」，系統就能在你把 YouTube 放到後台的同時將視頻內容以懸浮窗的形式繼續播放；當你在 Chrome 中查看網頁視頻時，也可以將某個標簽中的視頻「拿出來」，一邊瀏覽其他網頁一邊查看視頻；知名 Android 播放器 VLC 也搶在正式版發布前就適配了畫中畫模式，升級 Android 8.0 正式版以後別忘了試一試。
Android 系統上到底改採用異形圖標還是規則圖標？在這個問題上，不同的 OEM 廠商和用戶都有自己的選擇偏好。這也導致不同 Android 設備的體驗迥異，百花齊放的表象之下，無論是應用開發者和圖標設計師們往往感到很迷茫。
為了解決這個問題，Google 在 Android 8.0 中引入了自適應圖標規范。依據這一規范開發的自適應圖標不僅可以最大程度上保留自己的特色，同時還能完美地融入到不同啟動器和 ROM 的整體視覺風格當中。
除此之外，應用開發者還能腦洞大開，賦予這些圖標不同的動態效果。
關於自適應圖標規范的意義所在以及開發者如何進行設計和適配，請參閱少數派先前發布的譯文：
Android O 自適應圖標的意義何在？Google 設計師給你答案 | 科普設計自適應圖標實現自適應圖標Android O 新特性介紹：自適應圖標（Adaptive Icons）
Android 8.0 還從多個角度增強了原生 Android 平台對藍牙的支持，具體包括：
支持 AVRCP 1.4 標准：支持遠程瀏覽和控制 TV、HiFi 等設備的媒體庫。支持藍牙低功耗 (BLE) 5.0 標准：傳輸速度提升兩倍、傳輸距離提升四倍、數據承載能力提升八倍。此外，5.0 標准還優化了時隙可用性和信道選擇演算法，可規避 Wi-Fi 和 LTE 信道干擾來提高數據傳輸質量。集成更多藍牙協議編解碼器，包括由 Sony 提供的 LDAC 編解碼器。
毫無疑問，Android 8.0 對於那些愛聽歌的用戶來說是一次良心滿滿的升級：只要手裡藍牙耳機滿足硬體要求，就可以輕松實現無損藍牙音樂傳輸。
利用機器學習和人工智慧，當我們在 Android 8.0 中進行文字點選操作時，系統會自動識別我們想要復制的文字內容。在長按彈出的浮動工具條中，系統還將提供可用於處理被選中部分文字內容的應用選項。
自動識別文字內容並提供應用建議 - 1
例如，當我們長按一段文字中地址的一部分，系統不僅會將整個地址內容進行選中，還能在彈出的浮動工具條中顯示地圖應用，點擊即可快速調用地圖打開選中地址；同理，如果我們選中的是一段 URL，那麼 Chrome 瀏覽器就會出現在彈出的浮動工具條中，方便我們快速跳轉至該 URL 所指向的網頁。
自動識別文字內容並提供應用建議 - 2
同樣的技術也將運用於 Android 8.0 的「分享」介面中，如果我們試圖分享一張購物小票的照片，在分享列表中，系統會優先建議那些記賬應用；而如果我們分享一張自拍，美顏應用則更可能會出現在分享菜單的前列。
Android 8.0 新增了對 WLAN 感知的支持，此技術基於周邊感知聯網 (NAN) 規范。在具有相應 WLAN 感知硬體的設備上，應用和附近設備可以通過 WLAN 進行搜索和通信，無需依賴互聯網接入點。
開啟 WLAN 感知功能後，當我們位於已保存的 WiFi 連接附近時，系統就會自動使用這個 WiFi 接入點。
以 Android 7.1（API 級別 25）或更低版本為目標平台開發的應用默認最大屏幕縱橫比為 1.86，但這也導致這些應用在一些新近機型（比如 Galaxy S8/S8+）上顯示效果不佳（無法全屏、上下黑邊等等）。
採用非傳統屏幕縱橫比的新近機型 | 源：bgr
而面向 Android 8.0 或更高版本系統所開發的應用將不要求設定最大縱橫比，保證應用能夠最大限度地兼容屏幕比例各異的 Android 機型。
對開發者而言，他們還可以利用下面這些 Android 8.0 新特性：
Ⅱ android 7.0對開發者會有哪些影響
Android N 除了提供諸多新特性和功能外，還對系統和 API 行為做出了各種變更。 本文重點介紹您應該了解並在開發應用時加以考慮的一些重要變更。
如果您之前發布過 Android 應用，請注意您的應用可能受到這些平台變更的影響。
電池和內存
Android N 包括旨在延長設備電池壽命和減少 RAM 使用的系統行為變更。 這些變更可能會影響您的應用訪問系統資源，以及您的系統通過特定隱式 Intent 與其他應用互動的方式。
低電耗模式
Android 6.0（API 級別
23）引入了低電耗模式，當用戶設備未插接電源、處於靜止狀態且屏幕關閉時，該模式會推遲 CPU 和網路活動，從而延長電池壽命。而 Android N
則通過在設備未插接電源且屏幕關閉狀態下、但不一定要處於靜止狀態（例如用戶外出時把手持式設備裝在口袋裡）時應用部分 CPU
和網路限制，進一步增強了低電耗模式。
圖 1. 低電耗模式如何應用第一級系統活動限制以延長電池壽命的圖示。
當設備處於充電狀態且屏幕已關閉一定時間後，設備會進入低電耗模式並應用第一部分限制： 關閉應用網路訪問、推遲作業和同步。 如果進入低電耗模式後設備處於靜止狀態達到一定時間，系統則會對 PowerManager.WakeLock、AlarmManager 鬧鈴、GPS
和 Wi-Fi 掃描應用餘下的低電耗模式限制。 無論是應用部分還是全部低電耗模式限制，系統都會喚醒設備以提供簡短的維護時間窗口，在此窗口期間，應用程序可以訪問網路並執行任何被推遲的作業/同步。
圖 2. 低電耗模式如何在設備處於靜止狀態達到一定時間後應用第二級系統活動限制的圖示。
請注意，激活屏幕或插接設備電源時，系統將退出低電耗模式並取消這些處理限制。 此項新增的行為不會影響有關使您的應用適應 Android 6.0（API 級別 23）中所推出的舊版本低電耗模式的建議和最佳實踐，如低電耗模式和應用待機模式優化中所討論。
您仍應遵循這些建議（例如使用 Google Cloud Messaging (GCM) 發送和接收消息）並開始安排更新計劃以適應新增的低電耗模式行為。
Project Svelte：後台優化
Android N 刪除了三項隱式廣播，以幫助優化內存使用和電量消耗。 此項變更很有必要，因為隱式廣播會在後台頻繁啟動已注冊偵聽這些廣播的應用。 刪除這些廣播可以顯著提升設備性能和用戶體驗。
移動設備會經歷頻繁的連接變更，例如在 Wi-Fi 和移動數據之間切換時。 目前，可以通過在應用清單中注冊一個接收器來偵聽隱式 CONNECTIVITY_ACTION廣播，讓應用能夠監控這些變更。
由於很多應用會注冊接收此廣播，因此單次網路切換即會導致所有應用被喚醒並同時處理此廣播。
同理，應用可以注冊接收來自其他應用（例如相機）的隱式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 廣播。
當用戶使用相機應用拍攝照片時，這些應用即會被喚醒以處理廣播。
為緩解這些問題，Android N 應用了以下優化措施：
面向 Android N 開發的應用不會收到 CONNECTIVITY_ACTION 廣播，即使它們已有清單條目來請求接受這些事件的通知。
在前台運行的應用如果使用BroadcastReceiver 請求接收通知，則仍可以在主線程中偵聽 CONNECTIVITY_CHANGE。
應用無法發送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 廣播。此項優化會影響所有應用，而不僅僅是面向
Android N 的應用。
如果您的應用使用任何 Intent，您仍需要盡快移除它們的依賴關系，以正確適配 Android N 設備。 Android 框架提供多個解決方案來緩解對這些隱式廣播的需求。 例如，JobScheler API
提供了一個穩健可靠的機制來安排滿足指定條件（例如連入無限流量網路）時所執行的網路操作。 您甚至可以使用JobScheler 來適應內容提供程序變化。
如需了解有關 Android N 中後台優化以及如何改寫應用的詳細信息，請參閱後台優化。
許可權更改
Android N 做了一些許可權更改，這些更改可能會影響您的應用。
系統許可權更改
為了提高私有文件的安全性，面向 Android N 或更高版本的應用私有目錄被限制訪問(0700)。 此設置可防止私有文件的元數據泄漏，如它們的大小或存在。 此許可權更改有多重副作用：
私有文件的文件許可權不應再由所有者放寬，為使用 MODE_WORLD_READABLE 和/或 MODE_WORLD_WRITEABLE 而進行的此類嘗試將觸發SecurityException。
註：迄今為止，這種限制尚不能完全執行。 應用仍可能使用原生 API 或 File API 來修改它們的私有目錄許可權。 但是，我們強烈反對放寬私有目錄的許可權。
傳遞軟體包網域外的 file:// URI 可能給接收器留下無法訪問的路徑。 因此，嘗試傳遞 file:// URI 會觸發 FileUriExposedException。 分享私有文件內容的推薦方法是使用 FileProvider。
DownloadManager 不再按文件名分享私人存儲的文件。
舊版應用在訪問 COLUMN_LOCAL_FILENAME 時可能出現無法訪問的路徑。
面向 Android N 或更高版本的應用在嘗試訪問 COLUMN_LOCAL_FILENAME 時會觸發 SecurityException。
通過使用DownloadManager.Request.() 或 DownloadManager.Request.() 將下載位置設置為公共位置的舊版應用仍可以訪問 COLUMN_LOCAL_FILENAME 中的路徑，但是我們強烈反對使用這種方法。
訪問由 DownloadManager 公開的文件的首選方式是使用 ContentResolver.openFileDescriptor()。
應用間共享文件
對於面向 Android N 的應用，Android 框架執行的 StrictMode API
政策禁止向您的應用外公開 file:// URI。 如果一項包含文件 URI 的 Intent 離開您的應用，應用失敗，並出現 FileUriExposedException 異常。
若要在應用間共享文件，您應發送一項 content:// URI，並授予 URI 臨時訪問許可權。 進行此授權的最簡單方式是使用 FileProvider 類。
如需有關許可權和共享文件的更多信息，請參閱共享文件。
無障礙改進
為提高平台對於視力不佳或視力受損用戶的可用性，Android N 做出了一些更改。這些更改一般並不要求更改您的應用代碼，不過您應仔細檢查並使用您的應用測試這些功能，以評估它們對用戶體驗的潛在影響。
屏幕縮放
Android N 支持用戶設置顯示尺寸，以放大或縮小屏幕上的所有元素，從而提升設備對視力不佳用戶的可訪問性。用戶無法將屏幕縮放至低於最小屏幕寬度 sw320dp，該寬度是
Nexus 4 的寬度，也是常規中等大小手機的寬度。
圖 3. 右側屏幕顯示的是一台運行 Android N 系統映像的設備增大顯示尺寸後的效果。
當設備密度發生更改時，系統會以如下方式通知正在運行的應用：
如果是面向 API 級別 23 或更低版本系統的應用，系統會自動終止其所有後台進程。 這意味著如果用戶切換離開此類應用，轉而打開「Settings」屏幕並更改 Display size 設置，則系統會像處理內存不足的情況一樣終止該應用。 如果應用具有任何前台進程，則系統會如處理運行時變更中所述將配置變更通知給這些進程，就像對待設備屏幕方向變更一樣。
如果是面向 Android N 的應用，則其所有進程（前台和後台）都會收到有關配置變更的通知，如處理運行時變更中所述。
大多數應用並不需要進行任何更改即可支持此功能，不過前提是這些應用遵循 Android 最佳實踐。具體要檢查的事項：
在屏幕寬度為 sw320dp 的設備上測試您的應用，並確保其充分運行。
當設備配置發生變更時，更新任何與密度相關的緩存信息，例如緩存點陣圖或從網路載入的資源。當應用從暫停狀態恢復運行時，檢查配置變更。
註：如果您要緩存與配置相關的數據，則最好也包括相關元數據，例如該數據對應的屏幕尺寸或像素密度。 保存這些元數據便於您在配置變更後決定是否需要刷新緩存數據。
避免用像素單位指定尺寸，因為像素不會隨屏幕密度縮放。應改為使用與密度無關像素 (dp)
單位指定尺寸。
設置向導中的視覺設置
Android N 在「Welcome」屏幕中加入了「Vision Settings」，用戶可以在新設備上設置以下無障礙功能設置： Magnification gesture、Font size、Display size 和 TalkBack。 此項變更增強了與不同屏幕設置相關的錯誤的可見性。
要評估此功能的影響，您應在啟用這些設置的狀態下測試應用。 您可以在Settings > Accessibility 中找到這些設置。
NDK 應用鏈接至平台庫
Android N 做了一些命名空間更改，以阻止載入非公開 API。 如果您使用 NDK，則只能使用 Android 平台提供的公開 API。 在下一個官方發布的 Android 版本上使用非公開 API 會導致應用崩潰。
為提醒您使用了非公開 API，在 Android N
設備上運行的應用會在有應用調用非公開 API 時在日誌消息輸出中生成一個錯誤。
此錯誤還會作為消息顯示在設備屏幕上，以幫助增強您對此情況的認識。 您應檢查應用代碼以刪除使用非公開平台
API，並使用預覽版設備或模擬器全面測試應用。
如果您的應用依賴平台庫，則請參見 NDK 文檔，了解使用公開 API 等效項替換普通私有 API 的典型修復。 您還可以鏈接至平台庫，而無需實現此應用，如果應用使用的庫是平台的一部分（例如 libpng），但不屬於 NDK，則更可如此。 此情況下，請確保您的 APK 包含您打算鏈接到的所有 .so 文件。
注意：有些第三方庫可能會鏈接至非公開 API。 如果您的應用使用這些庫，那麼當您的應用在下一個官方發布的 Android 版本上運行時可能會出現崩潰現象。
應用不應依賴或使用不屬於 NDK
的原生庫，因為這些庫可能會發生更改或從一個 Android 版本遷移至另一版本。 例如，從 OpenSSL 切換至 BoringSSL
即屬於此類更改。 此外，不同的設備可能提供不同級別的兼容性，因為不屬於 NDK 中的平台庫沒有兼容性要求。 如果您必須在較舊設備上訪問非 NDK
庫，則請依據 Android API 級別進行載入。
為幫助您診斷此類問題，下面列舉了一些在您試圖使用 Android N 開發應用時可能遇到的 java 和 NDK 錯誤：
Java 錯誤示例：
java.lang.UnsatisfiedLinkError: dlopen failed: library "/system/lib/libcutils.so"
is not accessible for the namespace "classloader-namespace"
NDK 錯誤示例：
dlopen failed: cannot locate symbol "__system_property_get" referenced by ...
以下是遇到這類錯誤的應用的一些典型修復：
可以使用標准 JNI 函數來替代使用 libandroid_runtime.so 中的 getJavaVM 和 getJNIEnv：
AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.
可以使用公開 alternative __system_property_get 來替代使用 libcutils.so 中的 property_get 符號。如需這樣做，請使用__system_property_get 及以下 include 函數：
#include <sys/system_properties.h>
應使用應用本地版本來替代使用 libcrypto.so 中的 SSL_ctrl 符號。例如，您應在 .so 文件中靜態鏈接 libcyrpto.a，或者在應用中包含您自己的來自 BoringSSL 或 OpenSSL 的動態 libcrypto.so。
Android for Work
Android N 包含一些針對面向 Android
for Work 的應用的變更，包括對證書安裝、密碼重置、二級用戶管理、設備標識符訪問許可權的變更。如果您是要針對 Android for
Work 環境開發應用，則應仔細檢查這些變更並相應地修改您的應用。
您必須先安裝授權證書安裝程序，然後 DPC 才能對其進行設置。 對於面向 N SDK 的個人資料和設備所有者應用，您應在設備策略控制器 (DPC) 調用DevicePolicyManager.setCertInstallerPackage() 之前安裝授權證書安裝程序。 如果尚未安裝此安裝程序，則系統會引發IllegalArgumentException。
針對設備管理員的重置密碼限制現在也適用於個人資料所有者。 設備管理員無法再使用 DevicePolicyManager.resetPassword() 來清除或更改已經設置的密碼。 設備管理員仍可以設置密碼，但只能在設備沒有密碼、PIN 或圖案時這樣做。
即使設置了限制，設備所有者和個人資料所有者仍可以管理帳戶。而且，即使具有 DISALLOW_MODIFY_ACCOUNTS 用戶限制，設備所有者和個人資料所有者仍可調用 Account Management API。
設備所有者可以更輕松地管理二級用戶。當設備在設備所有者模式下運行時，系統將自動設置 DISALLOW_ADD_USER 限制。 這樣可以防止用戶創建非託管二級用戶。 此外，CreateUser() 和 createAndInitializeUser() 方法已棄用，取而代之的是 DevicePolicyManager.createAndManageUser() 方法。
設備所有者可以訪問設備標識符。設備所有者可以使用 DevicePolicyManagewr.getWifiMacAddress() 訪問設備的 Wi-Fi MAC 地址。 如果設備上從未啟用 Wi-Fi，則此方法將返回一個 null 值。
工作模式設置控制工作應用訪問。當工作模式關閉時，系統啟動器通過使工作應用顯示為灰色來指示它們不可用。 啟用工作模式會再次恢復正常行為。
如需了解有關 Android N 中針對 Android for Work 所做變更的詳細信息，請參閱 Android for
Work 更新。
註解保留
Android N 在註解可見性被忽略時修復錯誤。這種問題將啟用本不應被允許的運行時訪問註解。 這些註解包括：
VISIBILITY_BUILD:僅應編譯時可見。
VISIBILITY_SYSTEM:運行時應可見，但僅限基本系統。
如果您的應用依賴這種行為，請在註解中添加一項運行時必須可用的保留政策。 您可通過使用 @Retention(RetentionPolicy.RUNTIME) 來如此做。
其他重要說明
如果一個應用在 Android N 上運行，但卻是針對更低 API 級別開發的，那麼在用戶更改顯示尺寸時，系統將終止此應用進程。 應用必須能夠正常處理此情景。 否則，當用戶從最近使用記錄中恢復運行應用時，應用將會出現崩潰現象。
您應測試應用以確保不會發生此行為。要進行此測試，您可以通過 DDMS 手動終止應用，以造成相同的崩潰現象。
在密度發生更改時，系統不會自動終止面向 N 及更高版本的應用；不過，這些應用仍可能對配置變更做出不良響應。
Android N 上的應用應能夠正常處理配置變更，並且在後續啟動時不會出現崩潰現象。您可以通過更改字體大小 (Setting > Display > Font size) 並隨後從最近使用記錄中恢復運行應用，來驗證應用行為。
由於之前的 Android 版本中的一項錯誤，系統未能將對主線程上的一個 TCP 套接字的寫入操作舉報為嚴格模式違反。 Android N 修復了此錯誤。呈現出這種行為的應用引發 android.os.NetworkOnMainThreadException。一般情況下，我們不建議在主線程上執行網路操作，因為這些操作通常都有可能導致 ANR 和卡頓的高尾延遲。
Debug.startMethodTracing() 方法族現在默認在您的共享的存儲空間上的軟體包特定目錄中存儲輸出，而非 SD 卡頂級。 這意味著應用不再需要請求WRITE_EXTERNAL_STORAGE 使用這些 API 的許可權。
許多平台 API 現在開始檢查在 Binder 事務間發送的大負載，系統現在會將 TransactionTooLargeExceptions 再次作為 RuntimeExceptions 引發，而不再只是默默記錄或抑制它們。
一個常見例子是在 Activity.onSaveInstanceState() 上存儲過多數據，導致 ActivityThread.StopInfo 在您的應用面向
Android N 時引發 RuntimeException。
如果應用向 View 發布 Runnable 任務，並且 View 未附加到窗口，系統會用 View 為 Runnable 任務排隊；在 View 附加到窗口之前，Runnable 任務不會執行。
此行為會修復以下錯誤：
如果一項應用是從並非預期窗口 UI 線程的其他線程發布到 View，則Runnable 可能會因此運行錯誤的線程。
如果 Runnable 任務是從並非環路線程的其他線程發布，則應用可能會曝光 Runnable 任務。
如果 Android N 上一項有 DELETE_PACKAGES 許可權的應用嘗試刪除一個軟體包，但另一項應用已經安裝了這個軟體包，則系統可能要求用戶確認。
在這種情況下，應用在調用 PackageInstaller.uninstall() 時的返回狀態應為 STATUS_PENDING_USER_ACTION。
Ⅲ Android各版本間差異
一個好的APP最好支持90%設備，由於不同版本系統提供的API可能不同，所以了解不同版本間系統差異很重要，這樣才能更好的適配更多的智能設備。
Android4.X
Android5.X 這是一個里程碑的版本
Android6.X
Android7.X
Android8.X
Android9.0
對更大屏幕顯示的追求和視覺等體驗的優化，智能的開始體現（用戶行為的學習及正確化引導，網路環境的智能適應，電池電量的優化），更加人性化。
參考文檔：
Android從1.0到 6.0各版本的差別
大致總結一下 安卓各大版本的差異（安卓4以上版本）
Android 9.0新特性
關於Android Pie（Android 9.0），你想知道的都在這了