android系統適配

A. android 10（29）適配方案簡要說明

Android 10（29）適配方案簡要說明

1、根據Google官方文檔說明，Android10引入了大量變更

官方文檔： https://developer.android.google.cn/about/versions/10/highlights?hl=zh_cn

1.1、Android 10 中的隱私權變更

1.1.1重大隱私權變更

分區存儲

針對外部存儲的過濾視圖，可提供對特定於應用的文件和媒體集合的訪問許可權 訪問和共享外部存儲中的文件的應用 使用特定於應用的目錄和媒體集合目錄

增強了用戶對位置許可權的控制力

僅限前台許可權，可讓用戶更好地控制應用對設備位置信息的訪問許可權 在後台時請求訪問用戶位置信息的應用 確保在沒有後台位置信息更新的情況下優雅降級

使用 Android 10 中引入的許可權在後台獲取位置信息

系統執行後台 Activity

針對從後台啟動 Activity 實施了限制 不需要用戶互動就啟動 Activity 的應用 使用通知觸發的 Activity

不可重置的硬體標識符

針對訪問設備序列號和 IMEI 實施了限制 訪問設備序列號或 IMEI 的應用 使用用戶可以重置的標識符

無線掃描許可權

訪問某些 WLAN、WLAN 感知和藍牙掃描方法需要獲得精確位置許可權 使用 WLAN API 和藍牙 API 的應用 針對相關使用場景請求 ACCESS_FINE_LOCATION 許可權

1.1.2更多隱私權變更

標識符和數據： 針對硬體標識符（如 IMEI、序列號、MAC 和類似數據）實施了新限制。

移除了聯系人親密程度信息

隨機分配 MAC 地址

對 /proc/net 文件系統的訪問許可權實施了限制

對不可重置的設備標識符實施了限制

限制了對剪貼板數據的訪問許可權

保護 USB 設備序列號

攝像頭和連接性： 針對攝像頭元數據和連接 API 提供了更強大的保護措施。 對訪問攝像頭詳情和元數據的許可權實施了限制

對啟用和停用 WLAN 實施了限制

對直接訪問已配置的 WLAN 網路實施了限制

一些電話 API、藍牙 API 和 WLAN API 需要精確位置許可權

許可權 ： 針對許可權模型和要求的一些變更。

限制對屏幕內容的訪問

面向用戶的許可權檢查（針對舊版應用）

身體活動識別

從界面中移除了許可權組

1.2影響應用的行為變更

文檔： https://developer.android.google.cn/about/versions/10/behavior-changes-all?hl=zh_cn

限制非 SDK 介面： 為了幫助確保應用的穩定性和兼容性，Android 平台開始限制應用在 Android 9（API 級別 28）中使用非 SDK 介面。Android 10 包含更新後的受限制非 SDK 介面列表（基於與 Android 開發者之間的協作以及最新的內部測試）。我們的目標是在限制使用非 SDK 介面之前確保有可用的公開替代方案。

手勢導航： 從 Android 10 開始，用戶可以在設備中啟用手勢導航。用戶啟用後，手勢導航會影響設備上的所有應用，無論應用是否以 API 級別 29 為目標平台。例如，如果用戶從屏幕邊緣向內滑動，系統會將該手勢解讀為「返回」導航，除非應用針對屏幕的相應部分明確替換該手勢。

NDK 方面的變更

共享對象不得包含文本重定位

Bionic 庫和動態鏈接器路徑變更

系統二進制文件/庫會映射到只執行內存

安全方面的變更

 TLS 1.3 默認處於啟用狀態

TLS 不信任使用 SHA-1 簽名的證書

KeyChain 行為變更和改進

其他 TLS 和加密更改

WLAN 直連廣播

在 Android 10 中，以下與 WLAN 直連相關的廣播不具有粘性：

WIFI_P2P_CONNECTION_CHANGED_ACTION

WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

如果的應用依賴於在注冊時接收這些廣播（因為其之前一直具有粘性），請在初始化時使用適當的 get() 方法獲取信息。

WLAN 感知功能  

Android 10 擴大了支持范圍，現在可以使用 WLAN 感知數據路徑輕松創建 TCP/UDP 套接字。要創建連接到 ServerSocket 的 TCP/UDP 套接字，客戶端設備需要知道伺服器的 IPv6 地址和埠。這在之前需要通過頻外方式進行通信（例如使用 BT 或 WLAN 感知第 2 層消息傳遞），或者使用其他協議（例如 mDNS）通過頻內方式發現。而藉助 Android 10，可以將此類消息作為網路設置的一部分進行傳遞。

Go 設備上的 SYSTEM_ALERT_WINDOW

在 Android 10（Go 版本）設備上運行的應用無法獲得 SYSTEM_ALERT_WINDOW 許可權。這是因為繪制疊加層窗口會使用過多的內存，這對低內存 Android 設備的性能十分有害。

如果在搭載 Android 9 或更低版本的 Go 版設備上運行的應用獲得了 SYSTEM_ALERT_WINDOW 許可權，則即使設備升級到 Android 10，也會保留此許可權。不過，尚不具有此許可權的應用在設備升級後便無法獲得此許可權了。

如果 Go 設備上的應用發送具有 ACTION_MANAGE_OVERLAY_PERMISSION 操作的 intent，則系統會自動拒絕此請求，並將用戶轉到設置屏幕，上面會顯示不允許授予此許可權，原因是它會減慢設備的運行速度。如果 Go 設備上的應用調用 Settings.canDrawOverlays()，則此方法始終返回 false。同樣，這些限制不適用於在設備升級到 Android 10 之前便已收到 SYSTEM_ALERT_WINDOW 許可權的應用。

關於以舊版 Android 系統為目標平台的應用的警告

在搭載 Android 10 或更高版本的設備上，如果用戶首次運行以 Android 5.1（API 級別 22）或更低版本為目標平台的應用，則會看到警告。如果此應用要求用戶授予許可權，則系統會先向用戶提供調整應用許可權的機會，然後才會允許此應用首次運行。

