1.2 Device Compatibility

DeviceCompatibility

       Android被设计为可以在各种不同类型的设备上运行，包括手机，平板电脑和电视。为了让你的app在所有的设备上成功运行，android系统应该可以容忍某些特征变化，提供一个灵活的用户界面以适应不同的屏幕配置。

       Android提供一个动态的app框架，这样你可以在静态文件中提供app资源的特征性配置。（例如针对不同屏幕尺寸定义不同的xml布局）android可以根据当前设备的配置加载相应的资源。所以如果你的app具有一定的前瞻性设计，也具有额外的app资源，你可以单独建立一个apk对不同设备的用户都提供最佳的用户体验。

       在有必要的情况下，你可以指定你的app特定要求同时控制那些类型的设备可以从Google Play商店中下载安装你的应用。这一章就解释你如何控制那些类型的设备可以访问你的app，以及如何确保你的app呈现在正确的观众面前。

 

What Does “Compatibility” Mean?

       因为android是一个开源的项目，任何硬件制造商都可以生产出运行android操作系统的设备。当一个设备可以正确运行为安卓系统编写的app时，这个设备就可以称为是“android兼容性”(Androidcompatible)的。Androidcompatibility program(android兼容性程序)会为android执行环境声明精确的细节，另外每个设备都必须通过兼容性测试套件（CompatibilityTest Suite, CTS）来确保他们是android兼容性的。

       作为开发者，你不需要担心设备的android兼容性的问题，因为只有android兼容性的设备才会装载GooglePlay Store。所以只要是从Google PlayStore上下载安装你开发的app的设备就一定是android系统兼容的。

       然而，你需要考虑的是你的app是否兼容每一个设备的潜在配置。因为android可以运行在大量不同配置的设备上，一些功能并不在所有的设备上可用。例如，一些设备并没有装载罗盘传感器(CompassSensor)。如果你的app核心功能需要使用罗盘传感器，那么你的app只能兼容装有罗盘传感器的设备。

 

Controlling Your App’s Availability to Device

       Android支持各种手机功能，你的app可以通过API平台来控制它们。一些功能是基于硬件的（例如罗盘传感器），一些功能则是基于软件的（例如窗口小部件/widget），还有一些是基于平台版本(platform version)。并不是每个设备都支持所有的功能，所以基于你的app要求的特性，你必须控制你的app在设备上的可行性。

       为了给你的app获得最大量的忠实用户，你应该用一个apk支持尽可能多的设备配置。在大多数情况下，为了实现上述目的，你可以在运行期间禁用可选项，为不同配置的设备提供可选的app资源（例如不同屏幕大小的设备使用不同的布局）。在需要的情况下，你可以基于下面的设备特征利用GooglePlay Store限制你的app在一些设备的可行性：

Devicefeature/Platform version/Screen configuration

 

Device Feature

       为了让你管理你的app基于设备配置的可行性，android对任何硬件或软件功能都声明了featureID。例如罗盘传感器的feature ID就是FEATURE_SENSOR_COMPASS而app小窗口控件的featureID是FEATURE_APP_WIDGETS。

       在manifest.xml文件中，你可以用<uses-feature>标签声明你的app需要的功能，如果设备不具备你声明的这种功能，则你的app会被阻止安装在这台设备上。

       例如，你可以如下声明你的app需要罗盘传感器：

<manifest…..>

       <uses-feature android: name=”android.hardware.sensor.cpmpass”

android: required=”true” />

       …….

</manifest>

 

GooglePlay Store会比较你的app需要的配置和每个设备上的配置，判断你的app是否兼容每一个设备。如果设备没有提供你的app需要的配置，用户则不能从Google Play Store上下载安装你的app。

       然而，如果你的app的基本功能并不包含这个设备配置，你可以设置required选项为false，然后在app运行期间检查这个配置。如果app功能在当前设备上不可用，可以温和的降低app相应的功能。例如，你可以用hasSystemFeature()方法检查一个功能是否可用：

PackageManagerpm=getPackageManager ();

if(! pm.hasSystemFeature (PackageManager.FEATURE_SENSOR_COMPASS)){

       //This device does not have a compass,turn off the compass feature

       disableCompassFeature ();

}

