1 page.title=Android Compatibility 2 excludeFromSuggestions=true 3 @jd:body 4 5 <div id="qv-wrapper"> 6 <div id="qv"> 7 8 <h2>See also</h2> 9 <ol> 10 <li><a 11 href="{@docRoot}google/play/filters.html">Filtering on Google Play</a></li> 12 <li><a 13 href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">Providing Alternative Resources</a></li> 14 <li><a 15 href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li> 16 <li style="margin-top:3px;"><code><a 17 href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a></code></li> 18 <li><code><a 19 href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code></li> 20 <li><code><a 21 href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a></code></li> 22 <li><code><a 23 href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></li> 24 <li><code><a 25 href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></li> 26 <li><code><a 27 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></code></a></li> 28 </ol> 29 30 31 </div> </div> 32 33 <p>Android is designed to run on many different types of devices. For 34 developers, the range and number of devices means a huge potential audience: the 35 more devices that run Android apps, the more users who can access your app. In 36 exchange, however, it also means that your apps will have to cope with that same 37 variety of hardware.</p> 38 39 <p>Fortunately, Android has built-in tools and support that make it easy for 40 your apps to do that, while at the same time letting you maintain control of 41 what types of devices your app is available to. With a bit of forethought and 42 some minor changes in your app's manifest file, you can ensure that users 43 whose devices cant run your app will never see it on Google Play, and 44 will not get in trouble by downloading it. This page explains how you can 45 control which devices have access to your apps, and how to prepare your apps to 46 make sure they reach the right audience.</p> 47 48 49 <h3 id="defined">What does compatibility mean?</h3> 50 51 <p>A device is Android compatible if it can correctly run apps written for the 52 <em>Android execution environment</em>. The exact details of the Android execution 53 environment</em> are defined by the Android Compatibility Definition Document, 54 but the single most important characteristic of a compatible device is the 55 ability to install and correctly run an Android <code>.apk</code> file.</p> 56 57 <p>There is exactly one Android API for each <a 58 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">API level</a>, and its the same 59 API no matter what kind of device its installed on. No parts of the API are 60 optional, and you never have to worry about parts of the API missing on some 61 devices. Every compatible Android device your app will land on will include 62 every class and every API for that API level.</p> 63 64 <p>Of course, some APIs wont work correctly if a particular device lacks the 65 corresponding hardware or feature. But thats not a problem: we also designed 66 Android to prevent apps from being visible to devices which dont have features 67 the apps require. Weve built support for this right into the SDK tools, and 68 its part of the Android platform itself, as well as part of Google Play.</p> 69 70 <p>As a developer, you have complete control of how and where your apps are 71 available. Android provides tools as a first-class part of the platform that let 72 you manage this. You control the availability of your apps, so that they reach 73 only the devices capable of running them.</p> 74 75 <h3 id="how">How does it work?</h3> 76 77 <p>You manage your apps availability through a simple three-step process:</p> 78 79 <ol> 80 <li>You state the features your app requires by declaring <a 81 href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a> 82 elements its manifest file.</li> 83 <li>Devices are required to declare the features they include to Google 84 Play.</li> 85 <li>Google Play uses your apps stated requirements to filter it from devices 86 that dont meet those requirements.</li> 87 </ol> 88 89 <p>This way, users never even see apps that wont work properly on their 90 devices. As long as you accurately describe your apps requirements, you dont 91 need to worry about users blaming you for compatibility problems.</p> 92 93 <p>If youre familiar with web development, you may recognize this model as 94 capability detection. Web developers typically prefer this approach to 95 browser detection, because its very difficult to keep up as new browsers and 96 new versions of current browsers are released. By checking for support for 97 specific required capabilities instead of the current browser, web developers 98 get better fine-grained control. Thats the same approach Android uses: since 99 its impossible to keep up with all the Android devices being released, you 100 instead use the fine-grained controls Android provides.</p> 101 102 <h3>Filtering for technical reasons</h3> 103 104 <div class="sidebox-wrapper"> 105 <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> 106 <div id="qv-sub-rule"> 107 <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> 108 <p style="color:#669999;">Filtering on Google Play</p> 109 110 <p>Google Play filters the applications that are visible to users, so 111 that users can see and download only those applications that are compatible with 112 their devices.</p> 113 114 <p style="margin-top:1em;">One of the ways Google Play filters applications is by 115 feature compatibility. To do this, Google Play checks the 116 <code><uses-feature></code> elements in each application's manifest, to 117 establish the app's feature needs. Google Play then shows or hides the application to 118 each user, based on a comparison with the features available on the user's 119 device. 120 121 <p style="margin-top:1em;">For information about other filters that you can 122 use to control the availability of your apps, see the 123 <a href="{@docRoot}google/play/filters.html">Filters on Google Play</a> 124 document.</p> 125 </div> 126 </div> 127 128 <p>Android includes support for a lot of features, some hardware and some 129 software. Examples include compass and accelerometer sensors, cameras, and Live 130 Wallpapers. However, not every device will support every feature. For instance, 131 some devices dont have the hardware horsepower to display Live Wallpapers 132 well.</p> 133 134 <p>To manage this, Android defines <em>feature IDs</em>. Every capability has a 135 corresponding feature ID defined by the Android platform. For instance, the 136 feature ID for compass is <code>android.hardware.sensor.compass</code>, 137 while the feature 138 ID for Live Wallpapers is <code>android.software.live_wallpapers</code>. Each of these IDs 139 also has a corresponding Java-language constant on the 140 {@link android.content.pm.PackageManager} class that you can use to query whether 141 feature is supported at runtime. As Android adds support for new features in 142 future versions, new feature IDs will be added as well.</p> 143 144 <p>When you write your application, you specify which features your app requires 145 by listing their feature IDs in <code><uses-feature></code> elements in 146 the <code>AndroidManifest.xml</code> file. This is the information that Google 147 Play uses to match your app to devices that can run it. For instance, if you 148 state that your app requires android.software.live_wallpapers, it wont be shown 149 to devices that dont support Live Wallpapers.</p> 150 151 <p>This puts you in total control of your app — because you dont have to 152 declare these features. Consider an example involving cameras.</p> 153 154 <p>If youre building a really impressive next-generation augmented-reality app, 155 your app wont function at all without a camera. However, if youre building a 156 shopping app that only uses the camera for barcode scanning, users without 157 cameras might still find it useful even if they cant scan barcodes. While both 158 apps need to acquire the permission to access the camera, only the first app 159 needs to state that it requires a camera. (The shopping app can simply check at 160 runtime and disable the camera-related features if theres no camera 161 present.)</p> 162 163 <p>Since only you can say what the best approach is for your app, Android 164 provides the tools and lets you make your own tradeoff between maximizing 165 audience size and minimizing development costs.</p> 166 167 168 <h3 id="filtering">Filtering for business reasons</h3> 169 170 <p>Its possible that you may need to restrict your apps availability for 171 business or legal reasons. For instance, an app that displays train schedules 172 for the London Underground is unlikely to be useful to users outside the United 173 Kingdom. Other apps might not be permitted in certain countries for business or 174 legal reasons. For cases such as these, Google Play itself provides 175 developers with filtering options that allow them control their apps 176 availability for non-technical reasons.</p> 177 178 <p>The help information for Google Play provides full details, but in a 179 nutshell, developers can use the Google Play publisher UI to:</p> 180 181 <ul> 182 <li>List the countries an app is available in.</li> 183 <li>Select which carriers users are able to access the app.</li> 184 </ul> 185 186 <p>Filtering for technical compatibility (such as required hardware components) 187 is always based on information contained within your <code>.apk</code> file. But 188 filtering for non-technical reasons (such as geographic restrictions) is always 189 handled in the Google Play user interface.</p> 190 191 <h3 id="futureproofing">Future-proofing</h3> 192 193 <p>Theres one additional quirk that we havent yet addressed: protecting apps 194 from changes made to future versions of Android. If the Android platform 195 introduces a new feature or changes how existing features are handled, what 196 happens to existing apps that were written without any knowledge of the new 197 behavior?</p> 198 199 <p>Simply put, Android commits to not making existing apps available to devices 200 where they wont work properly, even when the platform changes. The best way to 201 explain this is through examples, so here are two:</p> 202 203 <ul> 204 <li>Android 1.0 through 1.5 required a 2 megapixel camera with auto-focus. 205 However, with version 1.6, Android devices were permitted to omit the auto-focus 206 capability, though a (fixed-focus) camera was still required. Some apps such as 207 barcode scanners do not function as well with cameras that do not auto-focus. To 208 prevent users from having a bad experience with those apps, existing apps that 209 obtain permission to use the Camera were assumed by default to require 210 auto-focus. This allowed Google Play to filter those apps from devices that 211 lack auto-focus.</li> 212 213 <li>Android 2.2, meanwhile, allowed the microphone to be optional on some 214 devices, such as set-top boxes. Android 2.2 included a new feature ID for the 215 microphone which allows developers to filter their apps if necessary, but 216 — as with camera — apps that obtain permission to record audio are 217 assumed to require the microphone feature by default. If your app can use a 218 microphone but doesnt strictly need it, you can explicitly state that you dont 219 require it; but unless you do that, your app wont be shown to devices without 220 microphones.</li> 221 </ul> 222 223 <p>In other words, whenever Android introduces new features or changes existing 224 ones, we will always take steps to protect existing applications so that they 225 dont end up being available to devices where they wont work.</p> 226 227 <p>This is implemented, in part, using the <code>aapt</code> tool in the SDK. 228 To see which features your app explicitly requires or is implicitly assumed to 229 require, you can use the command <code>aapt dump badging</code>.</p> 230 231 <h3 id="conclusion">Conclusion</h3> 232 233 <p>The goal of Android is to create a huge installed base for developers to take 234 advantage of. One of the ways we will achieve this is through different kinds of 235 hardware running the same software environment. But we also recognize that only 236 developers know which kinds of devices their apps make sense on. Weve built in 237 tools to the SDK and set up policies and requirements to ensure that developers 238 remain in control of their apps, today and in the future. With the information 239 you just read, and the resources listed in the sidebar of this document, you 240 can publish your app with the confidence that only users who can run it will 241 see it.</p> 242 243 <p>For more information about Android device compatibility, please visit:</p> 244 245 <p style="margin-left:2em;"><a href="http://source.android.com/compatibility/index.html">http://source.android.com/compatibility/index.html</a></p> 246 247 248
