android兼容,android兼容性的意义

Android 12 兼容之行为变更

Android 12 平台包含一些行为变更，这些变更可能会影响您的应用。以下行为变更将影响在 Android 12 上运行的 所有应用 ，无论采用哪种 targetSdkVersion 都不例外。您应该测试您的应用，然后根据需要进行修改，以适当地支持这些变更。

此外，请务必查看 仅影响以 Android 12 为目标平台的应用的行为变更 列表。

在搭载 Android 12 及更高版本的设备上， 滚动事件 的视觉行为发生了变化。

在 Android 11 及更低版本中，滚动事件会使视觉元素发光。在 Android 12 及更高版本中，发生拖动事件时，视觉元素会拉伸和反弹；发生快速滑动事件时，它们会快速滑动和反弹。

如需了解详情，请参阅 动画演示滚动手势 指南。

如果您之前在 Android 11 或更低版本中实现了自定义启动画面，则需要将您的应用迁移到 SplashScreen API，以确保它从 Android 12 开始正确显示。如果不迁移您的应用，则可能会导致应用启动体验变差或出乎预期。

如需了解相关说明，请参阅 将现有的启动画面实现迁移到 Android 12 。

此外，从 Android 12 开始，在所有应用的 冷启动 和 温启动 期间，系统始终会应用新的 Android 系统默认启动画面 。 默认情况下，此系统默认启动画面由应用的启动器图标元素和主题的 windowBackground （如果是单色）构成。

如需了解详情，请参阅 启动画面开发者指南 。

从 Android 12（API 级别 31）开始，仅当您的应用获准处理某个通用网络 intent 中包含的特定网域时，该网络 intent 才会解析为应用中的 activity。如果您的应用未获准处理相应的网域，则该网络 intent 会解析为用户的默认浏览器应用。

应用可通过执行以下某项操作来获准处理相应的网域：

如果您的应用调用网络 intent，不妨考虑添加一个提示或对话框，要求用户确认操作。

Android 12 整合了现有行为，让用户可以 在沉浸模式下更轻松地执行手势导航命令 。此外，Android 12 还为 粘性沉浸模式提供了向后兼容性行为 。

Android 设备有许多不同的外形规格，如大屏设备、平板电脑和可折叠设备。为了针对每种设备适当地呈现内容，您的应用需要确定屏幕或显示屏尺寸。随着时间的推移，Android 提供了不同的 API 来检索这些信息。在 Android 11 中，我们引入了 WindowMetrics API 并废弃了以下方法：

在 Android 12 中，我们继续建议使用 WindowMetrics ，并且正在逐步废弃以下方法：

为了缓解应用使用 Display API 检索应用边界的行为，Android 12 限制了 API 为不完全可调整大小的应用返回的值。这可能会对将此信息与 MediaProjection 一起使用的应用产生影响。

应用应使用 WindowMetrics API 查询其窗口的边界，并使用 Configuration.densityDpi 查询当前的密度。

为了与较低的 Android 版本实现更广泛的兼容性，您可以使用 Jetpack WindowManager 库，它包含一个 WindowMetrics 类，该类支持 Android 4.0（API 级别 14）及更高版本。

首先，确保应用的 activity 完全可调整大小 。

activity 应依赖于来自 activity 上下文的 WindowMetrics 来执行任何与界面相关的工作，尤其是 WindowManager.getCurrentWindowMetrics() 或 Jetpack 的 WindowMetricsCalculator.computeCurrentWindowMetrics() 。

如果您的应用创建了 MediaProjection ，则必须正确地调整边界的大小，因为投影会捕获运行投影仪应用的显示分区。

如果应用完全可调整大小，则 activity 上下文会返回正确的边界，如下所示：

如果应用并非完全可调整大小，则它必须从 WindowContext 实例进行查询，并使用 WindowManager.getMaximumWindowMetrics() 或 Jetpack 方法 WindowMetricsCalculator.computeMaximumWindowMetrics() 检索 activity 边界的 WindowMetrics 。

注意 ：任何使用 MediaProjection 的库也应遵循这些建议，并查询相应的 WindowMetrics 。