由於 Google Play 的目標 API 方面的要求，用戶只有在運行最近未更新的應用時才會看到這些警告。對於通過其他商店分發的應用，我們也將於 2019 年引入類似的目標 API 方面的要求。如需詳細了解這些要求，請參閱在 2019 年擴展目標 API 級別方面的要求。

移除了 SHA-2 CBC 加密套件

以下 SHA-2 CBC 加密套件已從平台中移除：

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

這些加密套件不如使用 GCM 的類似加密套件安全，並且大多數伺服器要麼同時支持這些加密套件的 GCM 變體和 CBC 變體，要麼二者均不支持。

應用使用情況的變更

UsageStats 應用使用情況方面的改進 - 當在分屏或畫中畫模式下使用應用時，Android 10 現在能夠使用 UsageStats 准確地跟蹤應用使用情況。此外，Android 10 可以正確地跟蹤免安裝應用的使用情況。

按應用開啟灰度模式 - Android 10 可針對各個應用設置灰度顯示模式。

按應用開啟干擾模式 - Android 10 可以選擇性地將應用設置為「干擾模式」，此時系統會禁止顯示其通知，並且不會將其顯示為推薦的應用。

暫停和播放 - 在 Android 10 中，暫停的應用無法播放音頻。

HTTPS 連接變更

如果在 Android 10 上運行的應用將 null 傳遞給 setSSLSocketFactory()，則會出現 IllegalArgumentException。在以前的版本中，將 null 傳遞給 setSSLSocketFactory() 與傳入當前的默認 SSL 套接字工廠效果相同。

android.preference 庫已棄用

從 Android 10 開始，將棄用 android.preference 庫。開發者應該改為使用 AndroidX preference 庫，這是 Android Jetpack 的一部分。如需獲取其他有助於遷移和開發的資源，請查看經過更新的設置指南以及我們的公開示例應用和參考文檔。

ZIP 文件實用程序庫變更

Android 10 對 java.util.zip 軟體包（用於處理 ZIP 文件）中的類進行了以下變更。這些變更會讓庫的行為在 Android 和使用 java.util.zip 的其他平台之間更加一致。

Inflater

在以前的版本中，如果在調用 end() 之後調用 Inflater 類中的某些方法，這些方法會拋出 IllegalStateException。在 Android 10 中，這些方法會改為拋出 NullPointerException。

ZipFile

在 Android 10 及更高版本中，如果所提供的 ZIP 文件不包含任何文件，則 ZipFile 的構造函數（採用的參數類型為 File、int 和 Charset）不會拋出 ZipException。

ZipOutputStream

在 Android 10 及更高版本中，如果 ZipOutputStream 中的 finish() 方法嘗試為不包含任何文件的 ZIP 文件寫入輸出流，則此方法不會拋出 ZipException。

攝像頭變更

很多使用攝像頭的應用都會假定如果設備採用縱向配置，則物理設備也會處於縱向，正如攝像頭方向中所述。在過去可以做出這樣的假定，但隨著可用的設備類型（例如可折疊設備）的擴展，這一情況發生了變化。針對這些設備做出這樣的假定可能導致相機取景器的顯示產生錯誤的旋轉和/或縮放。

以 API 級別 24 或更高級別為目標平台的應用應該明確設置 android:resizeableActivity，並提供必要的功能來處理多窗口操作。

電池用量跟蹤

從 Android 10 開始，只要在發生重大充電事件之後拔下設備電源插頭，SystemHealthManager 就會重置其電池用量統計信息。一般來說，重大充電事件指的是設備電池已充滿，或者設備電量從幾乎耗盡變為即將充滿。

在 Android 10 之前，無論何時拔下設備電源插頭，無論電池電量有多微小的變化，電池用量統計信息都會重置。

Android Beam 已棄用

在 Android 10 中，我們正式棄用了 Android Beam，這是一項舊版功能，可通過近距離無線通信 (NFC) 在多個設備之間啟動數據共享。我們還棄用了一些相關的 NFC API。Android Beam 仍可供需要的設備製造商合作夥伴使用，但它已不再處於積極的開發階段。不過，Android 仍將繼續支持其他的 NFC 功能和 API，並且從標簽和付款中讀取數據等使用場景仍將繼續按預期執行。

B. Android-屏幕適配全攻略（絕對詳細）（一）

關鍵字： 屏幕適配 px dp dpi sp large限定符 .9.png

前言： 這篇文章依然是我在 [慕課網 ][h]學習 凱子哥 的同名視頻 Android-屏幕適配全攻略 ，所記錄下來的筆記---凱子哥講得真的超詳細。
[h]: http://www.imooc.com/ "MOOC"

從上圖可以看出，主流的解析度是前六種：1280×720、1920×1080、800×480、854×480、960×540、1184×720，不過我們有解決方案。看完這篇文章，想必你就可以解決常見的屏幕適配問題。

接下來正式進入正題。

介紹幾個在Android屏幕適配上非常重要的名詞：

屏幕尺寸 是指屏幕對角線的長度。單位是英寸，1英寸=2.54厘米
屏幕解析度 是指在橫縱向上的像素點數，單位是px，1px=1像素點，一般是縱向像素橫向像素，如1280×720
屏幕像素密度 是指每英寸上的像素點數，單位是dpi，即「dot per inch」的縮寫，像素密度和屏幕尺寸和屏幕解析度有關

dip： Density Independent Pixels（密度無關像素）的縮寫。以 160dpi 為基準，1dp=1px
dp： 同 dip
dpi： 屏幕像素密度的單位，「dot per inch」的縮寫

px： 像素，物理上的絕對單位

sp： Scale-Independent Pixels的縮寫，可以根據文字大小首選項自動進行縮放。Google推薦我們使用12sp以上的大小，通常可以使用12sp，14sp，18sp，22sp，最好不要使用奇數和小數。

用於區分不同的像素密度。

