Android Google Official document parsing--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 apps to be successful on all these devices, it should tolerate some feature variability and provide a fle Xible user interface that adapts to different screen configurations.
Android is designed to run on many different devices, from mobile phones to tablets and TVs. As a developer, the range of devices provides a huge potential user for your app. For your app to work successfully on those devices, you need to tolerate some of the changing features and provide a flexible user interface to accommodate different screen structures.
To facilitate (promote) your effort toward that goal, Android provides a dynamic app framework in which you can provide Configur Ation-specific app resources in the static files (such as different XML layouts for different screen sizes). Android then loads the appropriate resources based in the current device configuration. So with some forethought to your app design and some additional app resources, you can publish a single application Packag E (APK) that provides an optimized user experience on a variety of devices.
To drive your efforts towards the goal, Android provides a dynamic app framework that allows you to provide unique configuration of app resources in a static file (for example, different XML layouts for different screen sizes). Android will then load the appropriate resources based on the current device profile. So with the pre-design of your app and some additional app resources, you can publish an app package (APK) that can then provide the best user experience on different 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 can control which devices has access to your apps, and how to prepare your apps to make sure T Hey reach the right audience. For more information about what you can do your app adapt to different devices, read supporting different devices.
However, if necessary, you can also specify the feature support for your app and control which devices can install your app from the Google Play store. This page explains how to control whether different devices can use your application, and how to prepare it in your app to ensure that the app is available to the right device. For more information on how to make your app available for different devices, see supporting Different Devices.

What Does "Compatibility" Mean?

As you read more on Android development, you'll probably encounter the term "compatibility" in various situations. There is types of Compatibility:device compatibility and app compatibility.
As you read more about Android development documentation, you are likely to encounter the term "compatibility" in a variety of situations. There are two different types of compatibility: Device compatibility and application compatibility.
Because Android is an open source project, any hardware manufacturer can build a device that runs the Android operating sy Stem. 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 is defined by the Android compatibility program and each device mu St Pass the Compatibility Test Suite (CTS) in order to be considered compatible.
Because Android is an open source project, any hardware manufacturer can make a device that runs the Android operating system. And as long as a device can run correctly Android apps in the running environment are "Android compatible". The exact details of the Android operating environment are defined by the Android-compatible program, and every device must pass the compatibility test to ensure that it is considered compatible.
As an app developer, you don ' t need to worry about whether a device is Android compatible, because only devices that's a Ndroid compatible include Google Play Store. So you can rest assured this users who install the your app from Google Play Store is using an Android compatible device.
As an app developer, you don't have to worry about whether the device is Android compatible, because only Android-compatible devices exist in the Google Play store. So you can rest assured that installing your app from the Google Play store is an Android-compatible device.
However, need to consider whether your app are compatible with each potential device configuration. Because Android runs on a wide range of device configurations, some features is not available on all devices. For example, some devices is not include a compass sensor. If your app ' s core functionality requires the use of a compass sensor and then your app is compatible only with devices that Include a compass sensor.
However, what you need to consider is whether your app is compatible with every possible device. Because Android runs on a wide range of device profiles, some features are not necessarily available on all devices. For example some devices may not have compass sensors. If your application core features require a compass, then your app is smart and compatible with a compass-enabled device.

Controlling Your App ' s availability to Devices

Android supports a variety of features your app can leverage through platform APIs. Some Features is hardware-based (such as a compass sensor), Some is software-based (such as app widgets), and Some are D Ependent on the platform version. Not every device supports every feature, so could need to control your app's availability to devices based on your app ' s Required features.
Android offers a variety of features that you can use with Platform APIs. Some features are hardware-based (such as a compass), some are software-based (such as app widgets), and others are platform-dependent versions. Not every device supports all features, so you need to control the availability of your app on your device based on the features you need for your app.
To achieve the largest user-base possible for your apps, you should strive to support as many device configurations as poss Ible using a single APK. In the most situations, you can do so by disabling optional features at runtime and providing apps 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 Followin G Device Characteristics:

• Device Features
• Platform version
• Screen configuration