Android 12 将多窗口模式作为标准行为。

在大屏设备 (sw = 600dp) 中，所有应用都将在多窗口模式下运行，无论应用配置为何。如果 resizeableActivity="false" ，应用会在必要时进入兼容模式，以适应显示屏尺寸。

在小屏设备 (sw 600dp) 中，系统会检查 activity 的 minWidth 和 minHeight ，来确定 activity 能否在多窗口模式下运行。如果 resizeableActivity="false" ，则无论最小宽度和高度如何，应用都无法在多窗口模式下运行。

如需了解详情，请参阅 多窗口模式支持 。

相机应用通常假定设备的屏幕方向和相机预览的宽高比呈固定关系。但是，大屏设备类型（例如可折叠设备）和显示模式（例如多窗口和多屏幕）挑战着这一假设。

在 Android 12 上，请求特定屏幕方向且不可调整大小 ( resizeableActivity="false" ) 的相机应用会自动进入边衬区人像模式，从而确保相机预览的屏幕方向和宽高比正确。在可折叠设备和其他具有相机硬件抽象层 ( HAL ) 的设备上，会对相机输出应用额外的旋转以补偿相机传感器方向，并会剪裁相机输出以匹配应用相机预览的宽高比。无论设备屏幕方向如何以及设备是处于折叠状态还是展开状态，剪裁和额外的旋转可确保应用正确呈现相机预览。

除了 一些例外情况 之外，为了为短时间运行的 前台服务 提供流畅体验，搭载 Android 12 或更高版本的设备可以将前台服务通知的显示延迟 10 秒。此更改使某些短期任务可在显示通知之前完成。

Android 11（API 级别 30）引入了 受限存储分区 作为应用待机模式存储分区。从 Android 12 开始，此存储分区默认处于活跃状态。在所有存储分区中，受限存储分区的优先级最低（限制最高）。存储分区按优先级从高到低的顺序排列如下：

除了使用模式之外，系统还会考虑应用的行为，以决定是否要将您的应用放在受限存储分区中。

如果您的应用更负责地使用系统资源，就不太可能被放在受限存储分区中。此外，如果用户直接与您的应用互动，系统会将其放在一个限制较少的存储分区中。

如需检查系统是否已将您的应用放在受限存储分区中，请调用 getAppStandbyBucket() 。如果此方法的返回值为 STANDBY_BUCKET_RESTRICTED ，则您的应用在受限存储分区中。

如需测试您的应用在系统将其放在受限存储分区中时的行为，您可以手动将您的应用移至该存储分区。为此，请在终端窗口中运行以下命令：

在搭载 Android 12 或更高版本的受支持设备上，用户可以通过按一个切换开关选项，为设备上的所有应用启用和停用摄像头和麦克风使用权限。用户可以从 快捷设置 访问可切换的选项（如图 1 所示），也可以从系统设置中的“隐私设置”屏幕访问。

详细了解这些 切换开关 以及如何检查您的应用是否遵循了关于 CAMERA 和 RECORD_AUDIO 权限的最佳实践。

在搭载 Android 12 或更高版本的设备上，当应用使用麦克风或相机时，图标会出现在状态栏中。

详细了解这些 指标 以及如何检查您的应用是否遵循了关于 CAMERA 和 RECORD_AUDIO 权限的最佳实践。

[图片上传中...(image-bd519-1643780883994-1)]

figcaption style="box-sizing: inherit; font-size: 14px; margin-top: -4px;" 图 1. “快捷设置”中的麦克风和摄像头切换开关。/figcaption

[图片上传中...(image-f49bfd-1643780883994-0)]

figcaption style="box-sizing: inherit; font-size: 14px; margin-top: -4px;" 图 2. 麦克风和摄像头指示标志，显示了最近的数据访问。/figcaption

在搭载 Android 12 或更高版本的设备上，根据应用对其他应用的 软件包可见性 ，以 Android 11（API 级别 30）或更高版本为目标平台且调用以下某种方法的应用会收到一组过滤后的结果：

