设备兼容性
Android正式为能在许多不同类型的设备上运行而设计的,从手机到平板电脑和电视机。作为一个开发者,大范围的设备为你的应用程序提供了巨大的潜在用户群。为了能在所有设备上成功运行,你的应用程序应该能够容许某些硬件差异,并提供灵活的用户界面来适应各种屏幕参数。
为了方便你朝着这个目标而努力,Android提供了一个动态的应用程序框架,它可以提供配置特定应用程序的资源的静态文件(如对应各种屏幕尺寸的不同 XML Layout布局文件)。然后Android会根据当前设备配置加载相应的资源。因此,通过预先设计加上一些应用程序资源,你可以只发布一个应用程序包(APK),就能为各种设备提供最优的用户体验。
不过,如果有必要,你可以指定你的应用程序的功能要求,并通过 Google Play Store 限制安装的设备类型,此页面介绍如何控制哪些可以访问你的应用程序设备,以及如何为确保应用程序安装到合适的设备而进行准备。有关如何让你的应用程序适应不同设备的详细信息,请阅读支持不同的设备(Supporting Different Devices)。
“兼容性”的含义?
随着你对Android开发的了解,你可能会在各种情况下遇到“兼容性”一词。兼容性分为两种:设备兼容性和应用程序的兼容性。
由于Android是开源的,任何硬件制造商都使用Android生产设备。但是,只有能正常运行 为Android 可执行环境编写的程序,才是“Android 兼容”的设备。 对于 Android 可执行环境的准确定义,在 Android compatibility program 中给出,并且所有设备都必须通过兼容性测试包(CTS)的测试。
作为一个应用程序开发者,你不必担心设备是否兼容Android,因为只有那些Android兼容的设备才有谷歌Play Store。所以你可以放心,从谷歌Play Store安装应用程序的用户都是使用Android的兼容设备的。
但是你仍需要考虑你的否应用程序是否与每一种不同配置设备兼容。因为可以运行 Android系统 的设备配置众多,某些特性并不是所有的设备都能提供。例如,一些设备没有罗盘传感器。如果你的应用程序的核心功能需要使用罗盘传感器,那么你的应用程序只跟包括罗盘传感器设备兼容。
控制应用程序的兼容性
Android提供了丰富的特性功能,你的应用程序可以通过平台API来利用它们。某些功能是基于硬件(如罗盘传感器),有些是基于软件(例如应用程序的窗口小部件Widget),以及一些依赖于平台版本的。由于并不是每个设备都支持的所有特性功能,所以你可能需要控制你的应用程序对于设备的可用性,根据你的应用程序所需的功能的设备。
为了让应用程序尽量获得最大的用户群,你应该努力让你的APK尽可能的支持多种多样的设备。在大多数情况下,你可以通过在运行时禁用可选功能,或者根据不同的配置提供替代资源(如不同的布局不同的屏幕尺寸)。如果有必要,你可以通过 Google Play Store 从以下几方面限制应用程序的适用范围:
设备功能
为了让你能够根据设备功能管理你的应用程序的可用性,Android为软硬件功能定义了对应的功能ID,这些ID可能不能适用于所有设备。例如,对于罗盘传感器的功能ID是FEATURE_SENSOR_COMPASS
和应用部件的功能ID是FEATURE_APP_WIDGETS
。
如果有必要,通过在 Manifest 文件的 < uses-feature > 元素中进行声明,你可以阻止用户在不提供给定特性的设备上安装应用程序。
例如,如果你的应用程序在缺少罗盘传感器的设备上无法使用,你就可以用如下 manifest 标签将罗盘传感器声明为必需项:
<manifest ... >
<uses-feature android:name="android.hardware.sensor.compass"
android:required="true" />
...
</manifest>
Google Play Store会比较你的应用程序要求,以提供每个用户的设备上的功能特性,以确定您的应用程序是否与每种设备兼容。如果设备不提供所有的应用程序需要的功能,用户无法安装应用程序。
不过,如果应用程序的主要功能并不是必需某个设备的功能,你就应该将 required 属性设为"false",并且在运行时自行检查设备配置的可用性。 如果当前设备不提供应用程序所需的配置,请平稳地对相关需求进行降级。 例如,你可以通过如下调用 hasSystemFeature() 查询可用的配置:
PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
// 这个设备不具有一个罗盘传感器,关闭罗盘功能
disableCompassFeature();
}
关于你用来控制你 通过Google Play Store给用户的应用程序的可用性的的所有过滤器的信息,请看Filters on Google Play文档。
注意:某些系统权限隐式的需求设备功能的可用性。例如,假如应用程序请求了对 蓝牙 的访问权限,那么就隐含了对 FEATURE_BLUETOOTH 的设备需求。通过将 < uses-feature > 标签中的 required 属性设为"false",你可以关闭与之相关的过滤,这样在没有蓝牙的设备上也可以使用此应用程序。
平台版本
不同的设备可以运行Android平台的不同版本,如Android 4.0或Android 4.4。每个连续的平台版本往往增加了一些以前的版本中不可用的新API。为了表明这些API是可用的,每个平台版本会指定一个API等级。举例来说,Android的1.0 API等级为1和Android 4.4的API等级为19。
API级别允许你声明与应用程序是兼容的最低版本,使用
清单标签及它的<uses-sdk>
属性。minSdkVersion
例如, Calendar Provider 的API是在Android 4.0(API等级14)加入的。如果您的应用程序不能没有这些API函数,你应该像这样声明API级别14,作为应用程序支持的最低版本:
<manifest ... >
<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
...
</manifest>
minSdkVersion
属性声明应用程序兼容的最低版本,
属性声明了应用程序运行最优的最高系统版本。targetSdkVersion
高版本的 Android 系统可以兼容较低版本 API 编译出来的应用程序,因此只要使用了公开的 API,应用程序就应该可与未来的 Android 版本兼容。
注: targetSdkVersion
属性不会阻止应用程序被安装在比规定版本更高的平台版本上,但这非常重要的,因为这表明系统的应用程序是否应该继承在新版本在更改的性能特性。如果不更新
到最新版本,系统会假定当应用程序在最新版本上运行时,应用程序需求一些向后兼容的行为。例如,在Android4.4改变的特性功能中,默认情况下,用targetSdkVersion
AlarmManager
API创建的警报是不精确的,这样系统可以对齐应用的警报并保护系统续航能力(对齐唤醒机制),但是,如果应用程序的目标API等级低于“19”,系统仍然会为应用程序保留之前版本的API功能。
但是,如果你的应用程序使用了较新平台版本添加的API,但又不要求它们的主要功能,您应在运行时检查API等级,而当API等级太低时,应适度降低相应的功能。在这种情况下,为应用程序的主要功能设置
可能的最低值,然后比较当前系统的版本, minSdkVersion
SDK_INT
,一个对应于你要检查的API等级代号常量Build.VERSION_CODES
。例如:
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that useClipboardManager
APIs
disableDragAndDrop();
}
屏幕配置
Android可以运行在各种尺寸的设备上,从手机到平板电脑和电视。为了将这些设备按屏幕的特性进行分类,Android为每个设备定义了两个特性:屏幕大小(屏幕的物理尺寸)和屏幕密度(在屏幕上,被称为上像素的物理密度DPI)。为了简化不同的配置, Android 把这些参数概括为几种,便于使用时对号入座:
- 四种尺寸大小:小,正常,大和XLARGE(更大)。
- 几种密度:MDPI(中等),hdpi (hdpi ),xhdpi(超高),xxhdpi(超特高),等等。
默认情况下,应用程序要兼容所有的屏幕尺寸和密度兼容,因为系统会根据实际的屏幕参数适时调整 UI 布局和图片资源。 不过,为了提供最佳的用户体验,你应该根据屏幕参数添加各种屏幕尺寸对应的布局,以及为常见屏幕密度优化过的位图资源。
关于如何为不同的屏幕创建备用资源,以及如何在必要时以一定的屏幕尺寸限制应用程序的详细信息,请参阅Supporting Different Screens文档。
控制应用程序的商业兼容性
除了根据设备特性限制应用程序的可用性,你可能因为商业和法律的原因而需要限制你的应用程序的可用性。例如,一个应用程序,用于显示伦敦地铁时刻表不太可能对英国以外的用户有用。对于这种情况,Google Play Store提供了开发者控制,对于非技术原因允许你控制应用程序可用性,如用户位置或者无线运营商。
过滤技术的兼容性(如需要的硬件组件)都是基于在你的APK文件的信息惊醒的。但是,非技术原因(如地理区域)的过滤都是由Google Play Store开发者控制台来控制。