版權聲明：本文為HaiyuKing原創文章，轉載請注明出處！
概述
了解新版本的特性還是很有必要的，為什么這么講呢？因為可以從應用市場對發布應用的目標API版本（targetSdkVersion值）的要求說起：
- 從 2018 年 8 月 1 日起，所有向 Google Play 首次提交的新應用都必須針對 Android 8.0 (API 等級 26) 開發； 2018 年 11 月 1 日起，所有 Google Play 的現有應用更新同樣必須針對 Android 8.0。
-
自2019年5月1日起，應用寶本商城新上架應用應基於Android 8.0 (API等級26，即targetSdkVersion大於等於26)及以上開發。自2019年8月1日起，現有應用的更新應基於Android 8.0 (API等級26，即targetSdkVersion大於等於26)及以上開發。2018年9月1日后，未達到要求的應用，騰訊開放平台將逐步采用不推薦的策略。2019年5月1日后，未達到要求的應用，騰訊開放平台將拒絕上架，2019年8月1日后，未達到要求的應用，騰訊開放平台將拒絕更新。
- 騰訊開放平台將在2018年3月21日啟動Android P (API 等級 28) 版本應用適配檢測工作。針對未適配Android P版本的應用，騰訊開放平台將在Android P版本機型上采取屏蔽或不推薦更新等策略。
- 華為開發者聯盟：自2019年5月1日起，華為應用市場新上架應用應基於Android 8.0 (API等級26，即targetSdkVersion大於等於26)及以上開發。自2019年8月1日起，現有應用的更新應基於Android 8.0 (API等級26，即targetSdkVersion大於等於26)及以上開發。2019年5月1日后，未達到要求的新應用，華為應用市場將拒絕上架。2019年8月1日后，未達到要求的現有應用，華為應用市場將拒絕更新。
而將targetSdkVersion的值修改成高版本，那么就代表在這個版本上的手機設備上已經進行了適配，比如Android8.0（API 26），那么就要考慮到適配應用圖標的問題、還有通知欄適配等等。
各版本對應的API值
數據來源：https://developer.android.google.cn/about/dashboards/?hl=zh-cn
Android 4.4 KitKat（targetSdkVersion =19）
參考《Android 4.4 API》
這里簡單講一下主要API變更，具體的請閱讀上面的鏈接。
外部存儲空間訪問權限
您的應用在 Android 4.4 上運行時無法讀取外部存儲空間上的共享文件，除非您的應用具有 READ_EXTERNAL_STORAGE 權限。也就是說，沒有此權限，您無法再訪問 getExternalStoragePublicDirectory() 返回的目錄中的文件。但是，如果您僅需要訪問 getExternalFilesDir() 提供的您的應用特有目錄，那么，您不需要 READ_EXTERNAL_STORAGE 權限。
webview底層代碼變化
WebView 類的底層代碼和相關 API 已升級為基於現代的 Chromium 源代碼快照。這會帶來各種性能提升，同時為新的 HTML5 功能和遠程調試 WebView 內容提供支持。此次升級的范圍意味着如果您的應用使用 WebView，則在某些情況下其行為可能會受影響。盡管對已知的行為變更進行了記錄，但僅在您將應用的 targetSdkVersion 更新為“19”或更高版本時這些變更才會對應用產生很大的影響—新的 WebView 在“兼容模式”中運行以便在面向 API 級別 18 和更低級別的應用中提供部分舊功能—您的應用有可能依賴來自以前的 WebView 版本的未知行為。
沉浸式全屏模式
要為您的應用提供填充整個屏幕的布局，適用於 setSystemUiVisibility() 的新標記 SYSTEM_UI_FLAG_IMMERSIVE（與 SYSTEM_UI_FLAG_HIDE_NAVIGATION 結合使用時）將啟用新的沉浸式全屏模式。在啟用沉浸式全屏模式后，您的 Activity 將繼續接收所有觸摸事件。用戶可以沿着系統狀態欄正常出現的區域向內滑動來顯示系統狀態欄。這將清除 SYSTEM_UI_FLAG_HIDE_NAVIGATION 標記（如果應用了 SYSTEM_UI_FLAG_FULLSCREEN 標記，也會清除該標記），因此系統狀態欄保持可見狀態。但是，如果您想要系統狀態欄在片刻后再次隱藏，可以改用 SYSTEM_UI_FLAG_IMMERSIVE_STICKY 標記。
透明系統狀態欄
現在，您可以使用新主題背景 Theme.Holo.NoActionBar.TranslucentDecor 和 Theme.Holo.Light.NoActionBar.TranslucentDecor 將系統狀態欄設置為部分透明。通過啟用透明系統狀態欄，您的布局將填充系統狀態欄后面的區域，因此，您也必須為不應被系統狀態欄覆蓋的布局部分啟用 fitsSystemWindows。
如果您要創建自定義主題背景，則將其中某個主題背景設置為父主題背景，或在您的主題背景中添加 windowTranslucentNavigation 和 windowTranslucentStatus 樣式屬性。
從Android4.4開始，才可以實現狀態欄着色，並且從5.0開始系統更加完善了這一功能。
Android 5.0（targetSdkVersion =21）
參考《Android 5.0 API》
這里簡單講一下主要API變更，具體的請閱讀上面的鏈接。
Material Design 支持
Android 5.0 添加了對 Android 的新 Material Design 樣式的支持。您可以創建具有 Material Design 功能的應用，實現動態視覺效果，利用其中的 UI 元素轉換賦予用戶自然的感覺。此支持包括：
- Material Design 主題
- 視圖陰影
- RecyclerView、卡片CardView、Toolbar、FloatingActionButton、TextInputLayout、Snackbar、AppBarLayout、TabLayout、NavigationView
- 可繪制動畫和造型效果
- Material Design 動畫和 Activity 轉換效果
- 針對基於視圖狀態的視圖屬性的動畫生成器
- 可自定義的 UI 小部件和具有可由您控制的調色板的應用欄
- 基於 XML 矢量圖形的動畫和非動畫可繪制對象
通知
1.普通Notification
創建Builder 對象，添加各種屬性，用PendingIntent 控制跳轉，最后是創建NotificationManager調用notify方法。
2.折疊式Notification
用RemoteViews來創建自定義Notification視圖。
3.懸掛式Notification（5.0新增）
調用setFullScreenIntent來將Notification變為懸掛式Notification。焦點不變，不會影響用戶操作，顯示幾秒會自動消失。
Android 6.0（targetSdkVersion =23）
參考《Android 6.0 API》
這里簡單講一下主要API變更，具體的請閱讀上面的鏈接。
指紋身份驗證
通知
此版本移除了 Notification.setLatestEventInfo() 方法。請改用 Notification.Builder 類來構建通知。要重復更新通知，請重復使用 Notification.Builder 實例。調用 build() 方法可獲取更新后的 Notification 實例。
此版本針對通知功能引入了下列 API 變更：
- 新增了 INTERRUPTION_FILTER_ALARMS 過濾級別，它對應於新增的“僅鬧鈴”免打擾模式。
- 新增了 CATEGORY_REMINDER 類別值，用於區分用戶安排的提醒與其他事件 (CATEGORY_EVENT) 和鬧鈴 (CATEGORY_ALARM)。
- 新增了 Icon 類，您可以通過 setSmallIcon()方法和 setLargeIcon()方法將其附加到通知上。同理，addAction() 方法現在接受 Icon 對象，而不接受可繪制資源 ID。
- 新增了 getActiveNotifications() 方法，讓您的應用能夠了解哪些通知目前處於活動狀態。要查看使用此功能的應用實現，請參閱 ActiveNotifications 示例。
運行時權限
此版本引入了一種新的權限模式，如今，用戶可直接在運行時管理應用權限。這種模式讓用戶能夠更好地了解和控制權限，同時為應用開發者精簡了安裝和自動更新過程。用戶可為所安裝的各個應用分別授予或撤銷權限。
對於以 Android 6.0（API 級別 23）或更高版本為目標平台的應用，請務必在運行時檢查和請求權限。要確定您的應用是否已被授予權限，請調用新增的 checkSelfPermission() 方法。要請求權限，請調用新增的 requestPermissions() 方法。即使您的應用並不以 Android 6.0（API 級別 23）為目標平台，您也應該在新權限模式下測試您的應用。
Android 7.0（targetSdkVersion =24）
這里簡單講一下主要API變更，具體的請閱讀上面的鏈接。
FileProvider【常用於調起系統相機拍照返回圖片路徑、調用系統文件管理器返回文件路徑】
傳遞軟件包網域外的 file:// URI 可能給接收器留下無法訪問的路徑。因此，嘗試傳遞 file:// URI 會觸發 FileUriExposedException。分享私有文件內容的推薦方法是使用 FileProvider。
對於面向 Android 7.0 的應用，Android 框架執行的 StrictMode API 政策禁止在您的應用外部公開 file:// URI。如果一項包含文件 URI 的 intent 離開您的應用，則應用出現故障，並出現 FileUriExposedException 異常。
要在應用間共享文件，您應發送一項 content:// URI，並授予 URI 臨時訪問權限。進行此授權的最簡單方式是使用 FileProvider 類。
多窗口支持
在 Android 7.0 中，我們為該平台引入了一個新的而且非常需要的多任務處理功能 — 多窗口支持。
現在，用戶可以一次在屏幕上打開兩個應用。
通知增強功能
在 Android 7.0 中，我們重新設計了通知，使其更易於使用並且速度更快。部分變更包括：
- 模板更新：我們正在更新通知模板，新強調了英雄形象和化身。開發者將能夠充分利用新模板，只需進行少量的代碼調整。
- 消息傳遞樣式自定義：您可以自定義更多與您的使用 MessagingStyle 類的通知相關的用戶界面標簽。您可以配置消息、會話標題和內容視圖。
- 捆綁通知：系統可以將消息組合在一起（例如，按消息主題）並顯示組。用戶可以適當地進行拒絕或歸檔等操作。如果您已實現 Android Wear 的通知，那么您已經很熟悉此模式。
- 直接回復：對於實時通信應用，Android 系統支持內聯回復，以便用戶可以直接在通知界面中快速回復短信。
- 自定義視圖：兩個新的 API 讓您在通知中使用自定義視圖時可以充分利用系統裝飾元素，如通知標題和操作。
多語言區域支持，更多語言
Android 7.0 現在允許用戶在設置中選擇多個語言區域，以更好地支持雙語用例。應用可以使用新的 API 獲取用戶選擇的語言區域，然后為多區域設置用戶提供更成熟的用戶體驗 — 如以多個語言顯示搜索結果，並且不會以用戶了解的語言翻譯網頁。
應用可以通過調用 LocaleList.GetDefault() 獲取用戶設置的語言區域列表。為支持擴展的語言區域數量，Android 7.0 正在改變其解析資源的方式。請務必使用新的資源解析邏輯測試和驗證您的應用是否能如期運行。
Android 8.0（targetSdkVersion =26）
這里簡單講一下主要API變更，具體的請閱讀上面的鏈接。
自適應圖標（應用圖標適配）
Android 8.0 引入自適應啟動器圖標。自適應圖標支持視覺效果，可在不同設備型號上顯示為各種不同的形狀。
最大屏幕縱橫比（為了全面屏適配）
以 Android 7.1（API 級別 25）或更低版本為目標平台的應用默認的最大屏幕縱橫比為 1.86。針對 Android 8.0 或更高版本的應用沒有默認的最大縱橫比。如果您的應用需要設置最大縱橫比，請使用定義您的操作組件的清單文件中的 maxAspectRatio 屬性。
權限
1、Android 8.0 引入了多個與電話有關的新權限：
- ANSWER_PHONE_CALLS 允許您的應用通過編程方式接聽呼入電話。要在您的應用中處理呼入電話，您可以使用 acceptRingingCall() 函數。
- READ_PHONE_NUMBERS 權限允許您的應用讀取設備中存儲的電話號碼。
2、在 Android 8.0 之前，如果應用在運行時請求權限並且被授予該權限，系統會錯誤地將屬於同一權限組並且在清單中注冊的其他權限也一起授予應用。
對於針對 Android 8.0 的應用，此行為已被糾正。系統只會授予應用明確請求的權限。然而，一旦用戶為應用授予某個權限，則所有后續對該權限組中權限的請求都將被自動批准。
例如，假設某個應用在其清單中列出 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE。應用請求 READ_EXTERNAL_STORAGE，並且用戶授予了該權限。如果該應用針對的是 API 級別 24 或更低級別，系統還會同時授予 WRITE_EXTERNAL_STORAGE，因為該權限也屬於同一 STORAGE 權限組並且也在清單中注冊過。如果該應用針對的是 Android 8.0，則系統此時僅會授予 READ_EXTERNAL_STORAGE；不過，如果該應用后來又請求 WRITE_EXTERNAL_STORAGE，則系統會立即授予該權限，而不會提示用戶。
語言區域和國際化
Android 7.0（API 級別 24）引入能指定默認類別語言區域的概念，但是某些 API 在本應使用默認 DISPLAY 類別語言區域時，仍然使用不帶參數的通用 Locale.getDefault() 函數。現在，在 Android 8.0 中，以下函數使用 Locale.getDefault(Category.DISPLAY) 來代替 Locale.getDefault()：
允許安裝未知來源應用
針對 8.0 的應用需要在 AndroidManifest.xml 中聲明 REQUEST_INSTALL_PACKAGES 權限，否則將無法進行應用內升級。
<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
通知
通知渠道：Android 8.0 引入了通知渠道，其允許您為要顯示的每種通知類型創建用戶可自定義的渠道。用戶界面將通知渠道稱之為通知類別。
Android 9.0（targetSdkVersion =28）
這里簡單講一下主要API變更，具體的請閱讀上面的鏈接。
顯示屏缺口支持（劉海屏適配）
Android 9 支持最新的全面屏，其中包含為攝像頭和揚聲器預留空間的屏幕缺口。 通過 DisplayCutout 類可確定非功能區域的位置和形狀，這些區域不應顯示內容。 要確定這些屏幕缺口區域是否存在及其位置，請使用 getDisplayCutout() 函數。
利用 Wi-Fi RTT 進行室內定位
Android 9 添加了對 IEEE 802.11mc Wi-Fi 協議（也稱為 Wi-Fi Round-Trip-Time(RTT)）的平台支持，從而讓您的應用可以利用室內定位功能。
Crypto provider去掉了
已知影響的主要是AES加密，網上的一些沒有添加對28版本號判斷的工具類都是不可行的。建議換成官網的。
參考資料：https://blog.csdn.net/drkcore/article/details/69931654
Http網絡請求
Google表示，為保證用戶數據和設備的安全，針對下一代 Android 系統(Android P) 的應用程序，將要求默認使用加密連接，這意味着 Android P 將禁止 App 使用所有未加密的連接，因此運行 Android P 系統的安卓設備無論是接收或者發送流量，未來都不能明碼傳輸，需要使用下一代(Transport Layer Security)傳輸層安全協議，而 Android Nougat 和 Oreo 則不受影響。
在Android P系統的設備上，如果應用使用的是非加密的明文流量的http網絡請求，則會導致該應用無法進行網絡請求，https則不會受影響，同樣地，如果應用嵌套了webview，webview也只能使用https請求。
有以下三種解決方案
- APP改用https請求
- targetSdkVersion 降到27以下
- 在 res 下新增一個 xml 目錄，然后創建一個名為：network_security_config.xml 文件（名字自定） ，內容如下，大概意思就是允許開啟http請求
<?xml version="1.0" encoding="utf-8"?>
<!-- 適配Android9.0 -->
<network-security-config>
<base-config cleartextTrafficPermitted="true" />
</network-security-config>
然后在APP的AndroidManifest.xml文件下的application標簽增加以下屬性：
android:networkSecurityConfig="@xml/network_security_config"
參考資料：http://www.cnblogs.com/renhui/p/9921790.html
https://developer.android.google.cn/training/articles/security-config
通知
提升短信體驗
渠道設置、廣播和請勿打擾
多攝像頭支持和攝像頭更新
在運行 Android 9 的設備上，您可以通過兩個或更多物理攝像頭來同時訪問多個視頻流。] 在配備雙前置攝像頭或雙后置攝像頭的設備上，您可以創建只配備單攝像頭的設備所不可能實現的創新功能，例如無縫縮放、背景虛化和立體成像。 通過該 API，您還可以調用邏輯或融合的攝像頭視頻流，該視頻流可在兩個或更多攝像頭之間自動切換。
動畫
Android 9 引入了 AnimatedImageDrawable 類，用於繪制和顯示 GIF 和 WebP 動畫圖像。 AnimatedImageDrawable 的工作方式與 AnimatedVectorDrawable 的相似之處在於，都是渲染線程驅動 AnimatedImageDrawable 的動畫。 渲染線程還使用工作線程進行解碼，因此，解碼不會干擾渲染線程的其他操作。 這種實現機制允許您的應用在顯示動畫圖像時，無需管理其更新，也不會干擾應用界面線程上的其他事件。