Android 12 移除了之前弃用的加密算法的许多 BouncyCastle 实现，包括所有 AES 算法。系统改用这些算法的 Conscrypt 实现。

如果符合以下任何条件，则此变更会影响您的应用：

在 Android 12 及更高版本中，当某个应用首次调用 getPrimaryClip() 以 从另一个应用访问剪辑数据 时，会弹出一个消息框消息，通知用户对剪贴板的访问。

消息框消息内的文本包含以下格式： var translate="no" style="box-sizing: inherit; color: var(--devsite-var-color); -webkit-font-smoothing: auto; font-weight: 500;"APP/var pasted from your clipboard.

注意 ：您的应用可能会调用 getPrimaryClipDescription() 以接收有关 剪贴板上当前数据的信息 。当您的应用调用此方法时，系统不会显示消息框消息。

在 Android 12 及更高版本中， getPrimaryClipDescription() 可以检测到以下详细信息：

为了加强用户与应用和系统互动时的控制，从 Android 12 开始，弃用了 ACTION_CLOSE_SYSTEM_DIALOGS intent 操作。除了 一些特殊情况 之外，当应用尝试 调用包含此操作的 intent 时，系统会基于应用的目标 SDK 版本执行以下操作之一：

在以下情况下，应用仍然可以在 Android 12 或更高版本上关闭系统对话框：

为了维持系统安全并保持良好的用户体验，Android 12 会阻止应用使用 触摸事件 ，使用触摸事件时叠加层会以不安全的方式遮掩应用。 换言之，系统会屏蔽穿透某些窗口的触摸操作，但 有一些例外情况 。

此变更会影响选择让触摸操作穿透其窗口的应用，例如使用 FLAG_NOT_TOUCHABLE 标志。包括但不限于以下示例：

在以下情况下，允许执行“穿透”触摸操作：

如果系统屏蔽触摸操作， Logcat 会记录以下消息：

在搭载 Android 12 或更高版本的设备上，不受信任的触摸功能默认被屏蔽。如需允许不受信任的触摸操作，请在终端窗口中运行以下 ADB 命令 ：

如需将行为还原为默认设置（不受信任的触摸操作被屏蔽），请运行以下命令：

Android 12 更改了在按下“返回”按钮时系统对为其任务根的启动器 activity 的默认处理方式。在以前的版本中，系统会在按下“返回”按钮时完成这些 activity。在 Android 12 中，现在系统会将 activity 及其任务移到后台，而不是完成 activity。当使用主屏幕按钮或手势从应用中导航出应用时，新行为与当前行为一致。

注意 ：系统仅会将新行为应用于为其任务根的启动器 activity，即使用 ACTION_MAIN 和 CATEGORY_LAUNCHER 声明 intent 过滤器 的 activity。对于其他 activity，在按下“返回”按钮时，系统会像以前一样完成 activity。

对于大多数应用而言，此变更意味着使用“返回”按钮退出应用的用户可以更快地从 温状态 恢复应用，而不必从 冷状态 完全重启应用。

建议您针对此变更测试您的应用。如果您的应用目前替换 onBackPressed() 来处理返回导航并完成 Activity ，请更新您的实现来调用 super.onBackPressed() 而不是完成 Activity。调用 super.onBackPressed() 可在适当时将 activity 及其任务移至后台，并可为不同应用中的用户提供更一致的导航体验。

另请注意，通常，我们建议您使用 AndroidX Activity API 提供自定义返回导航 ，而不是替换 onBackPressed() 。如果没有组件拦截系统按下“返回”按钮，AndroidX Activity API 会自动遵循适当的系统行为。

在 Android 12 中，无论显示屏是否支持无缝过渡到新的刷新率，都会发生使用 setFrameRate() 实现的刷新率变化；无缝过渡是指没有任何视觉中断，比如一两秒钟的黑屏。以前，如果显示屏不支持无缝过渡，它在调用 setFrameRate() 后通常会继续使用同一刷新率。您可以调用 getAlternativeRefreshRates() 来提前确定向新刷新率的过渡是否有可能是无缝过渡。通常，会在刷新率切换完成后调用回调 onDisplayChanged() ，但对于某些外接显示屏，会在非无缝过渡期间调用该回调。