To achieve the most possible user base for your application, you need to support as many device configurations as possible with only one installer. In most cases, you can implement it by canceling some of the optional features at run time, providing alternative app resources for different configurations, such as providing different layouts for different screen sizes. However, if necessary, you can limit your app availability by basing on the following device characteristics:

• Device features
• Platform version
• Screen shape

Device Features

In order for manage your app's availability based on device features, Android defines feature IDs for any Hardware or software feature that May is available on all devices. For instance, the feature ID for the compass sensor was feature_sensor_compass and the feature ID for app widgets is Featur E_app_widgets.
for you. Based on device features to manage the usability of your app, Android defines feature IDs for all hardware and software features that are not necessarily available on all devices. For example, the feature ID of the compass is feature_sensor_compass, and the feature ID of the app gadget is feature_app_widgets.
If necessary, you can prevent the users from installing your apps when their devices don ' t provide a given feature by Dec Laring it with a <uses-feature> element in your app ' s manifest file.
If necessary, you can prevent users ' devices from installing your app when they do not provide a feature in the manifest file of your application <uses-feature> definition.
For example, if your app does do sense on a device that lacks a compass sensor, you can declare the compass SE Nsor as required with the following manifest tag:
For example, if your app doesn't make sense on a device that lacks a compass, you can declare that the compass is needed by following the 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 Determi Ne 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.
Google Play Stor E Compare the features you need for your app and the features available to your user device to determine if your app is compatible on your device. If the device doesn't provide all the features your app needs, users won't be able to install your app.
However, if your app ' s primary functionality does not require a device feature, you should set the required Attribut E to ' false ' and check for the device feature at runtime. If The app is feature-available on the current device, gracefully degrade the corresponding app feature. For example, you can query whether a feature are available by calling Hassystemfeature () like this:
However, if your application's primary functionality does not require a device attribute, you should set the desired property to "false" and then check the device properties at run time. If the application features are not available on the current device, gracefully reduce the application characteristics. For example, you can query whether an attribute is available by calling Hassystemtfeature () like this:

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

For information on all the filters you can use the control the availability of your apps to users through Google Play Sto Re, see the Filters on Google Play document.
See all the filters you can use to control the usability of your app to users through the Google Play store, see filters on Google Play documentation.

　　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 apps available to devices without Bluetooth by setting the RE quired attribute to ' false ' in the <uses-feature> tag. For more information on implicitly required device features, read Permissions that imply Feature Requirements.
　　Note : Some system permissions imply the availability of device features that require support. For example, if your app requires Bluetooth access, the device features that need to be feature_bluetooth are implied. You can set this feature to be unavailable and make your app available on devices that don't have Bluetooth, and the properties you need in the Settings <uses-feature> tab are "false". For more information about the implied device features, see 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 isn't available in the previous version. to indicate which set of APIs is available, each platform version specifies a API level. For instance, Android 1.0 are API Level 1 and Android 4.4 are API level 19.
Different devices may run different versions of the Android platform, such as Android4.0 or Android4.4. Each successive platform version often adds new APIs and the previous version is not supported. Indicates which APIs collection is available, and each platform version specifies an API level. For example, Android1.0 is API Level 1, and Android4.4 is API level 19.
The API level allows-declare the minimum version with which your app is compatible, using the <uses-sdk> mani Fest tag and its minsdkversion attribute.
The API level allows you to define the least compatible version of your app, using the <uses-sdk>mainfest tag and his "minsdkversion" attribute.
For example, the Calendar Provider APIs were added with Android 4.0 (API level 14). If your app cannot function without these APIs, you should declare API level as your app ' s minimum supported version Li Ke this:
For example, the Calendar Provider APIs were added at Android4.0 (API level 14). If your application is not available without those APIs, you should define the APIs level 14 as the minimum supported version of your app like this:

<><android:minsdkversion= "+"  Android:targetsdkversion= "/> " ... </ Manifest >

The Minsdkversion attribute declares the minimum version with which your app is compatible and the Targetsdkversion attrib Ute declares the highest version on which you ' ve optimized your app.
The "Minsdkversion" attribute defines the minimum version that your app is compatible with, and the "Targetsdkversion" attribute defines the best version of your app.

