Device compatibility in android

Device Compatibility

In this document

See also

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

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 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:

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 required attribute 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:

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 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 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:

The minSdkVersion attribute declares the minimum version with which your app is compatible and the targetSdkVersion 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 compitible 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 in Build.VERSION_CODES that corresponds to the API level you want to check. For example:

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 Device Compatibility

Device compatibility for developing with Android.

The Android ecosystem has a wide array of devices with varying hardware and capabilities. This document provides information about which Android devices are supported by the most recent version of Unreal Engine and what criteria a device must meet for compatibility.

Minimum Device Requirements

As of Uneal Engine 4.24, Android devices using OpenGL ES 3.1 are the standard specification for Unreal Engine. In addition, target devices must support the following extensions:

All devices meeting these requirements are compatible with UE4 projects. In addition, these features are available on ES 3.2 devices by default, and all ES 3.2 devices should be compatible with UE4 projects.

OpenGL ES 2.0 is deprecated in 4.23 and 4.24. It will not be active by default, but you can enable it in your Project Settings. It is fully removed in 4.25.

Minimum Supported GPUs

The following GPUs meet the above requirements for ES3.1 as of version 4.25:

Adreno 4xx and above

Mali T6xx and above

PowerVR Rogue G6100

Device Profiles

The following specifications outline the default device profiles for Android. Android device profiles are separated into buckets to help better cover the wide range of Android GPUs. These buckets are meant as defaults and it is recommended that you create custom device profiles to meet the needs of your project. As a frame of reference, the Android_High profile represents the full array of features that UE4 supports for Android devices. The Android_Low profile represents the minimum features of the lowest-end devices that UE4 currently supports.

Источник

Device Filtering and Compatibility

When you submit your APK into the Amazon Appstore, the attributes in your app manifest and build.gradle files determine what devices your app can be installed on. Incompatibilities between these files and a device’s capabilities will prevent your APK file from being supported on that device. The sections that follow explain some of the filters that influence support for devices. You can also manually adjust the list of supported devices in the developer console.

Background Knowledge

Because Amazon’s Fire OS is based on Android, Amazon tries to maintain as much parity with Android as possible. Because of this, the documentation here doesn’t duplicate the information in the Android documentation; instead, it covers how Amazon and Fire OS differ. For a better understanding of the concepts here, consult these foundational Android documentation topics:

Key Terms Related to Device Filtering

The following are common terms used with device filtering in app submission.

For a more comprehensive glossary, see the App Submission Glossary.

Device Compatibility Determined by Your APK’s Manifest

As with standard Android practices, the attributes in your APK’s manifest and build.gradle files determine which devices are compatible with your app. For example:

• If you set minSdkVersion=4 and smallScreens=false in the app manifest, the Amazon Appstore prevents the app from being installed on any device that doesn’t support those requirements.
• If your manifest declares a requirement for a camera feature ( ), any device that does not have a camera won’t be compatible. Customers with incompatible devices will not see the app as available to be installed.

Using the filters in your APK’s manifest, Amazon Appstore checks the hardware and software requirements for the customer’s device as well as the carrier, location, and other characteristics. Amazon also looks at the geographic location availability requirements as specified in your app’s metadata (which you select when publishing your app). If your app is compatible with the device according to the filter rules, your app is made available to the customer. If the app is incompatible, your app is hidden from search results and category browsing for that customer’s device.

The following table shows examples of filters:

Filter Type	Example
Filtering based on device compatibility	If you state in the app manifest that the app requires GPS, the Amazon Appstore does not show the app to devices that do not have a GPS.
Filtering based on app availability	If you state in the developer portal that your app should only be available in North America, the Amazon Appstore does not show the app to devices outside North America.

For a full list of supported manifest filters, see Manifest Filters Supported by the Amazon Appstore.

Support on Non-Amazon Devices

In addition to supporting Amazon devices, the Amazon Appstore supports non-Amazon devices as well. Your manifest and build.gradle file determine the filtering logic and device support on these devices as well.

To install Amazon apps on non-Amazon devices, customers do so through the Amazon Appstore for Android app. Customers might install your Amazon app on a non-Amazon device if they already purchased the app from Amazon Appstore and don’t want to buy it again from Google Play, or if they have coins or subscriptions they purchased from Amazon and want to use them in the same app on other devices, such as Android tablets.

Fire OS and Android API Levels