在Google官方開發文檔中，說明了 ** mdpi：hdpi：xhdpi：xxhdpi：xxxhdpi=2：3：4：6：8 ** 的尺寸比例進行縮放。例如，一個圖標的大小為48×48dp，表示在mdpi上，實際大小為48×48px，在hdpi像素密度上，實際尺寸為mdpi上的1.5倍，即72×72px，以此類推。

我們可以通過以下幾種方式來支持各種屏幕尺寸：

wrap_content： 根據控制項的內容設置控制項的尺寸
math_parent： 根據父控制項的尺寸大小設置控制項的尺寸
weight： 權重，在線性布局中可以使用weight屬性設置控制項所佔的比例

例如，我們要實現下圖所顯示的效果：當屏幕尺寸改變時，new reader控制項兩邊的控制項大小不變，new reader控制項會占完剩餘的空間。

具體布局文件如下：

小插曲： 關於 android:layout_weight 屬性

一般情況，我們都是設置要進行比例分配的方向的寬度為0dp，然後再用權重進行分配。如下：

效果為：

效果為：

button1寬度=L+（L-2L）×1/3=2/3L
button2寬度=L+（L-2L）×2/3=1/3L

當然，還有其他的方式，都可以運用此公式進行計算。
在實際開發中，我們一般使用0dp的方式，而不使用其他方式。

簡單的布局一般都使用 線性布局 ，而略微復雜點的布局，我們使用 相對布局 ，大多數時候，我們都是使用這兩種布局的嵌套。

我們使用 相對布局 的原因是， 相對布局 能在各種尺寸的屏幕上保持控制項間的相對位置。

res/layout/main.xml 單面板：

res/layout-large/main.xml 雙面板：

如果這個程序運行在屏幕尺寸大於7inch的設備上，系統就會載入 res/layout-large/main.xml 而不是 res/layout/main.xml ，在小於7inch的設備上就會載入 res/layout/main.xml 。

需要注意的是，這種通過 large 限定符分辨屏幕尺寸的方法，適用於android3.2之前。在android3.2之後，為了更精確地分辨屏幕尺寸大小，Google推出了最小寬度限定符。

res/layout-sw600dp/main.xml ，雙面板布局： Small Width 最小寬度

這種方式是不區分屏幕方向的。這種最小寬度限定符適用於android3.2之後，所以如果要適配android全部的版本，就要使用 large 限定符和 sw600dp 文件同時存在於項目 res 目錄下。

這就要求我們維護兩個相同功能的文件。為了避免繁瑣操作，我們就要使用布局別名。

由於後兩個文具文件一樣，我們可以用以下兩個文件代替上面三個布局文件：

res/layout/main.xml 單面板布局
res/layout/main_twopanes.xml 雙面板布局

然後在 res 下建立
res/values/layout.xml 、
res/values-large/layout.xml 、
res/values-sw600dp/layout.xml 三個文件。

默認布局
res/values/layout.xml :

Android3.2之前的平板布局
res/values-large/layout.xml :

Android3.2之後的平板布局
res/values-sw600dp/layout.xml :

這樣就有了 main 為別名的布局。
在activity中 setContentView(R.layout.main);

這樣，程序在運行時，就會檢測手機的屏幕大小，如果是平板設備就會載入 res/layout/main_twopanes.xml ，如果是手機設備，就會載入 res/layout/main.xml 。我們就解決了只使用一個布局文件來適配android3.2前後的所有平板設備。

如果我們要求給橫屏、豎屏顯示的布局不一樣。就可以使用 屏幕方向限定符 來實現。
例如，要在平板上實現橫豎屏顯示不用的布局，可以用以下方式實現。
res/values-sw600dp-land/layouts.xml :橫屏

res/values-sw600dp-port/layouts.xml :豎屏

自動拉伸點陣圖，即android下特有的 .9.png 圖片格式。

當我們需要使圖片在拉伸後還能保持一定的顯示效果，比如，不能使圖片中的重要像素拉伸，不能使內容區域受到拉伸的影響，我們就可以使用 .9.png 圖來實現。

要使用 .9.png ，必須先得創建 .9.png 圖片，androidSDK給我們提供了的工具就包含 .9.png 文件的創建和修改工具。雙擊 SDK安裝目錄 oolsdraw9patch.bat ，就會打開下圖所示的窗口。

下面是一個例子：

Button屬性設置：

如果我們選擇的內容區域偏差太大，可能就不會顯示出text值 BUTTON 。

好了，這篇文章寫的有點多了，剩下的內容放在 下篇文章 記錄吧。
內容提要：
解決方案-支持各種屏幕密度
解決方案-實施自適應用戶界面流程

未完待續

C. Android的國際化語言適配(系統語言適配+APP內部適配)

Android國際化語言適配分為兩種

1.更改手機系統語言後，APP的語言也會跟著變化

2.只改變自己APP的語言，不受手機系統語言的影響，不影響其他APP的語言，可以參考微信的切換語言的效果。

只需要創建不同語言的values即可

具體操作參考  簡單的Android客戶端國際化(語言適配)方案

操作的時候要注意: 當選擇所要切換的語言後，則進行修改Config以及重啟APP，一定要將選擇的語言保存到SP中，且在activity中的oncreate中將SP中存儲的語言取出來重新設置Config，否則當重啟APP後，還是會跟系統語言一樣。 

具體操作參考  Android應用程序內部切換語言及自定義語言

D. Android設備的界面適配設計

Android設備App設計中有一個問題可能會被設計師忽略，在各種解析度各種明飢尺寸「雜屏」的界面適配。可能產出的界面稿在常用的720*1280的解析度中是完美，但一到各個不同解析度不同尺寸的設備後

這里就談談適配，了解適配讓設計從PS、sketch到移動設備上都能完美呈現。

如此繁雜的安卓設備，採用哪個標准設計呢？

1.選擇一種尺寸一種解析度作為基準。

2.選擇2-3款主流的Android設備，制定一套適配規則。（國內主流設備、解析度可參考友盟指數）

3.部分極端效果特別注釋說明。

目前移動端設計師多採用iPhone 5與6的解析度設計，這兩個解析度也最接近Android xhdpi的720*1280，設計之後再做等比適配（不做設計元素等比適配會導致Android設備上視覺呈現較小）。