以下示例说明了您可以如何实现此行为：

Android 12 中添加了以下 API：

如需创建 Passpoint 建议，应用必须使用 PasspointConfiguration 、 Credential 和 HomeSp 类。这些类描述了 Wi-Fi Alliance Passpoint 规范 中定义的 Passpoint 配置文件。

如需了解详情，请参阅 适用于互联网连接的 Wi-Fi 建议 API 。

Android 12 包含更新后的受限制非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 12 为目标平台，其中一些变更可能不会立即对您产生影响。然而，虽然您目前仍可以使用一些非 SDK 接口（ 具体取决于应用的目标 API 级别 ），但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以 测试您的应用 来进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。然而，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，应 请求新的公共 API 。

如需详细了解此 Android 版本中的变更，请参阅 Android 12 中有关限制非 SDK 接口的更新 。如需全面了解有关非 SDK 接口的详细信息，请参阅 对非 SDK 接口的限制 。

聚焦 Android 11: Android 11 应用兼容性

作者 / Android 产品经理 Diana Wong

在往期 #11WeeksOfAndroid 系列文章中我们介绍了 联系人和身份 、 隐私和安全 ，本期将聚焦 Android 11 兼容性 。我们将为大家陆续带来 #11WeeksOfAndroid 内容，深入探讨 Android 的各个关键技术点，您不会错过任何重要内容。

本期我们将重点探讨 Android 11 兼容性这一对所有开发者都非常重要的主题。对于 Android， 应用兼容性 一词指应用可以在特定版本的 Android (通常是最新版本) 上正常运行。

您可以前往官方网站详细获取可帮助您进行兼容性测试的资源，以及本期所有关于该领域的实用内容和资源！

在每次版本更新中，我们都希望尽量减少应用适配 Android 所需的工作。在 Android 11 中，我们添加了新的流程、开发者工具和版本发布里程碑，以帮助我们最大程度地减少平台更新带来的影响，更轻松实现应用的兼容性。

请继续阅读，详细了解我们如何简化 Android 11 中的应用测试和调试流程。

测试应用是否兼容 Android 新版本可能面临很多挑战，尤其是应用在受到多个平台变更影响的情况下。此过程中可能会出现很多问题:

开发者社区为我们提供了大量相关问题的优质反馈。在 Android 11 中，我们为平台添加了以下新工具，并在 Android Studio 中添加了新功能，因此您可以更加轻松的进行测试。

和往年的更新一样，Android 11 的一些平台变更可能会影响您的应用。尽管这些变更对于提升平台性能至关重要，但我们会尽可能将这些变更安排在平台的最新 targetSDKVersion 之后，以便减少对您的应用的直接改动。在 Android 11 中，我们还会将更多此类平台变更添加到新的 兼容性框架 中。

您可以使用全新开发者工具，针对包含在兼容性框架内的变更对应用进行测试和调试。

例如，我们已将包含在兼容性框架内的变更设为可切换，您可以通过设备的开发者选项或使用 Android ADB 强制启用或停用单个变更。Android 平台会自动调整内部 API 逻辑，因此您无需更改 targetSDKVersion 或重新编译应用，即可执行基本测试。此外，您可以隔离各项变更，从而节省发现和调试应用中问题所需的时间。

在切换变更的启用/停用状态之前，您应该通读 行为变更列表 ，确定哪些变更可能会影响您的应用。包含在兼容性框架内的变更已在变更描述前列出相应的 Change ID 和 Change Name。

一般来说，我们建议您从 影响所有应用的行为变更 开始测试，因为无论 targetSDKVersion 如何，这些变更都可能对您的应用造成影响。我们用下面这个 targetSDKVersion 控制的变更为例，说明您可以如何在不使用其他 targetSDK 重编译应用的情况下，对这些变更进行测试。

在 后台位置访问变更 中，请求始终在后台访问位置的应用会受影响。如果您的应用受到这一变更的影响，那么从该变更开始测试是不错的选择。此变更的名称为 BACKGROUND_RATIONALE_CHANGE_ID，变更 ID 为 147316723。您需要先使用这些信息启用此变更，然后再测试应用因此受到的影响。

