Compatibility mode in android

Screen Compatibility Mode

In this document

See also

Figure 1. An application running in compatibility mode on an Android 3.2 tablet.

Figure 2. The same application from figure 1, with compatibility mode disabled.

Notice: If you’ve developed an application for a version of Android lower than Android 3.0, but it does resize properly for larger screens such as tablets, you should disable screen compatibility mode in order to maintain the best user experience. To learn how to quickly disable the user option, jump to Disabling Screen Compatibility Mode.

Screen compatibility mode is an escape hatch for applications that are not properly designed to resize for larger screens such as tablets. Since Android 1.6, Android has supported a variety of screen sizes and does most of the work to resize application layouts so that they properly fit each screen. However, if your application does not successfully follow the guide to Supporting Multiple Screens, then it might encounter some rendering issues on larger screens. For applications with this problem, screen compatibility mode can make the application a little more usable on larger screens.

There are two versions of screen compatibility mode with slightly different behaviors:

Version 1 (Android 1.6 — 3.1) The system draws the application’s UI in a «postage stamp» window. That is, the system draws the application’s layout the same as it would on a normal size handset (emulating a 320dp x 480dp screen), with a black border that fills the remaining area of the screen.

This was introduced with Android 1.6 to handle apps that were designed only for the original screen size of 320dp x 480dp. Because there are so few active devices remaining that run Android 1.5, almost all applications should be developed against Android 1.6 or greater and should not have version 1 of screen compatibility mode enabled for larger screens. This version is considered obsolete.

To disable this version of screen compatibility mode, you simply need to set android:minSdkVersion or android:targetSdkVersion to «4» or higher, or set android:resizeable to «true» .

Version 2 (Android 3.2 and greater) The system draws the application’s layout the same as it would on a normal size handset (approximately emulating a 320dp x 480dp screen), then scales it up to fill the screen. This essentially «zooms» in on your layout to make it bigger, which will usually cause artifacts such as blurring and pixelation in your UI.

This was introduced with Android 3.2 to further assist applications on the latest tablet devices when the applications have not yet implemented techniques for Supporting Multiple Screens.

In general, large screen devices running Android 3.2 or higher allow users to enable screen compatibility mode when the application does not explicitly declare that it supports large screens in the manifest file. When this is the case, an icon (with outward-pointing arrows) appears next to the clock in the system bar, which allows the user to toggle screen compatibility mode on and off (figure 3). An application can also explicitly declare that it does not support large screens such that screen compatibility mode is always enabled and the user cannot disable it. (How to declare your application’s support for large screens is discussed in the following sections.)

Figure 3. The pop up menu to toggle screen compatibility mode (currently disabled, so normal resizing occurs).

As a developer, you have control over when your application uses screen compatibility mode. The following sections describe how you can choose to disable or enable screen compatibility mode for larger screens when running Android 3.2 or higher.

Disabling Screen Compatibility Mode

If you’ve developed your application primarily for versions of Android lower than 3.0, but your application does resize properly for larger screens such as tablets, you should disable screen compatibility mode in order to maintain the best user experience. Otherwise, users may enable screen compatibility mode and experience your application in a less-than-ideal format.

By default, screen compatibility mode for devices running Android 3.2 and higher is offered to users as an optional feature when one of the following is true:

• Your application has set both android:minSdkVersion and android:targetSdkVersion to «10» or lower and does not explicitly declare support for large screens using the element.
• Your application has set either android:minSdkVersion or android:targetSdkVersion to «11» or higher and explicitly declares that it does not support large screens, using the element.

To completely disable the user option for screen compatibility mode and remove the icon in the system bar, you can do one of the following:

Easiest:

In your manifest file, add the element and specify the android:xlargeScreens attribute to «true» :

That’s it. This declares that your application supports all larger screen sizes, so the system will always resize your layout to fit the screen. This works regardless of what values you’ve set in the attributes.

Easy but has other effects:

In your manifest’s element, set android:targetSdkVersion to «11» or higher:

This declares that your application supports Android 3.0 and, thus, is designed to work on larger screens such as tablets.

Caution: When running on Android 3.0 and greater, this also has the effect of enabling the Holographic theme for you UI, adding the Action Bar to your activities, and removing the Options Menu button in the system bar.

If screen compatibility mode is still enabled after you change this, check your manifest’s and be sure that there are no attributes set «false» . The best practice is to always explicitly declare your support for different screen sizes using the element, so you should use this element anyway.

For more information about updating your application to target Android 3.0 devices, read Optimizing Apps for Android 3.0.

element and specify the android:compatibleWidthLimitDp attribute to any value higher than «320» :

Using this technique allows you to specify exactly what your application’s limit is for layout resizing. Normally, only applications that are already built against Android 3.2 (or higher) use this attribute, because the primary intention is to specify at what size should screen compatibility mode actually be offered to users.

Note: Currently, screen compatibility mode only emulates handset screens with a 320dp width, so screen compatibility mode is not applied to any device if your value for android:compatibleWidthLimitDp is larger than 320.

Enabling Screen Compatibility Mode

When your application is targeting Android 3.2 (API level 13) or higher, you can affect whether compatibility mode is enabled for certain screens by using the element.

Note: Screen compatibility mode is not a mode in which you should want your application to run—it causes pixelation and blurring in your UI, due to zooming. The proper way to make your application work well on large screens is to follow the guide to Supporting Multiple Screens and provide alternative layouts for different screen sizes.

By default, when you’ve set either android:minSdkVersion or android:targetSdkVersion to «11» or higher, screen compatibility mode is not available to users. If either of these are true and your application does not resize properly for larger screens, you can choose to enable screen compatibility mode in one of the following ways:

In your manifest file, add the element and specify the android:compatibleWidthLimitDp attribute to «320» :

This indicates that the maximum «smallest screen width» for which your application is designed is 320dp. This way, any devices with their smallest side being larger than this value will offer screen compatibility mode as a user-optional feature.

Note: Currently, screen compatibility mode only emulates handset screens with a 320dp width, so screen compatibility mode is not applied to any device if your value for android:compatibleWidthLimitDp is larger than 320.

If your application is functionally broken when resized for large screens and you want to force users into screen compatibility mode (rather than simply providing the option), you can use the android:largestWidthLimitDp attribute:

This works the same as android:compatibleWidthLimitDp except it force-enables screen compatibility mode and does not allow users to disable it.

Источник

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.

Источник