我則傾向於選取720*1280的解析度設計。優點是處於常用解析度的中間值，對小解析度大解析度調整也較容易。另外iOS@1x的320與720剛好是2.25的倍率關系，使用sketch等比輸出快捷多了。（如果時間成本允許的話可以將Android的標注單位用dp，具體的設備尺寸、解析度知識這里不詳描述，可見文章最後面的「Android基礎知識」）

案例說明：

雅虎新聞為各個dpi做了優化，圖片等比縮放，文字區域等比縮放，並且考慮到在低dpi下會被推移至第二屏，就減小圖片了高度，保持文字區域最小高度。

老司機都不會忘記的，僅提醒下新手，每個圖標記得輸出多個比例。並且記得查看各個比例下圖標的顯示效果。

案例說明：

還是拿一個雅虎新聞的例子，大家感受下。

Android設備的系統各個廠商都做了定製化，默認的字體庫可能不同，且字體占空間大小可能不同。不同設備顯示文字會出現不同效果。設計時考慮3點：

多採用流式布局，不對單行做字數限制（如「單行顯示多少個字」「文本寬度多少」），而是定義文本容器的高寬，超出則用「…」「漸隱」或者「遮擋」等方式省略。

若較長的文本需要完整顯示，設計時預留換行空間。

若文本需要在單行完整顯示（如提示類文字），盡量控制字數（建議16字內），避免小屏不夠放置。

案例說明：

圖文混排同一行顯示時，圖片等比固定在右側顯示，文字部分區域寬度會因設備不同出現較大的差異，預留文字多行高度。如下圖不同設備下文字的展示空間有差異，需要考慮小解析度下預留多行文字空間。如圖2第二條新聞標題文字溢出的醜陋展示，建議設定一個文字區域最大高度，超出部分則隱藏。

單行出現多個文字元素時，注意元素在低dpi下的顯示層級，提前說明好該情況的清激覆蓋或者隱藏規則。如下圖第一個用戶名稱，在低dpi下，避免各元素交錯，而省略了超出的用戶名稱。

圖片常用的方式有固定寬度dp等比縮放高度（用於非通欄圖片）；固定高度dp等比縮放寬度（用於橫向滾動圖片，如全屏相冊中的縱向圖片）；根據屏幕寬度等比縮放（橫向通欄圖片）。設計時考慮3點：

注意圖片佔用的寬高比，避免大屏設備上占據大量空間，導致內容比例不協調同時降低了屏幕利用率。

考慮到設備屏幕密度不同，輸出圖片時別忘了輸出多個解析度。

考慮圖片寬高比過大的縮略圖處理（最常見的處理方式：高度遠大於寬度時，是給出最大區域，讓圖片等寬居中填充該區域，只顯示該區域；寬度遠大於高度時，與展示區域等高居中取部分顯示。當然也可能出現特殊顯示要求，需要根據具體情況具體處理。）

案例說明：激正返

網易游戲相冊的全屏瀏覽中，大於設備寬高比的寬圖按照最大寬度放置，小於設備寬高比的高度按照最大高度放置。

一行多張圖片要考慮圖片的在不同設備下等比縮放帶來顯示效果的差異。排列時會有兩種情況：

1.要求在一行內顯示完，根據圖片的顯示效果決定放置的數量，超過則不顯示（如下圖1第二條新聞）

2.流式布局，當圖片寬度小於設定值時自動換行（如下圖2相冊展示，低dpi低解析度設備一行顯示3張，高的顯示4-5張，且按比例撐滿屏幕寬度）。

寬高比超出設計區域時的處理，如網路貼吧中列表的小圖模式，給出了正方形區域，當圖片非正方形時，根據寬高中的短邊等比撐滿正方形區域後，截取了圖片居中的部分顯示。

在固定區域內多元素混合放置時，文字一般採取流式布局，圖片多採用等比縮放，圖標元素多採用 彈性布局，即元素內容本身規格不變，考慮水平、垂直方向的間距做相應擴展。設備屏幕越大，在擴展方向上可以顯示更多內容，發揮了大屏幕的優勢。

彈性布局需要給出哪一個元素dp不變，哪一個元素縮放的策略。

彈性布局下部分距離標注採用百分比標注。

當有兩個等比縮放元素時考慮避免重疊的情況。

案例說明：

網易游戲的新聞列表樣式，每一條新聞區域，要求圖片dp不變，而文字區域進行彈性縮放。

下圖網易游戲專區中間的幽靈按鈕圖標為確保點按效果，按照固定dp顯示，中間間隔的寬度按照設備寬度的百分比來確定

網易游戲求交往的界面，中間卡片區域大小根據設備等比縮放，如中間用戶頭像與「同喜歡2款游戲」的文字，在設計時需要考慮產品的目標設備中最小設備下的布局顯示效果，避免出現重疊的情況。而縱向的元素數量也需要如此考慮。

Android界面適配的案例說明就寫到這里啦。

設計時多考慮各個元素（圖標、文本、圖片、區域）在不同設備的情況。當然，做設計時也不是死板的按照建議來實現，特別是固定區域下的元素放置，根據實際情況來處理即可。

Android系統的UI也在不斷進化完善，隨著設計趨勢的改變，Android除了常見的卡片、列表、浮層外，可能會有更多的展示方式，而Android設備也是逐漸淘汰ldpi與mdpi，設備的解析度逐漸變大。也就要求我們需要不斷的去了解嘗試新的設計趨勢，產出最好的方案。

這不是彩蛋哈，僅僅補充安卓設備的基礎知識，老司機完全可以忽略，供新手參考閱讀。

為展示設備的多樣化，貼出Android屏幕尺寸示意圖（藍色矩形的大小代表不同尺寸，顏色深淺則代表所佔百分比的大小。）

屏幕大小以屏幕尺寸來衡量，指屏幕的對角線的長度，單位是英寸，1英寸=2.54厘米

