Device Compatibility

Device Compatibility

Android is designed to run on many different types of devices, from phones to tablets and televisions. As a developer, the range of devices provides a huge potential audience for your app. In order for your app to be successful on all these devices, it should tolerate some feature variability and provide a flexible user interface that adapts to different screen configurations.

To facilitate your effort toward that goal, Android provides a dynamic app framework in which you can provide configuration-specific app resources in static files (such as different XML layouts for different screen sizes). Android then loads the appropriate resources based on the current device configuration. So with some forethought to your app design and some additional app resources, you can publish a single application package (APK) that provides an optimized user experience on a variety of devices.

If necessary, however, you can specify your app's feature requirements and control which types of devices can install your app from Google Play Store. This page explains how you can control which devices have access to your apps, and how to prepare your apps to make sure they reach the right audience. For more information about how you can make your app adapt to different devices, read Supporting Different Devices.

What Does "Compatibility" Mean?

As you read more about Android development, you'll probably encounter the term "compatibility" in various situations. There are two types of compatibility: device compatibility and app compatibility.

Because Android is an open source project, any hardware manufacturer can build a device that runs the Android operating system. Yet, a device is "Android compatible" only if it can correctly run apps written for the Android execution environment. The exact details of the Android execution environment are defined by the Android compatibility program and each device must pass the Compatibility Test Suite (CTS) in order to be considered compatible.

As an app developer, you don't need to worry about whether a device is Android compatible, because only devices that are Android compatible include Google Play Store. So you can rest assured that users who install your app from Google Play Store are using an Android compatible device.

However, you do need to consider whether your app is compatible with each potential device configuration. Because Android runs on a wide range of device configurations, some features are not available on all devices. For example, some devices may not include a compass sensor. If your app's core functionality requires the use of a compass sensor, then your app is compatible only with devices that include a compass sensor.

Controlling Your App's Availability to Devices

Android supports a variety of features your app can leverage through platform APIs. Some features are hardware-based (such as a compass sensor), some are software-based (such as app widgets), and some are dependent on the platform version. Not every device supports every feature, so you may need to control your app's availability to devices based on your app's required features.

To achieve the largest user-base possible for your app, you should strive to support as many device configurations as possible using a single APK. In most situations, you can do so by disabling optional features at runtime and providing app resources with alternatives for different configurations (such as different layouts for different screen sizes). If necessary, however, you can restrict your app's availability to devices through Google Play Store based on the following device characteristics:

• Device features
• Platform version
• Screen configuration

Device features

In order for you to manage your app’s availability based on device features, Android defines feature IDs for any hardware or software feature that may not be available on all devices. For instance, the feature ID for the compass sensor is FEATURE_SENSOR_COMPASS and the feature ID for app widgets is FEATURE_APP_WIDGETS.

If necessary, you can prevent users from installing your app when their devices don't provide a given feature by declaring it with a <uses-feature> element in your app's manifest file.

For example, if your app does not make sense on a device that lacks a compass sensor, you can declare the compass sensor as required with the following manifest tag:

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

Google Play Store compares the features your app requires to the features available on each user's device to determine whether your app is compatible with each device. If the device does not provide all the features your app requires, the user cannot install your app.

However, if your app's primary functionality does not require a device feature, you should set the requiredattribute to "false" and check for the device feature at runtime. If the app feature is not available on the current device, gracefully degrade the corresponding app feature. For example, you can query whether a feature is available by calling hasSystemFeature() like this:

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

For information about all the filters you can use to control the availability of your app to users through Google Play Store, see the Filters on Google Play document.

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 <uses-feature> tag. For more information about implicitly required device features, read Permissions that Imply Feature Requirements.

Platform version

Different devices may run different versions of the Android platform, such as Android 4.0 or Android 4.4. Each successive platform version often adds new APIs not available in the previous version. To indicate which set of APIs are available, each platform version specifies an API level. For instance, Android 1.0 is API level 1 and Android 4.4 is API level 19.

The API level allows you to declare the minimum version with which your app is compatible, using the <uses-sdk> manifest tag and its minSdkVersion attribute.

For example, the Calendar Provider APIs were added in Android 4.0 (API level 14). If your app cannot function without these APIs, you should declare API level 14 as your app's minimum supported version like this:

<manifest ... >
    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
    ...
</manifest>

The minSdkVersion attribute declares the minimum version with which your app is compatible and thetargetSdkVersion attribute declares the highest version on which you've optimized your app.

Each successive version of Android provides compatibility for apps that were built using the APIs from previous platform versions, so your app should always be compatible with future versions of Android while using the documented Android APIs.

Note: The targetSdkVersion attribute does not prevent your app from being installed on platform versions that are higher than the specified value, but it is important because it indicates to the system whether your app should inherit behavior changes in newer versions. If you don't update the targetSdkVersion to the latest version, the system assumes that your app requires some backward-compatibility behaviors when running on the latest version. For example, among the behavior changes in Android 4.4, alarms created with the AlarmManager APIs are now inexact by default so the system can batch app alarms and preserve system power, but the system will retain the previous API behavior for your app if your target API level is lower than "19".

