diff options
Diffstat (limited to 'docs/html')
40 files changed, 2530 insertions, 867 deletions
diff --git a/docs/html/guide/appendix/market-filters.jd b/docs/html/guide/appendix/market-filters.jd index ef1deba..dc79d95 100644 --- a/docs/html/guide/appendix/market-filters.jd +++ b/docs/html/guide/appendix/market-filters.jd @@ -13,10 +13,15 @@ manifest file to the configurations defined by the device, as well as other fact <h2>In this document</h2> -<ol> <li><a href="#how-filters-work">How Filters Work in Android Market</a></li> -<li><a href="#manifest-filters">Filtering based on Manifest File Elements</a></li> -<li><a href="#other-filters">Other Filters</a></li> -<li><a href="#advanced-filters">Advanced Manifest Filters</a></li> +<ol> + <li><a href="#how-filters-work">How Filters Work in Android Market</a></li> + <li><a href="#manifest-filters">Filtering based on Manifest Elements</a> + <ol> + <li><a href="#advanced-filters">Advanced manifest filters</a></li> + </ol> + </li> + <li><a href="#other-filters">Other Filters</a></li> + <li><a href="#MultiApks">Publishing Multiple APKs with Different Filters</a></li> </ol> <h2>See also</h2> @@ -39,75 +44,72 @@ href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-per href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></code></a></li> </ol> -<div id="qv-extra"> <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> -<div id="qv-sub-rule"> <img src="{@docRoot}assets/images/icon_market.jpg" -style="float:left;margin:0;padding:0;"> <p style="color:#669999;">Interested in -publishing your app on Android Market?</p> <a id="publish-link" -href="http://market.android.com/publish">Go to Android Market »</a> </div> +<div id="qv-extra"> + <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> + <div id="qv-sub-rule"> + <img src="{@docRoot}assets/images/icon_market.jpg" style="float:left;margin:0;padding:0 5px;"> + <h2 style="color:#669999;">Interested in publishing your app on Android Market?</h2> + <p><a id="publish-link" +href="http://market.android.com/publish">Go to Android Market</a> to create a publisher +account and upload your app.</p></div> </div> </div> </div> -<p>When a user searches or browses in Android Market, the results are filtered based on which -applications are compatible with the user's device. For example, if an application requires a -trackball (as specified in the manifest file), then Android Market will not show -the app on any device that does not have a trackball.</p> +<p>When a user searches or browses in Android Market on an Android device, the results are filtered +based on which applications are compatible with that device. For example, if an application +requires a camera (as specified in the application manifest file), then Android Market will not show +the app on any device that does not have a camera.</p> -<p>The manifest file and the device's hardware and features are only part of how applications are -filtered—filtering might also depend on the country and carrier, the presence or absence of a -SIM card, and other factors. </p> +<p>Declarations in the manifest file that are compared to the device's configuration is not the +only part of how applications are filtered. Filtering might also occur due to the user's country and +carrier, the presence or absence of a SIM card, and other factors. </p> -<p>Changes to the Android Market filters are independent of changes -to the Android platform itself. This document will be updated periodically to reflect -any changes that affect the way Android Market filters applications.</p> +<p>Changes to the Android Market filters are independent of changes to the Android platform itself. +This document is updated periodically to reflect any changes that affect the way Android Market +filters applications.</p> <h2 id="how-filters-work">How Filters Work in Android Market</h2> <p>Android Market uses the filter restrictions described below to determine whether to show your application to a user who is browsing or searching for -applications on an Android-powered device. When determining whether to display your app, -Market checks the device's hardware and software capabilities, as well as it's +applications from the Android Market app. When determining whether to display your app, +Market checks the device's hardware and software configuration, as well as it's carrier, location, and other characteristics. It then compares those against the -restrictions and dependencies expressed by the application itself, in its +restrictions and dependencies expressed by the application's manifest file and publishing details. If the application is compatible with the device according to the filter rules, Market displays the application to the user. Otherwise, Market hides your application from search -results and category browsing. </p> - -<p>You can use the filters described below to control whether Market shows or -hides your application to users. You can use any combination of the -available filters for your app—for example, you can set a -<code>minSdkVersion</code> requirement of <code>"4"</code> and set -<code>smallScreens="false"</code> in the app, then when uploading the app to -Market you could target European countries (carriers) only. Android Market's -filters would prevent the application from being visible on any device that did -not match all three of these requirements. </p> - - <p>A filtered app is not visible within Market, even if a user specifically requests -the app by clicking a deep link that points directly to the app's ID within Market. -All filtering restrictions are associated with an application's version and can -change between versions. For example:</p> - -<ul> -<li>If you publish a new version of your app with stricter restrictions, the app -will not be visible to users for whom it is filtered, even if those users were -able see the previous version.</li> -<li>If a user has installed your application and you publish an upgrade that -makes the app invisible to the user, the user will not see that an upgrade is -available. </li> -</ul> +results and category browsing, even if a user specifically requests +the app by clicking a deep link that points directly to the app's ID within Market..</p> + +<p class="note"><strong>Note:</strong> When users browse the <a +href="http://market.android.com">Android Market web site</a>, they can see all published +applications. The Android Market web site compares the application requirements to each of the +user's registered devices for compatibility, though, and only allows them to install the application +if it's compatible with their device.</p> + +<p>You can use any combination of the available filters for your app. For example, you can set a +<code>minSdkVersion</code> requirement of <code>"4"</code> and set <code>smallScreens="false"</code> +in the app, then when uploading the app to Market you could target European countries (carriers) +only. Android Market's filters will thus prevent the application from being available on any device +that does not match all three of these requirements. </p> +<p>All filtering restrictions are associated with an application's version and can +change between versions. For example, if a user has installed your application and you publish an +update that makes the app invisible to the user, the user will not see that an update is +available.</p> <h2 id="manifest-filters">Filtering based on Manifest Elements</h2> <p>Most Market filters are triggered by elements within an application's manifest file, <a -href="{@docRoot}guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a>, -although not everything in the manifest file can trigger filtering. +href="{@docRoot}guide/topics/manifest/manifest-intro.html">AndroidManifest.xml</a> +(although not everything in the manifest file can trigger filtering). Table 1 lists the manifest elements that you should use to trigger Android Market filtering, and explains how the filtering for each element works.</p> @@ -143,29 +145,22 @@ devices.</p> attributes, which vary by API Level. Specifically: </p> <ul> -<li><p>In API level 3, the <code><supports-screens></code> element itself +<li><p>For applications that set either the <code><a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android: +minSdkVersion</a></code> or <code><a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">android: +targetSdkVersion</a></code> to 3 or lower, the <code><supports-screens></code> element itself is undefined and no attributes are available. In this case, Market assumes that the application is designed for normal-size screens and shows the application to -devices that have normal or large screens. </p> - -<p>This behavior is especially significant for applications that set their -<code><a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">android: -minSdkVersion</a></code> to 3 or lower, since Market will filter them from -small-screen devices by default. Such applications can enable support for -small-screen devices by adding a <code>android:targetSdkVersion="4"</code> -attribute to the <code><uses-sdk></code> element in their manifest -files. For more information, see <a -href="{@docRoot}guide/practices/screens_support.html#strategies">Strategies for -Legacy Applications</a>.</p></li> - -<li>In API Level 4, the defaults for all of the attributes is -<code>"true"</code>. If an application does not declare a -<code><supports-screens></code> element, Market assumes that the -application is designed for all screen sizes and does not filter it from any -devices. If the application does not declare one of the attributes, Market uses -the default value of <code>"true"</code> and does not filter the app for devices -of corresponding screen size.</li> +devices that have normal or larger screens. </p> + +<li>When the either the <code><a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android: +minSdkVersion</a></code> or <code><a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">android: +targetSdkVersion</a></code> is set to 4 or higher, the default for all attributes is +<code>"true"</code>. In this way, the application is considered to support all screen sizes by +default.</li> </ul> <p><strong>Example 1</strong><br /> @@ -192,6 +187,7 @@ of corresponding screen size.</li> Screens</a>.</p> </td> </tr> + <tr> <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></code> <!-- ##api level 3## --></td> @@ -207,6 +203,7 @@ of corresponding screen size.</li> <p>For more details, see <a href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><code><uses-configuration></code></a>.</p></td> </tr> + <tr> <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a> @@ -237,6 +234,7 @@ href="#uses-permission-filtering"><code><uses-permission></code></a>, below.</p> </td> </tr> + <tr> <td valign="top">OpenGL-ES Version<br /> @@ -263,6 +261,7 @@ below.</p> <p>For more details, see <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>.</p></td> </tr> + <tr> <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-library-element.html"><uses-library></a></code></td> <td valign="top">Software Libraries</td> @@ -299,6 +298,7 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions-feat element.</p> </td> </tr> + <tr> <td rowspan="2" valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a></code></td> <td valign="top">Minimum Framework Version (<code>minSdkVersion</code>)</td> @@ -324,11 +324,55 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max"><code>android:m </table> + +<h3 id="advanced-filters">Advanced manifest filters</h3> + +<p>In addition to the manifest elements in <a href="#table1">table 1</a>, Android Market can also +filter applications based on the advanced manifest elements in table 2.</p> + +<p>These manifest elements and the filtering they trigger are for exceptional use-cases +only. These are designed for certain types of high-performance games and similar applications that +require strict controls on application distribution. <strong>Most applications should never use +these filters</strong>.</p> + +<p id="table2" class="table-caption"><strong>Table 2.</strong> Advanced manifest elements for +Android Market filtering.</p> +<table> + <tr><th>Manifest Element</th><th>Summary</th></tr> + <tr> + <td><nobr><a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code +<compatible-screens>}</a></nobr></td> + <td> + <p>Android Market filters the application if the device screen size and density does not match +any of the screen configurations (declared by a {@code <screen>} element) in the {@code +<compatible-screens>} element.</p> + <p class="caution"><strong>Caution:</strong> Normally, <strong>you should not use +this manifest element</strong>. Using this element can dramatically +reduce the potential user base for your application, by excluding all combinations of screen size +and density that you have not listed. You should instead use the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> manifest element (described above in <a href="#table1">table +1</a>) to enable screen compatibility mode for screen configurations you have not accounted for +with alternative resources.</p> + </td> + </tr> + <tr> + <td><nobr><a href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code +<supports-gl-texture>}</a></nobr></td> + <td> + <p>Android Market filters the application unless one or more of the GL texture compression +formats supported by the application are also supported by the device. </p> + </td> + </tr> +</table> + + + <h2 id="other-filters">Other Filters</h2> <p>Android Market uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below. </p> -<p id="table2" class="table-caption"><strong>Table 2.</strong> Application and publishing +<p id="table3" class="table-caption"><strong>Table 3.</strong> Application and publishing characteristics that affect filtering on Market.</p> <table> <tr> <th>Filter Name</th> <th>How It Works</th> </tr> @@ -365,44 +409,46 @@ developer devices or unreleased devices.</p></td> </tr> </table> +<h2 id="MultiApks">Publishing Multiple APKs with Different Filters</h2> -<h2 id="advanced-filters">Advanced Manifest Filters</h2> +<p>Some specific Android Market filters allow you to publish multiple APKs for the same +application in order to provide a different APK to different device configurations. For example, if +you're creating a video game that uses high-fidelity graphic assets, you might want to create +two APKs that each support different texture compression formats. This way, you can reduce the +size of the APK file by including only the textures that are required for each device +configuration. Depending on each device's support for your texture compression formats, Android +Market will deliver it the APK that you've declared to support that device.</p> -<p>In addition to the manifest elements in <a href="#table1">table 1</a>, Android Market can also -filter applications based on the advanced manifest elements in table 3.</p> +<p>Currently, Android Market allows you to publish multiple APKs for the same application only +when each APK provides different filters based on the following configurations:</p> +<ul> + <li>OpenGL texture compression formats + <p>By using the <a +href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code +<supports-gl-texture>}</a> element.</p> + </li> + <li>Screen size (and, optionally, screen density) + <p>By using the <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> or <a +href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code +<compatible-screens>}</a> element.</p> + </li> + <li>API level + <p>By using the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code +<uses-sdk>}</a> element.</p> + </li> +</ul> -<p>These manifest elements and the filtering they trigger are for exceptional use-cases -only. They are designed for some types of high-performance games and similar applications that -require strict controls on application distribution. <strong>Most applications should never use -these filters</strong>.</p> +<p>All other filters still work the same as usual, but these three are the only filters that can +distinguish one APK from another within the same application listing on Android Market. For example, +you <em>cannot</em> publish multiple APKs for the same application if the APKs differ only based on +whether the device has a camera.</p> -<p id="table3" class="table-caption"><strong>Table 3.</strong> Advanced manifest elements for -Android Market filtering.</p> -<table> - <tr><th>Manifest Element</th><th>Summary</th></tr> - <tr> - <td><nobr><a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code -<compatible-screens>}</a></nobr></td> - <td> - <p>Android Market filters the application if the device screen size and density does not match -any of the screen configurations (declared by a {@code <screen>} element) in the {@code -<compatible-screens>} element.</p> - <p class="caution"><strong>Caution:</strong> Normally, <strong>you should not use -this manifest element</strong>. Using this element can dramatically -reduce the potential user base for your application, by excluding all combinations of screen size -and density that you have not listed. You should instead use the <a -href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code -<supports-screens>}</a> manifest element (described above in <a href="#table1">table -1</a>) to enable screen compatibility mode for screen configurations you have not accounted for -with alternative resources.</p> - </td> - </tr> - <tr> - <td><nobr><a href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code -<supports-gl-texture>}</a></nobr></td> - <td> - <p>Android Market filters the application unless one or more of the GL texture compression formats supported by the application are also supported by the device. </p> - </td> - </tr> -</table> +<p class="caution"><strong>Caution:</strong> Publishing multiple APKs for the same application is +considered an advanced feature and <strong>most application should publish only one +APK that supports a wide range of device configurations</strong>. Publishing multiple APKs +requires that you follow specific rules within your filters and that you pay extra attention to the +version codes for each APK to ensure proper update paths for each configuration.</p> +<p>If you need more information about how to publish multiple APKs on Android Market, read <a +href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> diff --git a/docs/html/guide/developing/debugging/index.jd b/docs/html/guide/developing/debugging/index.jd index 1f1a4ca..0ad1a08 100644 --- a/docs/html/guide/developing/debugging/index.jd +++ b/docs/html/guide/developing/debugging/index.jd @@ -1,4 +1,4 @@ -page.title=Debugging +page.title=Debugging @jd:body @@ -10,7 +10,7 @@ page.title=Debugging <li><a href="#stack">Debugging Environment</a></li> <li><a href="#addltools">Additional Debugging Tools</a></li> - + <li><a href="#tips">Debugging Tips</a></li> </ol> </div> @@ -50,7 +50,7 @@ page.title=Debugging <dd>The Dalvik VM (Virtual Machine) supports the JDWP protocol to allow debuggers to attach to a VM. Each application runs in a VM and exposes a unique port that you can attach a debugger to - via DDMS. If you want to debug multiple applications, attaching to each port might become + via DDMS. If you want to debug multiple applications, attaching to each port might become tedious, so DDMS provides a port forwarding feature that can forward a specific VM's debugging port to port 8700. You can switch freely from application to application by highlighting it in the Devices tab of DDMS. DDMS forwards the appropriate port to port 8700. Most modern Java IDEs include a JDWP debugger, @@ -109,11 +109,11 @@ page.title=Debugging that provide useful information such as CPU usage and frame rate. You can also transfer the application to a hardware device.</dd> </dl> - - - <h2 id="tips">Debugging Tips</h2> - -<p>While debugging, keep these helpful tips in mind to help you figure out common problems with your + + + <h2 id="tips">Debugging Tips</h2> + +<p>While debugging, keep these helpful tips in mind to help you figure out common problems with your applications:</p> <dl> @@ -131,14 +131,14 @@ Debugging with the Dev Tools App</a>. </dd> <dt><strong>Get application and system state information from the emulator</strong></dt> -<dd>You can access dumpstate information from the <code>adb shell</code> commands. See +<dd>You can access dumpstate information from the <code>adb shell</code> commands. See <a href="{@docRoot}guide/developing/tools/adb.html#dumpsys">dumpsys and dumpstate</a> on the adb topic page.</dd> <dt><strong>Get wireless connectivity information</strong></dt> -<dd>You can get information about wireless connectivity using DDMS. +<dd>You can get information about wireless connectivity using DDMS. From the <strong>Device</strong> menu, select <strong>Dump radio state</strong>.</dd> @@ -165,6 +165,16 @@ logcat -b radio <dt><strong>Use debugging helper classes</strong></dt> <dd>Android provides debug helper classes such as {@link android.util.Log util.Log} and {@link android.os.Debug} for your convenience. </dd> + +<dt><strong>Garbage collection</strong></dt> +<dd> +The debugger and garbage collector are currently loosely integrated. The VM guarantees that any +object the debugger is aware of is not garbage collected until after the debugger disconnects. +This can result in a buildup of objects over time while the debugger is connected. For example, +if the debugger sees a running thread, the associated {@link java.lang.Thread} object is not +garbage collected even after the thread terminates. +</dd> + </dl> <p>See the <a href="{@docRoot}resources/faq/troubleshooting.html">Troubleshooting</a> document @@ -176,10 +186,3 @@ for answers to some common developing and debugging issues.</p> - - - - - - - diff --git a/docs/html/guide/developing/device.jd b/docs/html/guide/developing/device.jd index cb5a0b6..bde170e 100644 --- a/docs/html/guide/developing/device.jd +++ b/docs/html/guide/developing/device.jd @@ -142,6 +142,9 @@ USB device support on Linux. The USB Vendor ID is the value given to the <td>Huawei</td> <td><code>12d1</code></td></tr> <tr> + <td>K-Touch</td> + <td><code>24e3</code></td></tr> + <tr> <td>Kyocera</td> <td><code>0482</code></td></tr> <tr> diff --git a/docs/html/guide/developing/index.jd b/docs/html/guide/developing/index.jd index 3d7e353..722c75a 100644 --- a/docs/html/guide/developing/index.jd +++ b/docs/html/guide/developing/index.jd @@ -98,20 +98,22 @@ information. <dt>Jarsigner (or similar signing tool)</dt> - <dd>To sign your .apk file with a private key generated by keytool. Jarsigner is part of the + <dd>To sign your .apk file with a private key generated by Keytool. Jarsigner is part of the JDK.</dd> </dl> - <p>If you are using Eclipse and ADT, tools such as <code>adb</code> and the <code>android</code> - are called by Eclipse and ADT under the hood or similar functionality is provided within Eclipse. - You need to be familiar with <code>adb</code>, however, because certain functions are not accessible from - Eclipse, such as the <code>adb</code> shell commands. You might also need to call Keytool and Jarsigner to + <p>If you are using Eclipse and ADT, tools such as <code>adb</code> and <code>android</code> + are automatically called by Eclipse and ADT so you don't have to manually invoke these tools. + You need to be familiar with <code>adb</code>, however, because certain functions are not +accessible from + Eclipse, such as the <code>adb</code> shell commands. You might also need to call Keytool and +Jarsigner to sign your applications, but you can set up Eclipse to do this automatically as well.</p> <p>For more information on the tools provided with the Android SDK, see the <a href="{@docRoot}guide/developing/tools/index.html">Tools</a> section of the documentation.</p> -<h2 id="ThirdParty">Third-Party Development Tools</h2> +<h2 id="ThirdParty">Other Third-Party Development Tools</h2> <p> The tools described in this section are not developed by the Android SDK team. The Android Dev Guide does not provide documentation for these tools. Please refer to the linked documents in each diff --git a/docs/html/guide/developing/tools/etc1tool.jd b/docs/html/guide/developing/tools/etc1tool.jd new file mode 100644 index 0000000..a7f76f5 --- /dev/null +++ b/docs/html/guide/developing/tools/etc1tool.jd @@ -0,0 +1,68 @@ +page.title=etc1tool +parent.title=Tools +parent.link=index.html +@jd:body + + + <p><code>etc1tool</code> is a command line utility that lets you encode PNG + images to the ETC1 compression standard and decode ETC1 compressed images back to PNG.</p> + + <p>The usage for <code>etc1tool</code> is:</p> +<pre>etc1tool infile [--help | --encode | --encodeNoHeader | --decode] [--showDifference +diff-file] [-o outfile]</pre> + + <table> + <tr> + <th>Option</th> + + <th>Description</th> + </tr> + + <tr> + <td><code>infile</code></td> + + <td>The input file to compress</td> + </tr> + + <tr> + <td><code>--help</code></td> + + <td>Print usage information</td> + </tr> + + <tr> + <td><code>--encode</code></td> + + <td>Create an ETC1 file from a PNG file. + This is the default mode for the tool if nothing is specified.</td> + </tr> + + <tr> + <td><code>--encodeNoHeader</code></td> + + <td>Create a raw ETC1 data file (without a header) from a PNG file.</td> + </tr> + + <tr> + <td><code>--decode</code></td> + + <td>Create a PNG file from an ETC1 file</td> + </tr> + + <tr> + <td><code>--showDifference <em>diff-file</em></code></td> + + <td>Write the difference between the original and encoded image to + <code><em>diff-file</em></code> (only valid when encoding).</td> + </tr> + + <tr> + <td><code>-o <em>outfile</em></code></td> + + <td>Specify the name of the output file. + If <code><em>outfile</em></code> is not specified, the output file is constructed + from the input filename with the appropriate suffix (<code>.pkm</code> or <code>.png</code>). + </td> + </tr> + + </table>
\ No newline at end of file diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index f7dbe30..a647cd3 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -148,7 +148,7 @@ </a></li> </ul> </li><!-- end of User Interface --> - + <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/topics/resources/index.html"> <span class="en">Application Resources</span> @@ -221,7 +221,7 @@ <li><a href="<?cs var:toroot ?>guide/topics/manifest/provider-element.html"><provider></a></li> <li><a href="<?cs var:toroot ?>guide/topics/manifest/receiver-element.html"><receiver></a></li> <li><a href="<?cs var:toroot ?>guide/topics/manifest/service-element.html"><service></a></li> - <li><a href="<?cs var:toroot ?>guide/topics/manifest/supports-gl-texture-element.html"><supports-gl-texture></a></li> + <li><a href="<?cs var:toroot ?>guide/topics/manifest/supports-gl-texture-element.html"><supports-gl-texture></a></li> <li><a href="<?cs var:toroot ?>guide/topics/manifest/supports-screens-element.html"><supports-screens></a> <span class="new">updated</span></li> <!-- ##api level 4## --> <li><a href="<?cs var:toroot ?>guide/topics/manifest/uses-configuration-element.html"><uses-configuration></a></li> @@ -231,8 +231,8 @@ <li><a href="<?cs var:toroot ?>guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a></li> </ul> </li><!-- end of the manifest file --> - </ul> - + </ul> + <ul> <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/topics/graphics/index.html"> @@ -265,7 +265,7 @@ <li><a href="<?cs var:toroot ?>guide/topics/renderscript/compute.html"> <span class="en">Compute</span> </a> - </li> + </li> </ul> </li> @@ -383,9 +383,6 @@ <span class="en">In-app Billing</span></a> </div> <ul> - <li><a href="<?cs var:toroot?>guide/market/billing/billing_about.html"> - <span class="en">About this Release</span></a> - </li> <li><a href="<?cs var:toroot?>guide/market/billing/billing_overview.html"> <span class="en">In-app Billing Overview</span></a> </li> @@ -409,6 +406,10 @@ <li><a href="<?cs var:toroot ?>guide/appendix/market-filters.html"> <span class="en">Market Filters</span></a> </li> + <li><a href="<?cs var:toroot ?>guide/market/publishing/multiple-apks.html"> + <span class="en">Multiple APK Support</span></a> + <span class="new">new!</span> + </li> </ul> </li> @@ -571,8 +572,10 @@ <li><a href="<?cs var:toroot ?>guide/developing/tools/android.html">android</a></li> <li><a href="<?cs var:toroot ?>guide/developing/tools/bmgr.html">bmgr</a> <li><a href="<?cs var:toroot ?>guide/developing/tools/dmtracedump.html">dmtracedump</a></li> - <li><a href="<?cs var:toroot ?>guide/developing/tools/draw9patch.html" >Draw 9-Patch</a></li> + <li><a href="<?cs var:toroot?>guide/developing/tools/draw9patch.html">Draw + 9-Patch</a></li> <li><a href="<?cs var:toroot ?>guide/developing/tools/emulator.html">Emulator</a></li> + <li><a href="<?cs var:toroot ?>guide/developing/tools/etc1tool.html">etc1tool</a></li> <li><a href="<?cs var:toroot ?>guide/developing/tools/hierarchy-viewer.html">Hierarchy Viewer</a></li> <li><a href="<?cs var:toroot ?>guide/developing/tools/hprof-conv.html">hprof-conv</a></li> <li><a href="<?cs var:toroot ?>guide/developing/tools/layoutopt.html">layoutopt</a></li> @@ -668,11 +671,14 @@ <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/practices/screens_support.html"> <span class="en">Supporting Multiple Screens</span> - </a></div> + </a> <span class="new">updated</span></div> <ul> <li><a href="<?cs var:toroot ?>guide/practices/screens-distribution.html"> <span class="en">Distributing to Specific Screens</span> </a></li> + <li><a href="<?cs var:toroot ?>guide/practices/screen-compat-mode.html"> + <span class="en">Screen Compatibility Mode</span> + </a> <span class="new">new!</span></li> <li><a href="<?cs var:toroot ?>guide/practices/screens-support-1.5.html"> <span class="en">Strategies for Android 1.5</span> </a></li> @@ -727,9 +733,16 @@ <li><a href="<?cs var:toroot ?>guide/practices/design/accessibility.html"> <span class="en">Designing for Accessibility</span> </a></li> - <li><a href="<?cs var:toroot ?>guide/practices/design/performance.html"> + <li class="toggle-list"> + <div><a href="<?cs var:toroot ?>guide/practices/design/performance.html"> <span class="en">Designing for Performance</span> - </a></li> + </a> <span class="new-child">new!</span></div> + <ul> + <li><a href="<?cs var:toroot ?>guide/practices/design/jni.html"> + <span class="en">JNI Tips</span> + </a> <span class="new">new!</span></li> + </ul> + </li> <li><a href="<?cs var:toroot ?>guide/practices/design/responsiveness.html"> <span class="en">Designing for Responsiveness</span> </a></li> diff --git a/docs/html/guide/market/billing/billing_about.html b/docs/html/guide/market/billing/billing_about.html new file mode 100644 index 0000000..d8395df --- /dev/null +++ b/docs/html/guide/market/billing/billing_about.html @@ -0,0 +1,12 @@ +<html> +<head> +<meta http-equiv="refresh" +content="0;url=http://developer.android.com/guide/market/billing/index.html"> +<title>Redirecting...</title> +</head> +<body> +<p>You should be redirected. Please <a +href="http://developer.android.com/guide/market/billing/index.html">click +here</a>.</p> +</body> +</html>
\ No newline at end of file diff --git a/docs/html/guide/market/billing/billing_about.jd b/docs/html/guide/market/billing/billing_about.jd deleted file mode 100755 index 5924170..0000000 --- a/docs/html/guide/market/billing/billing_about.jd +++ /dev/null @@ -1,30 +0,0 @@ -page.title=About this Release -parent.title=In-app Billing -parent.link=index.html -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - <h2>In this document</h2> - <ol> - <li><a href="#billing-about">About this Release</a></li> - </ol> - <h2>Downloads</h2> - <ol> - <li><a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">Sample Application</a></li> - </ol> - <h2>See also</h2> - <ol> - <li><a href="{@docRoot}guide/market/billing/billing_overview.html">Overview of In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_integrate.html">Implementing In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and Design</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_testing.html">Testing In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_admin.html">Administering In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_reference.html">In-app Billing Reference</a></li> - </ol> -</div> -</div> - -<p>Android Market In-app Billing has reached the final launch milestone and is now available to developers and users. You can now publish applications that use Android Market's in-app billing service, and users can make in-app purchases. To find out how to implement in-app billing in your applications, see the <a href="{@docRoot}guide/market/billing/index.html">documentation</a> and the <a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample application</a>.</p> - - diff --git a/docs/html/guide/market/billing/billing_admin.jd b/docs/html/guide/market/billing/billing_admin.jd index 939bbaa..cbb4b29 100755 --- a/docs/html/guide/market/billing/billing_admin.jd +++ b/docs/html/guide/market/billing/billing_admin.jd @@ -202,6 +202,11 @@ IN_APP_NOTIFY messages</a> and <a href="http://www.google.com/support/androidmarket/bin/answer.py?answer=1153485">In-app Billing Pricing</a>.</p> +<p class="caution"><strong>Important:</strong> You cannot use the Google Checkout API to issue +refunds or cancel in-app billing transactions. You must do this manually through your Google +Checkout merchant account. However, you can use the Google Checkout API to retrieve order +information.</p> + <h2 id="billing-testing-setup">Setting Up Test Accounts</h2> <p>The Android Market publisher site lets you set up one or more test accounts. A test account is a diff --git a/docs/html/guide/market/billing/billing_integrate.jd b/docs/html/guide/market/billing/billing_integrate.jd index 1a1f02a..3eebd59 100755 --- a/docs/html/guide/market/billing/billing_integrate.jd +++ b/docs/html/guide/market/billing/billing_integrate.jd @@ -783,11 +783,17 @@ request identifier for the request.</p> <code>RESPONSE_CODE</code> broadcast intent. This broadcast intent provides status and error information about the request.</p> -<p class="note"><strong>Note:</strong> As a best practice, you should not send a -<code>CONFIRM_NOTIFICATIONS</code> request for a purchased item until you have delivered the item to -the user. This way, if your application crashes or something else prevents your application from -delivering the product, your application will still receive an <code>IN_APP_NOTIFY</code> broadcast -intent from Android Market indicating that you need to deliver the product.</p> +<p>You must send a confirmation when you receive transaction information from Android Market. If you +don't send a confirmation message, Android Market will continue sending +<code>IN_APP_NOTIFY</code> messages for the transactions you have not confirmed. Also, +your application must be able to handle <code>IN_APP_NOTIFY</code> messages that contain multiple +orders.</p> + +<p>In addition, as a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request +for a purchased item until you have delivered the item to the user. This way, if your application +crashes or something else prevents your application from delivering the product, your application +will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Android Market indicating +that you need to deliver the product.</p> <h4>Restoring transaction information (RESTORE_TRANSACTIONS)</h4> @@ -828,6 +834,10 @@ message contains the detailed transaction information. The transaction informati signed JSON string (unencrypted). The message includes the signature so you can verify the integrity of the signed string.</p> +<p class="note"><strong>Note:</strong> You should use the <code>RESTORE_TRANSACTIONS</code> +request type only when your application is installed for the first time on a device or when your +application has been removed from a device and reinstalled.</p> + <h3>Other service tasks</h3> <p>You may also want your {@link android.app.Service} to receive intent messages from your {@link @@ -1061,7 +1071,12 @@ practices, see <a href="{@docRoot}guide/market/billing/billing_best_practices.ht Design</a>.</p> <p class="note"><strong>Note</strong>: If you store any purchase information on a device, be sure to -encrypt the data and use a device-specific encryption key.</p> +encrypt the data and use a device-specific encryption key. Also, if the purchase type for any of +your items is "unmanaged," we recommend that you back up the purchase information for these items to +a remote server or use Android's <a href="{@docRoot}guide/topics/data/backup.html">data +backup</a> framework to back up the purchase information. Backing up purchase information for +unmanaged items is important because unmanaged items cannot be restored by using the +<code>RESTORE_TRANSACTIONS</code> request type.</p> <h3>Creating a user interface for selecting items</h3> diff --git a/docs/html/guide/market/billing/billing_overview.jd b/docs/html/guide/market/billing/billing_overview.jd index a42b772..8f9fd4c 100755 --- a/docs/html/guide/market/billing/billing_overview.jd +++ b/docs/html/guide/market/billing/billing_overview.jd @@ -257,7 +257,10 @@ broadcast intents that are sent for every request.</p> <code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and <code>REQUEST_ID</code>. The <code>PURCHASE_INTENT</code> key provides a {@link android.app.PendingIntent}, which your application uses to start the checkout UI for the given product ID.</li> - <li>Your application launches the pending intent, which launches the checkout UI.</li> + <li>Your application launches the pending intent, which launches the checkout UI. + <p class="note"><strong>Note:</strong> You must launch the pending intent from an activity + context and not an application context.</p> + </li> <li>When the checkout flow finishes (that is, the user successfully purchases the item or cancels the purchase), Android Market sends your application a notification message (an <code>IN_APP_NOTIFY</code> broadcast intent). The notification message includes a notification ID, @@ -276,14 +279,21 @@ broadcast intents that are sent for every request.</p> <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key.</li> </ol> -<p class="note"><strong>Note:</strong> You must launch the pending intent from an activity context -and not an application context.</p> - <img src="{@docRoot}images/billing_request_purchase.png" height="231" id="figure2" /> <p class="img-caption"> <strong>Figure 2.</strong> Message sequence for a purchase request. </p> +<p>Keep in mind, you must send a confirmation when you receive transaction information from Android +Market (step 8 in figure 2). If you don't send a confirmation message, Android Market will +continue sending <code>IN_APP_NOTIFY</code> messages for the transactions you have not +confirmed. As a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request for +a purchased item until you have delivered the item to the user. This way, if your application +crashes or something else prevents your application from delivering the product, your application +will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Android Market indicating +that you need to deliver the product. Also, as a best practice, your application must be able to +handle <code>IN_APP_NOTIFY</code> messages that contain multiple orders.</p> + <p>The messaging sequence for a restore transaction request is shown in figure 3. Request types for each <code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents are shown in <em>italic</em>. For clarity, figure 3 does not show the <code>RESPONSE_CODE</code> @@ -308,6 +318,10 @@ pertains to.</p> information that is sent during a purchase request, although you do not need to respond to this intent with a <code>CONFIRM_NOTIFICATIONS</code> message.</p> +<p class="note"><strong>Note:</strong> You should use the <code>RESTORE_TRANSACTIONS</code> request +type only when your application is installed for the first time on a device or when your +application has been removed from a device and reinstalled.</p> + <p>The messaging sequence for checking whether in-app billing is supported is shown in figure 4. The request type for the <code>sendBillingRequest()</code> method is shown in <strong>bold</strong>.</p> @@ -335,21 +349,32 @@ purchase has changed. To retrieve the details of that purchase, your application <code>GET_PURCHASE_INFORMATION</code> request. Android Market responds with a <code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the details of the purchase state change. Your application then sends a <code>CONFIRM_NOTIFICATIONS</code> message, informing -Android Market that you've received the purchase state change information.</p> - -<p>When Android Market receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given message, it -usually stops sending <code>IN_APP_NOTIFY</code> intents for that message. However, there are some -cases where Android Market may send repeated <code>IN_APP_NOTIFY</code> intents for a message even -though your application has sent a <code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a -device loses network connectivity while you are sending the <code>CONFIRM_NOTIFICATIONS</code> -message. In this case, Android Market might not receive your <code>CONFIRM_NOTIFICATIONS</code> -message and it could send multiple <code>IN_APP_NOTIFY</code> messages until it receives -acknowledgement that you received the message. Therefore, your application must be able to recognize -that the subsequent <code>IN_APP_NOTIFY</code> messages are for a previously processed transaction. -You can do this by checking the <code>orderID</code> that's contained in the JSON string because -every transaction has a unique <code>orderId</code>.</p> - -<p>There are two cases where your application may also receive <code>IN_APP_NOTIFY</code> broadcast +Android Market that you have received the purchase state change information.</p> + +<p>In some special cases, you may receive multiple <code>IN_APP_NOTIFY</code> messages even though +you have confirmed receipt of the purchase information, or you may receive +<code>IN_APP_NOTIFY</code> messages for a purchase change even though you never initiated the +purchase. Your application must handle both of these special cases.</p> + +<h4>Handling multiple IN_APP_NOTIFY messages</h4> + +<p>When Android Market receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given +<code>PURCHASE_STATE_CHANGED</code> message, it usually stops sending <code>IN_APP_NOTIFY</code> +intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Android +Market may send repeated <code>IN_APP_NOTIFY</code> intents for a +<code>PURCHASE_STATE_CHANGED</code> message even though your application has sent a +<code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a device loses network connectivity +while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Android Market +might not receive your <code>CONFIRM_NOTIFICATIONS</code> message and it could send multiple +<code>IN_APP_NOTIFY</code> messages until it receives acknowledgement that you received the +transaction message. Therefore, your application must be able to recognize that the subsequent +<code>IN_APP_NOTIFY</code> messages are for a previously processed transaction. You can do this by +checking the <code>orderID</code> that's contained in the JSON string because every transaction has +a unique <code>orderId</code>.</p> + +<h4>Handling refunds and other unsolicited IN_APP_NOTIFY messages</h4> + +<p>There are two cases where your application may receive <code>IN_APP_NOTIFY</code> broadcast intents even though your application has not sent a <code>REQUEST_PURCHASE</code> message. Figure 5 shows the messaging sequence for both of these cases. Request types for each <code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents are @@ -359,11 +384,11 @@ broadcast intents that are sent for every request.</p> <div class="figure" style="width:481px"> <img src="{@docRoot}images/billing_refund.png" alt="" height="189" /> <p class="img-caption"> - <strong>Figure 5.</strong> Message sequence for refunds and other unsolicited IN_APP_NOTIFY messages. -</p> + <strong>Figure 5.</strong> Message sequence for refunds and other unsolicited +IN_APP_NOTIFY messages.</p> </div> -<p>In the first case, your application can receive an <code>IN_APP_NOTIFY</code> broadcast intent +<p>In the first case, your application may receive an <code>IN_APP_NOTIFY</code> broadcast intent when a user has your application installed on two (or more) devices and the user makes an in-app purchase from one of the devices. In this case, Android Market sends an <code>IN_APP_NOTIFY</code> message to the second device, informing the application that there is a purchase state change. Your @@ -384,6 +409,11 @@ refunded. The refund information is included in the JSON string that accompanies <code>PURCHASE_STATE_CHANGED</code> broadcast intent. Also, the <code>purchaseState</code> field in the JSON string is set to 2.</p> +<p class="caution"><strong>Important:</strong> You cannot use the Google Checkout API to +issue refunds or cancel in-app billing transactions. You must do this manually through your +Google Checkout merchant account. However, you can use the Google Checkout API to retrieve order +information.</p> + <h2 id="billing-security">Security Controls</h2> <p>To help ensure the integrity of the transaction information that is sent to your application, diff --git a/docs/html/guide/market/billing/billing_testing.jd b/docs/html/guide/market/billing/billing_testing.jd index 84d25b2..5453047 100755 --- a/docs/html/guide/market/billing/billing_testing.jd +++ b/docs/html/guide/market/billing/billing_testing.jd @@ -211,7 +211,8 @@ experience, including the actual responses from Android Market and the actual ch users will experience in your application.</p> <p class="note"><strong>Note</strong>: You do not need to publish your application to do end-to-end -testing. You only need to upload your draft application to perform end-to-end testing.</p> +testing. You only need to upload your application as a draft application to perform end-to-end +testing.</p> <p>To test your in-app billing implementation with actual in-app purchases, you will need to register at least one test account on the Android Market publisher site. You cannot use your @@ -233,8 +234,11 @@ actual payouts to your merchant account.</p> <ol> <li><strong>Upload your application as a draft application to the publisher site.</strong> <p>You do not need to publish your application to perform end-to-end testing with real product - IDs. To learn how to upload an application to Android Market, see <a - href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading + IDs; you only need to upload your application as a draft application. However, you must sign + your application with your release key before you upload it as a draft application. Also, the + version number of the uploaded application must match the version number of the application you + load to your device for testing. To learn how to upload an application to Android Market, see + <a href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading applications</a>.</p> </li> <li><strong>Add items to the application's product list.</strong> diff --git a/docs/html/guide/market/publishing/multiple-apks.jd b/docs/html/guide/market/publishing/multiple-apks.jd new file mode 100644 index 0000000..ff70e85 --- /dev/null +++ b/docs/html/guide/market/publishing/multiple-apks.jd @@ -0,0 +1,643 @@ +page.title=Multiple APK Support + +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>Quickview</h2> + <ul> + <li>Simultaneously publish different APKs for different +device configurations</li> + <li>Different APKs are distributed to different devices based on filters declared in the +manifest file</li> + <li>You should publish multiple APKs only when it's not possible or reasonable to +support all desired devices with a single APK</li> + </ul> + + <h2>In this document</h2> +<ol> + <li><a href="#Concepts">Publishing Concepts</a> + <ol> + <li><a href="#Active">Active APKs</a></li> + <li><a href="#SimpleAndAdvanced">Simple mode and advanced mode</a></li> + </ol> + </li> + <li><a href="#HowItWorks">How Multiple APKs Work</a> + <ol> + <li><a href="#SupportedFilters">Supported filters</a></li> + <li><a href="#Rules">Rules for multiple APKs</a></li> + </ol> + </li> + <li><a href="#CreatingApks">Creating Multiple APKs</a> + <ol> + <li><a href="#VersionCodes">Assigning version codes</a></li> + </ol> + </li> + <li><a href="#SingleAPK">Using a Single APK Instead</a> + <ol> + <li><a href="#TextureOptions">Supporting multiple GL textures</a></li> + <li><a href="#ScreenOptions">Supporting multiple screens</a></li> + <li><a href="#ApiLevelOptions">Supporting multiple API levels</a></li> + </ol> + </li> +</ol> + + <h2>See also</h2> +<ol> + <li><a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a></li> + <li><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li> + <li><a href="{@docRoot}sdk/compatibility-library.html">Compatibility +Package</a></li> + <li><a href="{@docRoot}guide/appendix/api-levels.html">Android API Levels</a></li> +</ol> + +</div> +</div> + +<p>Multiple APK support is a feature in Android Market that allows you to publish different APKs +for your application that are each targeted to different device configurations. Each APK is a +complete and independent version of your application, but they share the same application listing on +Android Market and must share the same package name and be signed with the same release key. This +feature is useful for cases in which your application cannot reach all desired devices with a single +APK.</p> + +<p>Android-powered devices may differ in several ways and it's important +to the success of your application that you make it available to as many devices as possible. +Android applications usually run on most compatible devices with a single APK, by supplying +alternative resources for different configurations (for example, different layouts for different +screen sizes) and the Android system selects the appropriate resources for the device at runtime. In +a few cases, however, a single APK is unable to support all device configurations, because +alternative resources make the APK file too big (greater than 50MB) or other technical challenges +prevent a single APK from working on all devices.</p> + +<p>Although <strong>we encourage you to develop and publish a single APK</strong> that supports as +many device configurations as possible, doing so is sometimes not possible. To help +you publish your application for as many devices as possible, Android Market allows you to +publish multiple APKs under the same application listing. Android Market then supplies each APK to +the appropriate devices based on configuration support you've declared in the manifest file of each +APK.</p> + +<p>By publishing your application with multiple APKs, you can:</p> + +<ul> + <li>Support different OpenGL texture compression formats with each APK.</li> + <li>Support different screen configurations with each APK.</li> + <li>Support different platform versions with each APK.</li> +</ul> + +<p>Currently, these are the only device characteristics that Android Market supports for publishing +multiple APKs as the same application.</p> + +<p class="note"><strong>Note:</strong> You should generally use multiple APKs to support +different device configurations <strong>only when your APK is too large</strong> (greater than +50MB). Using a single APK to support different configurations is always the best practice, +because it makes the path for application updates simple and clear for users (and also makes +your life simpler by avoiding development and publishing complexity). Read the section below about +<a href="#SingleAPK">Using a Single APK Instead</a> to +consider your options before publishing multiple APKs.</p> + + +<h2 id="Concepts">Publishing Concepts</h2> + +<p>Before you start publishing multiple APKs on Android Market, you must understand a few +concepts regarding how the Android Market publisher site works.</p> + +<h3 id="Active">Active APKs</h3> + +<div class="sidebox-wrapper"> +<div class="sidebox"> + <h4>The difference between "Publish" and "Save"</h4> + <p>When editing your application, there are two buttons on the top-right side of the page. The +first button is either <strong>Publish</strong> or <strong>Unpublish</strong> and the second +button is always <strong>Save</strong> (but its behavior changes).</p> + <p>When your application is new or you have unpublished it from Market, the first +button says <strong>Publish</strong>. Clicking it will publish any APKs listed as +Active, making them available on Android Market. Also while your application is new +or unpublished, clicking <strong>Save</strong> will save any changes you've made, such +as information added to the Product details and APKs you've uploaded, but nothing is made visible on +Android Market—this allows you to save your changes and sign out of the publisher site before +deciding to publish.</p> + <p>Once you've published your application, the first button changes to +<strong>Unpublish</strong>. Clicking it in this state unpublishes your application so that none +of the APKs are available on Android Market. Also while published, the behavior of the +<strong>Save</strong> button is different. In this state, clicking <strong>Save</strong> not +only saves all your changes, but also publishes them to Android Market. For example, if you've +already published your application and then make changes to your product details or activate new +APKs, clicking <strong>Save</strong> makes all those changes live on Android Market.</p> +</div> +</div> + + +<p>Before you can publish your application (whether publishing one or multiple APKs), you +must "activate" your APK(s) from the <strong>APK files</strong> tab. When you activate an APK, it +moves into the list of <em>Active</em> APKs. This list allows you to preview which APK(s) +you're about to publish.</p> + +<p>If there are no errors, any "active" APK will be published to +Android Market when you click the <strong>Publish</strong> button (if the application is +unpublished) or when you click the <strong>Save</strong> button (if the application is +already published).</p> + + +<h3 id="SimpleAndAdvanced">Simple mode and advanced mode</h3> + +<p>The Android Market publisher site provides two modes for managing the APKs associated with +your application: <em>simple mode</em> and <em>advanced mode</em>. You can switch between these by +clicking the +link at the top-right corner of the <strong>APK files</strong> tab.</p> + +<p>Simple mode is the traditional way to publish an application, using one APK at a time. In +simple mode, only one APK can be activated at a time. If you upload a new APK to update +the application, clicking "Activate" on the new APK deactivates the currently +active APK (you must then click <strong>Save</strong> to publish the new APK).</p> + +<p>Advanced mode allows you to activate and publish multiple APKs that are each designed for a +specific set of device configurations. However, there are several rules based on the manifest +declarations in each APK that determine whether you're allowed to activate each APK along with +others. When you activate an APK and it violates one of the rules, you will receive an error or +warning message. If it's an error, you cannot publish until you resolve the problem; if it's a +warning, you can publish the activated APKs, but there might be unintended consequences as to +whether your application is available for different devices. These rules are discussed more +below.</p> + + +<h2 id="HowItWorks">How Multiple APKs Work</h2> + +<p>The concept for using multiple APKs on Android Market is that you have just one entry in +Android Market for your application, but different devices might download a different APK. This +means that:</p> + +<ul> + <li>You maintain only one set of product details (app description, icons, screenshots, etc.). +This also means you <em>cannot</em> charge a different price for different APKs.</li> + <li>All users see only one version of your application on Android Market, so they are not +confused by different versions you may have published that are "for tablets" or +"for phones."</li> + <li>All user reviews are applied to the same application listing, even though users on different +devices may have different APKs.</li> + <li>If you publish different APKs for different versions of Android (for different API levels), +then when a user's device receives a system update that qualifies them for a different APK you've +published, Android Market updates the user's application to the APK designed for the higher version +of Android. Any system data associated with the application is retained (the same as with normal +application updates when using a single APK).</li> +</ul> + +<p>To publish multiple APKs for the same application, you must enable <strong>Advanced mode</strong> +in your application's <strong>APK files</strong> tab (as discussed in the previous section). Once +in advanced mode, you can upload, activate, then publish multiple APKs for the same application. The +following sections describe more about how it works.</p> + + +<h3 id="SupportedFilters">Supported filters</h3> + +<p>Which devices receive each APK is determined by <a +href="{@docRoot}guide/appendix/market-filters.html">Android Market filters</a> that are specified by +elements in the manifest file of each APK. However, Android Market allows you to publish multiple +APKs only when each APK uses filters to support a variation of the following +device characteristics:</p> + +<ul> + <li><strong>OpenGL texture compression formats</strong> + <p>This is based on your manifest file's <a +href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code +<supports-gl-texture>}</a> element(s).</p> + <p>For example, when developing a game that uses OpenGL ES, you can provide one APK for +devices that support ATI texture compression and a separate APK for devices +that support PowerVR compression (among many others).</p> + <br/> + </li> + + <li><strong>Screen size (and, optionally, screen density)</strong> + <p>This is based on your manifest file's <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> <em>or</em> <a +href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code +<compatible-screens>}</a> element. You should never use both elements and you should use only +<a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> when possible.</p> + <p>For example, you can provide one APK that supports small and normal size screens and another +APK that supports large and xlarge screens.</p> + + <p class="note"><strong>Note:</strong> The Android system provides strong support for +applications to support all screen configurations with a single APK. You should avoid creating +multiple APKs to support different screens unless absolutely necessary and instead follow the guide +to <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple +Screens</a> so that your application is flexible and can adapt to all screen configurations +with a single APK.</p> + <p class="caution"><strong>Caution:</strong> By default, all screen size attributes in the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element are "true" if you do not declare them otherwise. However, +because the {@code android:xlargeScreens} attribute was added in Android 2.3 (API level +9), Android Market will assume that it is "false" if your application does not set either <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code +android:minSdkVersion}</a> or <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code +android:targetSdkVersion}</a> to "9" or higher.</p> + <p class="caution"><strong>Caution:</strong> You should not combine both <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> and <a +href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code +<compatible-screens>}</a> elements in your manifest file. Using both increases the chances +that you'll introduce an error due to conflicts between them. For help deciding which to use, read +<a href="{@docRoot}guide/practices/screens-distribution.html">Distributing to Specific Screens</a>. +If you can't avoid using both, be aware that for any conflicts in agreement between a given size, +"false" will win.</p> + <br/> + </li> + + <li><strong>API level</strong> + <p>This is based on your manifest file's <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code <uses-sdk>}</a> element. +You +can use both the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code +android:minSdkVersion}</a> and <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max">{@code android:maxSdkVersion}</a> +attributes to specify support for different API levels.</p> + <p>For example, you can publish your application with one APK that supports API levels 4 - 7 +(Android 1.6 - 2.1)—using only APIs available since API level 4 or lower—and another +APK that supports API levels 8 and above (Android 2.2+)—using APIs available since API level 8 +or lower.</p> + <div class="note"> + <p><strong>Note:</strong></p> + <ul> + <li>If you use this characteristic as the factor to distinguish multiple APKs, then the APK +with a higher <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code +android:minSdkVersion}</a> value must have a higher <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code android:versionCode}</a> +value. This is also true if two APKs overlap their device support based on a different supported +filter. This ensures that when a device receives a system update, Android Market can offer the user +an update for your application (because updates are based on an increase in the app version code). +This requirement is described further in the section below about <a href="#Rules">Rules for +multiple APKs</a>.</li> + <li>You should avoid using <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max">{@code +android:maxSdkVersion}</a> in general, because as long as you've properly developed your +application with public APIs, it is always compatible with future versions of Android. If you want +to publish a different APK for higher API levels, you still do not need to specify the +maximum version, because if the <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code +android:minSdkVersion}</a> is {@code "4"} in one APK and {@code "8"} in another, devices that +support API level 8 or higher will always receive the second APK (because it's version code is +higher, as per the previous note).</li> + </ul> + </div> + </li> +</ul> + +<p>Other manifest elements that enable <a +href="{@docRoot}guide/appendix/market-filters.html">Android Market filters</a>—but are not +listed above—are still applied for each APK as usual. However, Android Market does not allow +you to publish multiple APKs based on variations of them. Thus, you cannot publish +multiple APKs if the above listed filters are the same for each APK (but the APKs differ based on +other characteristics in the manifest file). For +example, you cannot provide different APKs that differ purely on the <a +href="{@docRoot}guide/topics/manifest/uses-configuration-element.html">{@code +<uses-configuration>}</a> characteristics.</p> + + + +<h3 id="Rules">Rules for multiple APKs</h3> + +<p>Before you enable advanced mode to publish multiple APKs for your application, you need to +understand the following rules that define how publishing multiple APKs works:</p> + +<ul> + <li>All APKs you publish for the same application <strong>must have the same package +name and be signed with the same certificate key</strong>.</li> + + <li>Each APK <strong>must have a different version code</strong>, specified by the +<a href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code +android:versionCode}</a> attribute.</li> + + <li>Each APK <strong>must not exactly match the configuration support of another APK</strong>. + <p>That is, each APK must declare slightly different support for at least one of +the <a href="#MarketFiltersSupported">supported Market filters</a> (listed above).</p> + <p>Usually, you will differentiate your APKs based on a specific characteristic (such as the +supported texture compression formats), and thus, each APK will declare support for different +devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two +APKs do overlap (they support some of the same device configurations), a device that falls within +that overlap range will receive the APK with a higher version code (defined by <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code +android:versionCode}</a>).</p></li> + + <li>You cannot activate a new APK that has a version code lower than that of the APK it's +replacing. For example, say you have an active APK for screen sizes small - normal with version code +0400, then try to replace it with an APK for the same screen sizes with version code 0300. This +raises an error, because it means users of the previous APK will not be able to update the +application.</li> + + <li>An APK that requires a <strong>higher API level</strong> must have a <strong>higher +version code</strong>. + <p>This is true only when either: the APKs differ based <em>only</em> on the +supported API levels (no other <a href="#SupportedMarketFilters">supported market filters</a> +distinguish the APKs from each other) <em>or</em> when the APKs do use another supported filter, but +there is an overlap between the APKs within that filter.</p> + <p>This is important because a user's device receives an application update from +Android Market only if the version code for the APK on Android Market is higher than the version +code of the APK currently on the device. This ensures that if a device receives a system update that +then qualifies it to install the APK for higher API levels, the device receives an application +update because the version code increases.</p> +<p class="note"><strong>Note:</strong> The size of the version code increase is irrelevant; it +simply needs to be larger in the version that supports higher API levels.</p> + <p>Here are some examples:</p> + <ul> + <li>If an APK you've uploaded for API levels 4 and above (Android 1.6+) has a version code of +{@code 0400}, then an APK for API levels 8 and above (Android 2.2+) must be {@code 0401} or +greater. In this case, the API level is the only supported filter used, so the version codes +<strong>must increase</strong> in correlation with the API level support for each APK, so that users +get an update when they receive a system update.</li> + <li>If you have one APK that's for API level 4 (and above) <em>and</em> small - +large screens, and another APK for API level 8 (and above) <em>and</em> large - xlarge screens, then +the version codes <strong>must increase</strong>. In this case, the API level filter is used to +distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs +support large screens), the version codes must still be in order. This ensures that a large screen +device that receives a system update to API level 8 will receive an update for the second +APK.</li> + <li>If you have one APK that's for API level 4 (and above) <em>and</em> small - +normal screens, and another APK for API level 8 (and above) <em>and</em> large - xlarge +screens, then the version codes <strong>do not need to increase</strong> in correlation with the API +levels. Because there is no overlap within the screen size filter, there are no devices that +could potentially move between these two APKs, so there's no need for the version codes to +increase from the lower API level to the higher API level.</li> + </ul> + </li> + +</ul> + +<p>Failure to abide by the above rules results in an error on the Android Market publisher site +when you activate your APKs—you will be unable to publish your application until you +resolve the error.</p> + +<p>There are other conflicts that might occur when you activate your APKs, but which will result +in warnings rather than errors. Warnings can be caused by the following:</p> + +<ul> + <li>When you modify an APK to "shrink" the support for a device's characteristics and no other +APKs support the devices that then fall outside the supported range. For example, if an APK +currently supports small and normal size screens and you change it to support only small screens, +then you have shrunk the pool of supported devices and some devices will no longer see your +application in Android Market. You can resolve this by adding another APK that supports normal size +screens so that all previously-supported devices are still supported.</li> + + <li>When there are "overlaps" between two or more APKs. For example, if an APK supports screen +sizes small, normal, and large, while another APK supports sizes large and xlarge, there is an +overlap, because both APKs support large screens. If you do not resolve this, then devices that +qualify for both APKs (large screen devices in the example) will receive whichever APK has the +highest version code.</li> +</ul> + +<p>When such conflicts occur, you will see a warning message, but you can still publish your +application.</p> + + + +<h2 id="CreatingApks">Creating Multiple APKs</h2> + +<p>Once you decide to publish multiple APKs, you probably need to create separate +Android projects for each APK you intend to publish so that you can appropriately develop them +separately. You can do this by simply duplicating your existing project and give it a new name. +(Alternatively, you might use a build system that can output different resources—such +as textures—based on the build configuration.)</p> + +<p class="note"><strong>Tip:</strong> One way to avoid duplicating large portions of your +application code is to use a <a +href="{@docRoot}guide/developing/projects/index.html#LibraryProjects">library project</a>. A library +project holds shared code and resources, which you can include in your actual application +projects.</p> + +<p>When creating multiple projects for the same application, it's a good practice to identify each +one with a name that indicates the device restrictions to be placed on the APK, so you can +easily identify them. For example, "HelloWorld_8" might be a good name for an +application designed for API level 8 and above.</p> + +<p class="note"><strong>Note:</strong> All APKs you publish for the same application +<strong>must have the same package name and be signed with the same certificate key</strong>. Be +sure you also understand each of the <a href="#Rules">Rules for multiple APKs</a>.</p> + + +<h3 id="VersionCodes">Assigning version codes</h3> + +<p>Each APK for the same application <strong>must have a unique version code</strong>, specified by +the <a href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code +android:versionCode}</a> attribute. You must be careful about assigning version codes when +publishing multiple APKs, because they must each be different, but in some +cases, must or should be defined in a specific order, based on the configurations that each APK +supports.</p> + +<h4>Ordering version codes</h4> + +<p>An APK that requires a higher API level must usually have a higher version code. For example, if +you create two APKs to support different API levels, the APK for the higher API levels must have the +higher version code. This ensures that if a device receives a system update that then qualifies it +to install the APK for higher API levels, the user receives a notification to update the app. For +more information about how this requirement applies, see the section above about <a +href="#Rules">Rules for multiple APKs</a>.</p> + +<p>You should also consider how the order of version codes might affect which APK your users +receive either due to overlap between coverage of different APKs or future changes you might make to +your APKs.</p> + +<p>For example, if you have different APKs based on screen size, such as one for small - normal and +one for large - xlarge, but foresee a time when you will change the APKs to be one for small and one +for normal - xlarge, then you should make the version code for the large - xlarge APK be higher. +That way, a normal size device will receive the appropriate update when you make the change, because +the version code increases from the existing APK to the new APK that now supports the device. </p> + +<p>Also, when creating multiple APKs that differ based on support for different OpenGL texture +compression formats, be aware that many devices support multiple formats. Because a device +receives the APK with the highest version code when there is an overlap in coverage between two +APKs, you should order the version codes among your APKs so that the APK with the +preferred compression format has the highest version code. For example, you might want to perform +separate builds for your app using PVRTC, ATITC, and ETC1 compression formats. If you prefer these +formats in this exact order, then the APK that uses PVRTC should have the highest version code, the +APK that uses ATITC has a lower version code, and the version with ETC1 has the lowest. Thus, if a +device supports both PVRTC and ETC1, it receives the APK with PVRTC, because it has the highest +version code.</p> + + +<h4>Using a version code scheme</h4> + +<p>In order to allow different APKs to update their version codes independent of others (for +example, when you fix a bug in only one APK, so don't need to update all APKs), you should use a +scheme for your version codes that +provides sufficient room between each APK so that you can increase the code in one without requiring +an increase in others. You should also include your actual version name in the code (that is, the +user visible version assigned to <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vname">{@code android:versionName}</a>), +so that it's easy for you to associate the version code and version name.</p> + +<p class="note"><strong>Note:</strong> When you increase the version code for an APK, Android +Market will prompt users of the previous version to update the application. Thus, to avoid +unnecessary updates, you should not increase the version code for APKs that do not actually +include changes.</p> + +<p>We suggest using a version code with at least 7 digits: integers that represent +the supported configurations are in the higher order bits, and the version name (from <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vname">{@code +android:versionName}</a>) is in the lower order bits. For example, when the application version +name is 3.1.0, version codes for an API level 4 +APK and an API level 11 APK would be something like 0400310 and 1100310, respectively. The first +two digits are reserved for the API Level (4 and 11, respectively), the middle two digits are for +either screen sizes or GL texture formats (not used in these examples), and the last three digits +are for the application's version name (3.1.0). Figure 1 shows two examples that split based on both +the platform version (API Level) and screen size.</p> + +<img src="{@docRoot}images/market/version-codes.png" alt="" /> +<p class="img-caption"><strong>Figure 1.</strong> A suggested scheme for your version codes, +using the first two digits for the API Level, the second and third digits for the minimum and +maximum screen size (1 - 4 indicating each of the four sizes) or to denote the texture formats +and the last three digits for the app version.</p> + +<p>This scheme for version codes is just a suggestion for how you should establish a +pattern that is scalable as your application evolves. In particular, this scheme doesn't +demonstrate a solution for identifying different texture compression formats. One option might be +to define your own table that specifies a different integer to each of the different +compression formats your application supports (for example, 1 might correspond to ETC1 and 2 is +ATITC, and so on).</p> + +<p>You can use any scheme you want, but you should carefully consider how future versions of your +application will need to increase their version codes and how devices can receive updates when +either the device configuration changes (for example, due to a system update) or when you modify the +configuration support for one or several of the APKs.</p> + + + + +<h2 id="SingleAPK">Using a Single APK Instead</h2> + +<p><strong>Creating multiple APKs for your application is not the normal procedure</strong> for +publishing an application on Android Market. In most cases, you should be able to publish your +application to most users with a single APK and we encourage that you do so. When you encounter +a situation in which using a single APK becomes difficult, you should carefully consider all your +options before deciding to publish multiple APKs.</p> + +<p>First of all, there are a few key benefits to developing a single APK that supports all +devices:</p> + +<ul> + <li><strong>Publishing and managing your application is easier.</strong> + <p>With only one APK to worry about at any given time, you're less likely to become confused by +which APK is what. You also don't have to keep track of multiple version codes for each +APK—by using only one APK, you can simply increase the version code with each release and +be done.</p> </li> + <li><strong>You need to manage only a single code base.</strong> + <p>Although you can use a <a +href="{@docRoot}guide/developing/projects/index.html#LibraryProjects">library project</a> +to share code between multiple Android projects, it's still likely that you'll reproduce some code +across each project and this could become difficult to manage, especially when resolving +bugs.</p></li> + <li><strong>Your application can adapt to device configuration changes.</strong> + <p>By creating a single APK that contains all the resources for each device configuration, your +application can adapt to configuration changes that occur at runtime. For example, if the user docks +or otherwise connects a handset device to a larger screen, there's a chance that this will invoke a +system configuration change to support the larger screen. If you include all resources for different +screen configurations in the same APK, then your application will load alternative resources and +optimize the user experience for the new interface.</p> + </li> + <li><strong>App restore across devices just works.</strong> + <p>If a user has enabled data backup on his or her current device and then buys a new device +that has a different configuration, then when the user's apps are automatically restored during +setup, the user receives your application and it runs using the resources optimized for that device. +For example, on a new tablet, the user receives your application and it runs with your +tablet-optimized resources. This restore +process does not work across different APKs, because each APK can potentially have different +permissions that the user has not agreed to, so Android Market may not restore the application at +all. (If you use multiple APKs, the user receives either the exact same APK if it's compatible or +nothing at all and must manually download your application to get the APK designed for the new +device.)</p></li> +</ul> + +<p>The following sections describe some of the other options you should use to support multiple +device configurations before deciding to publish multiple APKs.</p> + + + +<h3 id="TextureOptions">Supporting multiple GL textures</h3> + +<p>To support multiple types of GL textures with a single APK, your application should query the GL +texture formats supported on the device and then use the appropriate resources or download +them from a web server. For example, in order to keep the size of your APK small, you can query the +device's support for different GL texture formats when the application starts for the first time and +then download only the textures you need for that device.</p> + +<p>For maximum performance and compatibility, your application should use ETC1 textures wherever it +doesn't impact the visual quality. However, because ETC1 cannot deal with images that have drastic +chroma changes, such as line art and (most) text, and doesn't support alpha, it may not the best +format for all textures.</p> + +<p>With a single APK, you should try to use ETC1 textures and uncompressed textures whenever +reasonable, and consider the use of PVRTC, ATITC, or DXTC as a last resort when ETC1 does not +suffice.</p> + +<p>Here's an example query for supported texture compression formats from inside a +{@link android.opengl.GLSurfaceView.Renderer GLSurfaceView.Renderer}:</p> + +<pre> +public void onSurfaceChanged(GL10 gl, int w, int h) { + String extensions = gl.glGetString(GL10.GL_EXTENSIONS); + Log.d("ExampleActivity", extensions); +} +</pre> + +<p>This returns a string that lists each of the supported compression formats.</p> + + + +<h3 id="ScreenOptions">Supporting multiple screens</h3> + +<p>Unless your APK file exceeds the Android Market size limit of 50MB, supporting multiple screens +should always be done with a single APK. Since Android 1.6, the Android system manages most of the +work required for your application to run successfully on a variety of screen sizes and +densities.</p> + +<p>To further optimize your application for different screen sizes and densities, you should provide +<a href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">alternative +resources</a> such as bitmap drawables at different resolutions and different layout designs for +different screen sizes.</p> + +<p>For more information about how to support multiple screens with a single APK, read <a +href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a>.</p> + +<p>Additionally, you should consider using a support library from the <a +href="{@docRoot}sdk/compatibility-library.html">Compatibility Package</a> so that you can add <a +href="{@docRoot}guide/topics/fundamentals/fragments.html">Fragments</a> to your activity designs +when running on larger screens such as tablets.</p> + + + +<h3 id="ApiLevelOptions">Supporting multiple API levels</h3> + +<p>If you want to support as many versions of the Android platform as possible, you should use +only APIs available in the lowest reasonable version. For example, your application may not require +APIs newer than Android 2.1 (API Level 7), which makes an application available to +over 95% of Android-powered devices (as indicated by the <a +href="{@docRoot}resources/dashboard/platform-versions.html">Platform Versions</a> dashboard).</p> + +<p>By using a support library from the <a +href="{@docRoot}sdk/compatibility-library.html">Compatibility Package</a>, you can also use APIs +from some of the latest versions (such as Android 3.0) while +still supporting versions as low as Android 1.6. The support library includes APIs for <a +href="{@docRoot}guide/topics/fundamentals/fragments.html">Fragments</a>, <a +href="{@docRoot}guide/topics/fundamentals/loaders.html">Loaders</a>, and more. Using the fragment +APIs is particularly valuable so that you can optimize your user interface for large devices such as +tablets.</p> + +<p>Alternatively, if you want to use some APIs that are available only in newer versions of Android +(which your application can still function without), then you should consider using reflection. By +using reflection, you can check whether the current device supports certain APIs. If the APIs are +not available, your application can gracefully disable and hide the feature.</p> + +<p>Another way to use new APIs only when running on a version that supports them is to check the +API level of the current device. That is, you can query the value of {@link +android.os.Build.VERSION#SDK_INT} and create different code paths depending on the API level +supported by the device. For example:</p> + +<pre> +if (android.os.Build.VERSION.SDK_INT >= 11) { + // Use APIs supported by API level 11 (Android 3.0) and up +} else { + // Do something different to support older versions +} +</pre> + diff --git a/docs/html/guide/practices/design/jni.jd b/docs/html/guide/practices/design/jni.jd index 39624f5..1d0e26e 100644 --- a/docs/html/guide/practices/design/jni.jd +++ b/docs/html/guide/practices/design/jni.jd @@ -6,7 +6,6 @@ page.title=JNI Tips <h2>In this document</h2> <ol> - <li><a href="#what">What is JNI?</a></li> <li><a href="#JavaVM_and_JNIEnv">JavaVM and JNIEnv</a></li> <li><a href="#threads">Threads</a></li> <li><a href="#jclass_jmethodID_and_jfieldID">jclass, jmethodID, and jfieldID</a></li> @@ -27,9 +26,6 @@ page.title=JNI Tips </div> </div> -<a name="what_is_jni" id="what_is_jni"></a> -<h2>What is JNI?</h2> - <p>JNI is the Java Native Interface. It defines a way for code written in the Java programming language to interact with native code, e.g. functions written in C/C++. It's VM-neutral, has support for loading code from diff --git a/docs/html/guide/practices/screen-compat-mode.jd b/docs/html/guide/practices/screen-compat-mode.jd new file mode 100644 index 0000000..a792386 --- /dev/null +++ b/docs/html/guide/practices/screen-compat-mode.jd @@ -0,0 +1,257 @@ +page.title=Screen Compatibility Mode +parent.title=Supporting Multiple Screens +parent.link=screens_support.html + +@jd:body + + +<div id="qv-wrapper"> +<div id="qv"> + +<h2>In this document</h2> +<ol> + <li><a href="#Disable">Disabling Screen Compatibility Mode</a></li> + <li><a href="#Enable">Enabling Screen Compatibility Mode</a></li> +</ol> +<h2>See also</h2> +<ol> + <li><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li> + <li><a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a></li> +</ol> +</div> +</div> + +<div class="figure" style="width:500px;"> +<a href="{@docRoot}images/screens_support/compat-zoom.png"> +<img src="{@docRoot}images/screens_support/compat-zoom-thumb.png" alt="" /> +</a> +<p class="img-caption"><strong>Figure 1.</strong> An application running in compatibility mode +on an Android 3.2 tablet.</p> +</div> + +<div class="figure" style="width:500px;"> +<a href="{@docRoot}images/screens_support/compat-stretch.png"> +<img src="{@docRoot}images/screens_support/compat-stretch-thumb.png" alt="" /> +</a> +<p class="img-caption"><strong>Figure 2.</strong> The same application from figure 1, with +compatibility mode disabled.</p> +</div> + +<p class="caution"><strong>Notice:</strong> 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 <a href="#Disable">Disabling Screen Compatibility +Mode</a>.</p> + +<p>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 +<a href="{@docRoot}guide/topics/practices/screens_support.html">Supporting Multiple Screens</a>, +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.</p> + +<p>There are two versions of screen compatibility mode with slightly different behaviors:</p> +<dl> + <dt>Version 1 (Android 1.6 - 3.1)</dt> + <dd>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. + +<p>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.</p> + <p>To disable this version of screen compatibility mode, you simply need to set <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code +android:minSdkVersion}</a> or <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code +android:targetSdkVersion}</a> to {@code "4"} or higher, or set <a +href="guide/topics/manifest/supports-screens-element.html#resizeable">{@code +android:resizeable}</a> to {@code "true"}.</p> + </dd> + + <dt>Version 2 (Android 3.2 and greater)</dt> + <dd>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. + <p>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 <a +href="{@docRoot}guide/topics/practices/screens_support.html">Supporting Multiple +Screens</a>.</p> + <p>In general, large screen devices running Android 3.2 or higher allow users to enable +screen compatibility mode when the application does not <strong>explicitly declare that it supports +large screens</strong> 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 <em>does not</em> 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.)</p></dd> +</dl> + +<img src="{@docRoot}images/screens_support/compat-toggle.png" alt="" /> +<p class="img-caption"><strong>Figure 3.</strong> The pop up menu to toggle screen compatibility +mode (currently disabled, so normal resizing occurs).</p> + +<p>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.</p> + + +<h2 id="Disable">Disabling Screen Compatibility Mode</h2> + +<p>If you've developed your application primarily for versions of Android lower than 3.0, but +<strong>your application does resize properly</strong> for larger screens such as tablets, +<strong>you should disable screen compatibility mode</strong> 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.</p> + +<p>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:</p> + +<ul> + <li>Your application has set both <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code android:minSdkVersion}</a> +and <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code +android:targetSdkVersion}</a> to {@code "10"} or lower and <strong>does not explicitly +declare support</strong> for large screens using the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element.</li> + + <li>Your application has set either <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code android:minSdkVersion}</a> +or <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code +android:targetSdkVersion}</a> to {@code "11"} or higher and <strong>explicitly declares that it does +not support</strong> large screens, using the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element.</li> +</ul> + +<p>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:</p> + +<ul> + <li><strong>Easiest:</strong> + <p>In your manifest file, add the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element and specify the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#xlarge">{@code +android:xlargeScreens}</a> attribute to {@code "true"}:</p> +<pre> +<supports-screens android:xlargeScreens="true" /> +</pre> + <p>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 <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code <uses-sdk>}</a> +attributes.</p> + </li> + + <li><strong>Easy but has other effects:</strong> + <p>In your manifest's <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html">{@code <uses-sdk>}</a> +element, set <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code +android:targetSdkVersion}</a> to {@code "11"} or higher:</p> +<pre> +<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="11" /> +</pre> + <p>This declares that your application supports Android 3.0 and, thus, is designed to +work on larger screens such as tablets.</p> + <p class="caution"><strong>Caution:</strong> When running on Android 3.0 and greater, this also +has the effect of enabling the Holographic theme for you UI, adding the <a +href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a> to your activities, and removing the +Options Menu button in the system bar.</p> + <p>If screen compatibility mode is still enabled after you change this, check your manifest's <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> and be sure that there are no attributes set {@code "false"}. The best +practice is to always explicitly declare your support for different screen sizes using the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element, so you should use this element anyway.</p> + <p>For more information about updating your application to target Android 3.0 devices, read <a +href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for Android +3.0</a>.</p> + </li> +<!-- + <li><strong>Most control</strong> (but you must compile against Android 3.2 or higher): + <p>In your manifest file, add the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element and specify the {@code android:compatibleWidthLimitDp} +attribute to any value <em>higher than</em> {@code "320"}:</p> +<pre> +<supports-screens android:compatibleWidthLimitDp="720" /> +</pre> + <p>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.</p> + <p class="note"><strong>Note:</strong> 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 {@code android:compatibleWidthLimitDp} is larger than 320.</p> + </li> + --> +</ul> + + + +<h2 id="Enable">Enabling Screen Compatibility Mode</h2> + +<p>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 <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element.</p> + +<p class="note"><strong>Note:</strong> Screen compatibility mode is <strong>not</strong> 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 <a +href="{@docRoot}guide/topics/practices/screens_support.html">Supporting Multiple Screens</a> and +provide alternative layouts for different screen sizes.</p> + +<p>By default, when you've set either <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code +android:minSdkVersion}</a> or <a +href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code +android:targetSdkVersion}</a> to {@code "11"} or higher, screen compatibility mode is +<strong>not</strong> 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:</p> + +<ul> + <li>In your manifest file, add the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element and specify the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#compatibleWidth">{@code +android:compatibleWidthLimitDp}</a> attribute to {@code "320"}:</p> +<pre> +<supports-screens android:compatibleWidthLimitDp="320" /> +</pre> + <p>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.</p> + <p class="note"><strong>Note:</strong> 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 <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#compatibleWidth">{@code +android:compatibleWidthLimitDp}</a> is larger than 320.</p> + </li> + + <li>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 <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html#largestWidth">{@code +android:largestWidthLimitDp}</a> attribute: +<pre> +<supports-screens android:largestWidthLimitDp="320" /> +</pre> + <p>This works the same as <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#compatibleWidth">{@code +android:compatibleWidthLimitDp}</a> except it force-enables +screen compatibility mode and does not allow users to disable it.</p> + </li> +</ul>
\ No newline at end of file diff --git a/docs/html/guide/practices/screens-distribution.jd b/docs/html/guide/practices/screens-distribution.jd index 0c5193b..951e364 100644 --- a/docs/html/guide/practices/screens-distribution.jd +++ b/docs/html/guide/practices/screens-distribution.jd @@ -17,6 +17,7 @@ screen configuration</li> <ol> <li><a href="#FilteringHansetApps">Filtering a Handset Application from Tablets</a></li> <li><a href="#FilteringTabletApps">Filtering a Tablet Application from Handsets</a></li> + <li><a href="#MultiApks">Publishing Multiple APKs for Different Screens</a></li> </ol> <h2>See also</h2> @@ -43,7 +44,7 @@ application supports.</p> should understand the techniques for <a href="{@docRoot}guide/practices/screens_support.html">supporting multiple screens</a> and implement them to the best of your ability. By supporting multiple screens, your application can be made -available to the greatest number of users with different devices, using a single {@code .apk}.</p> +available to the greatest number of users with different devices, using a single APK.</p> @@ -144,9 +145,9 @@ href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code with <em>larger</em> screens) and set the larger screen size attributes to {@code "false"}, then external services such as Android Market <strong>do not</strong> apply filtering. Your application will still be available to larger screens, but when it runs, it will not resize to fit the screen. -Instead, the system will draw it in a "postage stamp" window that's the same relative size as the -screen size that your application does support (see <a -href="screens-support-1.5.html#CompatMode">compatibility mode</a> for more information). If you want +Instead, the system will emulate a handset screen size (about 320dp x 480dp; see <a +href="{@docRoot}guide/practices/screen-compat-mode.html">Screen Compatibility Mode</a> for more +information). If you want to prevent your application from being downloaded on larger screens, use <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code <compatible-screens>}</a>, as discussed in the previous section about <a @@ -162,3 +163,24 @@ href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code or you have decided to provide different versions of your application for different sets of screen configurations.</p> + + +<h2 id="MultiApks">Publishing Multiple APKs for Different Screens</h2> + +<p>Although we recommend that you publish one APK for your application, Android Market allows +you to publish multiple APKs for the same +application when each APK supports a different set of screen configurations (as declared in +the manifest file). For example, if you want to publish both a handset version and a tablet +version of your application, but you're unable to make the same APK work for both screen sizes, +you can actually publish two APKs for the same application listing. Depending on each device's +screen configuration, Android Market will deliver it the APK that you've declared to support that +device's screen.</p> + +<p>Beware, however, that publishing multiple APKs for the same application is +considered an advanced feature and <strong>most applications should publish only one +APK that can support a wide range of device configurations</strong>. Supporting multiple screen +sizes, especially, is within reason using a single APK, as long as you follow the guide to +<a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a>.</p> + +<p>If you need more information about how to publish multiple APKs on Android Market, read <a +href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> diff --git a/docs/html/guide/practices/screens-support-1.5.jd b/docs/html/guide/practices/screens-support-1.5.jd index 6fd36bb..9f033b4 100644 --- a/docs/html/guide/practices/screens-support-1.5.jd +++ b/docs/html/guide/practices/screens-support-1.5.jd @@ -18,7 +18,6 @@ an application designed for Android 1.5</li> <h2>In this document</h2> <ol> <li><a href="#strategies">Adding Multiple Screens Support</a></li> - <li><a href="#CompatMode">Compatibility Mode</a></li> </ol> <h2>See also</h2> @@ -47,11 +46,13 @@ android:targetSdkVersion}</a> set to {@code "4"} or higher, then this document i default, an application written for Android 1.5 or below that does not set the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code android:targetSdkVersion}</a> set to {@code "4"} or higher runs in <a -href="#CompatMode">compatibility mode</a> when on a device with a screen larger than the +href="screen-compat-mode">screen compatibility mode</a> when on a device with a screen larger than +the <em>normal</em> screen size (basically, the system displays the application in a small window that is roughly the size of the normal screen size).</p> -<p>This document describes how to get your application out of <a href="#CompatMode">compatibility +<p>This document describes how to get your application out of <a +href="screen-compat-mode.html">screen compatibility mode</a> and instead support multiple screens, but also maintain compatibility with Android 1.5 and below.</p> @@ -144,43 +145,3 @@ Android 3.0 and use the WXGA emulator skin.</p> href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a> to add complete support for different screen configurations.</p> - -<h2 id="CompatMode">Compatibility Mode</h2> - -<div class="figure" style="width:450px;margin:0"> -<img src="{@docRoot}images/screens_support/compat-mode-on.png" alt="" /> -<p class="img-caption"><strong>Figure 1.</strong> An application running in compatibility mode -on an extra large screen.</p> -</div> - -<p>To allow applications to run on larger screens without stretching the UI, Android provides a -compatibility mode that draws an application's UI in a "postage stamp" window when on larger -screens. That is, the system displays the application at the baseline size (<em>normal</em>) and -density (<em>mdpi</em>), with a black border that fills the rest of the screen.</p> - -<p>Compatibility mode exists primarily to support application's developed for Android 1.5 (or lower) -when running on larger screens, because multiple screen support was not added until Android 1.6, -older applications were not designed to support different screen configurations.</p> - -<p>As such, if you've set your <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code -android:minSdkVersion}</a> to {@code "3"} or lower and have <em>not</em> set the <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code -android:targetSdkVersion}</a> to {@code "4"} or higher, then compatibility mode is enabled and -the system will not scale your application, because your application implicitly declares that it -only supports the baseline screen configuration (normal screen size and medium density).</p> - -<p>To disable compatibility mode, set either <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code -android:minSdkVersion}</a> or <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code -android:targetSdkVersion}</a> to {@code "4"} or higher. For more information, see the previous -section about <a href="#strategies">Adding Multiple Screens Support</a>.</p> - -<p>You can also affect whether compatibility mode is enabled by using the <a -href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code -<supports-screens>}</a> element (you can enable it by setting {@code android:resizeable} or -specific screen sizes to {@code "false"}). However, you should not explicitly enable compatibility -mode for your application, but should instead apply the necessary techniques to <a -href="{@docRoot}guide/practices/screens_support.html">supporting multiple screens</a> and allow your -application to properly fit the screen on all screen sizes.</p> diff --git a/docs/html/guide/practices/screens_support.jd b/docs/html/guide/practices/screens_support.jd index 14de152..6dec4b3 100644 --- a/docs/html/guide/practices/screens_support.jd +++ b/docs/html/guide/practices/screens_support.jd @@ -25,6 +25,13 @@ page.title=Supporting Multiple Screens <li><a href="#qualifiers">Using configuration qualifiers</a></li> <li><a href="#DesigningResources">Designing alternative layouts and drawables</a></li> </ol></li> + <li><a href="#DeclaringTabletLayouts">Declaring Tablet Layouts for Android 3.2</a> <span +class="new">new!</span> + <ol> + <li><a href="#NewQualifiers">Using new size qualifiers</a></li> + <li><a href="#ConfigurationExamples">Configuration examples</a></li> + <li><a href="#DeclaringScreenSizeSupport">Declaring screen size support</a></li> + </ol></li> <li><a href="#screen-independence">Best Practices</a></li> <li><a href="#DensityConsiderations">Additional Density Considerations</a> <ol> @@ -57,15 +64,15 @@ Guidelines</a></li> applications, the Android system provides a consistent development environment across devices and handles most of the work to adjust each application's user interface to the screen on which it is displayed. At the same time, the system provides APIs that allow you to control your -application's UI on specific screen sizes and densities, in order to modify and optimize your UI +application's UI for specific screen sizes and densities, in order to optimize your UI design for different screen configurations. For example, you might want a UI for tablets -that's different from the design for handsets.</p> +that's different from the UI for handsets.</p> -<p>Although the system performs sufficient scaling and resizing to make your application work on +<p>Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for <em>their</em> devices—rather than -simply stretched to fit their devices.</p> +simply stretched to fit the screen on their devices.</p> <p>By following the practices described in this document, you can create an application that displays properly and provides an optimized user experience on all supported screen configurations, @@ -74,7 +81,14 @@ using a single {@code .apk} file.</p> <p class="note"><strong>Note:</strong> The information in this document assumes that your application is designed for Android 1.6 (API Level 4) or higher. If your application supports Android 1.5 or lower, please first read <a -href="{@docRoot}guide/practices/screens-support-1.5.html">Strategies for Android 1.5</a>.</p> +href="{@docRoot}guide/practices/screens-support-1.5.html">Strategies for Android 1.5</a>. +<br/><br/> +Also, be aware that <strong>Android 3.2 has introduced new APIs</strong> that allow you to more +precisely control the layout resources your application uses for different screen sizes. These new +features are especially important if you're developing an application that's optimized for tablets. +For details, see the section about <a href="#DeclaringTabletLayouts">Declaring Tablet Layouts for +Android 3.2</a>. +</p> @@ -143,9 +157,16 @@ the range of actual screen sizes and densities into:</p> <li>A set of four generalized <strong>sizes</strong>: <em>small</em>, <em>normal</em>, <em>large</em>, and <em>xlarge</em></em> +<p class="note"><strong>Note:</strong> Beginning with Android 3.2 (API level 13), these size groups +are deprecated in favor of a new technique for managing screen sizes based on the available screen +width. If you're developing for Android 3.2 and greater, see <a +href="#DeclaringTabletLayouts">Declaring Tablet Layouts for Android 3.2</a> for more +information.</p> +</li> <li>A set of four generalized <strong>densities</strong>: <em>ldpi</em> (low), <em>mdpi</em> (medium), <em>hdpi</em> (high), and <em>xhdpi</em> (extra high) +</li> </ul> <p>The generalized sizes and densities are arranged around a @@ -154,7 +175,7 @@ baseline is based upon the screen configuration for the first Android-powered de G1, which has an HVGA screen (until Android 1.6, this was the only screen configuration that Android supported).</p> -<p>Each generalized size or density spans a range of actual screen sizes or density. For example, +<p>Each generalized size and density spans a range of actual screen sizes and densities. For example, two devices that both report a screen size of <em>normal</em> might have actual screen sizes and aspect ratios that are slightly different when measured by hand. Similarly, two devices that report a screen density of <em>hdpi</em> might have real pixel densities that are slightly different. @@ -168,11 +189,30 @@ and density groups.</p> Illustration of how Android roughly maps actual sizes and densities to generalized sizes and densities (figures are not exact).</p> +<p>As you design your UI for different screen sizes, you'll discover that each design requires a +minimum amount of space. So, each generalized screen size above has an associated minimum +resolution that's defined by the system. These minimum sizes are in "dp" units—the same units +you should use when defining your layouts—which allows the system to avoid worrying about +changes in screen density.</p> + +<ul> + <li><em>xlarge</em> screens are at least 960dp x 720dp</li> + <li><em>large</em> screens are at least 640dp x 480dp</li> + <li><em>normal</em> screens are at least 470dp x 320dp</li> + <li><em>small</em> screens are at least 426dp x 320dp</li> +</ul> + +<p class="note"><strong>Note:</strong> These minimum screen sizes were not as well defined prior to +Android 3.0, so you may encounter some devices that are mis-classified between normal and large. +These are also based on the physical resolution of the screen, so may vary across devices—for +example a 1024x720 tablet with a system bar actually has a bit less space available to the +application due to it being used by the system bar.</p> + <p>To optimize your application's UI for the different screen sizes and densities, you can provide <a href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">alternative resources</a> for any of the generalized sizes and densities. Typically, you should provide alternative layouts for some of the different screen sizes and alternative bitmap images for -different screen densities. At runtime, the system uses the appropriate size or density resources +different screen densities. At runtime, the system uses the appropriate resources for your application, based on the generalized size or density of the current device screen.</p> <p>You do not need to provide alternative resources for every combination of screen size and @@ -221,7 +261,7 @@ density, if necessary</li> </ul> <p>In figure 2, the text view and bitmap drawable have dimensions specified in pixels ({@code px} -units), so the elements are physically larger on a low density screen and smaller on a high density +units), so the views are physically larger on a low density screen and smaller on a high density screen. This is because although the actual screen sizes may be the same, the high density screen has more pixels per inch (the same amount of pixels fit in a smaller area). In figure 3, the layout dimensions are specified in density-independent pixels ({@code dp} units). Because the baseline for @@ -255,6 +295,18 @@ for the screen density, as appropriate. To more gracefully handle different scre however, you should also:</p> <ul> + <li><strong>Explicitly declare in the manifest which screen sizes your application +supports</strong> + <p>By declaring which screen sizes your application supports, you can ensure that only +devices with the screens you support can download your application. Declaring support for +different screen sizes can also affect how the system draws your application on larger +screens—specifically, whether your application runs in <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a>.</p> + <p>To declare the screen sizes your application supports, you should include the +<a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code +<supports-screens>}</a> element in your manifest file.</p> + </li> + <li><strong>Provide different layouts for different screen sizes</strong> <p>By default, Android resizes your application layout to fit the current device screen. In most cases, this works fine. In other cases, your UI might not look as good and might need adjustments @@ -264,6 +316,12 @@ you might need to adjust sizes so that everything can fit on the screen.</p> <p>The configuration qualifiers you can use to provide size-specific resources are <code>small</code>, <code>normal</code>, <code>large</code>, and <code>xlarge</code>. For example, layouts for an extra large screen should go in {@code layout-xlarge/}.</p> + <p>Beginning with Android 3.2 (API level 13), the above size groups are deprecated and you +should instead use the {@code sw<N>dp} configuration qualifier to define the smallest +available width required by your layout resources. For example, if your multi-pane tablet layout +requires at least 600dp of screen width, you should place it in {@code layout-sw600dp/}. Using the +new techniques for declaring layout resources is discussed further in the section about <a +href="#DeclaringTabletLayouts">Declaring Tablet Layouts for Android 3.2</a>.</p> </li> <li><strong>Provide different bitmap drawables for different screen densities</strong> @@ -386,7 +444,7 @@ provide special resources for different screen configurations.</p> </tr> <tr> -<td rowspan="5">Density</td> +<td rowspan="6">Density</td> <td><code>ldpi</code></td> <td>Resources for low-density (<em>ldpi</em>) screens (~120dpi).</td> </tr> @@ -408,7 +466,15 @@ density.)</td> <td>Resources for all densities. These are density-independent resources. The system does not scale resources tagged with this qualifier, regardless of the current screen's density.</td> </tr> - +<tr> +<td><code>tvdpi</code></td> +<td>Resources for screens somewhere between mdpi and hdpi; approximately 213dpi. This is not +considered a "primary" density group. It is mostly intended for televisions and most apps shouldn't +need it—providing mdpi and hdpi resources is sufficient for most apps and the system will +scale them as appropriate. If you find it necessary to provide tvdpi resources, you should size them +at a factor of 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x +133px for tvdpi.</td> +</tr> <tr> <td rowspan="2">Orientation</td> <td><code>land</code></td> @@ -432,6 +498,12 @@ configuration.</td> </tr> </table> +<p class="note"><strong>Note:</strong> If you're developing your application for Android 3.2 and +higher, see the section about <a +href="#DeclaringTabletLayouts">Declaring Tablet Layouts for Android 3.2</a> for information about +new configuration qualifiers that you should use when declaring layout resources for specific +screen sizes (instead of using the size qualifiers in table 1).</p></p> + <p>For more information about how these qualifiers roughly correspond to real screen sizes and densities, see <a href="#range">Range of Screens Supported</a>, earlier in this document.</p> @@ -457,6 +529,20 @@ configuration qualifiers (not just for screen configurations), see <a href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources"> Providing Alternative Resources</a>.</p> +<p>Be aware that, when the Android system picks which resources to use at runtime, it uses +certain logic to determing the "best matching" resources. That is, the qualifiers you use don't +have to exactly match the current screen configuration in all cases in order for the system to +use them. Specifically, when selecting resources based on the size qualifiers, the system will +use resources designed for a screen smaller than the current screen if there are no resources +that better match (for example, a large-size screen will use normal-size screen resources if +necessary). However, if the only available resources are <em>larger</em> than the current screen, +the system will not use them and your application will crash if no other resources match the device +configuration (for example, if all layout resources are tagged with the {@code xlarge} qualifier, +but the device is a normal-size screen). For more information about how the system selects +resources, read <a +href="{@docRoot}guide/topics/resources/providing-resources.html#BestMatch">How Android Finds the +Best-matching Resource</a>.</p> + <p class="note"><strong>Tip:</strong> If you have some drawable resources that the system should never scale (perhaps because you perform some adjustments to the image yourself at runtime), you should place them in a directory with the {@code nodpi} configuration qualifier. @@ -554,6 +640,291 @@ icons, status bar icons, tab icons, and more.</p> + +<h2 id="DeclaringTabletLayouts">Declaring Tablet Layouts for Android 3.2</h2> + +<p>For the first generation of tablets running Android 3.0, the proper way to declare tablet +layouts was to put them in a directory with the {@code xlarge} configuration qualifier (for example, + {@code res/layout-xlarge/}). In order to accommodate other types of tablets and screen +sizes—in particular, 7" tablets—Android 3.2 introduces a new way to specify resources +for more discrete screen sizes. The new technique is based on the amount of space your layout needs +(such as 600dp of width), rather than trying to make your layout fit the generalized size groups +(such as <em>large</em> or <em>xlarge</em>).</p> + +<p>The reason designing for 7" tablets is tricky when using the generalized size groups is +that a 7" tablet is technically in the same group as a 5" handset (the <em>large</em> group). While +these two devices are seemingly close to each other in size, the amount of space for an +application's UI is significantly different, as is the style of user interaction. Thus, a 7" and 5" +screen should not always use the same layout. To make it possible for you to provide different +layouts for these two kinds of screens, Android now allows you to specify your layout resources +based on the width and/or height that's actually available for your application's layout, specified +in dp units.</p> + +<p>For example, after you've designed the layout you want to use for tablet-style devices, you might +determine that the layout stops working well when the screen is less than 600dp wide. This threshold +thus becomes the minimum size that you require for your tablet layout. As +such, you can now specify that these layout resources should be used only when there is at least +600dp of width available for your application's UI.</p> + +<p>You should either pick a width and design to it as your minimum size, or test what is the +smallest width your layout supports once it's complete.</p> + +<p class="note"><strong>Note:</strong> Remember that all the figures used with these new size APIs +are density-indpendent pixel (dp) values and your layout dimensions should also always be defined +using dp units, because what you care about is the amount of screen space available after the system +accounts for screen density (as opposed to using raw pixel resolution). For more information about +density-indpendent pixels, read <a href="#terms">Terms and concepts</a>, earlier in this +document.</p> + + +<h3 id="NewQualifiers">Using new size qualifiers</h3> + +<p>The different resource configurations that you can specify based on the space available for your +layout are summarized in table 2. These new qualifiers offer you more control over the specific +screen sizes your application supports, compared to the traditional screen size groups (small, +normal, large, and xlarge).</p> + +<p class="note"><strong>Note:</strong> The sizes that you specify using these qualifiers are +<strong>not the actual screen sizes</strong>. Rather, the sizes are for the width or height in dp +units that are <strong>available to your activity's window</strong>. The Android system +might use some of the screen for system UI (such as the system bar at the bottom of the screen or +the status bar at the top), so some of the screen might not be available for your layout. Thus, the +sizes you declare should be specifically about the sizes needed by your activity—the system +accounts for any space used by system UI when declaring how much space it provides for your layout. +Also beware that the <a href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar</a> is considered +a part of your application's window space, although your layout does not declare it, so it reduces +the space available for your layout and you must account for it in your design.</p> + +<p class="table-caption"><strong>Table 2.</strong> New configuration qualifers for screen size +(introduced in Android 3.2).</p> +<table> + <tr><th>Screen configuration</th><th>Qualifier values</th><th>Description</th></tr> + <tr><td>smallestWidth</td> + <td><code>sw<N>dp</code><br/><br/> + Examples:<br/> + <code>sw600dp</code><br/> + <code>sw720dp</code><br/> + </td> + <td> + <p>The fundamental size of a screen, as indicated by the shortest dimension of the available +screen area. Specifically, the device's smallestWidth is the shortest of the screen's available +height and width (you may also think of it as the "smallest possible width" for the screen). You can +use this qualifier to ensure that, regardless of the screen's current orientation, your +application's has at least {@code <N>} dps of width available for it UI.</p> + <p>For example, if your layout requires that its smallest dimension of screen area be at +least 600 dp at all times, then you can use this qualifer to create the layout resources, {@code +res/layout-sw600dp/}. The system will use these resources only when the smallest dimension of +available screen is at least 600dp, regardless of whether the 600dp side is the user-perceived +height or width. The smallestWidth is a fixed screen size characteristic of the device; <strong>the +device's smallestWidth does not change when the screen's orientation changes</strong>.</p> + <p>The smallestWidth of a device takes into account screen decorations and system UI. For +example, if the device has some persistent UI elements on the screen that account for space along +the axis of the smallestWidth, the system declares the smallestWidth to be smaller than the actual +screen size, because those are screen pixels not available for your UI.</p> + <p>This is an alternative to the generalized screen size qualifiers (small, normal, large, xlarge) +that allows you to define a discrete number for the effective size available for your UI. +Using smallestWidth to determine the general screen size is useful because width is +often the driving factor in designing a layout. A UI will often scroll vertically, but have fairly +hard constraints on the minimum space it needs horizontally. The available width is also the key +factor in determining whether to use a one-pane layout for handsets or multi-pane layout for +tablets. Thus, you likely care most about what the smallest possible width will be on each +device.</p> + </td> + </tr> + <tr> + <td>Available screen width</td> + <td><code>w<N>dp</code><br/><br/> + Examples:<br/> + <code>w720dp</code><br/> + <code>w1024dp</code><br/> + </td> + <td> + <p>Specifies a minimum available width in dp units at which the resources should be +used—defined by the <code><N></code> value. The system's corresponding value for the +width changes when the screen's orientation switches between landscape and portrait to +reflect the current actual width that's available for your UI.</p> + <p>This is often useful to determine whether to use a multi-pane layout, because even on a +tablet device, you often won't want the same multi-pane layout for portrait orientation as you do +for landscape. Thus, you can use this to specify the minimum width required for the layout, instead +of using both the screen size and orientation qualifiers together.</p> + </td> + </tr> + <tr> + <td>Available screen height</td> + <td><code>h<N>dp</code><br/><br/> + Examples:<br/> + <code>h720dp</code><br/> + <code>h1024dp</code><br/> + etc. + </td> + <td> + <p>Specifies a minimum screen height in dp units at which the resources should be +used—defined by the <code><N></code> value. The system's corresponding value for +the height changes when the screen's orientation switches between landscape and portrait to +reflect the current actual height that's available for your UI.</p> + <p>Using this to define the +height required by your layout is useful in the same way as <code>w<N>dp</code> is for +defining the required width, instead of using both the screen size and orientation qualifiers. +However, most apps won't need this qualifier, considering that UIs often scroll vertically and are +thus more flexible with how much height is available, whereas the width is more rigid.</p> + </td> + </tr> +</table> + +<p>While using these qualifiers might seem more complicated than using screen size groups, it should +actually be simpler once you determine the requirements for your UI. When you design your UI, +the main thing you probably care about is the actual size at which your application switches between +a handset-style UI and a tablet-style UI that uses multiple panes. The exact point of this switch +will depend on your particular design—maybe you need a 720dp width for your tablet layout, +maybe 600dp is enough, or 480dp, or some number between these. Using these qualifiers in table 2, +you are in control of the precise size at which your layout changes.</p> + +<p>For more discussion about these size configuration qualifiers, see the <a +href="{@docRoot}guide/topics/resources/providing-resources.html#SmallestScreenWidthQualifier"> +Providing Resources</a> document.</p> + + +<h3 id="ConfigurationExamples">Configuration examples</h3> + +<p>To help you target some of your designs for different types of devices, here are some +numbers for typical screen widths:</p> + +<ul> + <li>320dp: a typical phone screen (240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).</li> + <li>480dp: a tweener tablet like the Streak (480x800 mdpi).</li> + <li>600dp: a 7” tablet (600x1024 mdpi).</li> + <li>720dp: a 10” tablet (720x1280 mdpi, 800x1280 mdpi, etc).</li> +</ul> + +<p>Using the size qualifiers from table 2, your application can switch between your different layout +resources for handsets and tablets using any number you want for width and/or height. For example, +if 600dp is the smallest available width supported by your tablet layout, you can provide these two +sets of layouts:</p> + +<pre class="classic"> +res/layout/main_activity.xml # For handsets +res/layout-sw600dp/main_activity.xml # For tablets +</pre> + +<p>In this case, the smallest width of the available screen space must be 600dp in order for the +tablet layout to be applied.</p> + +<p>For other cases in which you want to further customize your UI to differentiate between sizes +such as 7” and 10” tablets, you can define additional smallest width layouts:</p> + +<pre class="classic"> +res/layout/main_activity.xml # For handsets (smaller than 600dp available width) +res/layout-sw600dp/main_activity.xml # For 7” tablets (600dp wide and bigger) +res/layout-sw720dp/main_activity.xml # For 10” tablets (720dp wide and bigger) +</pre> + +<p>Notice that the previous two sets of example resources use the "smallest width" qualifer, {@code +sw<N>dp}, which specifies the smallest of the screen's two sides, regardless of the +device's current orientation. Thus, using {@code sw<N>dp} is a simple way to specify the +overall screen size available for your layout by ignoring the screen's orientation.</p> + +<p>However, in some cases, what might be +important for your layout is exactly how much width or height is <em>currently</em> available. For +example, if you have a two-pane layout with two fragments side by side, you might want to use it +whenever the screen provides at least 600dp of width, whether the device is in landscape or +portrait orientation. In this case, your resources might look like this:</p> + +<pre class="classic"> +res/layout/main_activity.xml # For handsets (smaller than 600dp available width) +res/layout-w600dp/main_activity.xml # Multi-pane (any screen with 600dp available width or more) +</pre> + +<p>Notice that the second set is using the "available width" qualifier, {@code w<N>dp}. This +way, one device may actually use both layouts, depending on the orientation of the screen (if +the available width is at least 600dp in one orientation and less than 600dp in the other +orientation).</p> + +<p>If the available height is a concern for you, then you can do the same using the {@code +h<N>dp} qualifier. Or, even combine the {@code w<N>dp} and {@code h<N>dp} +qualifiers if you need to be really specific.</p> + + +<h3 id="DeclaringScreenSizeSupport">Declaring screen size support</h3> + +<p>Once you've implemented your layouts for different screen sizes, it's equally important that you +declare in your manifest file which screens your application supports.</p> + +<p>Along with the new configuration qualifiers for screen size, Android 3.2 introduces new +attributes for the <a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><supports-screens></a> +manifest element:</p> + +<dl> + + <dt><a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#requiresSmallest"> +{@code android:requiresSmallestWidthDp}</a></dt> + <dd>Specifies the minimum smallestWidth required. The smallestWidth is the shortest dimension of +the screen space (in {@code dp} units) that must be available to your application UI—that is, +the shortest of the available screen's two dimensions. So, in order for a device to be considered +compatible with your application, the device's smallestWidth must be equal to or greater than this +value. (Usually, the value you supply for this is the "smallest width" that your layout supports, +regardless of the screen's current orientation.) + <p>For example, if your application is only for tablet-style devices with a 600dp +smallest available width:</p> +<pre> +<manifest ... > + <supports-screens android:requiresSmallestWidthDp="600" /> + ... +</manifest> +</pre> + <p>However, if your application supports all screen sizes supported by Android (as small as +426dp x 320dp), then you don't need to declare this attribute, because the smallest width your +application requires is the smallest possible on any device.</p> + + <p class="caution"><strong>Caution:</strong> The Android system does not pay attention to this +attribute, so it does not affect how your application behaves at runtime. Instead, it is used +to enable filtering for your application on services such as Android Market. However, +<strong>Android Market currently does not support this attribute for filtering</strong> (on Android +3.2), so you should continue using the other size attributes if your application does not support +small screens.</p> +</dd> + + <dt><a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#compatibleWidth"> +{@code android:compatibleWidthLimitDp}</a></dt> + <dd>This attribute allows you to enable <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a> as a +user-optional feature by specifying the maximum "smallest width" that your application +supports. If the smallest side of a device's available screen is greater than your value here, +users can still install your application, but are offered to run it in screen compatibility mode. By +default, screen compatibility mode is disabled and your layout is resized to fit the screen as +usual, but a button is available in the system bar that allows users to toggle screen compatibility +mode on and off. + <p class="note"><strong>Note:</strong> If your application's layout properly resizes for large +screens, you do not need to use this attribute. We recommend that you avoid using this +attribute and instead ensure your layout resizes for larger screens by following the +recommendations in this document.</p></dd> + + <dt><a +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#largestWidth"> +{@code android:largestWidthLimitDp}</a></dt> + <dd>This attribute allows you to force-enable <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a> by specifying +the maximum "smallest width" that your application supports. If the smallest +side of a device's available screen is greater than your value here, the application runs in screen +compatibility mode with no way for the user to disable it. + <p class="note"><strong>Note:</strong> If your application's layout properly resizes for large +screens, you do not need to use this attribute. We recommend that you avoid using this +attribute and instead ensure your layout resizes for larger screens by following the +recommendations in this document.</p></dd> +</dl> + +<p class="caution"><strong>Caution:</strong> When developing for Android 3.2 and higher, you +should not use the older screen size attributes in combination with the attributes +listed above. Using both the new attributes and the older size attributes might cause +unexpected behavior.</p> + +<p>For more information about each of these attributes, follow the respective links above.</p> + + + + <h2 id="screen-independence">Best Practices</h2> <p>The objective of supporting multiple screens is to create an application that can function @@ -875,7 +1246,7 @@ SDK Manager.exe} from your Android SDK directory (on Windows only) or execute {@ the {@code <sdk>/tools/} directory (on all platforms). Figure 6 shows the Android SDK and AVD Manager with a selection of AVDs, for testing various screen configurations.</p> -<p>Table 2 shows the various emulator skins that are available in the Android SDK, which you can use +<p>Table 3 shows the various emulator skins that are available in the Android SDK, which you can use to emulate some of the most common screen configurations.</p> <p>For more information about creating and using AVDs to test your application, see <a @@ -883,7 +1254,7 @@ href="{@docRoot}guide/developing/devices/managing-avds.html">Managing AVDs with Manager</a>.</p> -<p class="table-caption" id="screens-table"><strong>Table 2.</strong> Various screen +<p class="table-caption" id="screens-table"><strong>Table 3.</strong> Various screen configurations available from emulator skins in the Android SDK (indicated in bold) and other representative resolutions.</p> diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd index f471961..69aecd4 100644 --- a/docs/html/guide/publishing/preparing.jd +++ b/docs/html/guide/publishing/preparing.jd @@ -78,9 +78,6 @@ device to the greatest extent possible. You can then test your application's UI and performance. However, we strongly recommend that you test your application on an actual target device before publishing it. </li> -<li>If you are targeting the <a href="http://www.t-mobileg1.com/">T-Mobile -G1</a> device for your application, make sure that your UI handles screen -orientation changes. </li> </ul> <h3 id="eula">2. Consider adding an End User License Agreement in your diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd index 95d89fa..fa677e6 100644 --- a/docs/html/guide/publishing/publishing.jd +++ b/docs/html/guide/publishing/publishing.jd @@ -39,7 +39,7 @@ page.title=Publishing on Android Market <div id="qv-extra"> <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> <div id="qv-sub-rule"> - <img src="{@docRoot}assets/images/icon_market.jpg" style="float:left;margin:0;padding:0;"> + <img src="{@docRoot}assets/images/icon_market.jpg" style="float:left;margin:0;padding:0 5px;"> <h2 style="color:#669999;">Interested in publishing your app on Android Market?</h2> <p><a href="http://market.android.com/publish">Go to Android Market</a> to create a developer account and upload your application. For more information about the @@ -155,48 +155,43 @@ href="{@docRoot}guide/publishing/licensing.html">Application Licensing</a>.</p> <p>To help users discover your published applications, you can use two special Android Market URIs that direct users to your application's details page or perform a search for all of your published -applications in Android Market. You can use these URIs to do the following:</p> +applications in Android Market. You can use these URIs to create a button in your application or a +link on a web page that:</p> <ul> - <li>Create a button in your application or a link on a web page that opens one of your -application's details page in the Android Market application or web site.</li> - <li>Create a button in your application or a link on a web page that searches for all your -published applications in the Android Market application or web site.</li> + <li>Opens your application's details page in the Android Market application or web site.</li> + <li>Searches for all your published applications in the Android Market application or web +site.</li> </ul> <p>You can launch the Android Market application or web site in the following ways:</p> <ul> <li>Initiate an {@link android.content.Intent} from your application that launches the -Android Market application on the user's device. The intent must use the {@link -android.content.Intent#ACTION_VIEW} action, and include intent data with the appropriate -Android Market URI scheme.</li> - <li>Provide a hyperlink on a web page that opens the Android Market web site.</li> +Android Market application on the user's device.</li> + <li>Provide a link on a web page that opens the Android Market web site (but will also +open the Android Market application if clicked from a device).</li> </ul> -<p>In both cases, you need to create a URI that indicates either the application you'd like to view -in Android Market or the search you'd like to perform. The URI is quite similar whether you want -to open the application or open the web site. The only difference is the URI prefix.</p> +<p>In both cases, whether you want to initiate the action from your application or from a web +page, the URIs are quite similar. The only difference is the URI prefix.</p> -<p>To open the Android Market application on the device, the prefix for the intent's data URI -is:</p> +<p>To open the Android Market application from your application, the prefix for the intent's data +URI is:</p> <p style="margin-left:2em"><code>market://</code></p> -<p>To open the Android Market web site, the prefix for the link URI is:</p> +<p>To open Android Market from your web site, the prefix for the link URI is:</p> <p style="margin-left:2em"><code>http://market.android.com/</code></p> -<p>To complete each URI, you must append a string that specifies either the -application for which you want to view or the search to execute. The following sections -describe how to create a complete URI for each case.</p> +<p>The following sections describe how to create a complete URI for each action.</p> -<p class="note"><strong>Note:</strong> If you create a link to open the Android Market web site and -the user selects it from an Android-powered device, the Android Market application will also resolve -the link so the user can use the native application instead of the web site. Also, because the -Android Market application also reads the {@code http://} URIs, you can also use them in an intent, -but you should usually use the {@code market://} URIs for an intent, so that the native application -is opened by default. You should use {@code http://} URIs only when creating links from a web -page.</p> +<p class="note"><strong>Note:</strong> If you create a link to open Android Market from your web +site and the user selects it from an Android-powered device, the device's Market application will +resolve the link so the user can use the Market application instead of opening the web +site. As such, you should always use {@code http://market.android.com/} URIs when creating a link on +a web page. When pointing to your apps from within your Android app, use the +{@code market://} URIs in an intent, so that the Market application always opens.</p> <h3 id="OpeningDetails">Opening an app's details page</h3> @@ -209,22 +204,23 @@ the application description, screenshots, reviews and more, and choose to instal <p style="margin-left:2em"><code><URI_prefix><b>details?id=</b><package_name></code></p> -<p>The <code><package_name></code> is a placeholder for the target application's fully -qualified package name, as declared in the <a +<p>The <code><package_name></code> is a placeholder for the target application's +fully-qualified package name, as declared in the <a href="{@docRoot}guide/topics/manifest/manifest-element.html#package">{@code package}</a> attribute of the <a href="{@docRoot}guide/topics/manifest/manifest-element.html">{@code -<manifest>}</a> element in the application's manifest file.</p> +<manifest>}</a> element.</p> -<h4>Opening details in the Android Market application</h4> +<h4>Opening the app details page from your Android app</h4> -<p>To open the details page in the Android Market application, create an intent with the -{@link android.content.Intent#ACTION_VIEW} action and include a data URI in this format:</p> +<p>To open the Android Market details page from your application, +create an intent with the {@link android.content.Intent#ACTION_VIEW} action and include a data URI +in this format:</p> <p style="margin-left:2em"><code>market://details?id=<package_name></code></p> -<p>For example, here's how you can create an intent and open an application's details page in the -Android Market application:</p> +<p>For example, here's how you can create an intent and open an application's details page in +Android Market:</p> <pre> Intent intent = new Intent(Intent.ACTION_VIEW); @@ -232,23 +228,30 @@ intent.setData(Uri.parse("market://details?id=com.android.example")); startActivity(intent); </pre> +<p>This will open the Android Market application on the device to view the {@code +com.android.example} application.</p> + -<h4>Opening details on the Android Market web site</h4> +<h4>Opening the app details page from a web site</h4> -<p>To open the details page on the Android Market web site, create a link with a URI in this +<p>To open the details page from your web site, create a link with a URI in this format:</p> <p style="margin-left:2em"> <code>http://market.android.com/details?id=<package_name></code> </p> -<p>For example, here's a link that opens an application's details page on the Android Market web -site:</p> +<p>For example, here's a link that opens an application's details page on Android Market:</p> <pre> <a href="http://market.android.com/details?id=com.android.example">App Link</a> </pre> +<p>When clicked from a desktop web browser, this opens the Android Market web site to view the +{@code com.android.example} application. When clicked from an Android-powered device, users are +given the option to use either their web browser or the Android Market application to view the +application.</p> + <h3 id="PerformingSearch">Performing a search</h3> @@ -274,9 +277,9 @@ by the publisher name: </ul> -<h4>Searching the Android Market application</h4> +<h4>Searching from your Android app</h4> -<p>To perform a search in the Android Market application, create an intent with the +<p>To initiate a search on Android Market from your application, create an intent with the {@link android.content.Intent#ACTION_VIEW} action and include a data URI in this format:</p> <p style="margin-left:2em"><code>market://search?q=<query></code></p> @@ -292,13 +295,13 @@ intent.setData(Uri.parse("market://search?q=pub:Your Publisher Name")); startActivity(intent); </pre> -<p>The search result shows all applications published by the publisher and which are compatible with -the current device.</p> +<p>This opens the Android Market application to perform the search. The search result shows all +applications published by the publisher that are compatible with the current device.</p> -<h4>Searching the Android Market web site</h4> +<h4>Searching from a web site</h4> -<p>To perform a search on the Android Market web site, create a link with a URI in this +<p>To initiate a search on Android Market from your web site, create a link with a URI in this format:</p> <p style="margin-left:2em"> @@ -307,26 +310,31 @@ format:</p> <p>The query may include the {@code pub:} parameter described above.</p> -<p>For example, here's a link that initiates a search on the Android Market web site, based on the +<p>For example, here's a link that initiates a search on Android Market, based on the publisher name:</p> <pre> <a href="http://market.android.com/search?q=pub:Your Publisher Name">Search Link</a> </pre> -<p>The search result shows all applications published by the publisher.</p> +<p>When clicked from a desktop web browser, this opens the Android Market web site and performs the +search. When clicked from an Android-powered device, users are given the option to use either their +web browser or the Android Market application to perform the search.</p> <h3 id="BuildaButton">Build an Android Market button</h3> -<p>Use the following form to input either your application's package name or your publisher name -and generate a button that you can use on your web site. The button will take users to Android -Market to view your application details or view a list of all applications you've published.</p> +<p>Use the following form to generate an "Available in Android Market" button that you can use on +your web site. Input either your application's package name or publisher name and the button will +take users to Android Market to either view your application's information or view a list of +your published apps. If users click the button while on an Android-powered device, the Android +Market application will respond to show users your application(s).</p> -<p>This form offers four versions of the official "Available in Android Market" badge at -recommended sizes. If you would like to create a different size, you can download an EPS file for -the badges from the <a href="http://www.android.com/branding.html">Android Brand Guidelines</a>.</p> +<p>This form offers four versions of the official "Available in Android Market" button at +recommended sizes. If you want to create a different size, you can download an EPS file for +the button images from the <a href="http://www.android.com/branding.html">Android Brand +Guidelines</a>.</p> <style type="text/css"> @@ -548,4 +556,3 @@ the web and in the Android application), as discussed in the previous sections.< </tr> </table> - diff --git a/docs/html/guide/topics/graphics/animation.jd b/docs/html/guide/topics/graphics/animation.jd index 31e7c4b..e7a07e0 100644 --- a/docs/html/guide/topics/graphics/animation.jd +++ b/docs/html/guide/topics/graphics/animation.jd @@ -12,28 +12,33 @@ parent.link=index.html <ol> <li><a href="#how">How property animation works</a></li> </ol> - </li> + </li> + + <li><a href="#value-animator">Animating with ValueAnimator</a></li> - <li><a href="#value-animator">Animating with ValueAnimator</a></li> + <li><a href="#object-animator">Animating with ObjectAnimator</a></li> - <li><a href="#object-animator">Animating with ObjectAnimator</a></li> + <li><a href="#choreography">Choreographing Multiple Animations with + AnimatorSet</a></li> - <li><a href="#choreography">Choreographing Multiple Animations with - AnimatorSet</a></li> - - <li><a href="#listeners">Animation Listeners</a></li> + <li><a href="#listeners">Animation Listeners</a></li> - <li><a href="#type-evaluator">Using a TypeEvaluator</a></li> + <li><a href="#type-evaluator">Using a TypeEvaluator</a></li> - <li><a href="#interpolators">Using Interpolators</a></li> + <li><a href="#interpolators">Using Interpolators</a></li> - <li><a href="#keyframes">Specifying Keyframes</a></li> - <li><a href="#layout">Animating Layout Changes to ViewGroups</a></li> + <li><a href="#keyframes">Specifying Keyframes</a></li> - <li><a href="#views">Animating Views</a></li> + <li><a href="#layout">Animating Layout Changes to ViewGroups</a></li> - <li><a href="#declaring-xml">Declaring Animations in XML</a></li> - </ol> + <li><a href="#views">Animating Views</a> + <ol> + <li><a href="#view-prop-animator">ViewPropertyAnimator</a></li> + </ol> + </li> + + <li><a href="#declaring-xml">Declaring Animations in XML</a></li> + </ol> <h2>Key classes</h2> @@ -63,13 +68,13 @@ parent.link=index.html You can define an animation to change any object property over time, regardless of whether it draws to the screen or not.The property animation system also has a few advantages over the view animation system, which makes it more flexible to use.</p> - + <p>The view animation system provides the capability to only animate View objects, so if you wanted to animate non-View objects, you had to implement your own code to do so. The view animation system also was constrained in the fact that it only exposed a few aspects of a View object to animate, such as the scaling and rotation of a View but not the background color for instance.</p> - + <p>Another disadvantage of the view animation system is that it only modified where the View was drawn, and not the actual View itself. For instance, if you animated a button to move across the screen, the button draws correctly, but the actual location where you can click the @@ -80,7 +85,7 @@ parent.link=index.html <p>The view animation system, however, takes less time to setup and requires less code to write. If view animation accomplishes everything that you need to do, or if your existing code already works the way you want, there is no need to use the property animation system.</p> - + <p class="note"><strong>Tip:</strong> To see how the ADT layout editor allows you to develop and preview animations in your layout, watch the <a href="http://www.youtube.com/watch?v=Oq05KqjXTvs&feature=player_detailpage#t=1709s">Android @@ -114,7 +119,7 @@ Developer Tools session</a> from Google I/O '11</p> default is set to refresh every 10 ms, but the speed in which your application can refresh frames is ultimately dependent on how busy the system is overall and how fast the system can service the underlying timer.</li> </ul> - + <h3 id="how">How the property animation system works</h3> @@ -254,7 +259,7 @@ Developer Tools session</a> from Google I/O '11</p> </tr> </table> - + <p>Evaluators tell the property animation system how to calculate values for a given property. They take the timing data that is provided by an {@link android.animation.Animator} class, the animation's start and end value, and calculate the animated values of the property @@ -299,9 +304,9 @@ Developer Tools session</a> from Google I/O '11</p> information on how to write a custom evaluator.</td> </tr> </table> - - - + + + <p>A time interpolator defines how specific values in an animation are calculated as a function of time. For example, you can specify animations to happen linearly across the whole @@ -397,7 +402,7 @@ Developer Tools session</a> from Google I/O '11</p> <pre> ValueAnimator animation = ValueAnimator.ofFloat(0f, 1f); animation.setDuration(1000); -animation.start(); +animation.start(); </pre> <p>In this code, the {@link android.animation.ValueAnimator} starts calculating the values of the @@ -408,7 +413,7 @@ animation.start(); <pre> ValueAnimator animation = ValueAnimator.ofObject(new MyTypeEvaluator(), startPropertyValue, endPropertyValue); animation.setDuration(1000); -animation.start(); +animation.start(); </pre> <p>In this code, the {@link android.animation.ValueAnimator} starts calculating the values of the @@ -483,7 +488,7 @@ ObjectAnimator.ofFloat(targetObject, "propName", 1f) <li>Depending on what property or object you are animating, you might need to call the {@link android.view.View#invalidate invalidate()} method on a View force the screen to redraw itself with the - updated animated values. You do this in the + updated animated values. You do this in the {@link android.animation.ValueAnimator.AnimatorUpdateListener#onAnimationUpdate onAnimationUpdate()} callback. For example, animating the color property of a Drawable object only cause updates to the screen when that object redraws itself. All of the property setters on View, such as @@ -492,7 +497,7 @@ ObjectAnimator.ofFloat(targetObject, "propName", 1f) methods with new values. For more information on listeners, see the section about <a href="#listeners">Animation Listeners</a>. </li> </ul> - + <h2 id="choreography">Choreographing Multiple Animations with AnimatorSet</h2> <p>In many cases, you want to play an animation that depends on when another animation starts or @@ -576,12 +581,12 @@ You can listen for important events during an animation's duration with the list {@link android.view.View#invalidate invalidate()} on a View to force that area of the screen to redraw itself with the new animated values. For example, animating the color property of a Drawable object only cause updates to the screen when that object - redraws itself. All of the property setters on View, + redraws itself. All of the property setters on View, such as {@link android.view.View#setAlpha setAlpha()} and {@link android.view.View#setTranslationX setTranslationX()} invalidate the View properly, so you do not need to invalidate the View when calling these methods with new values. </p> - + </li> </ul> </li> @@ -658,7 +663,7 @@ public void onAnimationEnd(Animator animation) { android:layout_width="wrap_content" android:layout_height="match_parent" android:id="@+id/verticalContainer" - android:animateLayoutChanges="true" /> + android:animateLayoutChanges="true" /> </pre> <p>Setting this attribute to true automatically animates Views that are added or removed from the @@ -872,16 +877,55 @@ rotationAnim.setDuration(5000ms); ObjectAnimator.ofFloat(myView, "rotation", 0f, 360f); </pre> -For more information on creating animators, see the sections on animating with -<a href="#value-animator">ValueAnimator</a> and <a href="#object-animator">ObjectAnimator</a> +<p>For more information on creating animators, see the sections on animating with +<a href="#value-animator">ValueAnimator</a> and <a href="#object-animator">ObjectAnimator</a>. +</p> +<h3 id="view-prop-animator">Animating with ViewPropertyAnimator</h3> +<p>The {@link android.view.ViewPropertyAnimator} provides a simple way to animate several +properties of a {@link android.view.View} in parallel, using a single underlying {@link +android.animation.Animator} +object. It behaves much like an {@link android.animation.ObjectAnimator}, because it modifies the +actual values of the view's properties, but is more efficient when animating many properties at +once. In addition, the code for using the {@link android.view.ViewPropertyAnimator} is much +more concise and easier to read. The following code snippets show the differences in using multiple +{@link android.animation.ObjectAnimator} objects, a single +{@link android.animation.ObjectAnimator}, and the {@link android.view.ViewPropertyAnimator} when +simultaneously animating the <code>x</code> and <code>y</code> property of a view.</p> + +<p><strong>Multiple ObjectAnimator objects</strong></p> +<pre> +ObjectAnimator animX = ObjectAnimator.ofFloat(myView, "x", 50f); +ObjectAnimator animY = ObjectAnimator.ofFloat(myView, "y", 100f); +AnimatorSet animSetXY = new AnimatorSet(); +animSetXY.playTogether(animX, animY); +animSetXY.start(); +</pre> + +<p><strong>One ObjectAnimator</strong></p> +<pre> +PropertyValuesHolder pvhX = PropertyValuesHolder.ofFloat("x", 50f); +PropertyValuesHolder pvhY = PropertyValuesHolder.ofFloat("y", 100f); +ObjectAnimator.ofPropertyValuesHolder(myView, pvhX, pvyY).start(); +</pre> + +<p><strong>ViewPropertyAnimator</strong></p> +<pre> +myView.animate().x(50f).y(100f); +</pre> + +<p> +For more detailed information about {@link +android.view.ViewPropertyAnimator}, see the corresponding Android Developers +<a href="http://android-developers.blogspot.com/2011/05/introducing-viewpropertyanimator.html">blog +post</a>.</p> <h2 id="declaring-xml">Declaring Animations in XML</h2> <p>The property animation system lets you declare property animations with XML instead of doing it programmatically. By defining your animations in XML, you can easily reuse your animations in multiple activities and more easily edit the animation sequence.</p> - + <p>To distinguish animation files that use the new property animation APIs from those that use the legacy <a href="{@docRoot}guide/topics/graphics/view-animation.html">view animation</a> framework, starting with Android 3.1, you should save the XML files for property animations in the {@code diff --git a/docs/html/guide/topics/manifest/activity-element.jd b/docs/html/guide/topics/manifest/activity-element.jd index 743832c..b2a78fe 100644 --- a/docs/html/guide/topics/manifest/activity-element.jd +++ b/docs/html/guide/topics/manifest/activity-element.jd @@ -28,7 +28,9 @@ parent.link=manifest-intro.html android:<a href="#proc">process</a>="<i>string</i>" android:<a href="#screen">screenOrientation</a>=["unspecified" | "user" | "behind" | "landscape" | "portrait" | - "sensor" | "nosensor"] + "reverseLandscape" | "reversePortrait" | + "sensorLandscape" | "sensorPortrait" | + "sensor" | "fullSensor" | "nosensor"] android:<a href="#state">stateNotNeeded</a>=["true" | "false"] android:<a href="#aff">taskAffinity</a>="<i>string</i>" android:<a href="#theme">theme</a>="<i>resource or theme</i>" @@ -589,29 +591,54 @@ The value can be any one of the following strings: uses, and therefore the choices made in specific contexts, may differ from device to device.</td> </tr><tr> + <td>"{@code user}"</td> + <td>The user's current preferred orientation.</td> +</tr><tr> + <td>"{@code behind}"</td> + <td>The same orientation as the activity that's immediately beneath it in + the activity stack.</td> +</tr><tr> <td>"{@code landscape}"</td> <td>Landscape orientation (the display is wider than it is tall).</td> </tr><tr> <td>"{@code portrait}"</td> <td>Portrait orientation (the display is taller than it is wide).</td> </tr><tr> - <td>"{@code user}"</td> - <td>The user's current preferred orientation.</td> + <td>"{@code reverseLandscape}"</td> + <td>Landscape orientation in the opposite direction from normal landscape. +<em>Added in API level 9.</em></td> </tr><tr> - <td>"{@code behind}"</td> - <td>The same orientation as the activity that's immediately beneath it in - the activity stack.</td> + <td>"{@code reversePortrait}"</td> + <td>Portrait orientation in the opposite direction from normal portrait. +<em>Added in API level 9.</em></td> +</tr><tr> + <td>"{@code sensorLandscape}"</td> + <td>Landscape orientation, but can be either normal or reverse landscape based on the device +sensor. +<em>Added in API level 9.</em></td> +</tr><tr> + <td>"{@code sensorPortrait}"</td> + <td>Portrait orientation, but can be either normal or reverse portrait based on the device +sensor. +<em>Added in API level 9.</em></td> </tr><tr> <td>"{@code sensor}"</td> - <td>The orientation determined by a physical orientation sensor. The - orientation of the display depends on how the user is holding the device; - it changes when the user rotates the device.</td> + <td>The orientation is determined by the device orientation sensor. The orientation of the +display depends on how the user is holding the device; it changes when the user rotates the +device. Some devices, though, will not rotate to all four possible orientations, by default. To +allow all four orientations, use {@code "fullSensor"}.</td> +</tr><tr> + <td>"{@code fullSensor}"</td> + <td>The orientation is determined by the device orientation sensor for any of the 4 orientations. +This is similar to {@code "sensor"} except this allows any of the 4 possible screen orientations, +regardless of what the device will normally do (for example, some devices won't normally use reverse +portrait or reverse landscape, but this enables those). <em>Added in API level 9.</em></td> </tr><tr> <td>"{@code nosensor}"</td> - <td>An orientation determined without reference to a physical orientation sensor. - The sensor is ignored, so the display will not rotate based on how the user - moves the device. Except for this distinction, the system chooses the - orientation using the same policy as for the "{@code unspecified}" setting.</td> + <td>The orientation is determined without reference to a physical orientation sensor. The sensor +is ignored, so the display will not rotate based on how the user moves the device. Except for this +distinction, the system chooses the orientation using the same policy as for the "{@code +unspecified}" setting.</td> </tr> </table></dd> diff --git a/docs/html/guide/topics/manifest/supports-screens-element.jd b/docs/html/guide/topics/manifest/supports-screens-element.jd index 605a2bb..81d6e27 100644 --- a/docs/html/guide/topics/manifest/supports-screens-element.jd +++ b/docs/html/guide/topics/manifest/supports-screens-element.jd @@ -8,15 +8,15 @@ parent.link=manifest-intro.html <dt>syntax:</dt> <dd> <pre class="stx"> -<supports-screens android:<a href="#requiresSmallest">requiresSmallestWidthDp</a>="<em>integer</em>" - android:<a href="#compatibleWidth">compatibleWidthLimitDp</a>="<em>integer</em>" - android:<a href="#largestWidth">largestWidthLimitDp</a>="<em>integer</em>" - android:<a href="#resizeable">resizeable</a>=["true"| "false"] +<supports-screens android:<a href="#resizeable">resizeable</a>=["true"| "false"] android:<a href="#small">smallScreens</a>=["true" | "false"] android:<a href="#normal">normalScreens</a>=["true" | "false"] android:<a href="#large">largeScreens</a>=["true" | "false"] android:<a href="#xlarge">xlargeScreens</a>=["true" | "false"] - android:<a href="#any">anyDensity</a>=["true" | "false"] /> + android:<a href="#any">anyDensity</a>=["true" | "false"] + android:<a href="#requiresSmallest">requiresSmallestWidthDp</a>="<em>integer</em>" + android:<a href="#compatibleWidth">compatibleWidthLimitDp</a>="<em>integer</em>" + android:<a href="#largestWidth">largestWidthLimitDp</a>="<em>integer</em>"/> </pre> </dd> @@ -24,37 +24,38 @@ parent.link=manifest-intro.html <dd><code><a href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a></code></dd> <dt>description:</dt> -<dd>Lets you specify the screen sizes your application supports and enable screen -compatibility mode for screens larger than what your application supports. By default, a modern -application (using API Level 4 or higher) supports all screen sizes; older applications are assumed -to support only the "normal" screen size. Screen size is determined by the number of pixels on the -screen after the system accounts for screen density scaling. +<dd>Lets you specify the screen sizes your application supports and enable <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a> for screens +larger than what your application supports. It's important that you always use this element in your +application to specify the screen sizes your application supports. <p>An application "supports" a given screen size if it resizes properly to fill the entire screen. -By default, the system resizes your application UI to fill the screen if you have set -either <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code -minSdkVersion}</a> or <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code -targetSdkVersion}</a> to {@code "4"} or higher. Normal resizing works well for most applications and -you don't have to do any extra work to make your application work on screens larger than a -handset device.</p> - -<p>In addition to allowing the system to resize your application to fit the current screen, you can -optimize your UI for different screen sizes by providing <a +Normal resizing applied by the system works well for most applications and you don't have to do any +extra work to make your application work on screens larger than a handset device. However, it's +often important that you optimize your application's UI for different screen sizes by providing <a href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">alternative -layout resources</a> for different sizes. For instance, you might want to modify the layout -of an activity when it is on a tablet or similar device that has an <em>xlarge</em> screen.</p> - -<p>However, if your application does not work well when resized to fit different screen sizes, -you can use the attributes of the {@code <supports-screens>} element to control whether -your application should be distributed to smaller screens or have its UI scaled up to fit larger -screens using the system's screen compatibility mode. When you have not designed for larger screen -sizes and the normal resizing does not achieve the appropriate results, <em>screen compatibility -mode</em> will scale your UI by emulating a <em>normal</em> size screen and then zooming in on it so -that it fills the entire screen—thus achieving the same layout as a normal handset device on -the large screen (but this usually causes pixelation and blurring of your UI).</p> +layout resources</a>. For instance, you might want to modify the layout of an activity +when it is on a tablet compared to when running on a handset device.</p> + +<p>However, if your application does not work well when resized to fit different screen sizes, you +can use the attributes of the {@code <supports-screens>} element to control whether your +application should be distributed to smaller screens or have its UI scaled up ("zoomed") to fit +larger screens using the system's <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a>. When you +have not designed for larger screen sizes and the normal resizing does not achieve the appropriate +results, screen compatibility mode will scale your UI by emulating a <em>normal</em> size +screen and medium density, then zooming in so that it fills the entire screen. Beware that this +causes pixelation and blurring of your UI, so it's better if you optimize your UI for large +screens.</p> + +<p class="note"><strong>Note:</strong> Android 3.2 introduces new attributes: {@code +android:requiresSmallestWidthDp}, {@code android:compatibleWidthLimitDp}, and {@code +android:largestWidthLimitDp}. If you're developing your application for Android 3.2 and higher, +you should use these attributes to declare your screen size support, instead of the attributes +based on generalized screen sizes.</p> <p>For more information about how to properly support different screen sizes so that you can avoid -using screen compatibility mode, read +using screen compatibility mode with your application, read <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a>.</p> @@ -62,17 +63,90 @@ using screen compatibility mode, read <dd> <dl class="attr"> + + <dt><a name="resizeable"></a>{@code android:resizeable}</dt> + <dd>Indicates whether the application is resizeable for different screen sizes. This attribute is +true, by default. If set false, the system will run your application in <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a> on large +screens.</p> + + <p><strong>This attribute is deprecated</strong>. It was introduced to help applications +transition from Android 1.5 to 1.6, when support for multiple screens was first introduced. You +should not use it.</p> + </dd> + + <dt><a name="small"></a>{@code android:smallScreens}</dt> + <dd>Indicates whether the application supports smaller screen form-factors. + A small screen is defined as one with a smaller aspect ratio than + the "normal" (traditional HVGA) screen. An application that does + not support small screens <em>will not be available</em> for + small screen devices from external services (such as Android Market), because there is little +the platform can do to make such an application work on a smaller screen. This is {@code "true"} by +default. + </dd> + + <dt><a name="normal"></a>{@code android:normalScreens}</dt> + <dd>Indicates whether an application supports the "normal" screen + form-factors. Traditionally this is an HVGA medium density + screen, but WQVGA low density and WVGA high density are also + considered to be normal. This attribute is "true" by default. + </dd> + + <dt><a name="large"></a>{@code android:largeScreens}</dt> + <dd>Indicates whether the application supports larger screen form-factors. + A large screen is defined as a screen that is significantly larger + than a "normal" handset screen, and thus might require some special care + on the application's part to make good use of it, though it may rely on resizing by the +system to fill the screen. + <p>The default value for this actually varies between some versions, so it's better if +you explicitly declare this attribute at all times. Beware that setting it "false" will +generally enable <a href="{@docRoot}guide/practices/screen-compat-mode.html">screen +compatibility mode</a>.</p> + </dd> + + <dt><a name="xlarge"></a>{@code android:xlargeScreens}</dt> + <dd>Indicates whether the application supports extra large screen form-factors. + An xlarge screen is defined as a screen that is significantly larger + than a "large" screen, such as a tablet (or something larger) and may require special care + on the application's part to make good use of it, though it may rely on resizing by the +system to fill the screen. + <p>The default value for this actually varies between some versions, so it's better if +you explicitly declare this attribute at all times. Beware that setting it "false" will +generally enable <a href="{@docRoot}guide/practices/screen-compat-mode.html">screen +compatibility mode</a>.</p> + <p>This attribute was introduced in API level 9.</p> + </dd> + + <dt><a name="any"></a>{@code android:anyDensity}</dt> + <dd>Indicates whether the application includes resources to accommodate any screen + density. + <p>For applications that support Android 1.6 (API level 4) and higher, this is "true" +by default and <strong>you should not set it "false"</strong> unless you're absolutely certain that +it's necessary for your application to work. The only time it might be necessary to disable this +is if your app directly manipulates bitmaps (see the <a +href="{@docRoot}guide/practices/screens_support.html#DensityConsiderations">Supporting Multiple +Screens</a> document for more information).</p> + </dd> <dt id="requiresSmallest">{@code android:requiresSmallestWidthDp}</dt> - <dd>This attribute specifies the minimum "smallest screen width" with which your -application is compatible. In order for a device to be considered compatible with your -application, the shortest side of the available screen space must be equal to or greater than this -value. -<p>The width against which your value is compared takes into account screen decorations and system -UI. For example, if the device has some persistent UI elements on the left or right edge of the -display, the system declares the device's available width as one that is smaller than the actual -screen size, accounting for these UI elements because those are screen pixels not available for your -UI. Thus, the value you use should be the actual smallest width required by your layout.</p> + <dd>Specifies the minimum smallestWidth required. The smallestWidth is the shortest dimension of +the screen space (in {@code dp} units) that must be available to your application UI—that is, +the shortest of the available screen's two dimensions. So, in order for a device to be considered +compatible with your application, the device's smallestWidth must be equal to or greater than this +value. (Usually, the value you supply for this is the "smallest width" that your layout supports, +regardless of the screen's current orientation.) + + <p>For example, a typical handset screen has a smallestWidth of 320dp, a 7" tablet has a +smallestWidth of 600dp, and a 10" tablet has a smallestWidth of 720dp. These values are generally +the smallestWidth because they are the shortest dimension of the screen's available space.</p> + +<p>The size against which your value is compared takes into account screen decorations and system +UI. For example, if the device has some persistent UI elements on the display, the system declares +the device's smallestWidth as one that is smaller than the actual screen size, accounting for these +UI elements because those are screen pixels not available for your UI. Thus, the value you use +should be the minimum width required by your layout, regardless of the screen's current +orientation.</p> + <p>If your application properly resizes for smaller screen sizes (down to the <em>small</em> size or a minimum width of 320dp), you do not need to use this attribute. Otherwise, you should use a value for this attribute that @@ -80,12 +154,14 @@ matches the smallest value used by your application for the <a href="{@docRoot}guide/topics/resources/providing-resources.html#SmallestScreenWidthQualifier"> smallest screen width qualifier</a> ({@code sw<N>dp}).</p> -<p>For example, a typical handset screen has a minimum width of 320dp, a 7" tablet has a minimum -width of 600dp, and a 10" tablet has a minimum width of 720dp. If the smallest available screen -width on a device is less than the value you supply here, then the application is considered -incompatible with that -device. External services such as Android Market use this to determine whether a device -is compatible with your application and prevent incompatible devices from installing it.</p> + <p class="caution"><strong>Caution:</strong> The Android system does not pay attention to this +attribute, so it does not affect how your application behaves at runtime. Instead, it is used +to enable filtering for your application on services such as Android Market. However, +<strong>Android Market currently does not support this attribute for filtering</strong> (on Android +3.2), so you should continue using the other size attributes if your application does not support +small screens.</p> + +<!-- <p>Beginning with Android 3.2 (API level 13), using this attribute is the preferred way to specify the minimum screen size your application requires, instead of using the other attributes for small, normal, large, and xlarge screens. The advantage of using this attribute is that you @@ -95,29 +171,32 @@ to properly display its UI, rather than relying on the generalized size groups.< <code><a href="#small">smallScreens</a></code>, <code><a href="#normal">normalScreens</a></code>, <code><a href="#large">largeScreens</a></code>, or <code><a href="#xlarge">xlargeScreens</a></code> attributes are used instead to determine the smallest screen required.</p> +--> <p>This attribute was introduced in API level 13.</p> </dd> <dt id="compatibleWidth">{@code android:compatibleWidthLimitDp}</dt> - <dd>This attribute allows you to enable screen compatibility mode as a user-optional feature by -specifying the maximum "smallest screen width" for which your application is designed. If the value -you supply here is less than the shortest side of the available screen space, users can still -install your application, but are offered to run it in screen compatibility mode. By default, screen -compatibility mode is disabled and your layout is resized to fit the screen as usual, but a -button is available in the system bar that allows the user to toggle screen compatibility mode on -and off. + <dd>This attribute allows you to enable <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a> as a +user-optional feature by specifying the maximum "smallest screen width" for which your application +is designed. If the smallest side of a device's available screen is greater than your value here, +users can still install your application, but are offered to run it in screen compatibility mode. By +default, screen compatibility mode is disabled and your layout is resized to fit the screen as +usual, but a button is available in the system bar that allows the user to toggle screen +compatibility mode on and off. <p>If your application is compatible with all screen sizes and its layout properly resizes, you do not need to use this attribute.</p> - <p class="note"><strong>Note:</strong> Currently, screen compatibility mode only emulates handset + <p class="note"><strong>Note:</strong> Currently, screen compatibility mode emulates only handset screens with a 320dp width, so screen compatibility mode is not applied if your value for {@code android:compatibleWidthLimitDp} is larger than 320.</p> <p>This attribute was introduced in API level 13.</p> </dd> <dt id="largestWidth">{@code android:largestWidthLimitDp}</dt> - <dd>This attribute allows you to force enable screen compatibility mode by specifying the maximum -"smallest screen width" for which your application is designed. If the value you supply here is less -than the shortest side of the available screen space, the application runs in screen + <dd>This attribute allows you to force-enable <a +href="{@docRoot}guide/practices/screen-compat-mode.html">screen compatibility mode</a> by specifying +the maximum "smallest screen width" for which your application is designed. If the smallest side of +a device's available screen is greater than your value here, the application runs in screen compatibility mode with no way for the user to disable it. <p>If your application is compatible with all screen sizes and its layout properly resizes, you do not need to use this attribute. Otherwise, you should first consider using the <a @@ -125,102 +204,11 @@ href="#compatibleWidth">{@code android:compatibleWidthLimitDp}</a> attribute. Yo {@code android:largestWidthLimitDp} attribute only when your application is functionally broken when resized for larger screens and screen compatibility mode is the only way that users should use your application.</p> - <p class="note"><strong>Note:</strong> Currently, screen compatibility mode only emulates handset + <p class="note"><strong>Note:</strong> Currently, screen compatibility mode emulates only handset screens with a 320dp width, so screen compatibility mode is not applied if your value for {@code android:largestWidthLimitDp} is larger than 320.</p> <p>This attribute was introduced in API level 13.</p> </dd> - - <dt><a name="resizeable"></a>{@code android:resizeable}</dt> - <dd>Indicates whether the application is resizeable for different screen sizes. This attribute is -true, by default, if you have set either <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> or <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> to -{@code "4"} or higher. Otherwise, it is false by default. If set false, the system will not resize -your application when run on <em>large</em> or <em>xlarge</em> screens. Instead, the -application appears in a "postage stamp" that equals the <em>normal</em> screen size that your -application does support. This is less than an ideal experience for users, because the -application appears smaller than the available screen, but it might help your application run -normally if it were designed only for the <em>normal</em> screen size and some behaviors do not work -when resized.</p> - <p>To provide the best experience on all screen sizes, you should allow resizing and, if your -application does not work well on larger screens, follow the guide to <a -href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a> to enable -additional screen support.</p> - <p><strong>This attribute is deprecated</strong> as of API level 13.</p> - </dd> - - - <dt><a name="small"></a>{@code android:smallScreens}</dt> - <dd>Indicates whether the application supports smaller screen form-factors. - A small screen is defined as one with a smaller aspect ratio than - the "normal" (traditional HVGA) screen. An application that does - not support small screens <em>will not be available</em> for - small screen devices from external services (such as Android Market), because there is little -the platform can do - to make such an application work on a smaller screen. If the application has set either <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> or <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> to -{@code "4"} or higher, -the default value for this is {@code "true"}, any value less than {@code "4"} results in this set to -{@code "false"}. - <p><strong>This attribute is deprecated</strong> as of API level 13.</p> - </dd> - - <dt><a name="normal"></a>{@code android:normalScreens}</dt> - <dd>Indicates whether an application supports the "normal" screen - form-factors. Traditionally this is an HVGA medium density - screen, but WQVGA low density and WVGA high density are also - considered to be normal. This attribute is "true" by default, - and applications currently should leave it that way. - <p><strong>This attribute is deprecated</strong> as of API level 13.</p> - </dd> - - <dt><a name="large"></a>{@code android:largeScreens}</dt> - <dd>Indicates whether the application supports larger screen form-factors. - A large screen is defined as a screen that is significantly larger - than a "normal" handset screen, and thus might require some special care - on the application's part to make good use of it, though it may rely on resizing by the -system to fill the screen. If the application has set either <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> or <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> to -{@code "4"} or higher, -the default value for this is {@code "true"}, any value less than {@code "4"} results in this set to -{@code "false"}. - <p><strong>This attribute is deprecated</strong> as of API level 13.</p> - </dd> - - <dt><a name="xlarge"></a>{@code android:xlargeScreens}</dt> - <dd>Indicates whether the application supports extra large screen form-factors. - An xlarge screen is defined as a screen that is significantly larger - than a "large" screen, such as a tablet (or something larger) and may require special care - on the application's part to make good use of it, though it may rely on resizing by the -system to fill the screen. If the application has set either <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> or <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> to -{@code "4"} or higher, -the default value for this is {@code "true"}, any value less than {@code "4"} results in this set to -{@code "false"}. - <p>This attribute was introduced in API level 9.</p> - <p><strong>This attribute is deprecated</strong> as of API level 13.</p> - </dd> - - <dt><a name="any"></a>{@code android:anyDensity}</dt> - <dd>Indicates whether the application includes resources to accommodate any screen - density. Older applications (before API Level 4) are assumed unable to - accomodate all densities and this is {@code "false"} by default. If the application has set -either <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code minSdkVersion}</a> or <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code targetSdkVersion}</a> to -{@code "4"} or higher, -the default value for this is {@code "true"}. Otherwise, it is {@code "false"}. - You can explicitly supply your abilities here. - <p>Based on the "standard" device screen density (medium dpi), the Android framework will scale -down application assets by a factor of 0.75 (low dpi screens) or scale them up by a factor of 1.5 -(high dpi screens), when you don't provide alternative resources for a specifc screen density. The -screen density is expressed as dots-per-inch (dpi).</p> - <p><strong>This attribute is deprecated</strong> as of API level 13.</p> - </dd> </dl></dd> diff --git a/docs/html/guide/topics/resources/animation-resource.jd b/docs/html/guide/topics/resources/animation-resource.jd index 3df669c..480ca78 100644 --- a/docs/html/guide/topics/resources/animation-resource.jd +++ b/docs/html/guide/topics/resources/animation-resource.jd @@ -10,8 +10,8 @@ parent.link=available-resources.html <li><a href="#Property">Property Animation</a></li> <li><a href="#View">View Animation</a> <ol> - <li><a href="Tween">Tween animation</li> - <li><a href="Frame">Frame animation</li> + <li><a href="Tween">Tween animation</a></li> + <li><a href="Frame">Frame animation</a></li> </ol> </li> </ol> diff --git a/docs/html/guide/topics/resources/drawable-resource.jd b/docs/html/guide/topics/resources/drawable-resource.jd index 89c85e2..912b6fd 100644 --- a/docs/html/guide/topics/resources/drawable-resource.jd +++ b/docs/html/guide/topics/resources/drawable-resource.jd @@ -1418,7 +1418,7 @@ bound. The value's format is XX%. For instance: 100%, 12.5%, etc.</dd> The filename is used as the resource ID.</dd> <dt>compiled resource datatype:</dt> -<dd>Resource pointer to a {@link android.graphics.drawable.ShapeDrawable}.</dd> +<dd>Resource pointer to a {@link android.graphics.drawable.GradientDrawable}.</dd> <dt>resource reference:</dt> @@ -1458,9 +1458,7 @@ In XML: <code>@[<em>package</em>:]drawable/<em>filename</em></code> android:bottom="<em>integer</em>" /> <<a href="#size-element">size</a> android:width="<em>integer</em>" - android:color="<em>color</em>" - android:dashWidth="<em>integer</em>" - android:dashGap="<em>integer</em>" /> + android:height="<em>integer</em>" /> <<a href="#solid-element">solid</a> android:color="<em>color</em>" /> <<a href="#stroke-element">stroke</a> diff --git a/docs/html/guide/topics/resources/providing-resources.jd b/docs/html/guide/topics/resources/providing-resources.jd index ea778c1..252c153 100644 --- a/docs/html/guide/topics/resources/providing-resources.jd +++ b/docs/html/guide/topics/resources/providing-resources.jd @@ -334,7 +334,7 @@ indicates the current locale.</p> </td> </tr> <tr id="SmallestScreenWidthQualifier"> - <td>Smallest screen width</td> + <td>smallestWidth</td> <td><code>sw<N>dp</code><br/><br/> Examples:<br/> <code>sw320dp</code><br/> @@ -343,18 +343,23 @@ indicates the current locale.</p> etc. </td> <td> - <p>Specifies the "smallest width" in {@code dp} units that must be available to your - application in order for the resources to be used, regardless of the screen's current - orientation. For example, if your layout requires that its shortest side be at least 600 - dp in length at all times, then you can use this to create the layout resources, {@code - res/layout-sw600dp/}, and the system will use them only when the shortest side of - available screen space it at least 600dp.</p> - <p>The width against which the system compares your value takes into account screen - decorations and system UI. For example, if the device has some persistent UI elements on the - left or right edge of the display, the system declares its own available width as one that - is smaller than the actual screen size, accounting for these UI elements because those are - screen pixels not available for your UI. Thus, the value you use should be the actual - smallest width required by your layout.</p> + <p>The fundamental size of a screen, as indicated by the shortest dimension of the available +screen area. Specifically, the device's smallestWidth is the shortest of the screen's available +height and width (you may also think of it as the "smallest possible width" for the screen). You can +use this qualifier to ensure that, regardless of the screen's current orientation, your +application's has at least {@code <N>} dps of width available for it UI.</p> + <p>For example, if your layout requires that its smallest dimension of screen area be at +least 600 dp at all times, then you can use this qualifer to create the layout resources, {@code +res/layout-sw600dp/}. The system will use these resources only when the smallest dimension of +available screen is at least 600dp, regardless of whether the 600dp side is the user-perceived +height or width. The smallestWidth is a fixed screen size characteristic of the device; <strong>the +device's smallestWidth does not change when the screen's orientation changes</strong>.</p> + <p>The smallestWidth of a device takes into account screen decorations and system UI. For +example, if the device has some persistent UI elements on the screen that account for space along +the axis of the smallestWidth, the system declares the smallestWidth to be smaller than the actual +screen size, because those are screen pixels not available for your UI. Thus, the value you use +should be the actual smallest dimension <em>required by your layout</em> (usually, this value is the +"smallest width" that your layout supports, regardless of the screen's current orientation).</p> <p>Some values you might use here for common screen sizes:</p> <ul> <li>320, for devices with screen configurations such as: @@ -369,19 +374,22 @@ indicates the current locale.</p> <li>720, for screens such as 720x1280 mdpi (10" tablet).</li> </ul> <p>When your application provides multiple resource directories with different values for - this qualifier, the system uses the one closest to (without exceeding) the smallest width - for the available space. </p> + the smallestWidth qualifier, the system uses the one closest to (without exceeding) the +device's smallestWidth. </p> <p><em>Added in API level 13.</em></p> <p>Also see the <a - href="{@docRoot}guide/topics/manifest/supports-screens-element.html#requiresSmallest">{@code - android:requiresSmallestWidthDp}</a> attribute, which declares the smallest available width - with which your application is compatible, and the {@link - android.content.res.Configuration#smallestScreenWidthDp} configuration field, which holds - the current smallest screen width for the device.</p> +href="{@docRoot}guide/topics/manifest/supports-screens-element.html#requiresSmallest">{@code +android:requiresSmallestWidthDp}</a> attribute, which declares the minimum smallestWidth with which +your application is compatible, and the {@link +android.content.res.Configuration#smallestScreenWidthDp} configuration field, which holds the +device's smallestWidth value.</p> + <p>For more information about designing for different screens and using this +qualifier, see the <a href="{@docRoot}guide/practices/screens_support.html">Supporting +Multiple Screens</a> developer guide.</p> </td> </tr> <tr id="ScreenWidthQualifier"> - <td>Screen width</td> + <td>Available width</td> <td><code>w<N>dp</code><br/><br/> Examples:<br/> <code>w720dp</code><br/> @@ -389,7 +397,7 @@ indicates the current locale.</p> etc. </td> <td> - <p>Specifies a minimum screen width, in {@code dp} units at which the resource + <p>Specifies a minimum available screen width, in {@code dp} units at which the resource should be used—defined by the <code><N></code> value. This configuration value will change when the orientation changes between landscape and portrait to match the current actual width.</p> @@ -403,10 +411,13 @@ indicates the current locale.</p> <p><em>Added in API level 13.</em></p> <p>Also see the {@link android.content.res.Configuration#screenWidthDp} configuration field, which holds the current screen width.</p> + <p>For more information about designing for different screens and using this +qualifier, see the <a href="{@docRoot}guide/practices/screens_support.html">Supporting +Multiple Screens</a> developer guide.</p> </td> </tr> <tr id="ScreenHeightQualifier"> - <td>Screen height</td> + <td>Available height</td> <td><code>h<N>dp</code><br/><br/> Examples:<br/> <code>h720dp</code><br/> @@ -414,7 +425,7 @@ indicates the current locale.</p> etc. </td> <td> - <p>Specifies a minimum screen height, in "dp" units at which the resource + <p>Specifies a minimum available screen height, in "dp" units at which the resource should be used—defined by the <code><N></code> value. This configuration value will change when the orientation changes between landscape and portrait to match the current actual height.</p> @@ -432,6 +443,9 @@ indicates the current locale.</p> <p><em>Added in API level 13.</em></p> <p>Also see the {@link android.content.res.Configuration#screenHeightDp} configuration field, which holds the current screen width.</p> + <p>For more information about designing for different screens and using this +qualifier, see the <a href="{@docRoot}guide/practices/screens_support.html">Supporting +Multiple Screens</a> developer guide.</p> </td> </tr> <tr id="ScreenSizeQualifier"> @@ -444,30 +458,35 @@ indicates the current locale.</p> </td> <td> <ul class="nolist"> - <li>{@code small}: Screens based on the space available on a - low-density QVGA screen. Considering a portrait HVGA display, this has - the same available width but less height—it is 3:4 vs. HVGA's - 2:3 aspect ratio. The minimum layout size for this screen configuration + <li>{@code small}: Screens that are of similar size to a + low-density QVGA screen. The minimum layout size for a small screen is approximately 320x426 dp units. Examples are QVGA low density and VGA high density.</li> - <li>{@code normal}: Screens based on the traditional - medium-density HVGA screen. A screen is considered to be normal if it is - at least this size (independent of density) and not larger. The minimum - layout size for this screen configuration is approximately 320x470 dp units. Examples + <li>{@code normal}: Screens that are of similar size to a + medium-density HVGA screen. The minimum + layout size for a normal screen is approximately 320x470 dp units. Examples of such screens a WQVGA low density, HVGA medium density, WVGA high density.</li> - <li>{@code large}: Screens based on the space available on a - medium-density VGA screen. Such a screen has significantly more - available space in both width and height than an HVGA display. - The minimum layout size for this screen configuration is approximately 480x640 dp units. + <li>{@code large}: Screens that are of similar size to a + medium-density VGA screen. + The minimum layout size for a large screen is approximately 480x640 dp units. Examples are VGA and WVGA medium density screens.</li> <li>{@code xlarge}: Screens that are considerably larger than the traditional - medium-density HVGA screen. The minimum layout size for this screen configuration + medium-density HVGA screen. The minimum layout size for an xlarge screen is approximately 720x960 dp units. In most cases, devices with extra large screens would be too large to carry in a pocket and would most likely be tablet-style devices. <em>Added in API level 9.</em></li> </ul> + <p class="note"><strong>Note:</strong> Using a size qualifier does not imply that the +resources are <em>only</em> for screens of that size. If you do not provide alternative +resources with qualifiers that better match the current device configuration, the system may use +whichever resources are the <a href="#BestMatch">best match</a>.</p> + <p class="caution"><strong>Caution:</strong> If all your resources use a size qualifier that +is <em>larger</em> than the current screen, the system will <strong>not</strong> use them and your +application will crash at runtime (for example, if all layout resources are tagged with the {@code +xlarge} qualifier, but the device is a normal-size screen).</p> <p><em>Added in API level 4.</em></p> + <p>See <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a> for more information.</p> <p>Also see the {@link android.content.res.Configuration#screenLayout} configuration field, @@ -557,7 +576,8 @@ application during runtime.</p> <code>mdpi</code><br/> <code>hdpi</code><br/> <code>xhdpi</code><br/> - <code>nodpi</code> + <code>nodpi</code><br/> + <code>tvdpi</code> </td> <td> <ul class="nolist"> @@ -569,21 +589,23 @@ application during runtime.</p> Level 8</em></li> <li>{@code nodpi}: This can be used for bitmap resources that you do not want to be scaled to match the device density.</li> + <li>{@code tvdpi}: Screens somewhere between mdpi and hdpi; approximately 213dpi. This is +not considered a "primary" density group. It is mostly intended for televisions and most +apps shouldn't need it—providing mdpi and hdpi resources is sufficient for most apps and +the system will scale them as appropriate. This qualifier was introduced with API level 13.</li> </ul> - <p><em>Added in API level 4.</em></p> - <p>There is thus a 3:4:6:8 scaling ratio between the four densities, so a 9x9 bitmap - in ldpi is 12x12 in mdpi, 18x18 in hdpi and 24x24 in xhdpi.</p> - <p>When Android selects which resource files to use, - it handles screen density differently than the other qualifiers. - In step 1 of <a href="#BestMatch">How Android finds the best - matching directory</a> (below), screen density is always considered to - be a match. In step 4, if the qualifier being considered is screen - density, Android selects the best final match at that point, - without any need to move on to step 5. - </p> + <p>There is a 3:4:6:8 scaling ratio between the four primary densities (ignoring the +tvdpi density). So, a 9x9 bitmap in ldpi is 12x12 in mdpi, 18x18 in hdpi and 24x24 in xhdpi.</p> + <p>If you decide that your image resources don't look good enough on a television or +other certain devices and want to try tvdpi resources, the scaling factor is 1.33*mdpi. For +example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.</p> + <p class="note"><strong>Note:</strong> Using a density qualifier does not imply that the +resources are <em>only</em> for screens of that density. If you do not provide alternative +resources with qualifiers that better match the current device configuration, the system may use +whichever resources are the <a href="#BestMatch">best match</a>.</p> <p>See <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple -Screens</a> for more information about how to handle screen sizes and how Android might scale -your bitmaps.</p> +Screens</a> for more information about how to handle different screen densities and how Android +might scale your bitmaps to fit the current density.</p> </td> </tr> <tr id="TouchscreenQualifier"> @@ -993,7 +1015,10 @@ Primary text input method = <code>12key</code> </p> <p>By comparing the device configuration to the available alternative resources, Android selects -drawables from {@code drawable-en-port}. It arrives at this decision using the following logic:</p> +drawables from {@code drawable-en-port}.</p> + +<p>The system arrives at its decision for which resources to use with the following +logic:</p> <div class="figure" style="width:280px"> @@ -1069,6 +1094,14 @@ language is English ("en"), then any resource directory that has a language qual something other than English is never included in the pool of resources checked (though a resource directory <em>without</em> the language qualifier is still included).</p> +<p>When selecting resources based on the screen size qualifiers, the system will use resources +designed for a screen smaller than the current screen if there are no resources that better match +(for example, a large-size screen will use normal-size screen resources if necessary). However, if +the only available resources are <em>larger</em> than the current screen, the system will +<strong>not</strong> use them and your application will crash if no other resources match the device +configuration (for example, if all layout resources are tagged with the {@code xlarge} qualifier, +but the device is a normal-size screen).</p> + <p class="note"><strong>Note:</strong> The <em>precedence</em> of the qualifier (in <a href="#table2">table 2</a>) is more important than the number of qualifiers that exactly match the device. For example, in step 4 above, the last diff --git a/docs/html/guide/topics/resources/string-resource.jd b/docs/html/guide/topics/resources/string-resource.jd index 2db38f1..ecd2d48 100644 --- a/docs/html/guide/topics/resources/string-resource.jd +++ b/docs/html/guide/topics/resources/string-resource.jd @@ -107,7 +107,7 @@ ID.</dd> String string = {@link android.content.Context#getString(int) getString}(R.string.hello); </pre> <p>You can use either {@link android.content.Context#getString(int)} or -{@link android.content.Context#getText(int)} to retieve a string. {@link +{@link android.content.Context#getText(int)} to retrieve a string. {@link android.content.Context#getText(int)} will retain any rich text styling applied to the string.</p> </dd> <!-- end example --> @@ -233,9 +233,9 @@ the appropriate resource for you. <p>Note that the selection is made based on grammatical necessity. A string for <code>zero</code> in English will be ignored even if the quantity is 0, because 0 isn't grammatically different -from 2, or any other number except 1 ("zero books", "one book", "two books", et cetera). +from 2, or any other number except 1 ("zero books", "one book", "two books", and so on). Don't be misled either by the fact that, say, <code>two</code> sounds like it could only apply to -the quantity 2: a language may require that 2, 12, 102 (et cetera) are all treated like one +the quantity 2: a language may require that 2, 12, 102 (and so on) are all treated like one another but differently to other quantities. Rely on your translator to know what distinctions their language actually insists upon. @@ -359,8 +359,15 @@ values, with non-exhaustive examples in parentheses: int count = getNumberOfsongsAvailable(); Resources res = {@link android.content.Context#getResources()}; String songsFound = res.{@link android.content.res.Resources#getQuantityString(int,int) -getQuantityString}(R.plurals.numberOfSongsAvailable, count); +getQuantityString}(R.plurals.numberOfSongsAvailable, count, count); </pre> +<p>When using the {@link android.content.res.Resources#getQuantityString(int,int) +getQuantityString()} method, you need to pass the {@code count} twice if your string includes +<a href="#FormattingAndStyling">string formatting</a> with a number. For example, for the string +{@code %d songs found}, the first {@code count} parameter selects the appropriate plural string and +the second {@code count} parameter is inserted into the {@code %d} placeholder. If your plural +strings do not include string formatting, you don't need to pass the third parameter to {@link +android.content.res.Resources#getQuantityString(int,int) getQuantityString}.</p> </dd> <!-- end example --> </dl> @@ -405,7 +412,7 @@ your format arguments in the string resource. For example, with the following re </pre> <p>In this example, the format string has two arguments: {@code %1$s} is a string and {@code %2$d} -is a decimal number. You can format the string with arguements from your application like this:</p> +is a decimal number. You can format the string with arguments from your application like this:</p> <pre> Resources res = {@link android.content.Context#getResources()}; diff --git a/docs/html/guide/topics/usb/adk.jd b/docs/html/guide/topics/usb/adk.jd index b5a3f30..463ec9c 100644 --- a/docs/html/guide/topics/usb/adk.jd +++ b/docs/html/guide/topics/usb/adk.jd @@ -59,7 +59,6 @@ page.title=Android Open Accessory Development Kit <li><a href="https://dl-ssl.google.com/android/adk/adk_release_0512.zip">ADK package</a></li> </ol> - <h2>See also</h2> <ol> @@ -70,22 +69,29 @@ page.title=Android Open Accessory Development Kit <h2>Where to buy</h2> <ol> + + <li><a href="http://store.arduino.cc/"> + Arduino Store</a></li> + + <li><a href="https://store.diydrones.com/ProductDetails.asp?ProductCode=BR-PhoneDrone"> + DIY Drones</a></li> + + <li><a href= + "http://www.microchip.com/android"> + Microchip</a></li> + <li><a href="http://shop.moderndevice.com/products/freeduino-usb-host-board"> Modern Device</a></li> - <li><a href="http://www.seeedstudio.com/depot/seeeduino-adk-main-board-p-846.html"> - Seeed Studio</a></li> - - <li><a href= + <li><a href= "http://www.rt-net.jp/shop/index.php?main_page=product_info&cPath=3_4&products_id=1"> RT Corp</a></li> - <li><a href= - "http://www.microchip.com/android"> - Microchip</a></li> + <li><a href="http://www.seeedstudio.com/depot/seeeduino-adk-main-board-p-846.html"> + Seeed Studio</a></li> - <li><a href="https://store.diydrones.com/ProductDetails.asp?ProductCode=BR-PhoneDrone"> - DIY Drones</a></li> + <li><a href="http://www.sparkfun.com/products/10748"> + SparkFun</a></li> </ol> </div> @@ -114,21 +120,30 @@ page.title=Android Open Accessory Development Kit development boards:</p> <ul> + + <li>The <a href="http://store.arduino.cc/">Arduino Store</a> provides the Arduino Mega ADK + (in <a href="http://store.arduino.cc/eu/index.php?main_page=product_info&cPath=11_12&products_id=144">EU nations</a> + or <a href="http://store.arduino.cc/ww/index.php?main_page=product_info&cPath=11_12&products_id=144">non-EU nations</a>) + that is based on the ATmega2560 and supports the ADK firmware.</li> + + <li><a href="https://store.diydrones.com/ProductDetails.asp?ProductCode=BR-PhoneDrone">DIY + Drones</a> provides an Arduino-compatible board geared towards RC (radio controlled) and UAV + (unmanned aerial vehicle) enthusiasts.</li> + + <li><a href="http://www.microchip.com/android">Microchip</a> provides a PIC based USB + microcontroller board.</li> + <li><a href="http://shop.moderndevice.com/products/freeduino-usb-host-board">Modern Device</a> provides an Arduino-compatible board that supports the ADK firmware.</li> - <li><a href="http://www.seeedstudio.com/depot/seeeduino-adk-main-board-p-846.html"> - Seeed Studio</a> provides an Arduino-compatible board that supports the ADK firmware.</li> - <li><a href="http://www.rt-net.jp/shop/index.php?main_page=product_info&cPath=3_4&products_id=1"> RT Corp</a> provides an Arduino-compatible board based on the Android ADK board design.</li> - <li><a href="http://www.microchip.com/android">Microchip</a> provides a A PIC based USB - microcontroller board.</li> + <li><a href="http://www.seeedstudio.com/depot/seeeduino-adk-main-board-p-846.html"> + Seeed Studio</a> provides an Arduino-compatible board that supports the ADK firmware.</li> - <li><a href="https://store.diydrones.com/ProductDetails.asp?ProductCode=BR-PhoneDrone">DIY - Drones</a> provides an Arduino-compatible board geared towards RC (radio controlled) and UAV - (unmanned aerial vehicle) enthusiasts.</li> + <li><a href="http://www.sparkfun.com/products/10748"> + SparkFun</a>'s IOIO board now has beta support for the ADK firmware.</li> </ul> @@ -140,7 +155,7 @@ page.title=Android Open Accessory Development Kit accessory that is based on the <a href="http://www.arduino.cc/">Arduino open source electronics prototyping platform</a>, the accessory's hardware design files, code that implements the accessory's firmware, and the Android application that interacts with the accessory. The hardware - design files and firmware code are contained in the <a href=ctive + design files and firmware code are contained in the <a href= "https://dl-ssl.google.com/android/adk/adk_release_0512.zip">ADK package download</a>.</p> <p>The main hardware and software components of the ADK include:</p> @@ -347,7 +362,7 @@ page.title=Android Open Accessory Development Kit 2.3.4 devices that support accessory mode. This library is also forward compatible with Android 3.1 or newer devices that support accessory mode. If you only care about Android 3.1 or newer devices, all you need is API Level 12. For more information on deciding which API level to use, - see the <a href="{@docRoot}guide/topics/USB/accessory.html#choosing">USB Accessory</a> + see the <a href="{@docRoot}guide/topics/usb/accessory.html#choosing">USB Accessory</a> documentation.</li> <li>Click <strong>File > New > Project...</strong>, then select <strong>Android > @@ -885,4 +900,4 @@ int AndroidAccessory::write(void *buff, int len) { </pre> <p>See the <code>firmware/demokit/demokit.pde</code> file for information about how the ADK board - reads and writes data.</p>
\ No newline at end of file + reads and writes data.</p> diff --git a/docs/html/guide/topics/usb/host.jd b/docs/html/guide/topics/usb/host.jd index 942708d..4967033 100644 --- a/docs/html/guide/topics/usb/host.jd +++ b/docs/html/guide/topics/usb/host.jd @@ -264,11 +264,7 @@ UsbDevice device = (UsbDevice) intent.getParcelableExtra(UsbManager.EXTRA_DEVICE UsbManager manager = (UsbManager) getSystemService(Context.USB_SERVICE); ... HashMap<String, UsbDevice> deviceList = manager.getDeviceList(); -Iterator<UsbDevice> deviceIterator = deviceList.values().iterator(); -while(deviceIterator.hasNext()){ - UsbDevice device = deviceIterator.next(); - // your code -} +UsbDevice device = deviceList.get("deviceName"); </pre> <p>If desired, you can also just obtain an iterator from the hash map and process each device one diff --git a/docs/html/images/home/market_icon.png b/docs/html/images/home/market_icon.png Binary files differnew file mode 100644 index 0000000..ceb76f3 --- /dev/null +++ b/docs/html/images/home/market_icon.png diff --git a/docs/html/images/market/version-codes.png b/docs/html/images/market/version-codes.png Binary files differnew file mode 100644 index 0000000..c0c9858 --- /dev/null +++ b/docs/html/images/market/version-codes.png diff --git a/docs/html/index.jd b/docs/html/index.jd index dce46f9..a8b61bf 100644 --- a/docs/html/index.jd +++ b/docs/html/index.jd @@ -11,15 +11,14 @@ home=true </div><!-- end homeTitle --> <div id="announcement-block"> <!-- total max width is 520px --> - <img src="{@docRoot}assets/images/home/IO-logo-2011.png" -alt="Android at Google IO 2011" width="200px" -style="padding-left:22px;padding-bottom:15px;padding-top:15px;"/> + <img src="{@docRoot}images/home/market_icon.png" +alt="Android Market" width="120px" style="padding:10px 53px 5px"/> <div id="announcement" style="width:275px"> - <p>Thanks to everybody who joined us at Google I/O! If you couldn't make it or would like to -review any of the Android sessions, they're now available on YouTube at the <a -href="http://www.youtube.com/googledevelopers">Google Developers</a> channel, along with the keynote -and other developer sessions. You can also find all the Google I/O Android sessions on this site, on -the <a href="{@docRoot}videos/index.html">Videos</a> page.</p> + <p>We've completely redesigned Android Market for phones to make it easier to +explore Android apps, games, and other content. Look for the new version coming to your +Android phone!</p> <p><a +href="http://android-developers.blogspot.com/2011/07/new-android-market-for-phones.html">Learn more +»</a></p> </div> <!-- end annoucement --> </div> <!-- end annoucement-block --> </div><!-- end topAnnouncement --> @@ -130,14 +129,14 @@ href="{@docRoot}resources/dashboard/platform-versions.html">Learn more »</ 'sdk': { 'layout':"imgLeft", 'icon':"sdk-small.png", - 'name':"Android 3.1", + 'name':"Android 3.2", 'img':"honeycomb-android.png", - 'title':"Android 3.1 now available!", - 'desc': "<p>Android 3.1 includes new developer features such as APIs for USB " -+ "accessories, MTP/PTP, and RTP, as well as new input events from mice, trackballs, joysticks, " -+ "and more.</p>" -+ "<p>For more information about all the new APIs in Android 3.1, read the " -+ "<a href='{@docRoot}sdk/android-3.1.html'>version notes</a>.</p>" + 'title':"Android 3.2 is here!", + 'desc': "<p>Android 3.2 is a minor feature update that includes new APIs that allow you to " ++ "better target your layouts for specific screen sizes and other miscellaneous new APIs.</p>" ++ "<p>For more information about all the changes in Android 3.2, read the " ++ "<a href='{@docRoot}sdk/android-3.2.html'>version notes</a> and <a " ++ "href='{@docRoot}sdk/api_diff/13/changes.html'>diff report</a>.</p>" /* + "<p>If you have an existing SDK, add Android 3.0 as an " + "<a href='{@docRoot}sdk/adding-components.html'>SDK " @@ -153,10 +152,11 @@ href="{@docRoot}resources/dashboard/platform-versions.html">Learn more »</ 'img':"GTV_icon_large.png", 'title':"Google TV!", 'desc': "<p>Build something big. By big, we mean <em>worthy-of-the-living-room</em> big.</p>" - + " <p>Use <a href='http://code.google.com/tv'>Google TV</a> to bring the power of Android" + + " <p>Google TV brings the power of Android" + " and Google Chrome to television." - + " The average American watches five hours of TV per day. Give them the web and apps" - + " to update their status, listen to music, watch web videos, and much more...</p>" + + " The average American watches five hours of TV per day. Give them the apps" + + " to update their status, listen to music, watch web videos, and more.</p>" + + "<p><a href='http://code.google.com/tv'>Develop for Google TV »</a></p>" }, diff --git a/docs/html/resources/tutorials/views/hello-gallery.jd b/docs/html/resources/tutorials/views/hello-gallery.jd index 00757f5..5f2ed32 100644 --- a/docs/html/resources/tutorials/views/hello-gallery.jd +++ b/docs/html/resources/tutorials/views/hello-gallery.jd @@ -34,10 +34,10 @@ public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); - Gallery g = (Gallery) findViewById(R.id.gallery); - g.setAdapter(new ImageAdapter(this)); + Gallery gallery = (Gallery) findViewById(R.id.gallery); + gallery.setAdapter(new ImageAdapter(this)); - g.setOnItemClickListener(new OnItemClickListener() { + gallery.setOnItemClickListener(new OnItemClickListener() { public void onItemClick(AdapterView parent, View v, int position, long id) { Toast.makeText(HelloGallery.this, "" + position, Toast.LENGTH_SHORT).show(); } @@ -101,10 +101,10 @@ public class ImageAdapter extends BaseAdapter { public ImageAdapter(Context c) { mContext = c; - TypedArray a = obtainStyledAttributes(R.styleable.HelloGallery); - mGalleryItemBackground = a.getResourceId( + TypedArray attr = mContext.obtainStyledAttributes(R.styleable.HelloGallery); + mGalleryItemBackground = attr.getResourceId( R.styleable.HelloGallery_android_galleryItemBackground, 0); - a.recycle(); + attr.recycle(); } public int getCount() { @@ -120,14 +120,14 @@ public class ImageAdapter extends BaseAdapter { } public View getView(int position, View convertView, ViewGroup parent) { - ImageView i = new ImageView(mContext); + ImageView imageView = new ImageView(mContext); - i.setImageResource(mImageIds[position]); - i.setLayoutParams(new Gallery.LayoutParams(150, 100)); - i.setScaleType(ImageView.ScaleType.FIT_XY); - i.setBackgroundResource(mGalleryItemBackground); + imageView.setImageResource(mImageIds[position]); + imageView.setLayoutParams(new Gallery.LayoutParams(150, 100)); + imageView.setScaleType(ImageView.ScaleType.FIT_XY); + imageView.setBackgroundResource(mGalleryItemBackground); - return i; + return imageView; } } </pre> diff --git a/docs/html/sdk/android-2.1.jd b/docs/html/sdk/android-2.1.jd index 6eba6f0..3f28551 100644 --- a/docs/html/sdk/android-2.1.jd +++ b/docs/html/sdk/android-2.1.jd @@ -73,51 +73,44 @@ revision number. To determine what revision(s) of the Android {@sdkPlatformVersion} platforms are installed in your SDK environment, refer to the "Installed Packages" listing in the Android SDK and AVD Manager.</p> -<script type="text/javascript"> -function toggleDiv(link) { - var toggleable = $(link).parent(); - if (toggleable.hasClass("closed")) { - //$(".toggleme", toggleable).slideDown("fast"); - toggleable.removeClass("closed"); - toggleable.addClass("open"); - $(".toggle-img", toggleable).attr("title", "hide").attr("src", (toRoot + "assets/images/triangle-opened.png")); - } else { - //$(".toggleme", toggleable).slideUp("fast"); - toggleable.removeClass("open"); - toggleable.addClass("closed"); - $(".toggle-img", toggleable).attr("title", "show").attr("src", (toRoot + "assets/images/triangle-closed.png")); - } - return false; -} -</script> -<style> -.toggleable { - padding: .25em 1em 0em 1em; - margin-bottom: 0; -} -.toggleme { - padding: 1em 1em 0 2em; - line-height:1em; -} -.toggleable a { - text-decoration:none; -} -.toggleme a { - text-decoration:underline; -} -.toggleable.closed .toggleme { - display:none; -} -#jd-content .toggle-img { - margin:0; -} -</style> - -<div class="toggleable opened"> - <a href="#" onclick="return toggleDiv(this)"> - <img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-img" height="9px" width="9px" /> - Android 2.1, Revision 2</a> <em>(May 2010)</em></a> - <div class="toggleme"> + +<div class="toggle-content opened" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-opened.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 3</a> <em>(July 2011)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> + +<dl> +<dt>Dependencies:</dt> +<dd> +<p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r12</a> or +higher.</p> +</dd> +<dt>Notes:</dt> +<dd> +<p>Improvements to the platform's rendering library to support the visual layout editor in the ADT +Eclipse plugin. This revision allows for more drawing features in ADT and fixes several +bugs in the previous rendering library. It also unlocks several editor features that were added in +ADT 12.</p> +</dd> +</dl> + +</div> +</div> + +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 2</a> <em>(May 2010)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> <dl> <dt>Dependencies:</dt> <dd> @@ -136,11 +129,15 @@ function toggleDiv(link) { </div> </div> -<div class="toggleable closed"> - <a href="#" onclick="return toggleDiv(this)"> - <img src="{@docRoot}assets/images/triangle-closed.png" class="toggle-img" height="9px" width="9px" /> - Android 2.1, Revision 1</a> <em>(January 2010)</em></a> - <div class="toggleme"> +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 1</a> <em>(January 2010)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> <dl> <dt>Dependencies:</dt> <dd> diff --git a/docs/html/sdk/android-2.2.jd b/docs/html/sdk/android-2.2.jd index 063a10f..c22220c 100644 --- a/docs/html/sdk/android-2.2.jd +++ b/docs/html/sdk/android-2.2.jd @@ -74,54 +74,46 @@ revision number. To determine what revision(s) of the Android {@sdkPlatformVersion} platforms are installed in your SDK environment, refer to the "Installed Packages" listing in the Android SDK and AVD Manager.</p> -<script type="text/javascript"> -function toggleDiv(link) { - var toggleable = $(link).parent(); - if (toggleable.hasClass("closed")) { - //$(".toggleme", toggleable).slideDown("fast"); - toggleable.removeClass("closed"); - toggleable.addClass("open"); - $(".toggle-img", toggleable).attr("title", "hide").attr("src", (toRoot + "assets/images/triangle-opened.png")); - } else { - //$(".toggleme", toggleable).slideUp("fast"); - toggleable.removeClass("open"); - toggleable.addClass("closed"); - $(".toggle-img", toggleable).attr("title", "show").attr("src", (toRoot + "assets/images/triangle-closed.png")); - } - return false; -} -</script> -<style> -.toggleable { - padding: .25em 1em 0em 1em; - margin-bottom: 0; -} -.toggleme { - padding: 1em 1em 0 2em; - line-height:1em; -} -.toggleable a { - text-decoration:none; -} -.toggleme a { - text-decoration:underline; -} -.toggleable.closed .toggleme { - display:none; -} -#jd-content .toggle-img { - margin:0; -} -</style> - -<div class="toggleable opened"> - <a href="#" onclick="return toggleDiv(this)"> - <img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-img" height="9px" width="9px" /> - Android {@sdkPlatformVersion}, Revision 2</a> <em>(July 2010)</em></a> - <div class="toggleme"> + +<div class="toggle-content opened" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-opened.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 3</a> <em>(July 2011)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> + <dl> <dt>Dependencies:</dt> <dd> +<p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r12</a> or +higher.</p> +</dd> +<dt>Notes:</dt> +<dd> +<p>Improvements to the platform's rendering library to support the visual layout editor in the ADT +Eclipse plugin. This revision allows for more drawing features in ADT and fixes several +bugs in the previous rendering library. It also unlocks several editor features that were added in +ADT 12.</p> +</dd> +</dl> + +</div> +</div> + +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 2</a> <em>(July 2010)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> +<dt>Dependencies:</dt> +<dd> <p>Requires SDK Tools r6 or higher.</p> </dd> @@ -138,11 +130,15 @@ function toggleDiv(link) { </div> </div> -<div class="toggleable closed"> - <a href="#" onclick="return toggleDiv(this)"> - <img src="{@docRoot}assets/images/triangle-closed.png" class="toggle-img" height="9px" width="9px" /> - Android {@sdkPlatformVersion}, Revision 1</a> <em>(May 2010)</em></a> - <div class="toggleme"> +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 1</a> <em>(May 2010)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> <dl> <dt>Dependencies:</dt> <dd> diff --git a/docs/html/sdk/android-2.3.3.jd b/docs/html/sdk/android-2.3.3.jd index 10fc049..7a5b044 100644 --- a/docs/html/sdk/android-2.3.3.jd +++ b/docs/html/sdk/android-2.3.3.jd @@ -65,59 +65,52 @@ revision number. To determine what revision(s) of the Android {@sdkPlatformVersion} platforms are installed in your SDK environment, refer to the "Installed Packages" listing in the Android SDK and AVD Manager.</p> -<script type="text/javascript"> -function toggleDiv(link) { - var toggleable = $(link).parent(); - if (toggleable.hasClass("closed")) { - //$(".toggleme", toggleable).slideDown("fast"); - toggleable.removeClass("closed"); - toggleable.addClass("open"); - $(".toggle-img", toggleable).attr("title", "hide").attr("src", (toRoot + "assets/images/triangle-opened.png")); - } else { - //$(".toggleme", toggleable).slideUp("fast"); - toggleable.removeClass("open"); - toggleable.addClass("closed"); - $(".toggle-img", toggleable).attr("title", "show").attr("src", (toRoot + "assets/images/triangle-closed.png")); - } - return false; -} -</script> -<style> -.toggleable { - padding: .25em 1em 0em 1em; - margin-bottom: 0; -} -.toggleme { - padding: 1em 1em 0 2em; - line-height:1em; -} -.toggleable a { - text-decoration:none; -} -.toggleme a { - text-decoration:underline; -} -.toggleable.closed .toggleme { - display:none; -} -#jd-content .toggle-img { - margin:0; -} -</style> - -<div class="toggleable opened"> - <a href="#" onclick="return toggleDiv(this)"> - <img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-img" height="9px" width="9px" /> - Android {@sdkPlatformVersion}, Revision 1</a> <em>(February 2011)</em></a> - <div class="toggleme"> + +<div class="toggle-content opened" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-opened.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 2</a> <em>(July 2011)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> + <dl> <dt>Dependencies:</dt> <dd> -<p>Requires SDK Tools r9 or higher.</p> +<p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r12</a> or +higher.</p> </dd> +<dt>Notes:</dt> +<dd> +<p>Improvements to the platform's rendering library to support the visual layout editor in the ADT +Eclipse plugin. This revision allows for more drawing features in ADT and fixes several +bugs in the previous rendering library. It also unlocks several editor features that were added in +ADT 12.</p> +</dd> +</dl> + +</div> +</div> + +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 1</a> <em>(February 2011)</em> +</a></p> +<div class="toggle-content-toggleme" style="padding-left:2em;"> +<dl> +<dt>Dependencies:</dt> +<dd> +<p>Requires SDK Tools r9 or higher.</p> +</dd> </dl> - </div> + +</div> </div> diff --git a/docs/html/sdk/android-3.0.jd b/docs/html/sdk/android-3.0.jd index d73bd63..7b04446 100644 --- a/docs/html/sdk/android-3.0.jd +++ b/docs/html/sdk/android-3.0.jd @@ -62,25 +62,52 @@ read <a href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps refer to the "Installed Packages" listing in the Android SDK and AVD Manager.</p> + <div class="toggle-content opened" style="padding-left:1em;"> - <p><a href="#" onclick="return toggleContent(this)"> - <img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-content-img" alt="" /> - Android {@sdkPlatformVersion}, Revision 1</a> <em>(February 2011)</em> - </a></p> +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-opened.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 2</a> <em>(July 2011)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> + +<dl> +<dt>Dependencies:</dt> +<dd> +<p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r12</a> or +higher.</p> +</dd> +<dt>Notes:</dt> +<dd> +<p>Improvements to the platform's rendering library to support the visual layout editor in the ADT +Eclipse plugin. This revision allows for more drawing features in ADT and fixes several +bugs in the previous rendering library. It also unlocks several editor features that were added in +ADT 12.</p> +</dd> +</dl> + +</div> +</div> + +<div class="toggle-content closed" style="padding-left:1em;"> - <div class="toggle-content-toggleme" style="padding-left:2em;"> +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 1</a> <em>(February 2011)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> <dl> - <dt>Dependencies:</dt> <dd> <p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r10</a> or higher.</p> </dd> - </dl> - </div> +</div> </div> diff --git a/docs/html/sdk/android-3.1.jd b/docs/html/sdk/android-3.1.jd index 1614722..0d2d7f8 100644 --- a/docs/html/sdk/android-3.1.jd +++ b/docs/html/sdk/android-3.1.jd @@ -68,25 +68,79 @@ AVD Manager.</p> <div class="toggle-content opened" style="padding-left:1em;"> - <p><a href="#" onclick="return toggleContent(this)"> - <img src="{@docRoot}assets/images/triangle-opened.png" +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-content-img" alt="" /> - Android {@sdkPlatformVersion}, Revision 1</a> <em>(May 2011)</em> - </a></p> + Android {@sdkPlatformVersion}, Revision 3</a> <em>(July 2011)</em> +</a></p> - <div class="toggle-content-toggleme" style="padding-left:2em;"> +<div class="toggle-content-toggleme" style="padding-left:2em;"> <dl> +<dt>Dependencies:</dt> +<dd> +<p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r12</a> or +higher.</p> +</dd> +<dt>Notes:</dt> +<dd> +<p>Improvements to the platform's rendering library to support the visual layout editor in the ADT +Eclipse plugin. This revision allows for more drawing features in ADT and fixes several +bugs in the previous rendering library. It also unlocks several editor features that were added in +ADT 12.</p> +</dd> +</dl> +</div> +</div> + + +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 2</a> <em>(May 2011)</em> +</a></p> + +<div class="toggle-content-toggleme" style="padding-left:2em;"> + +<dl> <dt>Dependencies:</dt> <dd> <p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r11</a> or higher.</p> </dd> +<dt>Notes:</dt> +<dd> +<p>Fixes an issue with the visual layout editor rendering library that prevented Android 3.1 from +running in ADT.</p> +</dd> +</dl> + +</div> +</div> + + +<div class="toggle-content closed" style="padding-left:1em;"> + +<p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" +class="toggle-content-img" alt="" /> + Android {@sdkPlatformVersion}, Revision 1</a> <em>(May 2011)</em> +</a></p> +<div class="toggle-content-toggleme" style="padding-left:2em;"> + +<dl> +<dt>Dependencies:</dt> +<dd> +<p>Requires <a href="{@docRoot}sdk/tools-notes.html">SDK Tools r11</a> or +higher.</p> +</dd> </dl> - </div> +</div> </div> diff --git a/docs/html/sdk/compatibility-library.jd b/docs/html/sdk/compatibility-library.jd index d4669e5..c8cd5b2 100644 --- a/docs/html/sdk/compatibility-library.jd +++ b/docs/html/sdk/compatibility-library.jd @@ -1,4 +1,4 @@ -page.title=Compatibility Library +page.title=Compatibility Package @jd:body @@ -8,9 +8,10 @@ page.title=Compatibility Library <h2>In this document</h2> <ol> <li><a href="#Notes">Revisions</a></li> - <li><a href="#Installing">Installing the Compatibility Library</a></li> - <li><a href="#SettingUp">Setting Up a Project to Use the Library</a></li> - <li><a href="#Using">Using Some of the Library APIs</a></li> + <li><a href="#Downloading">Downloading the Compatibility Package</a></li> + <li><a href="#SettingUp">Setting Up a Project to Use a Library</a></li> + <li><a href="#Using">Using the v4 Library APIs</a></li> + <li><a href="#Docs">Reference Docs</a></li> <li><a href="#Samples">Samples</a></li> </ol> @@ -26,42 +27,92 @@ href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for And <p><em>Minimum API level supported:</em> <b>4</b></p> -<p>The Compatibility Library is a static library you can add to your Android application in order to -use APIs not available in older versions of the Android platform. The primary goal of the library is -to provide APIs introduced in Andriod 3.0 for older versions of Android so that all applications can -use them.</p> +<p>The Compatibility Package includes static "support libraries" that you can add to your Android +application in order to use APIs that are either not available for older platform versions or that +offer "utility" APIs that aren't a part of the framework APIs. The goal is to simplify your +development by offering more APIs that you can bundle with your application so you can +worry less about platform versions.</p> -<p>If you're not able to use APIs introduced in Android 3.0 directly, because you want to remain -backward-compatible, the Compatibility Library provides your application access to self-contained -versions of some of the latest APIs that you can use with older versions of Android. Most -importantly, the library provides implementations of the {@link android.app.Fragment} and {@link -android.content.Loader} APIs, so you can use them in a way that's compatible with devices running -Android 1.6 (API level 4) and higher. Thus, you can more easily create a single APK that supports a -majority of devices and provide larger devices (such as tablets) a fully optimized experience by -using <a href="{@docRoot}guide/topics/fundamentals/fragments.html">Fragments</a> in your activity -design.</p> +<p class="note"><strong>Note:</strong> The Compatibility Package includes more than one support +library. Each one has a different <em>minimum API level</em>. For example, one library requires API +level 4 or higher, while another requires API level 13 or higher. The minimum version is indicated +by the directory name, such as {@code v4/} and {@code v13/}.</p> <h2 id="Notes">Revisions</h2> <p>The sections below provide notes about successive releases of -the Compatibility Library, as denoted by revision number.</p> +the Compatibility Package, as denoted by revision number.</p> <div class="toggle-content open"> <p><a href="#" onclick="return toggleContent(this)"> <img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-content-img" /> - Compatibility Library, revision 2 (May 2011) + Compatibility Package, revision 3 (July 2011) </a></p> <div class="toggle-content-toggleme" style="padding-left:2em"> <dl> - <dt>Changes:</dt> + <dt>Changes for v4 support library:</dt> + <dd> + <ul> + <li>Adds support for {@link android.app.Fragment.SavedState}</li> + <li>Adds {@code MotionEventCompat} to support newer {@link +android.view.MotionEvent} APIs</li> + <li>Adds {@code VelocityTrackerCompat} to support a newer {@link +android.view.VelocityTracker} APIs</li> + <li>Adds {@code ViewConfigurationCompat} to support a newer {@link +android.view.ViewConfiguration} APIs</li> + <li>All new APIs (available only in the support library) that allow you to create UIs +with horizontal paging, allowing users to swipe left and right between content views. Classes to +support this include: + <ul> + <li>{@code ViewPager}: A {@link android.view.ViewGroup} that manages the +layout for the child views, which the user can swipe between.</li> + <li>{@code PagerAdapter}: An adapter that populates the {@code ViewPager} with the +views that represent each page.</li> + <li>{@code FragmentPagerAdapter}: An extension of {@code PagerAdapter} for flipping +between fragments.</li> + <li>{@code FragmentStatePagerAdapter}: An extension of {@code PagerAdapter} for +flipping between fragments that uses the library's support for {@link +android.app.Fragment.SavedState}.</li> + </ul> + </li> + </ul> + </dd> + <dt>New v13 support library:</dt> + <dd> + <ul> + <li>Includes the {@code FragmentPagerAdapter} and {@code FragmentStatePagerAdapter} +to support the horizontal paging. + <p>These are exactly the same as the APIs added to the v4 support library, but rely on +other platform components in Android 3.2. Use this library instead of v4 if you're developing for +Android 3.2 and higher (all other APIs in the v4 library are already available with API level +13).</p> + </li> + </ul> + </dd> + </dl> + </div> + +</div> + + +<div class="toggle-content closed"> + + <p><a href="#" onclick="return toggleContent(this)"> + <img src="{@docRoot}assets/images/triangle-closed.png" class="toggle-content-img" /> + Compatibility Package, revision 2 (May 2011) + </a></p> + + <div class="toggle-content-toggleme" style="padding-left:2em"> + <dl> + <dt>Changes for v4 library:</dt> <dd> <ul> - <li>Support for fragment animations.</li> - <li>Fix {@code Fragment.onActivityResult()} bug.</li> + <li>Support for fragment animations</li> + <li>Fix {@code Fragment.onActivityResult()} bug</li> </ul> </dd> </dl> @@ -74,21 +125,21 @@ the Compatibility Library, as denoted by revision number.</p> <p><a href="#" onclick="return toggleContent(this)"> <img src="{@docRoot}assets/images/triangle-closed.png" class="toggle-content-img" /> - Compatibility Library, revision 1 (March 2011) + Compatibility Package, revision 1 (March 2011) </a></p> <div class="toggle-content-toggleme" style="padding-left:2em"> - <p>Initial release of the library.</p> + <p>Initial release with the v4 library.</p> </div> </div> -<h2 id="Installing">Installing the Compatibility Library</h2> +<h2 id="Downloading">Downloading the Compatibility Package</h2> -<p>The Compatibility Library is provided as a downloadable package from the Android SDK and AVD -Manager. To install the library:</p> +<p>The Compatibility Package is provided as a downloadable package from the Android SDK and AVD +Manager. To install:</p> <ol> <li>Launch the SDK and AVD Manager. @@ -101,43 +152,53 @@ and click <strong>Install selected</strong>.</li> <li>Proceed to install the package.</li> </ol> -<p>When done, all files (including source code, samples, and the {@code .jar} file) are saved -into the <code><sdk>/extras/android/compatibility/</code> directory. The next directory -name is {@code v4}, which indicates the lowest compatible version for the library within. That -is, the code in {@code v4/} supports API level 4 and above. (There may be future libraries that -have a different minimum version, so they will be saved alongside this one.)</p> +<p>When done, all files (including source code, samples, and the {@code .jar} files) are saved +into the <code><sdk>/extras/android/compatibility/</code> directory. This directory contains +each of the different support libraries, such as the library for API level 4 and up and the library +for API level 13 and up, each named with the respective version (such as {@code v4/}).</p> -<h2 id="SettingUp">Setting Up a Project to Use the Library</h2> +<h2 id="SettingUp">Setting Up a Project to Use a Library</h2> -<p>To add the Compatibility Library to your Android project:</p> +<p>To add one of the libraries to your Android project:</p> <ol> <li>In your Android project, create a directory named {@code libs} at the root of your project (next to {@code src/}, {@code res/}, etc.)</li> - <li>Navigate to {@code <sdk>/extras/android/compatibility/v4/}.</li> - <li>Copy the {@code android-support-v4.jar} file into your project {@code libs/} directory.</li> - <li>Add the JAR to your project build path. In Eclipse, right-click the JAR file in the -Package Explorer, select <strong>Build Path</strong> > <strong>Add to Build Path</strong>. -You should then see the JAR file appear in a new directory called Referenced Libraries.</li> + <li>Locate the JAR file for the library you want to use and copy it into the {@code +libs/} directory. + <p>For example, the library that supports API level 4 and up is located at {@code +<sdk>/extras/android/compatibility/v4/android-support-v4.jar}.</p> + </li> + <li>Add the JAR to your project build path. + <p>In Eclipse, right-click the JAR file in the Package Explorer, select <strong>Build +Path</strong> > <strong>Add to Build Path</strong>. You should then see the JAR file appear in a +new directory called Referenced Libraries.</p> + </li> </ol> -<p>Your application is now ready to use fragments, loaders and other APIs from the library. All the -provided APIs are in the {@code android.support.v4} package.</p> +<p>Your application is now ready to use the library APIs. All the +provided APIs are available in the {@code android.support} package (for +example, {@code android.support.v4}).</p> + +<p class="note"><strong>Tip:</strong> To see the library APIs in action, take a look at the sample +apps in {@code extras/android/compatibility/<version>/samples/}.</p> <p class="warning"><strong>Warning:</strong> Be certain that you not confuse the standard -{@code android} packages with those in {@code android.support.v4}. Some code completion tools might +{@code android} packages with those in {@code android.support} library. Some code completion tools +might get this wrong, especially if you're building against recent versions of the platform. To be safe, keep your build target set to the same version as you have defined for your <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code android:minSdkVersion}</a> -and double check the import statements for classes that are duplicated in the Compatibility -Library, such as {@code SimpleCursorAdapter}.</p> +and double check the import statements for classes that also exist in the support library, such as +{@code SimpleCursorAdapter}.</p> -<h2 id="Using">Using Some of the Library APIs</h2> +<h2 id="Using">Using the v4 Library APIs</h2> -<p>The Compatibility Library provides access to several classes introduced with Android 3.0, plus -some updated version of existing classes. Some of the most useful and notable classes in the -library are:</p> +<p>The support library for v4 provides access to several classes introduced with Android 3.0 and +beyond, plus some updated version of existing classes, and even some APIs that currently don't +exist in the Android platform. Some of the most useful and notable classes that have +counterparts in the v4 support library are:</p> <ul> <li>{@link android.app.Fragment}</li> @@ -152,8 +213,8 @@ library are:</p> </ul> <p>For each of the classes above (and others not listed), the APIs work almost exactly the same -as the counterparts in the latest version of the Android platform. Thus, you can usually refer to -the latest reference documentation for information about the supported APIs. There are some +as the counterparts in the latest Android platform. Thus, you can usually refer to +the online documentation for information about the supported APIs. There are some differences, however. Most notably:</p> <ul> @@ -181,18 +242,6 @@ public boolean onCreateOptionsMenu(Menu menu) { </li> </ul> -<p>The Compatibility Library currently does not provide reference documentation for the included -APIs. To generate your own set, using the {@code javadoc} tool, perform the -following from a command line:</p> - -<pre class="no-pretty-print"> -cd <sdk>/extras/android/compatibility/v4/ -mkdir docs -javadoc -sourcepath src/java/ -subpackages android.support.v4 -d docs -</pre> -<p>Open the {@code docs/index.html} file to begin browsing the generated documentation.</p> - - <div class="note"><p><strong>Tip:</strong> To enable the Holographic theme on devices running Android 3.0 or higher, declare in your manifest file that your application targets API level 11. For example:</p> @@ -208,16 +257,30 @@ Android-powered devices, read <a href="{@docRoot}guide/practices/optimizing-for- Apps for Android 3.0</a>.</p> +<h2 id="Docs">Reference Docs</h2> + +<p>The libraries currently do not provide reference documentation for the included APIs. To generate +your own set using the {@code javadoc} tool, perform the following from a command (as appropriate +for the library version you're using). In this example, documentation is generated for the v4 +library:</p> + +<pre class="no-pretty-print"> +cd <sdk>/extras/android/compatibility/v4/ +mkdir docs +javadoc -sourcepath src/java/ -subpackages android.support.v4 -d docs +</pre> +<p>Open the {@code docs/index.html} file to begin browsing the generated documentation.</p> + + <h2 id="Samples">Samples</h2> -<p>If you want to see some sample code that uses the Compatibility Library, take a look at the -<a href="{@docRoot}resources/samples/ApiDemos/src/com/example/android/apis/support/index.html">API -Demos</a> sample code that's included with the Samples package you can download from the AVD and SDK -Manager.</p> +<p>If you want to see some code that uses the support libraries, samples are included with the +Compatibility Package, inside each support library directory. For example, at {@code +extras/android/compatibility/v4/samples/}.</p> <p>Additionally, the <a href="http://code.google.com/p/iosched/">Google I/O App</a> is a complete -application that uses the library to provide a single APK for both handsets and tablets and also -demonstrates some of Android's best practices in Android UI design.</p> +application that uses the v4 support library to provide a single APK for both handsets and tablets +and also demonstrates some of Android's best practices in Android UI design.</p> diff --git a/docs/html/sdk/sdk_toc.cs b/docs/html/sdk/sdk_toc.cs index 829ed52..1b1fc8d 100644 --- a/docs/html/sdk/sdk_toc.cs +++ b/docs/html/sdk/sdk_toc.cs @@ -145,8 +145,8 @@ class="new">new!</span></li> <li><a href="<?cs var:toroot ?>sdk/tools-notes.html">SDK Tools, r12</a> <span class="new">new!</span></li> <li><a href="<?cs var:toroot ?>sdk/win-usb.html">Google USB Driver, r4</a></li> - <li><a href="<?cs var:toroot ?>sdk/compatibility-library.html">Compatibility Library, -r2</a></li> + <li><a href="<?cs var:toroot ?>sdk/compatibility-library.html">Compatibility Package, +r3</a> <span class="new">new!</span></li> </ul> </li> <li> @@ -183,8 +183,8 @@ r2</a></li> <span style="display:none" class="zh-TW"></span> </h2> <ul> - <li><a href="<?cs var:toroot ?>sdk/ndk/index.html">Android NDK, r6 <span - class="new">new!</span></a> + <li><a href="<?cs var:toroot ?>sdk/ndk/index.html">Android NDK, r6</a> + <span class="new">new!</span> </li> <li><a href="<?cs var:toroot ?>sdk/ndk/overview.html">What is the NDK?</a></li> </ul> |