目前的主流尺寸：5.0" ~ 5.5" (有繼續往更大尺寸發展的趨勢，但趨於穩定)

常見的設備尺寸： 4" ~ 10" 。

手機適配參考尺寸： 4" ~ 6"

手機 + 平板適配參考尺寸： 4" ~ 10」

屏幕解析度是指在橫縱向上的像素點數，單位是px，1px=1個像素點。一般以縱向像素*橫向像素，如1960*1080。

屏幕像素密度是指每英寸上的像素點數，單位是dpi，即「dot per inch」的縮寫。目前每個屏幕像素可以認為就是一個「點」。

屏幕 dpi 的計算方式:

Android 設備中 dpi 分幾個段：

•ldpi：~ 120 dpi (幾乎絕跡)

•mdpi：~ 160 dpi (罕見)

•hdpi：~ 240 dpi (逐漸減少中)

•xhdpi：~ 320 dpi

•xxhdpi：~ 480 dpi

•xxxhdpi：~ 640dpi (目前較少)

dp(與 dip 同義) 是在 160dpi 下每個像素對應的物理尺寸，可近似理解為:

•160 dp = 1 inch

•1 dp = 1 / 160 inch = 0.15875 mm

•1 dp = 1 px (160 dpi 屏幕下)

•1 dp = 2 px (320 dpi 屏幕下)

Android的屏幕適配指標都基於物理尺寸（即屏幕的物理大小），而非像素（解析度）。為什麼呢？這里根據dp與px適配出兩種效果來說明。

按 dp 適配不同屏幕的效果如下，內容的物理尺寸變化不大:

若直接按照像素適配，出現以下情況，高像素密度的設備內容顯得特別小，影響布局與可用性：

屏幕長邊和短邊的比例。

目前手持設備的 長邊 dpi 和 短邊 dpi 普遍非常接近，可認為屏幕比例和屏幕水平、垂直像素比例一致

屏幕比例目前趨於 16:9 ~ 16:10 (8:5)

因不少設備使用了虛擬按鍵，所以通常非全屏的 app 可用面積略低，屏幕比例更接近 16:10

E. 安卓軟體適配多少安卓系統

安卓軟體適配兩版安卓系統。安卓軟體是安卓公司開發的軟體，適配目前在市面上流通的兩版安卓系統。

F. Android兼容性適配（一）—— 設備兼容性概覽

Android 適用於眾多類型的設備，從手機到平板電腦和電視都能搭載使用。作為開發者，如此廣泛的設備類型能為您的應用帶來廣大的潛在受眾群體。為了能在所有這些設備上順利運行，應用應該容許部分設備功能的變化，並提供可適應不同屏幕配置的靈活界面。

隨著您進一步閱讀 Android 開發相關內容，您可能會在各種語境下遇到「兼容性」一詞。兼容性有兩種類型：設備兼容性和應用兼容性。

作為應用開發者，您無需擔心設備是否兼容 Android，因為只有與 Android 兼容的設備才會附帶 Google Play 商店或該設備的官方手機應用市場。因此，您可以放心，通過Google Play 商店和官方手機應用市場安裝您的應用的用戶使用的是 Android 兼容設備。

不過，您確實需要考慮您的應用是否兼容每一種可能的設備配置。由於 Android 以各種設備配置運行，因此部分功能並不適用於所有設備。例如，某些設備可能未配備羅盤感測器。如果應用的核心功能需要使用羅盤感測器，那麼應用只能與帶有羅盤感測器的設備兼容。

應用可通過平台 API 利用 Android 支持的各種功能。有些功能基於硬體（例如羅盤感測器），有些功能基於軟體（如應用窗口微件），有些功能則依賴於平台版本。並非每台設備都支持所有功能，因此您可能需要根據應用所需的功能控制應用在設備上的可用性。

要盡可能擴大應用的用戶群，您應設法使用單個 APK 支持盡可能多的設備配置。在大多數情況下，要實現這一目標，您可以在運行時停用可選功能，並為應用資源提供針對不同配置的替代選項（例如針對不同屏幕尺寸的不同布局）。不過，如果需要，您可以根據以下設備特徵，通過 Google Play 商店限制應用在設備上的可用性：

為了讓您根據設備功能管理應用的可用性，Android 為可能並不適用於所有設備的任何硬體或軟體功能定義了功能 ID。例如，羅盤感測器的功能 ID 為 FEATURE_SENSOR_COMPASS，而應用微件的功能 ID 為 FEATURE_APP_WIDGETS。

根據需要，要在用戶的設備不具備特定功能時阻止用戶安裝您的應用，您可以通過應用清單文件中的<uses-feature>元素聲明這一點。

例如，如果您的應用在沒有羅盤感測器的設備上沒有意義，您可以使用以下清單標記聲明需要羅盤感測器：

Google Play 商店會將您的應用所需的功能與每個用戶的設備上可用的功能進行比較，以確定您的應用是否與每台設備兼容。如果設備不具備您的應用所需的所有功能，則用戶無法安裝您的應用。

但是，如果應用的主要功能不需要某項設備功能，則應將required屬性設置為 "false"並在運行時檢查是否有該設備功能。如果應用功能在當前設備上不可用，請適當降級相應的應用功能。例如，您可以通過調用hasSystemFeature()來查詢功能是否可用，如下所示：

Java

Kotlin

不同的設備可能會運行不同版本的 Android 平台，例如 Android 4.0 或 Android 4.4。每個後續的平台版本通常會添加之前版本中不可用的新 API。為表明可用的 API 集，每個平台版本都會指定API 級別。例如，Android 1.0 是 API 級別 1，而 Android 4.4 是 API 級別 19。

通過 API 級別，您可以使用<uses-sdk>清單標記及其minSdkVersion屬性來聲明應用兼容的最低版本。例如，Android 4.0（API 級別 14）中添加了 日歷提供程序 API。如果您的應用在沒有這些 API 的情況下無法運行，您應將 API 級別 14 聲明為應用的最低支持版本。

minSdkVersion屬性聲明應用兼容的最低版本，targetSdkVersion屬性聲明應用經過優化後適用的最高版本。