Fire devices use Fire OS as the operating system. Since Fire OS is a custom version of Android, each Fire OS version corresponds to an Android API level. The first step in creating your app manifest is to specify the proper Android API level in the android:minSdkVersion attribute for the Fire devices you intend to target. For example, to target all 2013 and newer tablets, your manifest should contain an entry like this:

You can also set the Android API level using the android:targetSdkVersion attribute. The targetSdkVersion attribute designates a specific Android API level. To ensure that your apps run newer API levels with enhanced security and performance, Android enforces minimum API levels for targetSdkVersion . See Android documentation to learn more about minimum targetSdkVersion requirements.

As with Android devices, not all Fire devices have the same API level. For example, some Fire TV devices run on Fire OS 7 (based on Android API level 28), others run on Fire OS 6 (based on Android API level 25), and others run on Fire OS 5 (based on API level 22). Fire tablets have even more differences between API levels. See the following for specific API levels for different Fire devices:

Minimum API Levels for targetSdkVersion

Due to requirements from Android, on December 31, 2021, Amazon will enforce the following Android API level requirements for targetSdkVersion on Fire OS 6 and 7:

Fire OS Version	Minimum API Level
Fire OS 6	25
Fire OS 7	28

You cannot submit new apps or update existing apps that do not meet the minimum API levels for targetSdkVersion on or after December 31, 2021. Any existing apps submitted to the Appstore will continue to work and be available for your customers.

See Fire OS documentation to learn more about setting minimum API levels:

Backwards and Forwards Compatibility Across API Levels

Android APIs are usually backwards compatible, meaning a device that supports Android Level 28 will support Levels 1 through 27. However, Android APIs are not forwards compatible, meaning Level 27 will not necessarily support all the functionality introduced in Level 28. As such, some features available in Fire OS 7 might not be supported in Fire OS 6. Some features in Fire OS 6 might not be supported on Fire OS 5, and so on. See the following for special considerations about how to develop for Fire OS 6 and Fire OS 7:

Evolving API Levels

Some Android API levels for devices change over time as Fire OS updates are deployed. For example, some versions of Fire tablets were initially released with Fire OS 6, but they were upleveled to Fire OS 7 later on through an over-the-air («OTA») update process.

If your APK is compatible with multiple versions of Fire OS, in the element in your manifest, set your minSdkVersion to the lowest API level your device supports in order to ensure maximum compatibility with devices. If you set the minSdkVersion to 22, devices that support only level 19 and lower won’t be compatible.

The Amazon Appstore also supports the android:maxSdkVersion attribute, which specifies the maximum allowed API level on the device. In most cases, use of this attribute is not needed unless there is a breaking incompatibility with a higher API level.

Common Hardware and Software Capabilities

After you specify the minSdkVersion , make sure your and elements are appropriate for the devices you want your app to be compatible with. Refer to specifications for Fire Tablets and Fire TV for specific hardware and software capabilities.

Be aware of implied (or unstated) feature requirements as well. As noted in the Android documentation, specifying for certain capabilities implies one or more elements, with android:required=»true» assumed. Because the implied features are required, the APK will not be compatible with any device that does not provide those features, even if the app is designed to degrade gracefully when features aren’t present.

To better understand implied features, consider this scenario. Your app uses the device’s current location to find nearby gas stations. The app can get your current location from the device’s GPS, but if GPS is not available, the user can input an address or location. To use the GPS, you should include this element in your manifest:

However, if you don’t explicitly define the feature requirements, these elements are implicitly defined:

If you then provide this APK to the Amazon Appstore, only Fire tablets with built-in GPS capabilities (that is, with WAN, or wireless access networks) would be compatible. To be compatible with additional Fire devices, you should include these elements in your manifest but specify them as not required (provided your app functions correctly without GPS):

For a full list of permissions that cause implied features, see Permissions that Imply Feature Requests.

Device Filtering for Fire TV Devices

For Fire TV devices, the following manifest attribute identifies support for Fire TV:

This attribute indicates that the touchscreen feature is false . Fire TV devices do not support touchscreens and multi-touch capabilities, whereas phones and tablets do. As a result, you must declare this android.hardware.touchscreen attribute to be false for the Appstore to classify your app as compatible with Fire TV devices.

However, this classification isn’t automatic. When you upload an APK designed for Fire TV devices, you must still manually select which devices your APK is compatible with in the developer console. See Adjust Device Support for your APK for details.

Device Filtering for Web Apps

