Android API guides–device Compatibility

Compatibility of devices

Statement:

This article is translated by Gordon

Posted on www.dlvoice.com

Welcome reprint, but please keep this statement

Original address: http://developer.android.com/guide/practices/compatibility.html

Android can be run on different types of devices, from mobile phones to tablets and TVs. These different devices will provide developers with a large number of potential users. So in order for your app to run well on all devices, you need to accept a variety of features and a friendly user interface that provides a different screen configuration.

To achieve this goal, Android provides a dynamic framework. Developers only need to provide a static file with different configuration application resources (such as different XML layouts for different screen sizes) on this basis. Then, Android will load the appropriate resource files based on the different device configurations. So, with a little predictive application design plus some additional application resources, you can make your app work well on different devices with just one app package (APK).

Of course, if necessary, you can specify your app performance requirements so that the Google Store can control which devices can install your app. This article will explain how to get your app to control the devices used and how to ensure that your app is accessible to the right users. For more information on how to adapt your application to different devices, read the "Supporting Different Devices" section.

What does compatibility mean?

When you read the Android development manual, you will encounter the word "compatibility" in different situations. In a way, there are two types of compatibility: Device compatibility and application compatibility.

Because Android is an open source project, any hardware manufacturer can produce a device that runs an Android operating system. However, we call it "Android-compatible" only if the device can properly run applications written based on the Android execution environment. Details about the Android execution environment are defined in the Android compatibility program, and each device needs to pass the compatibility test (CTS) to be considered compatible.

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

However, you do need to determine whether your app is compatible with various device configurations. Because Android runs on many different configurations of devices, not all features are supported on any device. For example, some devices may not support compass sensors, and if your application requires a compass sensor, then your application will only be compatible with those devices that have compass sensors.

Control the compatibility of applications with different devices

Apps can use the platform's APIs to work with the various features that Android supports, some of which are hardware-related (such as compass sensors), some that are related to software (such as app widgets), and some that are related to the Peace platform version. Not all devices support all features, so you need to control the compatibility of your devices based on the needs of your application.

In order for your app to be used to the fullest, you need to work hard to make your app use an APK compatible with as many devices as possible. In most cases, you can do this by banning optional features at run time and providing optional application resources for different configurations, such as using different layouts for different screen sizes. If necessary, you can decide if you can install your app from the Google store based on the following device features:

• Device features
• Platform version
• Screen configuration

Device features

To be able to manage application compatibility based on the device's characteristics, Android defines a feature ID for hardware and software features that are not present on all devices. For example, the feature ID of the compass sensor is feature_sensor_compass and the feature ID of the app widget is feature_app_widgets.

If necessary, you can declare an <uses-feature> element in your app's manifest file so that devices that do not support these features will not be able to install your app.

For example, if your application is not interested in devices that do not have a compass sensor, then you can declare the requirements of a compass sensor in the manifest file as follows:

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

The Google store compares the feature requirements of your app with the available features of the user's device, and then determines whether your app meets the appropriate device. If the device doesn't have all the features required to support the app, the user won't be able to install your app.

Of course, if your application's main function does not require such device features, you should set the required property to false and then check the corresponding device features when the app is running. If the device does not support these features, it is necessary to turn off the relevant application features. For example, you can call the Hassystemfeature () function as shown below to query whether the device supports the corresponding feature:

Packagemanager pm = Getpackagemanager (); if (!pm.hassystemfeature (Packagemanager.feature_sensor_compass)) {//This device does is not a COMPASS, turn off the CO Mpass feature Disablecompassfeature (); }

For more information on using the Google Store to control whether an app is available, refer to the "Filters on Google Play" document.

Note : Some system permissions and device features are relevant. For example, your app requests access to Bluetooth (Bluetooth), which implies the device features that require featrue_bluetooth. You can prevent devices that do not support Bluetooth from filtering out by setting the required in <uses-feature> to "false". For more information on implied requests, please read "Permission that imply Feature Requirements".

Platform version

Different devices may not work on Android platform versions, such as android4.0,android4.4. New versions often include new APIs that were not supported by previous versions. To illustrate which APIs are available, each platform version specifies an API level. For example, Android1.0 is API Level 1 and Android4.4 is API level 19.

The app can use API level to declare a compatible minimum version and can use the Minsdkversion attribute in the <uses-sdk> tag.

For example, the Calendar Provider API was added to Android 4.0 (API level 14). If your app doesn't work without these APIs, you should declare that the minimum version supported by the app is API level 14:

<manifest > <uses-sdk android:minsdkversion= "" "android:targetsdkversion="/> ... </manifest >

The Minsdkversion property is the minimum version that the app can be compatible with, and the Targetsdkversion property is the highest version that the app has optimized.

All Android versions are forward compatible, so a high-level app should support older versions of the Android API.

Note : Targetsdkversion does not prevent devices that are above this version value from installing the app, but this value is also important because it indicates whether your app inherits the new version of the behavior change. If you do not update the Targetsdkversion value to the latest version, the system running on the latest version will assume that your application needs some previously compatible features. For example, in Android4.4 behavior changes, the alarms created by the Alarmmanager API will default incorrectly so that the system can process the application alarms in batches to conserve system power. But if your application target API level is less than 9, the system will keep the previous API.

However, when your app uses the latest platform version of the API, but the main feature does not use this API, you should check the API level at runtime and then do some processing when the API level is low. In this case, it is possible to set Minsdkversion as the lowest value of the primary function, then compare the current system version in the code, Sdk_int is the macro that represents the API level defined in Build.version_codes. Examples are as follows:

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

Configuration of the screen

Android runs on devices of different screen sizes, such as phones, tablets, and TVs. To classify devices by screen type, Android defines two properties for each device: Screen size (physical size of the screen) and screen density (the density of the screen pixels, called dpi). To simplify the different configurations, Android divides them into the following categories:

Four common size values: small, medium, large and oversized.

Some common density values are: mdpi (medium), hdpi,xhdpi (particularly high), xxhdpi (particularly high), and others.

By default, your app should be compatible with all screen sizes and densities, as the system adjusts your UI layout and image resources adaptively based on the screen. Then, you need to add different layouts and pictures based on different screen configurations, so users will have a better experience.

For more information on how to create an optional resource based on different screen configurations, and how to make your app use a different screen size, refer to the "supporting DifferentScreens" section.

Compatibility of business reason control applications

In addition to the application compatibility caused by device properties, there may be commercial and legal reasons to apply compatibility to the specified application. For example, the application of a timetable showing the operation of the London Metro may be useless outside the UK. In this case, the Google Store provides some filtering options in the developer interface, allowing you to control the effectiveness of your application, such as the user's address or wireless carrier, without the need for technical processing.

Technical compatibility filtering is always based on the information of the APK file. Non-technical filtering is filtered through the developer control interface of the Google App Store.

Then you can read the following:

Providing Resources

It's about how Android apps combine different application resources and application code and how to provide different resources for different device configurations.

Filters on Google Play

It's a different way to use Google Store to prevent your app from being installed on different devices.

You may also be interested in these chapters:

System Permissions

It's about how Android apps combine different application resources and application code and how to provide different resources for different device configurations.

Android API guides–device Compatibility