不過，請注意<uses-sdk>元素中的屬性會被替換為build.gradle文件中的相應屬性。因此，如果您使用的是 Android Studio，則必須在其中指定minSdkVersion和targetSdkVersion值：

要詳細了解build.gradle文件，請參閱 如何配置編譯版本 。

每個後續版本的 Android 都為使用之前平台版本的 API 構建的應用提供兼容性，因此您的應用應始終與未來版本的 Android 兼容，同時使用已記錄的 Android API。

注意 ： targetSdkVersion 屬性不會阻止您的應用安裝在高於指定值的平台版本上，但它很重要，因為它向系統指示您的應用是否應繼承較新版本中的行為更改。如果您不將 targetSdkVersion 更新到最新版本，則系統會認為您的應用在最新版本上運行時需要一些向後兼容性行為。例如，在 Android 4.4 中的行為更改 中，使用 AlarmManager API 創建的鬧鍾現在默認不精確，因此系統可以批量處理應用鬧鍾並節省系統電量，但如果您的目標 API 級別低於「19」，則系統會為您的應用保留之前的 API 行為。

不過，如果您的應用使用的是較新平台版本中添加的 API，但其主要功能並不需要這些 API，則應在運行時檢查 API 級別，並在 API 級別過低時適當降級相應的功能。在這種情況下，請將 minSdkVersion 盡量設置為適用於應用主要功能的最低值，然後將當前系統的版本 SDK_INT 與 Build.VERSION_CODES 中對應於您要檢查的 API 級別的一個代號常量進行比較。例如：

Android 可在各種尺寸的設備上運行，包括手機、平板電腦和電視。為了按照屏幕類型對設備進行分類，Android 為每種設備定義了兩個特徵：屏幕尺寸（屏幕的物理尺寸）和屏幕密度（屏幕上像素的物理密度，稱為 DPI）。為了簡化不同的配置，Android 將這些變體歸納成組，使它們更容易作為定位目標：

四種廣義的尺寸：小、標准、大和特大。
還有幾種廣義的密度：mdpi（中）、hdpi（高）、xhdpi（超高）、xxhdpi（超超高）等。
默認情況下，您的應用會兼容所有屏幕尺寸和密度，因為系統會根據需要對各個屏幕的界面布局和圖片資源進行相應的調整。不過，您應針對不同的屏幕尺寸添加專門的布局，針對常見的屏幕密度添加優化的點陣圖圖片，以優化每種屏幕配置的用戶體驗。

G. 總結 - Android UI適配方案

1、最原始的dp+自信態適應布局+weight，多套dimens.xml
缺點：只能滿足90%以上的手機，同一像素的手機，dpi不一樣

2、smallestWidth適配,res 文件夾下創建冊滲各種屏幕分滑姿源辨率對應的 values-sw{xxx}dp 文件夾
缺點: 1、包會增加500kb左右
2、只支持3.2及以上的系統

3、AutoSize今日頭條屏幕適配方案
當前設備屏幕總寬度（單位為像素）/ 設計圖總寬度（單位為 dp) = density
原理：調用Android API，根據設備某一維度（寬或高）的真實長度（單位是px）與這一維度在UI設計圖上的dp值之間的關系，重新計算density來實現
缺點: 第三方庫適配

H. Android 13 適配指南

2022 的Google I/O 發布了 Android 13 beta 2 和 Android 13 Beta 1 國內廠商的設備支持列表，雖然按照慣帶羨嫌例， Android 13 應該是年末才發布正式版，但是相信有的開發者已經收到了平台的 Android13 的適配要求，所以本篇也是派陵結合 Oppo 的 Android 13 應用兼容性適配指導 和官方提供的一些文檔內容做一個整理測試。

目前 Android 13 主要的兼容問題還是在於隱私許可權上，所以本次的適配指南相關內容也是著重在這一部分， 這里涉及面比較廣的應該就是相冊和通知許可權 。

這個動圖大家可能看到過， 這是 Android 13 上提供的系統圖片選擇器，通過 Intent(MediaStore.ACTION_PICK_IMAGES); 就可以打開，支持視頻、音頻、圖片分類，支持多選和單選 ，另外官方也表示過，這個特性不僅僅會在 Android 13 中出現，谷歌還會將其放置到 Play 商店中，向 Android 11 和 Android 12 設備推送。

我們通過調整 TargetSDK 設置為 PreView ，然後運行到 Tiramisu 的模擬器上進行測試，主要測試 TargetSDK 在低於 "Tiramisu" 和等於 "Tiramisu" 時的不同情況。

如下圖所示：

總結： 所以如果是 TargetSDK 在 Android 13 以下，不需要處理，如果在 Android 13 以及以上 ，需要增加申請許可權 。

在 Android R 上設置里開始支蠢手持在設置里對應用的通知許可權進行管理，但是應用自身是無法修改應用級別的通知許可權，所以 App 無法知道自身有沒有發送通知的許可權

所以在 Android 13 里增加了通知的運行時許可權 ，其中 Android 13 (33) 的通知會根據正在運行的應用程序的目標 API 級別進行不同的處理， 不過不管應用程序的目標API級別如何，Android 13 都會提示用戶授予應用程序發送通知的許可權 。

例如下圖，是 targetSdk 30 運行在 Android 13 模擬器上，依然會彈出讓用戶是否允許推送 。

當然，系統也會根據應用程序的目標 API 級別處理通知訪問:

如果是 現有應用更新 ，程序的目標 API 級別為：

最後測試和總結一下：

由於 Android 之前可以通過跟蹤附近的 Wi-Fi AP 和藍牙設備來推斷設備的位置，所以這次谷歌決定禁止應用程序 訪問藍牙 結果，除非這類應用需要聲明 ACCESS_FINE_LOCATION 許可權。

