[Android document translator] device compatibility

Original address: Device compatibility

Android is designed to run on many different types of devices, from mobile phones to tablets to TVs. As a developer, the coverage of your device provides a broad range of potential users for your app. In order for your app to run successfully on these devices, it should allow for some feature differences and provide a flexible UI to fit different screen configurations.

To boost your efforts to achieve your goals, Android provides a dynamic application framework that allows you to put application resources (such as XML layout files that correspond to different screen sizes) in a static file that you specify. Android will load the appropriate resources based on the current device configuration. So, by thinking ahead of your app design and additional application resources, you can publish a single app package (APK) to provide an optimized user experience for multiple devices.

If necessary, you can also specify the app's feature requirements and control which types of devices can install your app from the Google Play store (App Store). This article will show you how to control which devices can use your app to get your app to the right people. For more information on adapting to different devices, please read support for different devices.

What does "Compatibility" mean?

As you read more information about Android development, you will encounter the term "compatibility" in a number of situations. There are two types of compatibility: Device compatibility and app compatibility.

Because Android is an open source project, any hardware vendor can develop a device that runs the Android operating system. Android is compatible only if the device works correctly for apps that are developed for Android execution environments. 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) to be considered compatible.

As an app developer, you don't have to worry about whether your device is compatible with Android, because only Android-compatible devices will have Google Play Store. So you can rest assured that users who install your app from the Google Play store use Android-compatible devices.

However, you do need to consider whether your app is compatible with a variety of potential device configurations. Because Android runs on a variety 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 features require a compass sensor, your app is only compatible with devices with compass sensors.

Control the usability of your app on your device

Android supports a wide range of features, and your app can take advantage of platform APIs to get them. Some of the features are hardware-based (such as compass sensors), some are software-based (such as application widgets), and others are platform-dependent versions. Not every device supports every feature, so you may need to control the availability of your app to your device based on the features your app requires.

In order for the app to reach the maximum user base, you should try to get a single apk to support as many device configurations as possible. In most cases, you can do this by disabling certain features at run time, providing replaceable application resources for different configurations, such as layouts that correspond to different screen sizes. However, if necessary, you can limit the availability of apps on your device based on the following device features:

• Device features
• Platform version
• Screen configuration

Device features
To enable you to manage the usability of your app based on device features, Android defines a "feature ID" for hardware or software features that might not be available. For example, the feature ID of a compass sensor is feature_sensor_compass, and the feature ID of the application widget is feature_app_widgets.

If necessary, you can avoid installing apps when the user's device does not provide this feature by declaring it in the <uses-feature> element of the app's manifest file.

For example, if your app doesn't make sense for devices that don't have a compass sensor, you can claim the compass sensor in the manifest tag below:

<>    <android:name= " Android.hardware.sensor.compass "                  android:required=" true "/>     ... </ Manifest >

Google Play Store compares the features required by your app and the features available to each user's device to determine if your app is compatible with the device. If the device does not provide all the features required by the app, the user will not be able to install your app.

However, if the main functionality of the app does not require device features, you should set the "required" property to "false" and check the device features at run time. If the app feature is not available on the current device, it is graceful not to use the corresponding feature. For example, you can query the availability of a feature by calling Hassystemfeature ():

Packagemanager pm = Getpackagemanager (); if (! pm.hassystemfeature (Packagemanager.feature_sensor_compass)) {    // This device does does have a compass, turn off the compass feature    DISABLECOMPASSFE Ature ();}

For information about your ability to control user filtering of app availability, see Google Play filtering for documents.

Note: Some system permissions implicitly require the availability of device features. For example, if the app requests access to Bluetooth, it implicitly requires a Feature_bluetooth device feature. You can disable filtering based on this feature by setting the Require property to False in the <uses-feature> tab so that the app can be used for devices that do not have Bluetooth. For more information on the implicit requirement for device features, read the permission that implies the requirement attribute.

Platform version
Different devices may run different versions of the Android platform, such as Android4.0 or Android4.4. Each successive platform version tends to add new APIs that are not available in the previous version. to indicate which set of APIs are available, each platform version specifies the API level. As an example, Android1.0 is API Level 1 and Android4.4 is API level 19.

The API level allows you to declare the minimum version compatible with the app by using the <uses-sdk> manifest tag and its minsdkversion properties.

For example, API Calendar provider is added at Android4.0 (API level 14). If the app does not have these APIs, you should declare API level 14 as the minimum supported version of the app:

<>    <android:minsdkversion= "14"  android:targetsdkversion= "/>     " ... </ Manifest >

The Minsdkversion property declares the minimum app-compatible version, and the Targetversion attribute declares the highest version of app optimization.

Each successive version of Android provides compatibility with apps compiled with the previous version of the API, so your app uses the document's Android API to always be compatible with future Android versions.

Note:The Targetversion property does not prevent your app from being installed above the specified version, but it is important that it indicates to the system whether the app will inherit the updated version of the behavior changes. If you do not update targetversion to the latest version, when running in the latest version, the system will assume that your app requires some compatible behavior. For example, in Android4.4 behavior changes, alarms created by the Alarmmanager API are now inaccurate, so the system can batch apply alarms and save system power, but if your target API level is below 19, The system retains the previous API behavior for your app.

However, if your app uses an earlier platform version of the API, but not for its main features, you should check the API level at run time and gracefully not use the corresponding feature when the API level is too low. In this case, set the minimum minsdkversion for the main function of the app, and then compare the current system version (Sdk_int) with the corresponding API-level constants you want to check in Build.version_codes. As an example:

if (Build.VERSION.SDK_INT < build.version_codes. Honeycomb) {    //  Running on something older than API level one, so disable    //  th e Drag/drop features that use Clipboardmanager APIs    disabledraganddrop ();}

Screen configuration
Android runs on devices of different sizes, from phones, tablets to TVs. To sort by their screen type, Android defines two features for each device: Screen size (physical size of the screen) and screen density (the physical density of the pixels on the screen, called DPI). To simplify different configurations, Android sums them up into groups to make them easier to correspond to:
Four general-purpose sizes: small, normal, large, oversized
Several common densities: mdpi,hdpi,xhdpi,xxhdpi and others

By default, your app will be compatible with all screen sizes and densities, as the system will make the appropriate adjustments for each screen based on your UI layout and image resources. However, you should optimize the user experience for each screen configuration by adding specific layouts for different screen sizes and optimizing bitmap images for common screen densities.

For more information on how to create alternate resources for different screens and how to limit apps to certain screen sizes if necessary, read support for different screens.

Control the availability of applications for business reasons

In addition to limiting your app availability based on device features, you may also need to limit the availability of your app for business or legal reasons. For example, the app showing the London subway itinerary is unlikely to be useful outside of the UK. Because of this, Google Play store provides filtering options in the developer console, allowing you to control the availability of your app for non-technical reasons, such as where your users are located or wireless carriers.

The filtering criteria for technical compatibility (such as requiring hardware components) are usually based on the information contained in your APK file. But the filters for non-technical reasons (such as geographic areas) are usually processed on the Google Play developer console.

[Android document translator] device compatibility