你可以使用过滤器(filter)通过GooglePlay Store为用户控制app的可用性，所有的filter信息可以参见Filterson Google Play文档。

 

Platform Version

       不同的设备可能运行的是不同的android平台，每个连续的平台通常都添加了在前一个平台中不可用的新的API。为了明确哪一套API是可用的，每一个平台都指定一个APIlevel（API级别）。例如，Android1.0就是API级别1，Android4.4就是API级别19.

       API级别允许你指定你的app兼容的最低版本，使用<uses-sdk>清单标签和minSdkVersion属性。

       例如，CalendarProvider API是在Android4(APIlevel 14)中添加进来的，如果你的app不能没有这些API，你必须将APIlevel14 作为你的app最低支持版本。

<manifest…..>

       <uses-sdk android: minSdkVersion=”14” android: targetSdkVersion=”19”/>

</manifest>

minSdkVersion标签描述的是你的app兼容的最低版本，targetSdkVersion标签描述的是你的app的最优化的版本。

       每一个连续性的android版本都会为你的app提供对前一个android版本的兼容，所以你的app也会对未来的android平台兼容。

 

Note:targetSdkVersion标签不会阻止你的app安装在比这个标签描述的更高版本的android平台上，它很重要是因为它向系统指出你的app应该继承新版本的行为变化。如果你没有将targetSdkVersion升级到最新的版本，则你的app在最新的android平台上运行的时候，系统会假设你的app需要一些向后兼容(Backward-compatibility)。
(For example, among the behavior changes inAndroid4.4,alarms created with the AlarmManager APIs are now inexact by defaultso the system can batch app alarms and preserve system power.)

例如，在android4.4的行为变化中，用AlarmManager这个API默认创建的警报(Alarm)现在并非是精确的，所以系统可以批量处理app的警报同时保护系统功率。但是系统仍然会为你的app保留先前的API，如果你的targetAPI水平比19低的话，你的app仍然可以正常使用。

 

       然而，如果你的app使用的API添加到了更近的一个android平台上，且不需要这些API作为app的主要功能，你可以在运行期间检查API的水平，如果API的水平很低，你可以适当的降低app的相关功能。在保证你的app主要功能的前提下，将minSdkVersion设置为最低版本，然后比较当前系统版本——SDK_INT和在Build.VERSION_CODES中的版本名字，可以对你想要检查的API水平做出响应。例如：

If(Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {

       //Running on something older than APIlevel 11, so disable

       //the drag/drop features that useClipboardMnager APIs

       disableDragAndDrop ();

}

 

Screen configuration

       为了从屏幕类型来区分设备，android为每个设备都声明了两种类型：屏幕尺寸（屏幕的物理大小）和屏幕密度（屏幕上像素的物理密度，thephysical density of the pixels on the screen, DPI）。为了简单区分这些配置，android将他们如下分组：

四种广义的尺寸：small, normal, large, xlarge

几种广义的密度(density)：mdpi(medium),hdpi, xhdpi(extra high),xxhdpi(extra-extra high)等

       默认情况下，你的app兼容所有的屏幕尺寸和密度，因为系统能够针对每一个屏幕适当的调整你的UI布局和图像资源。然而，你可以针对不同的屏幕尺寸增加不同的布局，根据屏幕密度调整图像资源，从而优化用户体验。更多的细节可以参照SupportDifferent Screens.

 

Controlling Your App’s Availability for BusinessReason

        除了根据设备特点限制你的app可用性以外，你可能会因为商业原因或者法律原因限制你的app的有效性。例如，一个显示伦敦地铁的列车时刻表的app不太可能被伦敦以外的用户使用到。对于这种情况，Google PlayStore提供了由开发者控制的选择过滤器。通过这个过滤器，你可以根据非技术原因例如用户的地域或者用户的无线运营商来控制你的app的可用性。

       技术兼容性的过滤器（例如需要某个硬件配置）需要的信息总是被包含在你的APK文件中。而非技术性过滤器（例如用户的地理位置）则由Google PlayStore developer console来控制。