在 Android 13 中，Google 將 Wi-Fi 掃描與位置相關內容分離， Android 13 為管理設備與周圍 Wi-Fi 熱點連接的應用添加 NEARBY_WIFI_DEVICES 運行時許可權 (屬於 NEARBY_DEVICES 許可權組)，從而在不需要 ACCESS_FINE_LOCATION 許可權的情況下，也可以讓應用訪問附近的 Wi-Fi 設備。

此前，對於僅需要連接 Wi-Fi 設備，但實際上並不需要了解設備位置的應用來說，以 Android 13 (33)為目標平台的應用現在可以通過 「 neverForLocation 」 屬性來完善申請 NEARBY_WIFI_DEVICES 許可權。

這項新許可權會影響幾個不同的 Wi-Fi 用例，包括以下用例：

所以開發需要區分不同api對應的許可權；

由於 NEARBY_WIFI_DEVICES 許可權僅適用於 Android 13 或更高版本， 如果是 Android12L(32) 以及以下的 App 應保留對 ACCESS_FINE_LOCATION 的所有聲明：

以 Android 13(33) 為目標平台時，如果應用不會通過 Wi-Fi API 推導物理位置，請在清單文件中將 usesPermissionFlags 屬性設為 neverForLocation。

所以總結： 以 Android 13(33) 為目標平台的應用程序，訪問附近的 WI-FI 設備。除特例API需要申請ACCESS_FINE_LOCATION外，其他需要申請 android.permission.NEARBY_WIFI_DEVICES 運行時許可權 ；

Android 13 中引入了 「在使用時」 訪問身體感測器（例如心率、體溫和血氧飽和度）的概念，此訪問模式與 Android 10（API 級別 29）系統為位置信息 引入的模式非常相似。

如果你的 App 以 Android 13(33) 為目標平台，並且在後台運行時需要訪問身體感測器信息，那麼除了現有的 BODY_SENSORS 許可權外，還必須聲明新的 BODY_SENSORS_BACKGROUND 許可權 。

當 App 以 Android 13(33) 或更高版本為 Target 的其他應用的導出組件發送 intent 時，僅當該 intent 與接收應用中的 <intent-filter> 元素匹配時，系統才會傳送該 intent，換言之系統會屏蔽所有不匹配的 intent，但以下情況除外：

為了幫助提高運行時接收器的安全性，Android 13 允許你指定 App 中的特定廣播接收器是否應被導出以及是否對設備上的其他應用可見，此變更是 Android 12 更安全的組件 的延續；

以 Android 13(33) 或更高版本為目標平台的應用，必須為每個廣播接收器指定 RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED ，否則當 App 嘗試注冊廣播接收器時，系統會拋出 SecurityException

在 Android 13中，谷歌添加了一個新的API，允許開發者降級許可權。

應用程序可以觸發撤銷授予調用 API 的包的一個或多個運行時許可權，不需要訪問特定運行時許可權控制 API 的應用程序可以自行撤銷這些許可權，這樣用戶就可以確保這些應用程序不會在不知情的情況下使用這些API。

如需撤消特定運行時許可權，請將該許可權的名稱傳入 revokeOwnPermissionOnKill() 方法，如需同時撤消一組運行時許可權，請將這組許可權的名稱傳入 revokeOwnPermissionsOnKill() 。

系統只有在安全的情況下才會觸發撤消操作，也就是當有應用組件仍在前台運行，或者有另一個應用正在訪問你應用的組件（如 content provider）時不會發生撤消。

Android 之前一直提供了一個剪貼板服務，所有 App 都可以使用它來放置和檢索文本。

盡管從技術上講，任何應用都可以清除全局剪貼板中的主內容（只要它們是前台應用或 Android 10+ 上的默認輸入法），但 Android 本身不會自動清除剪貼板。

這意味著任何留在全局剪貼板中的剪貼板內容，都可以在以後被應用程序讀取，盡管 Android 的剪貼板訪問有 toast 消息可能會提醒用戶。

Android 13 增加了剪貼板自動清除功能，此功能在默認情況下處於禁用狀態，在經過設定的時間後，將自動從全局剪貼板中清除主剪輯， 默認情況下經過3600000毫秒（60分鍾）後，剪貼板將被清除。

每次執行復制/讀取（寫入剪貼板 setPrimaryClip ，讀 getPrimaryClip ）時，會重置一個消息 timeout（60min），之後會自動清除剪貼板內存中的內容，即60min內，如果一直沒有寫入剪貼板的操作，剪貼板的內容會被自動清除。

Android 13 的新前台服務（ Foreground Services：FGS）任務管理器顯示當前運行前台服務的應用程序列表，此列表稱為活動應用程序，可以通過下拉通知抽屜並點擊啟示來訪問，這時候每個應用程序旁邊都會有一個「停止」按鈕。

利用 JobScheler，應用可使用 JobInfo.Builder.setPrefetch() 將特定作業標記為「預提取」，這意味著理想情況下這些作業應該在應用下一次啟動前提前一點運行，以提升用戶體驗。

過去，JobScheler 僅使用該信號讓預提取作業有機會使用免費或多餘的數據，在 Android 13 中系統現在會嘗試確定應用下次啟動的時間，並根據該估算值運行預提取作業，應用應嘗試使用「預提取」來完成他們想要在下次應用啟動前完成的任何工作。

Android 13 中引入了 電池資源利用率 功能，以便為系統提供多種方法來更好地管理設備電池續航時間：

I. Android 屏幕適配

摘自： https://www.jianshu.com/p/ec5a1a30694b
摘自： https://www.jianshu.com/p/337c47721690
摘自： https://www.jianshu.com/p/4669814362ee

因為ui設計師給你的設計圖是以px為單位的，Android開發則是使用dp作為單位的，那麼我們需要進行轉換：