However, if your app uses APIs added in a more recent platform version, but does not require them for its primary functionality, you should check the API level at runtime and gracefully degrade the corresponding features when the API level is too low. In this case, set the minSdkVersion to the lowest value possible for your app's primary functionality, then compare the current system's version, SDK_INT, to one the codename constants inBuild.VERSION_CODES that corresponds to the API level you want to check. For example:

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();
}

Screen configuration

Android runs on devices of various sizes, from phones to tablets and TVs. In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical size of the screen) and screen density (the physical density of the pixels on the screen, known as DPI). To simplify the different configurations, Android generalizes these variants into groups that make them easier to target:

• Four generalized sizes: small, normal, large, and xlarge.
• And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), and others.

By default, your app is compatible with all screen sizes and densities, because the system makes the appropriate adjustments to your UI layout and image resources as necessary for each screen. However, you should optimize the user experience for each screen configuration by adding specialized layouts for different screen sizes and optimized bitmap images for common screen densities.

For information about how to create alternative resources for different screens and how to restrict your app to certain screen sizes when necessary, read Supporting Different Screens.

Controlling Your App's Availability for Business Reasons

In addition to restricting your app's availability based on device characteristics, it’s possible you may need to restrict your app’s availability for business or legal reasons. For instance, an app that displays train schedules for the London Underground is unlikely to be useful to users outside the United Kingdom. For this type of situation, Google Play Store provides filtering options in the developer console that allow you to control your app’s availability for non-technical reasons such as the user's locale or wireless carrier.

Filtering for technical compatibility (such as required hardware components) is always based on information contained within your APK file. But filtering for non-technical reasons (such as geographic locale) is always handled in the Google Play developer console.

Android是可以在许多不同类型的设备上运行，从手机到平板电脑和电视机。作为一名开发人员，设备的范围内提供为您的应用潜力巨大的受众。为了让你的应用是成功的在所有这些设备，就应该容忍一些功能变异，并提供适应不同的屏幕配置灵活的用户界面。

为了方便您的朝着这个目标努力，Android提供一个动态的应用程序框架，它可以提供特定配置的应用程序资源的静态文件（比如不同的屏幕大小不同的XML布局）。Android的然后加载基于当前设备配置相应的资源。因此，与一些深谋远虑到您的应用程序的设计和一些额外的应用程序资源，可以发布单个应用程序包（APK），提供在各种设备上的优化用户体验。

如果有必要，但是，你可以指定你的应用程序的功能需求和控制哪些类型的设备可以安装谷歌Play商店您的应用程序。本页说明如何控制哪些设备可以访问你的应用程序，以及如何准备你的应用程序，以确保它们达到正确的受众。有关如何可以使您的应用程序适应不同设备的详细信息，请阅读支持不同设备。

什么是“兼容性”呢？

当你阅读更多关于Android开发，你可能会遇到的各种情况，术语“兼容性”。有两种类型的兼容性：设备的兼容性和应用程序兼容性。

由于Android是一个开源项目，任何硬件制造商可以建立一个运行Android操作系统的设备。然而，一个设备的“Android兼容”只有当它能够正确运行为编写的应用程序 的Android执行环境。Android的执行环境的具体细节由定义的Android兼容性计划以及各设备必须按顺序通过兼容性测试套件（CTS）被认为是兼容的。

作为应用开发者，你不必担心设备是否兼容Android的，因为只有那些的Andr​​oid兼容设备包括谷歌Play商店。所以，你可以放心，谁安装你的应用程序从谷歌Play商店的用户使用的是Android兼容设备。

但是，你需要考虑你是否应用程序是兼容与每个潜在的设备配置。由于Android在多种设备配置的运行，某些功能并非适用于所有设备。例如，某些设备可以不包括指南针传感器。如果你的应用程序的核心功能需要使用罗盘传感器，那么你的应用程序只与包括指南针传感器设备兼容。

控制你的应用程序的可用性，以设备

Android支持多种功能，您的应用程序可以通过平台API利用。某些功能是基于硬件的（如一个指南针传感器），一些是（例如应用窗口小部件）基于软件的，有些是依赖于平台的版本。不是每个设备支持的所有功能，所以你可能需要控制你的应用程序的可用性根据您的应用所需的功能的设备。

为了达到最大的用户群可能您的应用程序，你要努力支持使用单个APK尽可能多的设备配置成为可能。在大多数情况下，你可以在运行时禁用可选功能，并为此提供应用资源 与不同的配置方案（如不同的屏幕大小不同的布局）。如果有必要，但是，你可以限制你的应用程序的可用性，通过基于以下设备特性谷歌Play商店的设备：

