有关于屏幕兼容性的问题汇总

最新推荐文章于 2023-03-23 10:45:52 发布

qq_40295727

最新推荐文章于 2023-03-23 10:45:52 发布

阅读量1.3k

点赞数

分类专栏：屏幕适配

屏幕适配专栏收录该内容

0 篇文章 0 订阅

订阅专栏

Android 手机被设计为运行在不同类型的设备上，从手机到平板再到android 电视。作为一个开发者，这广泛的设备为你的app提供了巨大的潜在用户。为了使的你app能够成功运行到所有设备上，Android 系统被设计为能能够容忍一些特征的可变性并且提供一个灵活的用户界面以便适配不同的屏幕配置。

为了促进你实现这一目标，android 提供了一个动态的 app 框架，在这个框架中，你可以在静态文件中（比如说针对不同的屏幕尺寸提供不同的xml布局文件）提供特定配置的 app 资源。Android 更具当前设配的配置加载相应的资源（xml布局文件，不同尺寸的图片）.因此一款深谋远虑和提供一些额外资源的app只需要打包发布一个apk就可以为不同设备提供最佳的用户体验。

"兼容性"(compatibility)是什么意思

当您阅读有关Android开发的更多信息时，在很多各种不同情况下你都会遇到"compatibility" 这个词。

这儿有两种类型的“compatibility” : 设备兼容性和app 兼容性

因为android 是一个开源项目，任何硬件厂商（比如手机厂商）都可以生产一款运行android 操作系统的设备，然而只有当一个设备能正确的运行为android 执行环境编写的app时这个设备才是 Android 兼容的。每个设备必须通过兼容性测试套件（CTS）才能被视为兼容。

作为应用开发者，您无需担心设备是否与Android兼容，因为只有Android兼容的设备才包含Google Play商店。因此，您可以放心，从Google Play商店安装应用的用户使用的是Android兼容设备

但是，您需要考虑您的应用是否与每个潜在的设备配置兼容。由于Android可在各种设备配置上运行，因此某些功能并非在所有设备上都可用。

例如，某些设备可能不包括罗盘传感器。如果您的应用程序的核心功能需要使用指南针传感器，那么您的应用程序仅与包含指南针传感器的设备兼容。

控制你app的对设备的可用性

Android 提供了各种特性，你的app可以通过平台api来使用这些特性。某些特性是基于硬件的（比如传感器），某系特性是基于android 平台版本（比如应用控件在某些低平台上就不支持）。并不是每个设备都支持所有特性。因此，您可能需要根据应用所需的功能控制应用对设备的可用性。

比如在google store 上，你上传app的时候在app配置里面指明了最低支持的系统版本，那么低于这个版本的手机就不能从google store 上下载你的应用，再比如你在app 配置文件里面指明你的app需要某个硬件才能运行，那么缺乏这个硬件的手机就不能安装这个硬件。

为了实现应用程序的最大用户群，你应该努力使用单个APK支持尽可能多的设备配置。在大多数情况下，您可以通过在运行时禁用可选功能并为不同配置提供备用应用程序资源来实现此目的（比如为不同的屏幕尺寸提供不同的布局文件）。然后，你也可以根据以下设备特征，通过Google Play商店限制应用对设备的可用性：

设备特性

为了让您根据设备功能（特性）管理应用的可用性，Android 为所有可能不是所用设备都支持的硬件和软件特性定义了特性ID。例如指南针传感器特性ID FEATURE_SENSOR_COMPASS

如有必要，您可以通过在应用的清单文件中使用元素声明用户设备未提供给定功能时阻止用户安装应用

例如，如果您的应用程序在缺少罗盘传感器的设备上没有意义，您可以根据需要使用以下清单标记声明罗盘传感器

<manifest ... >
    <uses-feature android:name="android.hardware.sensor.compass"
                  android:required="true" />
    ...
</manifest>

Google Play商店会将您的应用所需的功能与每个用户设备上的功能进行比较，以确定您的应用是否与每个设备兼容。

如果设备未提供您的应用所需的所有功能，则用户无法安装您的应用。

但是，如果您的应用程序的主要功能不需要设备功能，则应将required属性设置为“false”并在运行时检查设备功能.

