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得出。