docs/html/guide/practices/compatibility.jd - LeafOS-Project/android_frameworks_base - Gitiles

 page.title=Device Compatibility
 excludeFromSuggestions=true
 @jd:body

 <div id="qv-wrapper">
 <div id="qv">
 <h2>In this document</h2>
 <ol>
   <li><a href="#defined">What Does "Compatibility" Mean?</a></li>
   <li><a href="#how">Controlling Your App's Availability to Devices</a>
     <ol>
       <li><a href="#Features">Device features</a></li>
       <li><a href="#Versions">Platform version</a></li>
       <li><a href="#Screens">Screen configuration</a></li>
     </ol>
   </li>
   <li><a href="#filtering">Controlling Your App's Availability for Business Reasons</a></li>
 </ol>

 <h2>See also</h2>
  <ol>
 <li><a
 href="{@docRoot}google/play/filters.html">Filtering on Google Play</a></li>
 <li><a
 href="{@docRoot}guide/topics/resources/providing-resources.html">Providing Resources</a></li>
 <li><a href="http://source.android.com/compatibility/index.html" class="external-link">
 Android Compatibility</a></li>
 </ol>


 </div> </div>

 <p>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.</p>

 <p>To facilitate your effort toward that goal, Android provides a dynamic app framework in which
 you can provide configuration-specific <a href="{@docRoot}guide/topics/resources/overview.html"
 >app resources</a> 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.

 <p>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 <a href="{@docRoot}training/basics/supporting-devices/index.html"
 >Supporting Different Devices</a>.</p>


 <h2 id="defined">What Does "Compatibility" Mean?</h2>

 <p>As you read more about Android development, you'll probably encounter the term "compatibility"
 in various situations. There are two types of compatibility: <em>device compatibility</em>
 and <em>app compatibility</em>.

 <p>Because Android is an open source project, any hardware manufacturer can build a device
 that runs the Android operating system. Yet, a <b>device is "Android compatible"</b> only if
 it can correctly run apps written for the
 <em>Android execution environment</em>. The exact details of the Android execution
 environment are defined by the <a href="http://source.android.com/compatibility/overview.html"
 class="external-link">Android compatibility program</a> and each device must pass the Compatibility
 Test Suite (CTS) in order to be considered compatible.</p>

 <p>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.</p>


 <p>However, you do need to consider whether your <b>app is compatible</b> 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.</p>


 <h2 id="how">Controlling Your App's Availability to Devices</h2>

 <p>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.</p>


 <p>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 <a
 href="{@docRoot}guide/topics/resources/providing-resources.html">providing app resources</a>
 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:</p>

 <ul>
   <li><a href="#Features">Device features</a>
   <li><a href="#Version">Platform version</a>
   <li><a href="#Screens">Screen configuration</a>
 </ul>


 <h3 id="Features">Device features</h3>

 <p>In order for you to manage your app’s availability based on device features,
 Android defines <em>feature IDs</em> for any hardware or software feature
 that may not be available on all devices. For instance, the
 feature ID for the compass sensor is {@link
 android.content.pm.PackageManager#FEATURE_SENSOR_COMPASS} and the feature ID for app widgets
 is {@link android.content.pm.PackageManager#FEATURE_APP_WIDGETS}.</p>

 <p>If necessary, you can prevent users from installing your app when their devices don't provide a
 given feature by declaring it with a <a href=
 "{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code &lt;uses-feature&gt;}</a>
 element in your app's <a href="{@docRoot}guide/topics/manifest/manifest-intro.html">manifest
 file</a>.</p>

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

 <pre>
 &lt;manifest ... >
     &lt;uses-feature android:name="android.hardware.sensor.compass"
                   android:required="true" />
     ...
 &lt;/manifest>
 </pre>

 <p>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.</p>

 <p>However, if your app's primary functionality does not <em>require</em>
 a device feature, you should set the <a href=
 "{@docRoot}guide/topics/manifest/uses-feature-element.html#required">{@code required}</a>
 attribute to {@code "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
 {@link android.content.pm.PackageManager#hasSystemFeature hasSystemFeature()} like this:</p>

 <pre>
 PackageManager pm = getPackageManager();
 if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
     // This device does not have a compass, turn off the compass feature
     disableCompassFeature();
 }
 </pre>

 <p>For information about all the filters you can
 use to control the availability of your app to users through Google Play Store, see the
 <a href="{@docRoot}google/play/filters.html">Filters on Google Play</a>
 document.</p>

 <p class="note"><strong>Note:</strong> Some <a href=
 "{@docRoot}guide/topics/security/permissions.html">system permissions</a> implicitly require the
 availability of a device feature. For example, if your app requests permission to access to {@link
 android.Manifest.permission#BLUETOOTH}, this implicitly requires the {@link
 android.content.pm.PackageManager#FEATURE_BLUETOOTH} device feature. You can disable filtering based
 on this feature and make your app available to devices without Bluetooth by setting the <a href=
 "{@docRoot}guide/topics/manifest/uses-feature-element.html#required">{@code required}</a> attribute
 to {@code "false"} in the <a href=
 "{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code &lt;uses-feature&gt;}</a> tag.
 For more information about implicitly required device features, read <a href=
 "{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions">Permissions that Imply
 Feature Requirements</a>.</p>


 <h3 id="Versions">Platform version</h3>

 <p>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 <a
 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">API level</a>. For instance,
 Android 1.0 is API level 1 and Android 4.4 is API level 19.</p>

 <p>The API level allows you to declare the minimum version with which your app is
 compatible, using the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code
 &lt;uses-sdk>}</a> manifest tag and its <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> attribute.</p>

 <p>For example, the <a href="{@docRoot}guide/topics/providers/calendar-provider.html">Calendar
 Provider</a> 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:</p>

 <pre>
 &lt;manifest ... >
     &lt;uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
     ...
 &lt;/manifest>
 </pre>

 <p>The <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code
 minSdkVersion}</a> attribute declares the minimum version with which your app is compatible
 and the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
 targetSdkVersion}</a> attribute declares the highest version on which you've optimized
 your app.</p>

 <p>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.</p>

 <p class="note"><strong>Note:</strong>
 The <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
 targetSdkVersion}</a> 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
 <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
 targetSdkVersion}</a> 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 <a href="{@docRoot}about/versions/android-4.4.html#Behaviors"
 >behavior changes in Android 4.4</a>, alarms created with the {@link android.app.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".</p>

 <p>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 <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code
 minSdkVersion}</a> to the lowest value possible for your app's primary functionality,
 then compare the current system's version, {@link android.os.Build.VERSION#SDK_INT}, to one the
 codename constants in {@link android.os.Build.VERSION_CODES} that corresponds to the
 API level you want to check. For example:</p>

 <pre>
 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
     // Running on something older than API level 11, so disable
     // the drag/drop features that use {@link android.content.ClipboardManager} APIs
     disableDragAndDrop();
 }
 </pre>


 <h3 id="Screens">Screen configuration</h3>

 <p>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 <acronym title="dots per inch">DPI</acronym>).
 To simplify the different configurations, Android generalizes these variants into groups that make
 them easier to target:</p>

 <ul>
   <li>Four generalized sizes: small, normal, large, and xlarge.</li>
   <li>And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high),
   xxhdpi (extra-extra high), and others.</li>
 </ul>

 <p>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.</p>

 <p>For information about how to create alternative resources for different screens
 and how to restrict your app to certain screen sizes when necessary, read <a
 href="{@docRoot}training/basics/supporting-devices/screens.html">Supporting Different Screens</a>.
 </p>


 <h2 id="filtering">Controlling Your App's Availability for Business Reasons</h2>

 <p>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.</p>

 <p>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.</p>


 <div class="next-docs">
 <div class="col-6">
   <h2 class="norule">Continue reading about:</h2>
   <dl>
     <dt><a
 href="{@docRoot}guide/topics/resources/providing-resources.html">Providing Resources</a></dt>
     <dd>Information about how Android apps are structured to separate app resources from the
    app code, including how you can provide alternative resources for specific device
    configurations.
     </dd>
     <dt><a href="{@docRoot}google/play/filters.html">Filters on Google Play</a></dt>
     <dd>Information about the different ways that Google Play Store can prevent your app
    from being installed on different devices.</dd>
   </dl>
 </div>
 <div class="col-6">
   <h2 class="norule">You might also be interested in:</h2>
   <dl>
     <dt><a href="{@docRoot}guide/topics/security/permissions.html"
         >System Permissions</a></dt>
     <dd>How Android restricts app access to certain APIs with a permission system that requires
   the user's consent for your app to use those APIs.</dd>
   </dl>
 </div>
 </div>
	page.title=Device Compatibility
	excludeFromSuggestions=true
	@jd:body

	<div id="qv-wrapper">
	<div id="qv">
	<h2>In this document</h2>
	<ol>
	<li><a href="#defined">What Does "Compatibility" Mean?</a></li>
	<li><a href="#how">Controlling Your App's Availability to Devices</a>
	<ol>
	<li><a href="#Features">Device features</a></li>
	<li><a href="#Versions">Platform version</a></li>
	<li><a href="#Screens">Screen configuration</a></li>
	</ol>
	</li>
	<li><a href="#filtering">Controlling Your App's Availability for Business Reasons</a></li>
	</ol>

	<h2>See also</h2>
	<ol>
	<li><a
	href="{@docRoot}google/play/filters.html">Filtering on Google Play</a></li>
	<li><a
	href="{@docRoot}guide/topics/resources/providing-resources.html">Providing Resources</a></li>
	<li><a href="http://source.android.com/compatibility/index.html" class="external-link">
	Android Compatibility</a></li>
	</ol>


	</div> </div>

	<p>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.</p>

	<p>To facilitate your effort toward that goal, Android provides a dynamic app framework in which
	you can provide configuration-specific <a href="{@docRoot}guide/topics/resources/overview.html"
	>app resources</a> 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.

	<p>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 <a href="{@docRoot}training/basics/supporting-devices/index.html"
	>Supporting Different Devices</a>.</p>



	<h2 id="defined">What Does "Compatibility" Mean?</h2>

	<p>As you read more about Android development, you'll probably encounter the term "compatibility"
	in various situations. There are two types of compatibility: <em>device compatibility</em>
	and <em>app compatibility</em>.

	<p>Because Android is an open source project, any hardware manufacturer can build a device
	that runs the Android operating system. Yet, a <b>device is "Android compatible"</b> only if
	it can correctly run apps written for the
	<em>Android execution environment</em>. The exact details of the Android execution
	environment are defined by the <a href="http://source.android.com/compatibility/overview.html"
	class="external-link">Android compatibility program</a> and each device must pass the Compatibility
	Test Suite (CTS) in order to be considered compatible.</p>

	<p>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.</p>


	<p>However, you do need to consider whether your <b>app is compatible</b> 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.</p>




	<h2 id="how">Controlling Your App's Availability to Devices</h2>

	<p>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.</p>


	<p>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 <a
	href="{@docRoot}guide/topics/resources/providing-resources.html">providing app resources</a>
	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:</p>

	<ul>
	<li><a href="#Features">Device features</a>
	<li><a href="#Version">Platform version</a>
	<li><a href="#Screens">Screen configuration</a>
	</ul>


	<h3 id="Features">Device features</h3>

	<p>In order for you to manage your app’s availability based on device features,
	Android defines <em>feature IDs</em> for any hardware or software feature
	that may not be available on all devices. For instance, the
	feature ID for the compass sensor is {@link
	android.content.pm.PackageManager#FEATURE_SENSOR_COMPASS} and the feature ID for app widgets
	is {@link android.content.pm.PackageManager#FEATURE_APP_WIDGETS}.</p>

	<p>If necessary, you can prevent users from installing your app when their devices don't provide a
	given feature by declaring it with a <a href=
	"{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code <uses-feature>}</a>
	element in your app's <a href="{@docRoot}guide/topics/manifest/manifest-intro.html">manifest
	file</a>.</p>

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

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

	<p>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.</p>

	<p>However, if your app's primary functionality does not <em>require</em>
	a device feature, you should set the <a href=
	"{@docRoot}guide/topics/manifest/uses-feature-element.html#required">{@code required}</a>
	attribute to {@code "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
	{@link android.content.pm.PackageManager#hasSystemFeature hasSystemFeature()} like this:</p>

	<pre>
	PackageManager pm = getPackageManager();
	if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
	// This device does not have a compass, turn off the compass feature
	disableCompassFeature();
	}
	</pre>

	<p>For information about all the filters you can
	use to control the availability of your app to users through Google Play Store, see the
	<a href="{@docRoot}google/play/filters.html">Filters on Google Play</a>
	document.</p>

	<p class="note"><strong>Note:</strong> Some <a href=
	"{@docRoot}guide/topics/security/permissions.html">system permissions</a> implicitly require the
	availability of a device feature. For example, if your app requests permission to access to {@link
	android.Manifest.permission#BLUETOOTH}, this implicitly requires the {@link
	android.content.pm.PackageManager#FEATURE_BLUETOOTH} device feature. You can disable filtering based
	on this feature and make your app available to devices without Bluetooth by setting the <a href=
	"{@docRoot}guide/topics/manifest/uses-feature-element.html#required">{@code required}</a> attribute
	to {@code "false"} in the <a href=
	"{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code <uses-feature>}</a> tag.
	For more information about implicitly required device features, read <a href=
	"{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions">Permissions that Imply
	Feature Requirements</a>.</p>







	<h3 id="Versions">Platform version</h3>

	<p>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 <a
	href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">API level</a>. For instance,
	Android 1.0 is API level 1 and Android 4.4 is API level 19.</p>

	<p>The API level allows you to declare the minimum version with which your app is
	compatible, using the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code
	<uses-sdk>}</a> manifest tag and its <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> attribute.</p>

	<p>For example, the <a href="{@docRoot}guide/topics/providers/calendar-provider.html">Calendar
	Provider</a> 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:</p>

	<pre>
	<manifest ... >
	<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
	...
	</manifest>
	</pre>

	<p>The <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code
	minSdkVersion}</a> attribute declares the minimum version with which your app is compatible
	and the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
	targetSdkVersion}</a> attribute declares the highest version on which you've optimized
	your app.</p>

	<p>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.</p>

	<p class="note"><strong>Note:</strong>
	The <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
	targetSdkVersion}</a> 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
	<a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
	targetSdkVersion}</a> 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 <a href="{@docRoot}about/versions/android-4.4.html#Behaviors"
	>behavior changes in Android 4.4</a>, alarms created with the {@link android.app.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".</p>

	<p>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 <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code
	minSdkVersion}</a> to the lowest value possible for your app's primary functionality,
	then compare the current system's version, {@link android.os.Build.VERSION#SDK_INT}, to one the
	codename constants in {@link android.os.Build.VERSION_CODES} that corresponds to the
	API level you want to check. For example:</p>

	<pre>
	if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
	// Running on something older than API level 11, so disable
	// the drag/drop features that use {@link android.content.ClipboardManager} APIs
	disableDragAndDrop();
	}
	</pre>






	<h3 id="Screens">Screen configuration</h3>

	<p>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 <acronym title="dots per inch">DPI</acronym>).
	To simplify the different configurations, Android generalizes these variants into groups that make
	them easier to target:</p>

	<ul>
	<li>Four generalized sizes: small, normal, large, and xlarge.</li>
	<li>And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high),
	xxhdpi (extra-extra high), and others.</li>
	</ul>

	<p>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.</p>

	<p>For information about how to create alternative resources for different screens
	and how to restrict your app to certain screen sizes when necessary, read <a
	href="{@docRoot}training/basics/supporting-devices/screens.html">Supporting Different Screens</a>.
	</p>








	<h2 id="filtering">Controlling Your App's Availability for Business Reasons</h2>

	<p>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.</p>

	<p>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.</p>






	<div class="next-docs">
	<div class="col-6">
	<h2 class="norule">Continue reading about:</h2>
	<dl>
	<dt><a
	href="{@docRoot}guide/topics/resources/providing-resources.html">Providing Resources</a></dt>
	<dd>Information about how Android apps are structured to separate app resources from the
	app code, including how you can provide alternative resources for specific device
	configurations.
	</dd>
	<dt><a href="{@docRoot}google/play/filters.html">Filters on Google Play</a></dt>
	<dd>Information about the different ways that Google Play Store can prevent your app
	from being installed on different devices.</dd>
	</dl>
	</div>
	<div class="col-6">
	<h2 class="norule">You might also be interested in:</h2>
	<dl>
	<dt><a href="{@docRoot}guide/topics/security/permissions.html"
	>System Permissions</a></dt>
	<dd>How Android restricts app access to certain APIs with a permission system that requires
	the user's consent for your app to use those APIs.</dd>
	</dl>
	</div>
	</div>