Although device filtering based on your Android manifest is not available for web apps, you can still control the supported devices through a list of check boxes during the submission process. With web apps, even though you submit a URL to a website or upload a zip package with web files, the Amazon Appstore takes the web app and generates an Android app using a Cordova wrapper. This Cordova-packaged app is the an Android app that users download and install on their devices.

Web apps are compatible with all devices because in terms of Android APIs, they are very basic — there’s one activity with a WebView into which web files or a URL is loaded, and the API level is set to 10 to gain the widest compatibility possible.

Specifying an Installation Location for Your App

Your Android Manifest file specifies the installation location for your app on Fire devices. For most apps, setting this value to External Storage ( preferExternal ) will provide a better experience for your app’s users, as it will reduce scenarios where customers can’t install your app because their device’s internal storage is full. For more information, see Specifying the Installation Location for Your App.

Remove uses-amzn-sdk from App Manifest

If you have the following tag in your app’s manifest, , remove it. This tag relates to the old Fire OS SDK add-on and is no longer used for apps on Fire TV.

Although your app will (usually) still work with this tag in your manifest, removing it will avoid any future incompatibilities. None of the components of the old Fire OS SDK add-on are required to develop apps for Fire devices. Instead, use standard Android APIs and the Amazon SDKs.

Multiple APKs for the Same Application Listing

Although you can support different devices within a single APK (such as by checking for the permissions at runtime and degrading gracefully if the device doesn’t support the feature), it might be easier for you to build multiple APKs for the same application listing. Each APK can accommodate different software or hardware features and components for different devices.

The device differences accommodated by multiple APKs might include the API level, OpenGL compression format, CPU, screen size and density, device features, or even other factors such as geographic locales. For example, you might want an APK for Fire tablets, a separate APK for Fire TV, and another APK for non-Amazon Android devices. For this reason, the Amazon Appstore lets you upload more than one APK for the same app.

No matter how many APKs you upload, the user sees just one app in the Appstore. The APK that gets downloaded depends on the user’s device. For example, suppose you have an app called «Stream Sports Everywhere.» You want the app to work seamlessly across phones, tablets, and TVs. However, you find it difficult to use a single APK for all of these devices. As such, you decide to create two APKs — one for phones/tablets, and one for TVs.

In the Appstore, the user sees just one «Stream Sports Everywhere» app. When the user installs the app from a TV device, the APK designed for TVs gets installed. When the user installs the app from a phone or tablet, the APK designed for phones and tablets gets installed.

If you charge for your app, the customer won’t be prompted to re-purchase the same app on other devices because the user has already purchased the app. Customers have to buy your app just one time, and the correct, optimized version will automatically be delivered for each device they use.

Additionally, reporting, metrics, and reviews are consolidated for the app across all the APKs associated with the app.

Requirements for Multiple APKs

When you submit multiple APKs for the same app, be sure to do the following:

1. Give each APK a unique version code.

The versionCode is an internal numbering scheme not displayed to users. (Only the versionName is shown to users.) Version codes are single integers you choose, for example, 1 or 1254 . The versionCode (and versionName ) are specified in your app’s build.gradle file. See Version Your App for details.

The versionCode is used to indicate successive versions of your app. When you have multiple APKs and publish an update, the versionCode also determines whether the device receives the updated APK. Higher versionCode numbers indicate newer versions. Devices compatible with the APK will receive an app update only if the versionCode in the updated APK is higher than the existing device APK’s versionCode .

For example, suppose you have one app with two APKs — APK «Ham» with versionCode 10 and APK «Eggs» with versionCode 20. A customer has a device with «Eggs» installed. In an update to your APKs, you decide to remove «Eggs» and use «Ham» exclusively, targeting all devices with it. If you increment Ham’s versionCode to 11, customers with Eggs already installed won’t receive the update because Eggs has a higher versionCode . Therefore you will need to set your versionCode to 21 or higher before submitting an update.

2. Use the same package name for each APK within the same application listing.

Each APK for the same application listing must use the same package name in the manifest. See package for details.

Every app in the Appstore is identified by its package name. Each app’s package name must be unique, and for catalog integration, the package name cannot include the term amazon .

Example of versionCode with Multiple APKs

Let’s walk through an example of package names and versionCode with multiple APKs. Suppose that for the same app, you’re building separate APKs — one APK for Fire tablets and one APK for Amazon Fire TV devices. The attributes for your first APK’s manifest might look like this:

Источник