Each successive version of Android provides compatibility for apps this were built using the APIs from previous platform V Ersions, so your app should all is compitible with a future versions of Android while using the documented Android APIs.
Each successive version of Android offers application compatibility because it is constructed with the previous platform version of APIs, so your application is always compatible with future Android versions by using the identified Android APIs.

　　 Note: The targetsdkversion attribute does not prevent your apps from being installed on platform versions that is higher than The specified value, but it's important because it indicates to the system whether your app should inherit behavior Chang Es in newer versions. If you don't update the targetsdkversion to the latest version, the system assumes that your app requires some Backward-co Mpatibility behaviors when running on the latest version. For example, among the behavior changes on Android 4.4, alarms created with the Alarmmanager APIs is now inexact by Defau Lt so the system can batch app alarms and preserve system power, but the system would retain the previous API behavior for Your app if your target API level is lower than "19".
　　 Note: the "Targetsdkversion" property does not prevent your app from being installed on a platform higher than the given version value, but it is important because it indicates to the system whether your app can inherit the new version of the behavior change. If you do not update "Targetsdkversion" to the latest version, the system assumes that your app requires some backward compatibility behavior when running under the latest version. For example, in the Android4.4 version of the behavior change, the alarm clock is created by the Alarmmanager APIs, but now it is the default, so the system can process the alarm in batches to protect the system power, but if your target API level is less than 19 o'clock, The system will still retain the previous API behavior for your app.
However, if your app uses APIs added in a to recent platform version, but does not require them for its primary function Ality, should check the API level at runtime and gracefully degrade the corresponding features when the API level is T OO Low. In this case, set the minsdkversion to the lowest value possible for your app's primary functionality, then compare the CU Rrent system's version, Sdk_int, to one of the codename constants in Build.version_codes this corresponds to the API level yo U want to check. For example:
However, if your application uses a newer version of the platform APIs but is not required in the main features, when the API level is too low, you should check the API level at runtime and then smooth down the appropriate features. In this case, set the "Minsdkversion" to the lowest value for your app's main function, and then compare it to the current version of the system, "Sdk_int", as a constant in "build.version_codes", equivalent 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 one, so disable// the Drag/dro P features that use Clipboardmanager APIsdisabledraganddrop ();}

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, and characteristics for each device:screen size (the Physical size of the screen) and screens 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.

Android runs on different sizes of devices, from phones to tablets and TVs. To classify devices by their screen type, Android defines two features for each device: the screen size (physical size of the screen) and the number of screen cables (the physical density of the pixels on the screen, called DPI). To simplify different configurations, Android sets the concept of a group of situations to make sure they are easily identifiable:

• Four broad dimensions: Small,normal,large, and XLarge.
• There are several generalized densities: mdpi (Medium), hdpi (hdpi), xhdpi (Extra high), xxhdpi (Extra-extra), and others.

By default, your app. compatible with all screens sizes and densities, because the system makes the appropriate adjustmen TS to your UI layout and image resources as necessary for each screen. However, 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 what to create alternative resources for different screens and how to restrict your apps to certain SC Reen sizes when necessary, read supporting Different Screens.

By default, your app is compatible with all screen sizes and densities, as the system adjusts your UI layout and image resources appropriately for each screen when necessary. However, you should configure the maximum user experience for each screen by setting the optimal binary image for different screen sizes and adding specialized layouts and for the same number of screen cables.
For information on how to create a different screen for selection and how to limit the determination of the screen 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 could need to restrict Your app ' s availability for business or legal reasons. For instance, a app, displays train schedules for the London underground are unlikely to being useful to users outside th e-Kingdom. For this type of situation, Google Play Store provides filtering options in the developer console L 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) are always based on information contained with In your APK file. But filtering for non-technical reasons (such as geographic locale) are always handled in the Google Play developer Console .

In addition, based on device configuration to limit the availability of your app, it's likely that you need to limit the availability of your app for business or legal reasons. For example, an app that showcases the London Metro train timetable is unlikely to be useful for users outside of the UK. In this case, the Google Play store provides filtering options in the development console, allowing you to control the usability of your application for non-technical reasons such as the user's address or wireless carrier.
Filtering for technical compatibility (such as requiring hardware components) is always based on the information contained in the APK file. But filtering for non-technical reasons (such as geolocation) is always done in the developer console of Google Play.