确定要测试的变更后，您可以使用开发者选项切换此变更的启用/停用状态。如要使用开发者选项，请打开设备上的 "设置" 应用，导航至 系统 高级 开发者选项 应用兼容性变更 。

开发者选项中可切换的平台变更，后台位置访问变更已启用

在本例中，BACKGROUND_RATIONALE_CHANGE_ID 是唯一已启用的变更，旨在最大程度缩小应用可能遇到的各种问题的原因范围。

您也可以使用 Logcat 或 ADB 识别已启用的变更 ，或 使用 ADB 切换变更的启用/停用状态 。请注意，您只能在使用可调试应用时切换变更。

启用变更后，您可以使用常用的测试工作流来测试和调试应用。如遇到问题，请查看日志，确定问题的原因。如果不确定问题是否由已启用的平台变更引起，您可以尝试停用此变更，然后重新测试应用的同一模块。

如需了解其他相关示例，您可以观看有关 测试 Android 11 中平台变更的视频 ，或阅读 官方文档 。

除了在新平台上手动进行测试外，我们还简化了使用 Android Studio 在最新 Android 系统上运行自动化测试的流程。

从 Android Studio 4.2 开始，我们实现了在多个实体或虚拟设备上并行运行插桩测试 (instrumentation tests)。现在，您可以在运行测试的过程中，从目标设备下拉菜单中选择 多个设备 。

此功能旨在帮助您在开发周期中尽早发现问题，并让您能够比较不同 Android 设备之间的差异。您可以使用 视图 工具窗口 运行 下的新 测试矩阵 ，研究这些测试的结果。

请观看有关 使用 Android Studio 测试应用兼容性的视频 ，或阅读 官方文档 。

我们建议您尝试这些新工具，并 向我们发送反馈 ，告诉我们这些工具对您是否有用。我们希望这些工具能帮助您更轻松地测试 Android 11 应用兼容情况。

Android外部存储兼容(Android12)

Android 12之后系统就不允许自由访问外部存储了，只能访问指定的外部存储存储，例如：context.getExternalFilesDir(Environment.type)下的外部存储，或者其他/Android/data/data下的外部存储。

老规矩了，访问外部存储前需要申请权限。

此时不需要申请权限了，可以直接访问。如果你要分享就需要添加FileProvider配置。

WRITE_EXTERNAL_STORAGE when targeting Android 10

小米手机怎么开启安卓12兼容模式

打开浏览器以后，点击菜单中偏好设置；进入偏好设置后，点击进入高级设置标签，勾选显示开发的菜单；进入开发的菜单中，找到用户代理，可以看到兼容模式，点击进入，并且开启兼容模式。

拓展资料:

兼容性：

兼容性（compatibility）是指硬件之间、软件之间或是软硬件组合系统之间的相互协调工作的程度。兼容的概念比较广，相对于硬件来说，几种不同的电脑部件，如CPU、主板、显示卡等，如果在工作时能够相互配合、稳定地工作，就说它们之间的兼容性比较好，反之就是兼容性不好。

对于软件的兼容性，指的是指某个软件能稳定地工作在若干个操作系统之中，而不会出现意外的退出等问题。

在软件行业，一种是指某个软件能稳定地工作在若干个操作系统之中，就说明这个软件对于各系统有良好的兼容性。

再就是在多任务操作系统中，几个同时运行的软件之间，如果能稳定地工作，不频繁崩溃、死机，则称之为它们之间的兼容性良好，反之兼容性不好。另一种就是软件共享，几个软件之间无需复杂的转换，即能方便地共享相互间的数据，也称为兼容。

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（超超高）等。

默认情况下，您的应用会兼容所有屏幕尺寸和密度，因为系统会根据需要对各个屏幕的界面布局和图片资源进行相应的调整。不过，您应针对不同的屏幕尺寸添加专门的布局，针对常见的屏幕密度添加优化的位图图片，以优化每种屏幕配置的用户体验。