• 设备功能
• 平台版本
• 屏幕配置

设备功能

为了让您能够根据设备功能管理自己的应用程序的可用性，Android的定义要素ID为任何硬件或软件的功能，可能并不适用于所有设备。例如，对于罗盘传感器的功能ID是FEATURE_SENSOR_COMPASS和应用小部件的功能ID是FEATURE_APP_WIDGETS。

如果有必要，可以阻止用户安装您的应用程序时，他们的设备不通过一个声明它提供给定功能<用途特征> 在应用程序的元素清单文件。

例如，如果您的应用程序不缺乏指南针传感器的设备上的意义，你可以声明为需要具有以下明显标记的指南针传感器：

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

谷歌Play商店比较您的应用程序需要对每个用户的设备上可用的功能特性，以确定您的应用程序是否与每个设备兼容。如果设备不提供所有您的应用程序所需的功能，用户无法安装您的应用程序。

但是，如果你的应用程序的主要功能并不需要 的设备功能，应设置所需的 属性为“假”，并检查在运行时的设备功能。如果应用程序功能不可用当前设备上，优雅地降低了对应的应用程序功能。例如，您可以查询功能是否可用通过调用 hasSystemFeature（）是这样的：

PackageManager pm = getPackageManager (); 
if  (! pm . hasSystemFeature ( PackageManager . FEATURE_SENSOR_COMPASS ))  { 
    //该设备没有指南针，关闭罗盘功能
    disableCompassFeature （）; 
}

有关你可以使用你的应用程序的可用性控制用户通过谷歌Play商店，看到滤镜的信息 在谷歌的过滤器播放 的文件。

注意：有些系统权限隐含需要的设备功能的可用性。例如，如果你的应用程序请求允许访问蓝牙，这含蓄地要求FEATURE_BLUETOOTH设备功能。您可以通过设置基于此功能禁用过滤，使您的应用程序提供给设备，而无需蓝牙所需的属性为“假”的<使用特征>标记。有关隐含所需的设备功能的详细信息，请阅读暗示功能要求的权限。

平台版本

不同的设备可以运行不同版本的Android平台，如Android 4.0或Android 4.4。每个连续的平台版本通常会加重以前的版本不提供新的API。为了表明这组API可用，各平台版本指定一个API级。例如，Android的1.0 API等级1和Android 4.4的API级别19。

API级别，您可以申报与您的应用程序兼容的最低版本，使用<使用-SDK>清单标签和它 的minSdkVersion 属性。

例如，日历提供商中的Android 4.0（API级别14）加入的API。如果您的应用程序不能没有这些API函数，你应该声明API级别14为这样你的应用程序的最低支持版本：

<清单... > 
    <使用-SDK  安卓的minSdkVersion = “14”  机器人：targetSdkVersion = “19”  /> 
    ... 
</清单>

该的minSdkVersion属性声明与您的应用程序是兼容的和最低版本targetSdkVersion属性声明上，你已经优化您的应用程序的最高版本。

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级别。例如：

如果 （建设。VERSION 。SDK_INT <  建设。VERSION_CODES 。蜂窝） { 
    //上的东西比API级别11年长运行，因此禁用
    //拖/放功能，使用ClipboardManager的API 
    disableDragAndDrop （）; 
}

屏幕配置

运行Android的各种尺寸的设备，从手机到平板电脑和电视。为了通过屏幕类型进行分类的设备，机器人定义为每个设备两个特点：屏幕大小（屏幕的物理尺寸）和屏幕密度（在屏幕上，被称为上像素的物理密度DPI）。为了简化配置的不同，Android的推广这些变异成使它们更容易向目标群体：

• 广义的尺寸：小，中，大，XLARGE。
• 和几个广义密度：MDPI（中），华电国际（华电国际），xhdpi（超高），xxhdpi（超特高），等等。

默认情况下，您的应用程序与所有的屏幕大小和密度的兼容，因为系统让你的UI布局和图像资源进行适当调整，根据需要为每个屏幕。然而，你应该通过添加不同的屏幕尺寸和优化的位图图像常见的屏幕密度专业布局优化每个屏幕配置的用户体验。

有关如何在必要的时候，读为不同的屏幕和如何限制你的应用程序特定的屏幕尺寸可替代资源的信息支持不同的屏幕。

控制你的应用程序的可用性出于商业原因

除了根据设备特性限制您的应用程序的可用性，这是可能的，你可能需要限制你的应用程序的商业或法律原因可用性。例如，一个显示列车时刻表伦敦地铁的应用程序是不太可能有用到英国以外的用户。对于这种情况，谷歌Play商店提供了在开发者控制台，让您控制您的应用程序的非技术原因的可用性，如用户的区域或无线运营商过滤选项。

技术兼容性（如需要的硬件组件）过滤总是基于包含您的APK文件内的信息。但是，过滤非技术原因（如地理区域）在谷歌Play开发者控制台始终处理。