如果当前设备上的应用功能不可用，优雅地降低相应的应用功能。例如，您可以通过调用hasSystemFeature（）来查询功能是否可用，如下所示：

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device does not have a compass, turn off the compass feature
    disableCompassFeature();
}

有关可用于通过Google Play商店控制用户应用程序可用性的所有过滤器的信息，请参阅Google Play上的过滤器文档。

Note: Some system permissions implicitly require the availability of a device feature. For example, if your app requests permission to access to BLUETOOTH, this implicitly requires the FEATURE_BLUETOOTH device feature. You can disable filtering based on this feature and make your app available to devices without Bluetooth by setting the required attribute to "false"in the `` tag. For more information about implicitly required device features, read Permissions that Imply Feature Requirements.

注意：某些系统权限隐式需要设备功能的可用性。例如，如果您的应用请求访问BLUETOOTH的权限，则隐式需要FEATURE_BLUETOOTH设备功能。您可以根据此功能禁用过滤，并通过在标记中将required属性设置为“false”，使您的应用可用于没有蓝牙的设备。有关隐式所需设备功能的更多信息，请阅读暗示功能要求的权限

Platform version

不同的设备可能运行不同版本的Android平台，例如Android 4.0或Android 4.4。每个连续的平台版本通常会添加以前版本中不可用的新API。为了标识那些API可用，每个平台版本都指定了一个API level(API 级别) 。例如，Android 1.0是API级别1，Android 4.4是API级别19。

API级别允许您声明应用程序兼容的最低版本，通过Manifest 文件中的 <uses-sdk> 的 minSdkVersion 属性设置最低版本。例如 Calendar Provider 的API 是在android 4.0 的时候被加入的。如果您的应用无法在没有这些API的情况下运行，则应将API级别14声明为应用的最低支持版本。

minSdkVersion属性声明了你应用兼容的最低版本，

targetSdkVersion 属性声明了您优化应用的最高版本

此属性告知系统你已针对目标版本进行了测试，系统不应启用任何兼容性行为来维持应用程序与目标版本的向前兼容性。该应用程序仍然可以在旧版本上运行（低至minSdkVersion）

随着Android每个新版本的发展一些行为甚至出现可能会改变（比如权限）。但是，如果平台的API级别高于应用程序的targetSdkVersion声明的版本，系统可以启用兼容性行为，以确保你的应用程序继续以您期望的方式工作，您可以通过指定targetSdkVersion以匹配运行它的平台的API级别来禁用此类兼容性行为。例如，将此值设置为“11”或更高允许系统在Android 3.0或更高版本上运行时将新的默认主题（Holo）应用于您的应用，并在大屏幕上运行时禁用屏幕兼容模式（因为对API级别11的支持隐式支持更大的屏幕）。

但是，请注意元素中的属性将被build.gradle文件中的相应属性覆盖

因此，如果您使用的是Android Studio，则必须在其中指定minSdkVersion和targetSdkVersion值：

android {
  defaultConfig {
    applicationId 'com.example.myapp'

    // Defines the minimum API level required to run the app.
    minSdkVersion 15

    // Specifies the API level used to test the app.
    targetSdkVersion 26

    ...
  }
}

每个连续版本的Android都为使用以前平台版本的API构建的应用程序提供兼容性，

因此，在使用官方给出的Android API时，你的应用应始终与Android的未来版本兼容。

targetSdkVersion属性不会阻止您的应用程序安装在高于指定值的平台版本上，这很重要，因为它向系统指示您的应用程序是否应该继承新版本中的行为更改。如果未将targetSdkVersion更新为最新版本，则系统会假定您的应用程序在最新版本上运行时需要一些向后兼容性行为。例如，在Android 4.4中的行为更改中，默认情况下使用AlarmManager API创建的警报不准确，因此系统可以批量应用警报并保留系统电源，但如果您的目标API，系统将保留您应用的先前API行为水平低于“19”。

但是，如果您的应用程序使用在较新的平台版本中添加的API，但不要求它们用于其主要功能，则应在运行时检查API级别，并在API级别过低时优雅地降低相应的功能。在这种情况下，将minSdkVersion设置为应用程序主要功能可能的最低值，然后将当前系统的版本SDK_INT与Build.VERSION_CODES中与您要检查的API级别对应的代号常量进行比较。例如：

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag/drop features that use ClipboardManager APIs
    disableDragAndDrop();
}