擴展：
Android屏幕適配-基礎篇

   Android推薦使用dp作為尺寸單位來適配UI ，通過dp加上自適應布局和weight比例布局可以基本解決不同手機上適配的問題，這基本是最原始的Android適配方案。
   缺點：
  （1）這種方案只能保證我們寫出來的界面適配絕大部分手機，部分手機仍然需要單獨適配，但dpi的不同，還是會存在差異。
  （2）一般的設計稿都是以px為單位的，所以我們在寫layout文件的時候需要將px轉為dp，影響開發效率。

  為了高效的實現UI開發，出現了新的適配方案，我把它稱作寬高限定符適配。簡單說，就是模仿市面上所有的Android手機的寬高像素值，設定一個基準的解析度，其他解析度都根據這個基準解析度來計算，在不同的尺寸文件夾內部，根據該尺寸編寫對應的dimens文件:

   鴻洋大神的作品 ，使用也超級簡單，核心功能就是在繪制的時候在onMeasure裡面做變換，重新計算px。

   缺點：
  我們自定義的控制項可能會被影響或限制，可能有些特定的控制項（框架沒有做適配的控制項），需要單獨適配。

小結：上述幾種適配方案都是實際開發中用過的方案，但隨著技術不斷的更新，出現了更好的適配方案。

   1.SmallestWidth適配（sw限定符適配）
   實現原理：
  Android會識別屏幕可用高度和寬度的最小尺寸的dp值（其實就是手機的寬度值），然後根據識別到的結果去資源文件中尋找對應限定符的文件夾下的資源文件。

   sw限定符適配 和 寬高限定符適配 類似，區別在於，前者有很好的容錯機制，如果沒有value-sw360dp文件夾，系統會向下尋找，比如離360dp最近的只有value-sw350dp，那麼Android就會選擇value-sw350dp文件夾下面的資源文件。這個特性就完美的解決了上文提到的寬高限定符的容錯問

   優點：
    1.非常穩定，極低概率出現意外
    2.不會有任何性能的損耗
    3.適配范圍可自由控制，不會影響其他三方庫
   缺點：
    就是多個dimens文件可能導致apk變大，幾百k。

    這里有個問題：
    在項目的其他 mole 中怎麼實現適配？難道也要多套 dimens 文件？

    解答：
    並不需要多套 dimens 文件，只需要在 values 文件夾下有一套與 app mole 一樣的 dimens 文件即可達到適配。因為經過編譯，所有 mole 中的 dimen 數據都會統一歸類到主 mole（即 app mole）中的 values/dimens.xml 文件中了，然後系統又會根據你設置的值去找對應 values-swxxxdp 文件夾下的dimens.xml 文件中的值。

附件： [生成sw文件的工具]( https://links.jianshu.com/go ?

to=https%3A%2F%2Fgithub.com%2Fladingwu%2Fdimens_sw)

實現原理：修改系統的density值（核心）
  今日頭條適配是以設計圖的寬或高進行適配的，適配最終是改變系統density實現的。
過程：

缺點：
   1.只需要修改一次 density，項目中的所有地方都會自動適配，這個看似解放了雙手，減少了很多操作，但是實際上反應了一個缺點，那就是只能一刀切的將整個項目進行適配，但適配范圍是不可控的。
   2.這個方案依賴於設計圖尺寸，但是項目中的系統控制項、三方庫控制項、等非我們項目自身設計的控制項，它們的設計圖尺寸並不會和我們項目自身的設

  AndroidAutoSize 是基於今日頭條適配方案，該開源庫已經很大程度上解決了今日頭條適配方案的兩個缺點，可以對activity，fragment進行取消適配。也是目前我的項目中所使用的適配方案。

   使用也非常簡單只需兩步：
     第一步： 導入依賴

     第二步： 配置AndroidManifest
     在 AndroidManifest 中填寫全局設計圖尺寸 (單位 dp)，如果使用副單位，則可以直接填寫像素尺寸，不需要再將像素轉化為 dp，詳情請查看 demo-subunits

老師給的UI設計是在藍湖上的，因為還沒工作，接觸就藍湖，SW個人感覺好處就是藍湖上尺寸多少你就寫多少就行

J. android 屏幕適配基礎知識

最近參考 今日頭條演算法 ，優化了項目的屏幕適配策略。下面是適配過程中的一些心得，部分內容來源於網路。

舉個例子：屏幕解析度為：1920*1080，屏幕尺寸為5吋的話，那麼dpi為440。

dp就是密度自適應的像素。1dp表示 在dpi為160的設備上的一顆像素
px與dp的換算公式px = dp * (dpi / 160)，很顯然，由於相同解析度但不同屏幕大小的設備dpi是不同的，導致px和dp的基本不存在一個固定的換算關系，為了方便屏幕適昌做配，Android設置了6個通用的密度，換算px與dp時採取通用密度計算，而非設備實際的密度。

以下為6種通用密度，以及其最小的解析度

得到上面通用密度之後，我們換算dp與px多了一種簡便方式。Android系統用mdpi(160dpi)作為基準，此時1px = 1dp，又有px = dp * (dpi / 160)，所以我們可以很容易的得到以下換算：

sp在dp的基礎上引入了scaleFactor變數，一般用於字型大小，可在系統設置里調大。

同一張圖片放到以上4個解析度類肆羨型的文件夾里，在頁面上呈現的效果如下

實際呈現的演算法為： 圖片尺寸 * 系統density / 文件夾 density
因為圖片尺寸、系統density都是固定的，因此圖片最終尺寸表現為： 圖片放的位置越"low"，呈現的尺寸越大

比如 圖片寬度200px，系統 density =3，則圖片寬度

下面是詳細的解釋

我們知道，不管在布局文件中填寫的是什麼單位，它最後都會被系統轉化為 px。系統的轉換演算法如下：

可以看到 px = dp*density 。

橫向適配的最終目的：讓100dp的寬度，在各個機型上，在屏幕上所佔的 比例相同 。
其核心演算法是px = dp* density。通過修改density這個變數，我們可以讓px和畫布標注的px值一致，達到適配的效果。

美工同學提供的畫布寬度為 750px（iphone6） ，開發中，我們對這些px標注 除2 得到裂迅拍dp值進行使用。
那麼density如何求出呢？ 根據系統演算法px = dp*density，反推 density =px/dp
拿橫向適配畫布， density對於不同解析度的手機修改後如下：

375是我們拿UI畫布橫向解析度750/2得出。