diff options
Diffstat (limited to 'docs/html/guide')
90 files changed, 6879 insertions, 4868 deletions
diff --git a/docs/html/guide/appendix/api-levels.jd b/docs/html/guide/appendix/api-levels.jd index cc98f8f..bc7d83b 100644 --- a/docs/html/guide/appendix/api-levels.jd +++ b/docs/html/guide/appendix/api-levels.jd @@ -350,11 +350,11 @@ including the latest version, and provides an updater tool that you can use to download other platform versions as necessary. </p> <p>To access the updater, use the <code>android</code> command-line tool, -located in the <sdk>/tools directory. You can launch the Updater by using -the <code>android</code> command without specifying any options. You can +located in the <sdk>/tools directory. You can launch the SDK updater by +executing <code>android sdk</code>. You can also simply double-click the android.bat (Windows) or android (OS X/Linux) file. In ADT, you can also access the updater by selecting -<strong>Window</strong> > <strong>Android SDK and AVD +<strong>Window</strong> > <strong>Android SDK Manager</strong>.</p> <p>To run your application against different platform versions in the emulator, diff --git a/docs/html/guide/appendix/install-location.jd b/docs/html/guide/appendix/install-location.jd index 292d3e7..63a3817 100644 --- a/docs/html/guide/appendix/install-location.jd +++ b/docs/html/guide/appendix/install-location.jd @@ -172,9 +172,9 @@ persist after external storage is remounted.</dd> before the external storage is mounted to the device. If your application is installed on the external storage, it can never receive this broadcast.</dd> <dt>Copy Protection</dt> - <dd>Your application cannot be installed to a device's SD card if it uses Android Market's - Copy Protection feature. However, if you use Android Market's - <a href="{@docRoot}guide/publishing/licensing.html">Application Licensing</a> instead, your + <dd>Your application cannot be installed to a device's SD card if it uses Google Play's + Copy Protection feature. However, if you use Google Play's + <a href="{@docRoot}guide/market/licensing.html">Application Licensing</a> instead, your application <em>can</em> be installed to internal or external storage, including SD cards.</dd> </dl> diff --git a/docs/html/guide/appendix/market-filters.jd b/docs/html/guide/appendix/market-filters.jd index d9b2155..3e502d7 100644 --- a/docs/html/guide/appendix/market-filters.jd +++ b/docs/html/guide/appendix/market-filters.jd @@ -1,4 +1,4 @@ -page.title=Market Filters +page.title=Filters on Google Play @jd:body <div id="qv-wrapper"> @@ -6,15 +6,15 @@ page.title=Market Filters <h2>Quickview</h2> <ul> -<li>Android Market applies filters that control which Android-powered devices can access your -application on Market.</li> +<li>Google Play applies filters that control which Android-powered devices can access your +application when the user is visiting the store.</li> <li>Filtering is determined by comparing device configurations that you declare in you app's manifest file to the configurations defined by the device, as well as other factors.</li> </ul> <h2>In this document</h2> <ol> - <li><a href="#how-filters-work">How Filters Work in Android Market</a></li> + <li><a href="#how-filters-work">How Filters Work on Google Play</a></li> <li><a href="#manifest-filters">Filtering based on Manifest Elements</a> <ol> <li><a href="#advanced-filters">Advanced manifest filters</a></li> @@ -47,10 +47,10 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></c <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> + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0 5px;"> + <h2 style="color:#669999;padding-top:1em;">Interested in publishing your app on Google Play?</h2> <p><a id="publish-link" -href="http://market.android.com/publish">Go to Android Market</a> to create a publisher +href="http://play.google.com/apps/publish">Go to Google Play</a> to create a publisher account and upload your app.</p></div> </div> @@ -58,44 +58,44 @@ account and upload your app.</p></div> </div> -<p>When a user searches or browses in Android Market on an Android device, the results are filtered +<p>When a user searches or browses on Google Play 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 +requires a camera (as specified in the application manifest file), then Google Play will not show the app on any device that does not have a camera.</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 is updated periodically to reflect any changes that affect the way Android Market +<p>Changes to the Google Play filters are independent of changes to the Android platform itself. +This document is updated periodically to reflect any changes that affect the way Google Play filters applications.</p> -<h2 id="how-filters-work">How Filters Work in Android Market</h2> +<h2 id="how-filters-work">How Filters Work on Google Play</h2> -<p>Android Market uses the filter restrictions described below to determine +<p>Google Play uses the filter restrictions described below to determine whether to show your application to a user who is browsing or searching for -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 +applications from the Google Play app. When determining whether to display your app, +Google Play 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'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 +compatible with the device according to the filter rules, Google Play displays the +application to the user. Otherwise, Google Play hides your application from search 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> +the app by clicking a deep link that points directly to the app's ID within Google Play..</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 +href="http://play.google.com/apps">Google Play web site</a>, they can see all published +applications. The Google Play 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 +in the app, then when uploading the app to Google Play you could target European countries (carriers) +only. Google Play'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 @@ -106,15 +106,15 @@ available.</p> <h2 id="manifest-filters">Filtering based on Manifest Elements</h2> -<p>Most Market filters are triggered by elements within an application's +<p>Most 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). -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> +Table 1 lists the manifest elements that you should use to trigger +filtering, and explains how the filtering for each element works.</p> <p id="table1" class="table-caption"><strong>Table 1.</strong> Manifest elements that -trigger filtering on Market.</p> +trigger filtering on Google Play.</p> <table> <tr> <th>Manifest Element</th> @@ -129,19 +129,19 @@ trigger filtering on Market.</p> <p>An application indicates the screen sizes that it is capable of supporting by setting attributes of the <code><supports-screens></code> element. When -the application is published, Market uses those attributes to determine whether +the application is published, Google Play uses those attributes to determine whether to show the application to users, based on the screen sizes of their devices. </p> -<p>As a general rule, Market assumes that the platform on the device can adapt +<p>As a general rule, Google Play assumes that the platform on the device can adapt smaller layouts to larger screens, but cannot adapt larger layouts to smaller screens. Thus, if an application declares support for "normal" screen size only, -Market makes the application available to both normal- and large-screen devices, +Google Play makes the application available to both normal- and large-screen devices, but filters the application so that it is not available to small-screen devices.</p> <p>If an application does not declare attributes for -<code><supports-screens></code>, Market uses the default values for those +<code><supports-screens></code>, Google Play uses the default values for those attributes, which vary by API Level. Specifically: </p> <ul> @@ -150,7 +150,7 @@ 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 +is undefined and no attributes are available. In this case, Google Play assumes that the application is designed for normal-size screens and shows the application to devices that have normal or larger screens. </p> @@ -166,19 +166,19 @@ default.</li> <p><strong>Example 1</strong><br /> The manifest declares <code><uses-sdk android:minSdkVersion="3"></code> and does not include a <code><supports-screens></code> element. - <strong>Result</strong>: Android Market does not show the app to a user of a - small-screen device, but does show it to users of normal and large-screen - devices, unless other filters also exclude those devices. </p> + <strong>Result</strong>: Google Play will not show the app to a user of a + small-screen device, but will show it to users of normal and large-screen + devices, unless other filters apply. </p> <p><strong>Example 2<br /> </strong>The manifest declares <code><uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"></code> and does not include a <code><supports-screens></code> element. - <strong>Result</strong>: Android Market will show the app to users on all + <strong>Result</strong>: Google Play will show the app to users on all devices, unless other filters apply. </p> <p><strong>Example 3<br /> </strong>The manifest declares <code><uses-sdk android:minSdkVersion="4"></code> and does not include a <code><supports-screens></code> element. - <strong>Result</strong>: Android Market will show the app to all users, + <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply. </p> <p>For more information on how to declare support for screen sizes in your application, see <code><a @@ -195,11 +195,11 @@ default.</li> Configuration: <br /> keyboard, navigation, touch screen</td> <td valign="top"><p>An application can - request certain hardware features, and Android Market will show the app only on devices that have the required hardware.</p> + request certain hardware features, and Google Play will show the app only on devices that have the required hardware.</p> <p><strong>Example 1<br /> - </strong>The manifest includes <code><uses-configuration android:reqFiveWayNav="true" /></code>, and a user is searching for apps on a device that does not have a five-way navigational control. <strong>Result</strong>: Android Market will not show the app to the user. </p> + </strong>The manifest includes <code><uses-configuration android:reqFiveWayNav="true" /></code>, and a user is searching for apps on a device that does not have a five-way navigational control. <strong>Result</strong>: Google Play will not show the app to the user. </p> <p><strong>Example 2<br /> - </strong>The manifest does not include a <code><uses-configuration></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p> + </strong>The manifest does not include a <code><uses-configuration></code> element. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply.</p> <p>For more details, see <a href="{@docRoot}guide/topics/manifest/uses-configuration-element.html"><code><uses-configuration></code></a>.</p></td> </tr> @@ -218,16 +218,16 @@ Level 5).</p> </strong>The manifest includes <code><uses-feature android:name="android.hardware.sensor.light" /></code>, and a user is searching for apps on a device that does not have a light sensor. -<strong>Result</strong>: Android Market will not show the app to the user. </p> +<strong>Result</strong>: Google Play will not show the app to the user. </p> <p><strong>Example 2<br /> </strong>The manifest does not include a <code><uses-feature></code> -element. <strong>Result</strong>: Android Market will show the app to all users, +element. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply.</p> <p>For complete information, see <code><a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-feature></a> </code>.</p> - <p><em>Filtering based on implied features:</em> In some cases, Android -Market interprets permissions requested through + <p><em>Filtering based on implied features:</em> In some cases, Google +Play interprets permissions requested through <code><uses-permission></code> elements as feature requirements equivalent to those declared in <code><uses-feature></code> elements. See <a href="#uses-permission-filtering"><code><uses-permission></code></a>, @@ -245,19 +245,19 @@ below.</p> <p><strong>Example 1<br /> </strong>An app requests multiple OpenGL-ES versions by specifying <code>openGlEsVersion</code> multiple times in the - manifest. <strong>Result</strong>: Market assumes that the app requires the highest of the indicated versions.</p> + manifest. <strong>Result</strong>: Google Play assumes that the app requires the highest of the indicated versions.</p> <p><strong>Example 2<br /> </strong>An app - requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. <strong>Result</strong>: Android Market will show the app to the user, unless other filters apply. If a - device reports that it supports OpenGL-ES version <em>X</em>, Market assumes that it + requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. <strong>Result</strong>: Google Play will show the app to the user, unless other filters apply. If a + device reports that it supports OpenGL-ES version <em>X</em>, Google Play assumes that it also supports any version earlier than <em>X</em>. </p> <p><strong>Example 3<br /> </strong>A user is searching for apps on a device that does not - report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). <strong>Result</strong>: Android Market assumes that the device - supports only OpenGL-ES 1.0. Market will only show the user apps that do not specify <code>openGlEsVersion</code>, or apps that do not specify an OpenGL-ES version higher than 1.0. </p> + report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). <strong>Result</strong>: Google Play assumes that the device + supports only OpenGL-ES 1.0. Google Play will only show the user apps that do not specify <code>openGlEsVersion</code>, or apps that do not specify an OpenGL-ES version higher than 1.0. </p> <p><strong>Example 4<br /> - </strong>The manifest does not specify <code>openGlEsVersion</code>. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply. </p> + </strong>The manifest does not specify <code>openGlEsVersion</code>. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply. </p> <p>For more details, see <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>.</p></td> </tr> @@ -268,28 +268,28 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses- <td valign="top"><p>An application can require specific shared libraries to be present on the device. </p> <p><strong>Example 1<br /> - </strong>An app requires the <code>com.google.android.maps</code> library, and a user is searching for apps on a device that does not have the <code>com.google.android.maps</code> library. <strong>Result</strong>: Android Market will not show the app to the user. </p> + </strong>An app requires the <code>com.google.android.maps</code> library, and a user is searching for apps on a device that does not have the <code>com.google.android.maps</code> library. <strong>Result</strong>: Google Play will not show the app to the user. </p> <p><strong>Example 2</strong><br /> - The manifest does not include a <code><uses-library></code> element. <strong>Result</strong>: Android Market will show the app to all users, unless other filters apply.</p> + The manifest does not include a <code><uses-library></code> element. <strong>Result</strong>: Google Play will show the app to all users, unless other filters apply.</p> <p>For more details, see <a href="{@docRoot}guide/topics/manifest/uses-library-element.html"><code><uses-library></code></a>.</p></td> </tr> <tr id="uses-permission-filtering"> <td valign="top" style="white-space:nowrap;"><code><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a></code></td> <td valign="top"> </td> - <td valign="top">Strictly, Android Market does not filter based on + <td valign="top">Strictly, Google Play does not filter based on <code><uses-permission></code> elements. However, it does read the elements to determine whether the application has hardware feature requirements that may not have been properly declared in <code><uses-feature></code> elements. For example, if an application requests the <code>CAMERA</code> permission but does not declare a <code><uses-feature></code> element for -<code>android.hardware.camera</code>, Android Market considers that the +<code>android.hardware.camera</code>, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.</p> <p>In general, if an application requests hardware-related permissions, -Android Market assumes that the application requires the underlying hardware +Google Play assumes that the application requires the underlying hardware features, even though there might be no corresponding to -<code><uses-feature></code> declarations. Android Market then sets up +<code><uses-feature></code> declarations. Google Play then sets up filtering based on the features implied by the <code><uses-feature></code> declarations.</p> <p>For a list of permissions that imply hardware features, see @@ -305,9 +305,9 @@ element.</p> <td valign="top"><p>An application can require a minimum API level. </p> <p><strong>Example 1</strong><br /> The manifest includes <code><uses-sdk - android:minSdkVersion="3"></code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Android Market will not show the app to the user. </p> + android:minSdkVersion="3"></code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Google Play will not show the app to the user. </p> <p><strong>Example 2</strong><br /> - The manifest does not include <code>minSdkVersion</code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Android Market assumes that <code>minSdkVersion</code> is "1" and that the app is compatible with all versions of Android. Market shows the app to the user and allows the user to download the app. The app crashes at runtime. </p> + The manifest does not include <code>minSdkVersion</code>, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. <strong>Result</strong>: Google Play assumes that <code>minSdkVersion</code> is "1" and that the app is compatible with all versions of Android. Google Play shows the app to the user and allows the user to download the app. The app crashes at runtime. </p> <p>Because you want to avoid this second scenario, we recommend that you always declare a <code>minSdkVersion</code>. For details, see <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min"><code>android:minSdkVersion</code></a>.</p></td> </tr> @@ -316,7 +316,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min"><code>android:m <td valign="top"><p><em>Deprecated.</em> Android 2.1 and later do not check or enforce the <code>maxSdkVersion</code> attribute, and the SDK will not compile if <code>maxSdkVersion</code> is set in an app's manifest. For devices already - compiled with <code>maxSdkVersion</code>, Market will respect it and use it for + compiled with <code>maxSdkVersion</code>, Google Play will respect it and use it for filtering.</p> <p> Declaring <code>maxSdkVersion</code> is <em>not</em> recommended. For details, see <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max"><code>android:maxSdkVersion</code></a>.</p></td> @@ -327,7 +327,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max"><code>android:m <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 +<p>In addition to the manifest elements in <a href="#table1">table 1</a>, Google Play 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 @@ -336,14 +336,14 @@ require strict controls on application distribution. <strong>Most applications s these filters</strong>.</p> <p id="table2" class="table-caption"><strong>Table 2.</strong> Advanced manifest elements for -Android Market filtering.</p> +Google Play 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 + <p>Google Play 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 @@ -360,7 +360,7 @@ with alternative resources.</p> <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 + <p>Google Play 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> @@ -370,16 +370,16 @@ formats supported by the application are also supported by the device. </p> <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>Google Play 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="table3" class="table-caption"><strong>Table 3.</strong> Application and publishing -characteristics that affect filtering on Market.</p> +characteristics that affect filtering on Google Play.</p> <table> <tr> <th>Filter Name</th> <th>How It Works</th> </tr> <tr> <td valign="top">Publishing Status</td> <td valign="top"><p>Only published applications will appear in - searches and browsing within Android Market.</p> <p>Even if an app is unpublished, it can + searches and browsing within Google Play.</p> <p>Even if an app is unpublished, it can be installed if users can see it in their Downloads area among their purchased, installed, or recently uninstalled apps.</p> <p>If an application has been suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.</p> </td></tr> @@ -390,10 +390,10 @@ must have a SIM card and be running Android 1.1 or later, and it must be in a country (as determined by SIM carrier) in which paid apps are available.</p></td> </tr> <tr> <td valign="top">Country / Carrier Targeting</td> <td valign="top"> <p>When you upload your app to - the Android Market, you can select specific countries to target. The app will only + Google Play, you can select specific countries to target. The app will only be visible to the countries (carriers) that you select, as follows:</p> <ul><li><p>A device's country is determined based on the carrier, if a carrier is - available. If no carrier can be determined, the Market application tries to + available. If no carrier can be determined, Google Play tries to determine the country based on IP.</p></li> <li><p>Carrier is determined based on the device's SIM (for GSM devices), not the current roaming carrier.</p></li></ul> </td> </tr> <tr> @@ -404,22 +404,22 @@ country (as determined by SIM carrier) in which paid apps are available.</p></td Android NDK?</a></p> </tr> <tr> <td valign="top">Copy-Protected Applications</td> <td valign="top"><p>To copy protect an application, set copy protection to "On" when you configure publishing -options for your application. Market will not show copy-protected applications on +options for your application. Google Play will not show copy-protected applications on developer devices or unreleased devices.</p></td> </tr> </table> <h2 id="MultiApks">Publishing Multiple APKs with Different Filters</h2> -<p>Some specific Android Market filters allow you to publish multiple APKs for the same +<p>Some specific Google Play 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> +configuration. Depending on each device's support for your texture compression formats, Google +Play will deliver it the APK that you've declared to support that device.</p> -<p>Currently, Android Market allows you to publish multiple APKs for the same application only +<p>Currently, Google Play 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 @@ -440,7 +440,7 @@ href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code </ul> <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, +distinguish one APK from another within the same application listing on Google Play. 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> @@ -450,5 +450,5 @@ APK that supports a wide range of device configurations</strong>. Publishing mul 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 +<p>If you need more information about how to publish multiple APKs on Google Play, read <a href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> diff --git a/docs/html/guide/developing/building/building-cmdline.jd b/docs/html/guide/developing/building/building-cmdline.jd index c43962a..fd90b1a 100644 --- a/docs/html/guide/developing/building/building-cmdline.jd +++ b/docs/html/guide/developing/building/building-cmdline.jd @@ -202,12 +202,12 @@ ant release <ol> <li> - <strong>Open the SDK and AVD Manager and launch a virtual device</strong> + <strong>Open the AVD Manager and launch a virtual device</strong> - <p>From your SDK's <code>platform-tools/</code> directory, execute the {@code android} tool with no - arguments:</p> + <p>From your SDK's <code>platform-tools/</code> directory, execute the {@code android} tool +with the <code>avd</code> options:</p> <pre> -android +android avd </pre> <p>In the <em>Virtual Devices</em> view, select an AVD and click <strong>Start</strong>.</p> @@ -237,7 +237,7 @@ adb -s emulator-5554 install <em>path/to/your/app</em>.apk </ol> <p>If you don't see your application on the emulator, try closing the emulator and launching the - virtual device again from the SDK and AVD Manager. Sometimes when you install an application for the + virtual device again from the AVD Manager. Sometimes when you install an application for the first time, it won't show up in the application launcher or be accessible by other applications. This is because the package manager usually examines manifests completely only on emulator startup.</p> diff --git a/docs/html/guide/developing/building/index.jd b/docs/html/guide/developing/building/index.jd index 59c4645..569cd28 100644 --- a/docs/html/guide/developing/building/index.jd +++ b/docs/html/guide/developing/building/index.jd @@ -27,8 +27,8 @@ page.title=Building and Running <p>To run an application on an emulator or device, the application must be signed using debug or release mode. You typically want to sign your application in debug mode when you develop and test your application, because the build tools use a debug key with a known password so you do not have - to enter it every time you build. When you are ready to release the application to Android - Market, you must sign the application in release mode, using your own private key.</p> + to enter it every time you build. When you are ready to release the application to Google + Play, you must sign the application in release mode, using your own private key.</p> <p>Fortunately, Eclipse or your Ant build script signs the application for you in debug mode when you build your application. You can also easily setup Eclipse or your Ant build to sign your diff --git a/docs/html/guide/developing/debugging/ddms.jd b/docs/html/guide/developing/debugging/ddms.jd index 4398ec9..80b1e47 100644 --- a/docs/html/guide/developing/debugging/ddms.jd +++ b/docs/html/guide/developing/debugging/ddms.jd @@ -11,7 +11,19 @@ parent.link=index.html <li><a href="#running">Running DDMS</a></li> <li><a href="#how-ddms-works">How DDMS Interacts with a Debugger</a></li> - <li><a href="#using-ddms">Using DDMS</a></li> + <li><a href="#using-ddms">Using DDMS</a> + <ol> + <li><a href="#heap">Viewing heap usage for a process</a></li> + <li><a href="#alloc">Tracking memory allocation of objects</a></li> + <li><a href="#emulator">Working with an emulator or device's file system</a></li> + <li><a href="#thread">Examining thread information</a></li> + <li><a href="#profiling">Starting method profiling</a></li> + <li><a href="#network">Using the Network Traffic tool</a></li> + <li><a href="#logcat">Using LogCat</a></li> + <li><a href="#ops-location">Emulating phone operations and location</a></li> + </ol> + + </li> </ol> </div> </div> @@ -90,7 +102,7 @@ parent.link=index.html <a href="#running">Running DDMS</a>. - <h3>Viewing heap usage for a process</h3> + <h3 id="heap">Viewing heap usage for a process</h3> <p>DDMS allows you to view how much heap memory a process is using. This information is useful in tracking heap usage at a certain point of time during the execution of your application.</p> @@ -110,7 +122,7 @@ parent.link=index.html allocated for a particular memory size in bytes.</li> </ol> - <h3>Tracking memory allocation of objects</h3> + <h3 id="alloc">Tracking memory allocation of objects</h3> <p>DDMS provides a feature to track objects that are being allocated to memory and to see which classes and threads are allocating the objects. This allows you to track, in real time, where @@ -140,7 +152,7 @@ parent.link=index.html line number of the code that allocated the object.</li> </ol> - <h3>Working with an emulator or device's file system</h3> + <h3 id="emulator">Working with an emulator or device's file system</h3> <p>DDMS provides a File Explorer tab that allows you to view, copy, and delete files on the device. This feature is useful in examining files that are created by your application or if you @@ -160,7 +172,7 @@ parent.link=index.html <!-- Need to elaborate more on where things are stored in the file system, databases, apks, user info, files that are important to look at --> - <h3>Examining thread information</h3> + <h3 id="thread">Examining thread information</h3> <p>The Threads tab in DDMS shows you the currently running threads for a selected process.</p> @@ -204,6 +216,67 @@ parent.link=index.html Profiling</strong>.</li> </ol> + <h3 id="network">Using the Network Traffic tool</h3> + + <p>In Android 4.0, the DDMS (Dalvik Debug Monitor Server) includes a Detailed +Network Usage tab that makes it possible to track when your application is +making network requests. Using this tool, you can monitor how and when your app +transfers data and optimize the underlying code appropriately. You can also +distinguish between different traffic types by applying a “tag” to network +sockets before use.</p> + +<p>These tags are shown in a stack area chart in DDMS, as shown in figure 2:</p> + +<img src="{@docRoot}images/developing/ddms-network.png" /> +<p class="img-caption"><strong>Figure 2.</strong> Network Usage tab.</p> + +<p>By monitoring the frequency of your data transfers, and the amount of data +transferred during each connection, you can identify areas of your application +that can be made more battery-efficient. Generally, you should look for +short spikes that can be delayed, or that should cause a later transfer to be +pre-empted. </p> + +<p>To better identify the cause of transfer spikes, the +{@link android.net.TrafficStats} API allows you +to tag the data transfers occurring within a thread using {@link +android.net.TrafficStats#setThreadStatsTag setThreadStatsTag()}, followed +by manually tagging (and untagging) individual sockets using {@link +android.net.TrafficStats#tagSocket tagSocket()} and {@link +android.net.TrafficStats#untagSocket untagSocket()}. For example:</p> + +<pre>TrafficStats.setThreadStatsTag(0xF00D); +TrafficStats.tagSocket(outputSocket); +// Transfer data using socket +TrafficStats.untagSocket(outputSocket);</pre> + +<p>Alternatively, the Apache {@link org.apache.http.client.HttpClient} and +{@link java.net.URLConnection} APIs included in the platform +automatically tag sockets internally based on the active tag (as +identified by +{@link android.net.TrafficStats#getThreadStatsTag getThreadStatsTag()}). +These APIs correctly tag/untag sockets when recycled through +keep-alive pools. In the following example, +{@link android.net.TrafficStats#setThreadStatsTag setThreadStatsTag()} +sets the active tag to be {@code 0xF00D}. +There can only be one active tag per thread. +That is the value that will +be returned by {@link android.net.TrafficStats#getThreadStatsTag getThreadStatsTag()} +and thus used by {@link org.apache.http.client.HttpClient} + to tag sockets. The {@code finally} statement +invokes +{@link android.net.TrafficStats#clearThreadStatsTag clearThreadStatsTag()} +to clear the tag.</p> + +<pre>TrafficStats.setThreadStatsTag(0xF00D); + try { + // Make network request using HttpClient.execute() + } finally { + TrafficStats.clearThreadStatsTag(); +}</pre> + +<p>Socket tagging is supported in Android 4.0, but real-time stats will only be +displayed on devices running Android 4.0.3 or higher.</p> + <h3 id="logcat">Using LogCat</h3> <p>LogCat is integrated into DDMS, and outputs the messages that you print out using the {@link android.util.Log} @@ -230,7 +303,7 @@ parent.link=index.html with the log tags or with the process id that generated the log message. The add filter, edit filter, and delete filter buttons let you manage your custom filters.</p> - <h3>Emulating phone operations and location</h3> + <h3 id="ops-location">Emulating phone operations and location</h3> <p>The Emulator control tab lets you simulate a phone's voice and data network status. This is useful when you want to test your application's robustness in differing network environments.</p> diff --git a/docs/html/guide/developing/device.jd b/docs/html/guide/developing/device.jd index d22dca1..d91551a 100644 --- a/docs/html/guide/developing/device.jd +++ b/docs/html/guide/developing/device.jd @@ -134,11 +134,11 @@ above.</p> </tr> <tr> <td>ASUS</td> - <td><code>0B05</code></td> + <td><code>0b05</code></td> </tr> <tr> <td>Dell</td> - <td><code>413C</code></td> + <td><code>413c</code></td> </tr> <tr> <td>Foxconn</td> @@ -146,35 +146,35 @@ above.</p> </tr> <tr> <td>Fujitsu</td> - <td><code>04C5</code></td> + <td><code>04c5</code></td> </tr> <tr> <td>Fujitsu Toshiba</td> - <td><code>04C5</code></td> + <td><code>04c5</code></td> </tr> <tr> <td>Garmin-Asus</td> - <td><code>091E</code></td> + <td><code>091e</code></td> </tr> <tr> <td>Google</td> - <td><code>18D1</code></td> + <td><code>18d1</code></td> </tr> <tr> <td>Hisense</td> - <td><code>109B</code></td> + <td><code>109b</code></td> </tr> <tr> <td>HTC</td> - <td><code>0BB4</code></td> + <td><code>0bb4</code></td> </tr> <tr> <td>Huawei</td> - <td><code>12D1</code></td> + <td><code>12d1</code></td> </tr> <tr> <td>K-Touch</td> - <td><code>24E3</code></td> + <td><code>24e3</code></td> </tr> <tr> <td>KT Tech</td> @@ -185,8 +185,8 @@ above.</p> <td><code>0482</code></td> </tr> <tr> - <td>Lenevo</td> - <td><code>17EF</code></td> + <td>Lenovo</td> + <td><code>17ef</code></td> </tr> <tr> <td>LG</td> @@ -194,7 +194,7 @@ above.</p> </tr> <tr> <td>Motorola</td> - <td><code>22B8</code></td> + <td><code>22b8</code></td> </tr> <tr> <td>NEC</td> @@ -214,11 +214,11 @@ above.</p> </tr> <tr> <td>Pantech</td> - <td><code>10A9</code></td> + <td><code>10a9</code></td> </tr> <tr> <td>Pegatron</td> - <td><code>1D4D</code></td> + <td><code>1d4d</code></td> </tr> <tr> <td>Philips</td> @@ -226,31 +226,31 @@ above.</p> </tr> <tr> <td>PMC-Sierra</td> - <td><code>04DA</code></td> + <td><code>04da</code></td> </tr> <tr> <td>Qualcomm</td> - <td><code>05C6</code></td> + <td><code>05c6</code></td> </tr> <tr> <td>SK Telesys</td> - <td><code>1F53</code></td> + <td><code>1f53</code></td> </tr> <tr> <td>Samsung</td> - <td><code>04E8</code></td> + <td><code>04e8</code></td> </tr> <tr> <td>Sharp</td> - <td><code>04DD</code></td> + <td><code>04dd</code></td> </tr> <tr> <td>Sony</td> - <td><code>054C</code></td> + <td><code>054c</code></td> </tr> <tr> <td>Sony Ericsson</td> - <td><code>0FCE</code></td> + <td><code>0fce</code></td> </tr> <tr> <td>Teleepoch</td> @@ -262,6 +262,6 @@ above.</p> </tr> <tr> <td>ZTE</td> - <td><code>19D2</code></td> + <td><code>19d2</code></td> </tr> </table> diff --git a/docs/html/guide/developing/devices/emulator.jd b/docs/html/guide/developing/devices/emulator.jd index 02dcb68..5edd1f5 100644 --- a/docs/html/guide/developing/devices/emulator.jd +++ b/docs/html/guide/developing/devices/emulator.jd @@ -9,28 +9,58 @@ parent.link=index.html <h2>In this document</h2> <ol> <li><a href="#overview">Overview</a></li> + <li><a href="#avds">Android Virtual Devices and the Emulator</a></li> <li><a href="#starting">Starting and Stopping the Emulator</a></li> - <li><a href="#starting">Android Virtual Devices and the Emulator</a></li> - <li><a href="#controlling">Controlling the Emulator</a></li> - <li><a href="#startup-options">Emulator Startup Options</a></li> + <li><a href="#apps">Installing Applications on the Emulator</a></li> + <li><a href="#acceleration">Using Hardware Acceleration</a> + <ol> + <li><a href="#accel-graphics">Configuring Graphics Acceleration</a></li> + <li><a href="#accel-vm">Configuring Virtual Machine Acceleration</a></li> + </ol> + </li> + <li><a href="#sdcard">SD Card Emulation</a> + <ol> + <li><a href="#sdcard-creating">Creating an SD card image</a></li> + <li><a href="#sdcard-files">Copying files to an SD card image</a></li> + <li><a href="#sdcard-loading">Loading an SD card image</a></li> + </ol> + </li> <li><a href="#diskimages">Working with Emulator Disk Images</a> <ol> - <li><a href="#defaultimages">Default Images</a></li> - <li><a href="#runtimeimages">Runtime Images: User Data and SD Card</a></li> - <li><a href="#temporaryimages">Temporary Images</a></li> + <li><a href="#defaultimages">Default image files</a></li> + <li><a href="#runtimeimages">Runtime images: user data and SD card</a></li> + <li><a href="#temporaryimages">Temporary images</a></li> </ol> </li> <li><a href="#emulatornetworking">Emulator Networking</a> <ol> <li><a href="#networkaddresses">Network Address Space</a></li> <li><a href="#networkinglimitations">Local Networking Limitations</a></li> - <li><a href="#redirections">Using Network Redirections</a></li> + <li><a href="#redirection">Using Network Redirection</a></li> <li><a href="#dns">Configuring the Emulator's DNS Settings</a></li> <li><a href="#proxy">Using the Emulator with a Proxy</a></li> <li><a href="#connecting">Interconnecting Emulator Instances</a></li> <li><a href="#calling">Sending a Voice Call or SMS to Another Emulator Instance</a></li> </ol> </li> + <li><a href="#console">Using the Emulator Console</a> + <ol> + <li><a href="#portredirection">Port Redirection</a></li> + <li><a href="#geo">Geo Location Provider Emulation</a></li> + <li><a href="#events">Hardware Events Emulation</a></li> + <li><a href="#power">Device Power Characteristics</a></li> + <li><a href="#netstatus">Network Status</a></li> + <li><a href="#netdelay">Network Delay Emulation</a></li> + <li><a href="#netspeed">Network Speed Emulation</a></li> + <li><a href="#telephony">Telephony Emulation</a></li> + <li><a href="#sms">SMS Emulation</a></li> + <li><a href="#vm">VM State</a></li> + <li><a href="#window">Emulator Window</a></li> + <li><a href="#terminating">Terminating an Emulator Instance</a></li> + </ol> + </li> + <li><a href="#limitations">Emulator Limitations</a></li> + <li><a href="#troubleshooting">Troubleshooting Emulator Problems</a></li> </ol> <h2>See also</h2> @@ -44,7 +74,7 @@ parent.link=index.html <img src="{@docRoot}images/emulator-wvga800l.png" alt="Image of the Android Emulator" width="367" height="349" style="margin-left:2em;float:right;"/> <p>The Android SDK includes a virtual mobile device emulator -that runs on your computer. The emulator lets you prototype, develop, and test +that runs on your computer. The emulator lets you prototype, develop and test Android applications without using a physical device. </p> <p>The Android emulator mimics all of the hardware and software features @@ -52,7 +82,7 @@ of a typical mobile device, except that it cannot place actual phone calls. It provides a variety of navigation and control keys, which you can "press" using your mouse or keyboard to generate events for your application. It also provides a screen in which your application is displayed, together with any other -Android applications running. </p> +active Android applications. </p> <p>To let you model and test your application more easily, the emulator utilizes Android Virtual Device (AVD) configurations. AVDs let you define certain hardware @@ -62,35 +92,34 @@ the emulator, it can use the services of the Android platform to invoke other applications, access the network, play audio and video, store and retrieve data, notify the user, and render graphical transitions and themes. </p> -<p>The emulator also includes a variety of debug capabilities, such as a console -from which you can log kernel output, simulate application interrupts (such as -arriving SMS messages or phone calls), and simulate latency effects and dropouts -on the data channel.</p> +<p>The emulator also includes a variety of debug capabilities, such as a console +from which you can log kernel output, simulate application interrupts (such as +arriving SMS messages or phone calls), and simulate latency effects and dropouts +on the data network.</p> -<h2 id="overview">Overview</h2> +<h2 id="overview">Overview</h2> -<p>The Android emulator is a QEMU-based application that provides a virtual ARM +<p>The Android emulator is an application that provides a virtual mobile device on which you can run your Android applications. It runs a full Android system stack, down to the kernel level, that includes a set of preinstalled applications (such as the dialer) that you can access from your applications. You can choose what version of the Android system you want to run in the emulator by configuring AVDs, and you can also customize the mobile device skin and key mappings. When launching the emulator and at runtime, -you can use a variety of commands and options to control the its behaviors. +you can use a variety of commands and options to control its behavior. </p> -<p>The Android system image distributed in the SDK contains ARM machine code for -the Android Linux kernel, the native libraries, the Dalvik VM, and the various -Android package files (such as for for the Android framework and preinstalled -applications). The emulator's QEMU layers provide dynamic binary translation of -the ARM machine code to the OS and processor architecture of your development -machine. </p> +<p>The Android system images available through the Android SDK Manager contain +code for the Android Linux kernel, the native libraries, the Dalvik VM, and the +various Android packages (such as the Android framework and preinstalled +applications). The emulator provides dynamic binary translation of device +machine code to the OS and processor architecture of your development +machine.</p> -<p>Adding custom capabilities to the underlying QEMU services, the Android -emulator supports many hardware features likely to be found on mobile devices, -including: </p> +<p>The Android emulator supports many hardware features likely to be found on +mobile devices, including: </p> <ul> <li>An ARMv5 CPU and the corresponding memory-management unit (MMU)</li> @@ -101,41 +130,37 @@ buttons)</li> <li>Flash memory partitions (emulated through disk image files on the development machine)</li> <li>A GSM modem, including a simulated SIM Card</li> + <li>A camera, using a webcam connected to your development computer.</li> + <li>Sensors like an accelerometer, using data from a USB-connected Android device.</li> </ul> -<p>The sections below provide more information about the emulator and how to use -it for developing Android applications.</p> - +<p>The following sections describe the emulator and its use for development of Android +applications in more detail.</p> -<a name="avds"></a> -<h2>Android Virtual Devices and the Emulator</h2> +<h2 id="avds">Android Virtual Devices and the Emulator</h2> <p>To use the emulator, you first must create one or more AVD configurations. In each configuration, you specify an Android platform to run in the emulator and the set of hardware options and emulator skin you want to use. Then, when you launch the emulator, you specify the AVD configuration that you want to load. </p> -<p>To specify the AVD you want to load when starting the emulator, you use the -<code>-avd</code> argument, as shown in the previous section. </p> - <p>Each AVD functions as an independent device, with its own private storage for user data, SD card, and so on. When you launch the emulator with an AVD configuration, it automatically loads the user data and SD card data from the AVD directory. By default, the emulator stores the user data, SD card data, and cache in the AVD directory.</p> <p>To create and manage AVDs you use the AVD Manager UI or the <code>android</code> tool -that is included in the SDK. +that is included in the SDK. For complete information about how to set up AVDs, see <a href="{@docRoot}guide/developing/devices/index.html">Managing Virtual Devices</a>.</p> -<a name="starting"></a> -<h2>Starting and Stopping the Emulator</h2> +<h2 id="starting">Starting and Stopping the Emulator</h2> <p>During development and testing of your application, you install and run your application in the Android emulator. You can launch the emulator as a standalone -application, from a command line, or you can use it as part of your Eclipse +application from a command line, or you can run it from within your Eclipse development environment. In either case, you specify the AVD configuration to load and any startup options you want to use, as described in this document. </p> @@ -144,20 +169,24 @@ load and any startup options you want to use, as described in this document. depending on your needs, you can start multiple emulator instances and run your application in more than one emulated device. You can use the emulator's built-in commands to simulate GSM phone calling or SMS between emulator -instances, and you can set up network redirections that allow emulators to send +instances, and you can set up network redirection that allows emulators to send data to one another. For more information, see <a href="#telephony">Telephony Emulation</a>, <a href="#sms">SMS Emulation</a>, and <a href="#emulatornetworking">Emulator Networking</a></p> -<p>To start an instance of the emulator from the command line, change to the +<p>To start an instance of the emulator from the command line, navigate to the <code>tools/</code> folder of the SDK. Enter <code>emulator</code> command like this: </p> -<pre>emulator -avd <avd_name></pre> +<pre>emulator -avd <avd_name> [<options>]</pre> + +<p>This initializes the emulator, loads an AVD configuration and displays the emulator +window. For more information about command line options for the emulator, see the +<a href="{@docRoot}guide/developing/tools/emulator.html">Android Emulator</a> tool reference.</p> -<p>This initializes the emulator and loads an AVD configuration (see the next -section for more information about AVDs). You will see the emulator window -appear on your screen. </p> +<p class="note"><strong>Note:</strong> You can run multiple +instances of the emulator concurrently, each with its own AVD configuration and +storage area for user data, SD card, and so on.</p> <p>If you are working in Eclipse, the ADT plugin for Eclipse installs your application and starts the emulator automatically, when you run or debug @@ -171,585 +200,435 @@ on the Emulator</a> for information about how to install your application.</p> <p>To stop an emulator instance, just close the emulator's window.</p> <p>For a reference of the emulator's startup commands and keyboard mapping, see -the <a href="{@docRoot}guide/developing/tools/emulator.html">Android Emulator</a> document.</p> +the <a href="{@docRoot}guide/developing/tools/emulator.html">Android Emulator</a> tool +reference.</p> + + +<h2 id="apps">Installing Applications on the Emulator</h2> + +<p>If you don't have access to Eclipse or the ADT Plugin, you can install your application on the +emulator using the <a href="{@docRoot}guide/developing/tools/adb.html#move">adb</a> utility. Before +installing the application, you need to build and package it into an <code>.apk</code> as described +in <a href="{@docRoot}guide/developing/building/index.html">Building and +Running Apps</a>. Once the application is installed, you can start the emulator from the command +line as described previously, using any startup options necessary. +When the emulator is running, you can also connect to the emulator instance's +<a href="#console">console</a> to issue commands as needed.</p> + +<p>As you update your code, you periodically package and install it on the emulator. +The emulator preserves the application and its state data across restarts, +in a user-data disk partition. To ensure that the application runs properly +as you update it, you may need to delete the emulator's user-data partition. +To do so, start the emulator with the <code>-wipe-data</code> option. +For more information about the user-data partition and other emulator storage, +see <a href="#diskimages">Working with Emulator Disk Images</a>.</p> +<h2 id="acceleration">Using Hardware Acceleration</h2> +<p>In order to make the Android emulator run faster and be more responsive, you can configure it to +take advantage of hardware acceleration, using a combination of configuration options, specific +Android system images and hardware drivers.</p> -<a name="controlling"></a> +<h3 id="accel-graphics">Configuring Graphics Acceleration</h3> +<p class="caution"><strong>Caution:</strong> As of SDK Tools Revision 17, the graphics +acceleration feature for the emulator is experimental; be alert for incompatibilities and +errors when using this feature. </p> -<h2>Controlling the Emulator</h2> +<p>Graphics acceleration for the emulator takes advantage of your development computer's graphics +hardware, specifically its graphics processing unit (GPU), to make screen drawing faster. To use +the graphics acceleration feature, you must have the following versions of the Android development +tools installed:</p> -<p>You can use emulator <a href="#startup-options">startup options</a> and <a -href="#console">console commands</a> to control the behaviors and -characteristics of the emulated environment itself. -</p> +<ul> + <li>Android SDK Tools, Revision 17 or higher</li> + <li>Android SDK Platform API 15, Revision 3 or higher</li> +</ul> -<p>When the emulator is running, you can interact with the emulated mobile -device just as you would an actual mobile device, except that you use your mouse -pointer to "touch" the touchscreen and your keyboard keys to -"press" the simulated device keys. </p> +<p>Use the <a href="{@docRoot}sdk/installing.html#AddingComponents">Android SDK +Manager</a> to install these components:</p> -<p>The table below summarizes the mappings between the emulator keys and and -the keys of your keyboard. </p> +<p class="note"><strong>Note:</strong> Not all applications are compatible with graphics hardware +acceleration. In particular, the Browser application and applications using the {@link +android.webkit.WebView} component are not compatible with graphics acceleration.</p> -<table border="0" style="clear:left;"> - <tr> - <th>Emulated Device Key </th> - <th>Keyboard Key </th> - </tr> - <tr> - <td>Home</td> - <td>HOME</td> - </tr> - <tr> - <td>Menu (left softkey)</td> - <td>F2 <em>or</em> Page-up button</td> - </tr> - <tr> - <td>Star (right softkey)</td> - <td>Shift-F2 <em>or </em>Page Down</td> - </tr> - <tr> - <td>Back</td> - <td>ESC</td> - </tr> - <tr> - <td>Call/dial button </td> - <td>F3</td> - </tr> - <tr> - <td>Hangup/end call button</td> - <td>F4</td> - </tr> - <tr> - <td>Search</td> - <td>F5 </td> - </tr> - <tr> - <td>Power button</td> - <td>F7 </td> - </tr> - <tr> - <td>Audio volume up button</td> - <td>KEYPAD_PLUS, Ctrl-5</td> - </tr> +<p>To configure an AVD to use graphics acceleration:</p> - <tr> - <td>Audio volume down button</td> - <td>KEYPAD_MINUS, Ctrl-F6</td> - </tr> - <tr> - <td>Camera button</td> - <td>Ctrl-KEYPAD_5, Ctrl-F3</td> - </tr> - <tr> - <td>Switch to previous layout orientation (for example, portrait, landscape)</td> - <td>KEYPAD_7, Ctrl-F11</td> - </tr> - <tr> - <td>Switch to next layout orientation (for example, portrait, landscape)</td> - <td>KEYPAD_9, Ctrl-F12</td> - </tr> - <tr> - <td>Toggle cell networking on/off</td> - <td>F8</td> - </tr> - <tr> - <td>Toggle code profiling</td> - <td>F9 (only with <code>-trace</code> startup option)</td> - </tr> - <tr> - <td>Toggle fullscreen mode</td> - <td>Alt-Enter</td> - </tr> - <tr> - <td>Toggle trackball mode</td> - <td>F6</td> - </tr> - <tr> - <td>Enter trackball mode temporarily (while key is pressed)</td> - <td>Delete</td> - </tr> - <tr> - <td>DPad left/up/right/down</td> - <td>KEYPAD_4/8/6/2</td> - </tr> - <tr> - <td>DPad center click</td> - <td>KEYPAD_5</td> - </tr> - <tr> - <td>Onion alpha increase/decrease</td> - <td>KEYPAD_MULTIPLY(*) / KEYPAD_DIVIDE(/)</td> - </tr> -</table> +<ol> + <li>Make sure you have the required SDK components installed (listed above).</li> + <li>Start the AVD Manager and create a new AVD with the <strong>Target</strong> value of +<strong>Android 4.0.3 (API Level 15)</strong>, revision 3 or higher.</li> + <li>If you want to have graphics acceleration enabled by default for this AVD, in the +<strong>Hardware</strong> section, click <strong>New</strong>, select <strong>GPU emulation</strong> +and set the value to <strong>Yes</strong>. + <p class="note"><strong>Note:</strong> You can also enable graphics acceleration when you +start an emulator using command line options as describe in the next section.</p> + </li> + <li>Name the AVD instance and select any other configuration options. + <p class="caution"><strong>Caution:</strong> Do not select the <strong>Snapshot: Enabled</strong> +option. Snapshots are not supported for emulators with graphics acceleration enabled.</p> + </li> + <li>Click <strong>Create AVD</strong> to save the emulator configuration.</li> +</ol> -<p>Note that, to use keypad keys, you must first disable NumLock on your development computer. </p> +<p>If you set <strong>GPU emulation</strong> to <strong>Yes</strong> for your AVD, then graphics +acceleration is automatically enabled when you run it. If you did not enable <strong>GPU +emulation</strong> when you created the AVD, you can still enable it at runtime.</p> -<h2 id="emulator">Emulator Startup Options</h2> +<p>To enable graphics acceleration at runtime for an AVD:</p> -<p>The emulator supports a variety of options that you can specify -when launching the emulator, to control its appearance or behavior. -Here's the command-line usage for launching the emulator with options: </p> +<ul> + <li>If you are running the emulator from the command line, just include the {@code -gpu on} +option: +<pre>emulator -avd <avd_name> -gpu on</pre> + <p class="note"><strong>Note:</strong> You must specify an AVD configuration that uses +Android 4.0.3 (API Level 15, revision 3) or higher system image target. Graphics acceleration is not +available for earlier system images.</p> + </li> + <li>If you are running the emulator from Eclipse, run your Android application using an AVD with +the {@code -gpu on} option enabled: + <ol> + <li>In Eclipse, click your Android project folder and then select <strong>Run > Run +Configurations...</strong></li> + <li>In the left panel of the <strong>Run Configurations</strong> dialog, select your Android +project run configuration or create a new configuration.</li> + <li>Click the <strong>Target</strong> tab.</li> + <li>Select the AVD you created in the previous procedure.</li> + <li>In the <strong>Additional Emulator Command Line Options</strong> field, enter:<br> + {@code -gpu on}</li> + <li>Run your Android project using this run configuration.</li> + </ol> + </li> +</ul> -<pre>emulator -avd <avd_name> [-<option> [<value>]] ... [-<qemu args>]</pre> -<p>The table below summarizes the available options.</p> +<h3 id="accel-vm">Configuring Virtual Machine Acceleration</h2> -<table> -<tr> - <th width="10%" >Category</th> - <th width="20%" >Option</th> - <th width="30%" >Description</th> - <th width="40%" >Comments</th> -</tr> +<p class="caution"><strong>Caution:</strong> As of SDK Tools Revision 17, the virtual machine +acceleration feature for the emulator is experimental; be alert for incompatibilities and errors +when using this feature.</p> + +<p>Many modern CPUs provide extensions for running virtual machines (VMs) more efficiently. Taking +advantage of these extensions with the Android emulator requires some additional configuration of +your development system, but can significantly improve the execution speed. Before attempting to use +this type of acceleration, you should first determine if your development system’s CPU supports one +of the following virtualization extensions technologies:</p> -<tr> - <td rowspan="9">Help</td> - <td><code>-help</code></td> - <td>Print a list of all emulator options.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-all</code></td> - <td>Print help for all startup options.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-<option></code></td> - <td>Print help for a specific startup option.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-debug-tags</code></td> - <td>Print a list of all tags for <code>-debug <tags></code>.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-disk-images</code></td> - <td>Print help for using emulator disk images.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-environment</code></td> - <td>Print help for emulator environment variables.</td> - <td> </td> -</tr><tr> - <td><code>-help-keys</code></td> - <td>Print the current mapping of keys.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-keyset-file</code></td> - <td>Print help for defining a custom key mappings file.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-virtual-device</code></td> - <td>Print help for Android Virtual Device usage.</td> - <td> </td> -</tr> -<tr> - <td>AVD</td> - <td><code>-avd <avd_name></code> or <br> - <code>@<avd_name></code></td> - <td><strong>Required</strong>. Specifies the AVD to load for this emulator - instance.</td> - <td>You must create an AVD configuration before launching the emulator. For - information, see <a href="{@docRoot}guide/developing/devices/managing-avds.html">Managing - Virtual Devices with AVD Manager</a>.</td> -<tr> - <td rowspan="7">Disk Images</td> - <td><code>-cache <filepath></code></td> - <td>Use <filepath> as the working cache partition image. </td> - <td>Optionally, you can specify a path relative to the current working directory. - If no cache file is specified, the emulator's default behavior is to use a temporary file instead. - <p>For more information on disk images, use <code>-help-disk-images</code>.</p> -</td></tr> -<tr> - <td><code>-data <filepath></code></td> - <td>Use <filepath> as the working user-data disk image. </td> - <td>Optionally, you can specify a path relative to the current working directory. - If <code>-data</code> is not used, the emulator looks for a file named "userdata-qemu.img" - in the storage area of the AVD being used (see <code>-avd</code>). -</td></tr> -<!-- -<tr> - <td><code>-datadir <dir></code></td> - <td>Search for the user-data disk image specified in <code>-data</code> in <dir></td> - <td><code><dir></code> is a path relative to the current working directory. - -<p>If you do not specify <code>-datadir</code>, the emulator looks for the user-data image -in the storage area of the AVD being used (see <code>-avd</code>)</p><p>For more information -on disk images, use <code>-help-disk-images</code>.</p> -</td></tr> ---> -<!-- -<tr> - <td><code>-image <filepath></code></td> - <td>Use <filepath> as the system image.</td> - <td>Optionally, you can specify a path relative to the current working directory. - Default is <system>/system.img.</td> -</tr> ---> -<tr> - <td><code>-initdata <filepath></code></td> - <td>When resetting the user-data image (through <code>-wipe-data</code>), copy the contents - of this file to the new user-data disk image. By default, the emulator copies the <code><system>/userdata.img</code>.</td> - <td>Optionally, you can specify a path relative to the current working directory. See also <code>-wipe-data</code>. - <p>For more information on disk images, use <code>-help-disk-images</code>.</p></td> -</tr> -<!-- -<tr> - <td><code>-kernel <filepath></code></td> - <td>Use <filepath> as the emulated kernel.</td> - <td>Optionally, you can specify a path relative to the current working directory. </td> -</tr> ---> -<tr> - <td><code>-nocache</code></td> - <td>Start the emulator without a cache partition.</td> - <td>See also <code>-cache <file></code>.</td> -</tr> -<tr> - <td><code>-ramdisk <filepath></code></td> - <td>Use <filepath> as the ramdisk image.</td> - <td>Default value is <code><system>/ramdisk.img</code>. - <p>Optionally, you can specify a path relative to the current working directory. - For more information on disk images, use <code>-help-disk-images</code>.</p> -</td> -</tr> -<tr> - <td><code>-sdcard <filepath></code></td> - <td>Use <file> as the SD card image.</td> - <td>Default value is <code><system>/sdcard.img</code>. - <p>Optionally, you can specify a path relative to the current working directory. For more information on disk images, use <code>-help-disk-images</code>.</p> -</td> -</tr> -<!-- -<tr> - <td><code>-system <dirpath></code></td> - <td>Search for system, ramdisk and user data images in <dir>.</td> - <td><code><dir></code> is a directory path relative to the current - working directory.</td> -</tr> ---> -<tr> - <td><code>-wipe-data</code></td> - <td>Reset the current user-data disk image (that is, the file specified by <code>-datadir</code> and - <code>-data</code>, or the default file). The emulator deletes all data from the user data image file, - then copies the contents of the file at <code>-inidata</code> data to the image file before starting. - </td> - <td>See also <code>-initdata</code>. - <p>For more information on disk images, use <code>-help-disk-images</code>.</p> -</td> -</tr> -<tr> - <td rowspan="9">Debug</td> - <td><code>-debug <tags></code></td> - <td>Enable/disable debug messages for the specified debug tags.</td> - <td><code><tags></code> is a space/comma/column-separated list of debug component names. - Use <code>-help-debug-tags</code> to print a list of debug component names that you can use. </td> -</tr> -<tr> - <td><code>-debug-<tag></code></td> - <td>Enable/disable debug messages for the specified debug tag.</td> - <td rowspan="2">Use <code>-help-debug-tags</code> to print a list of debug component names that you can use in <code><tag></code>. </td> -</tr> -<tr> - <td><code>-debug-no-<tag></code></td> - <td>Disable debug messages for the specified debug tag.</td> -</tr> -<tr> - <td><code>-logcat <logtags></code></td> - <td>Enable logcat output with given tags.</td> - <td>If the environment variable ANDROID_LOG_TAGS is defined and not - empty, its value will be used to enable logcat output by default.</td> -</tr> -<tr> - <td><code>-shell</code></td> - <td>Create a root shell console on the current terminal.</td> - <td>You can use this command even if the adb daemon in the emulated system is broken. - Pressing Ctrl-c from the shell stops the emulator instead of the shell.</td> -</tr> -<tr> - <td><code>-shell-serial <device></code></td> - <td>Enable the root shell (as in <code>-shell</code> and specify the QEMU character - device to use for communication with the shell.</td> - <td><device> must be a QEMU device type. See the documentation for '-serial <em>dev</em>' at - <a href="http://wiki.qemu.org/download/qemu-doc.html">http://wiki.qemu.org/download/qemu-doc.html</a> - for a list of device types. - -<p>Here are some examples: </p> <ul> - <li><code>-shell-serial stdio</code> is identical to <code>-shell</code></li> - <li><code>-shell-serial tcp::4444,server,nowait</code> lets you communicate with the shell over TCP port 4444</li> - <li><code>-shell-serial fdpair:3:6</code> lets a parent process communicate with the shell using fds 3 (in) and 6 (out)</li> - <li><code>-shell-serial fdpair:0:1</code> uses the normal stdin and stdout fds, except that QEMU won't tty-cook the data.</li> - </ul> -</td> -</tr> -<tr> - <td><code>-show-kernel <name></code></td> - <td>Display kernel messages.</td> - <td> </td> -</tr> -<tr> - <td><code>-trace <name></code></td> - <td>Enable code profiling (press F9 to start), written to a specified file.</td> - <td> </td> -</tr> -<tr> - <td><code>-verbose</code></td> - <td>Enable verbose output.</td> - <td>Equivalent to <code>-debug-init</code>. -<p>You can define the default verbose output options used by emulator instances in the Android environment variable -ANDROID_VERBOSE. Define the options you want to use in a comma-delimited list, specifying only the stem of each option: -<code>-debug-<tags>.</code> </p> -<p>Here's an example showing ANDROID_VERBOSE defined with the <code>-debug-init</code> and <code>-debug-modem</code> options: -<p><code>ANDROID_VERBOSE=init,modem</code></p> -<p>For more information about debug tags, use <code><-help-debug-tags></code>.</p> -</td> -</tr> -<tr> - <td rowspan="6">Media</td> - <td><code>-audio <backend></code></td> - <td>Use the specified audio backend.</td> - <td> </td> -</tr> -<tr> - <td><code>-audio-in <backend></code></td> - <td>Use the specified audio-input backend.</td> - <td> </td> -</tr> -<tr> - <td><code>-audio-out <backend></code></td> - <td>Use the specified audio-output backend.</td> - <td> </td> -</tr> -<!--<tr> - <td><code>-mic <device or file></code></td> - <td>Use device or WAV file for audio input.</td> - <td> </td> -</tr> ---> -<tr> - <td><code>-noaudio</code></td> - <td>Disable audio support in the current emulator instance.</td> - <td> </td> -</tr> -<tr> - <td><code>-radio <device></code></td> - <td>Redirect radio modem interface to a host character device.</td> - <td> </td></tr> -<tr> - <td><code>-useaudio</code></td> - <td>Enable audio support in the current emulator instance.</td> - <td>Enabled by default. </td> -</tr> + <li>Intel Virtualization Technology (VT, VT-x, vmx) extensions</li> + <li>AMD Virtualization (AMD-V, SVM) extensions (only supported for Linux)</li> +</ul> -<tr> - <td rowspan="7">Network</td> - <td><code>-dns-server <servers></code></td> - <td>Use the specified DNS server(s). </td> - <td>The value of <code><servers></code> must be a comma-separated list of up to 4 DNS server names or - IP addresses.</td> -</tr> -<tr> - <td><code>-http-proxy <proxy></code></td> - <td>Make all TCP connections through a specified HTTP/HTTPS proxy</td> - <td>The value of <code><proxy></code> can be one of the following:<br> - <code>http://<server>:<port></code><br> - <code>http://<username>:<password>@<server>:<port></code> - <p>The <code>http://</code> prefix can be omitted. If the <code>-http-proxy <proxy></code> command is not supplied, - the emulator looks up the <code>http_proxy</code> environment variable and automatically uses any value matching - the <code><proxy></code> format described above.</p></td> -</tr> -<tr> - <td><code>-netdelay <delay></code></td> - <td>Set network latency emulation to <delay>.</td> - <td>Default value is <code>none</code>. See the table in <a href="#netdelay">Network Delay Emulation</a> for - supported <code><delay></code> values. </td> -</tr> -<tr> - <td><code>-netfast</code></td> - <td>Shortcut for <code>-netspeed full -netdelay none</code></td> - <td> </td></tr> -<tr> - <td><code>-netspeed <speed></code></td> - <td>Set network speed emulation to <speed>.</td> - <td>Default value is <code>full</code>. See the table in <a href="#netspeed">Network Speed Emulation</a> for - supported <code><speed></code> values. </td> -</tr> -<tr> - <td><code>-port <port></code></td> - <td>Set the console port number for this emulator instance to <code><port></code>.</td> - <td>The console port number must be an even integer between 5554 and 5584, inclusive. <code><port></code>+1 - must also be free and will be reserved for ADB.</td> -</tr> -<tr> - <td><code>-report-console <socket></code></td> - <td>Report the assigned console port for this emulator instance to a remote third party - before starting the emulation. </td> - <td><code><socket></code> must use one of these formats: +<p>The specifications from the manufacturer of your CPU should indicate if it supports +virtualization extensions. If your CPU does not support one of these virtualization technologies, +then you cannot use virtual machine acceleration.</p> -<p><code>tcp:<port>[,server][,max=<seconds>]</code></br> -<code>unix:<port>[,server][,max=<seconds>]</code></p> +<p class="note"><strong>Note:</strong> Virtualization extensions are typically enabled through +your computer's BIOS and are frequently turned off by default. Check the documentation for your +system's motherboard to find out how to enable virtualization extensions.</p> -<p>Use <code>-help-report-console</code></p> to view more information about this topic. </td> -</tr> -<tr> - <td rowspan="8">System</td> - <td><code>-cpu-delay <delay></code></td> - <td>Slow down emulated CPU speed by <delay> </td> - <td>Supported values for <delay> are integers between 0 and 1000. - -<p>Note that the <delay> does not correlate to clock speed or other absolute metrics -— it simply represents an abstract, relative delay factor applied non-deterministically -in the emulator. Effective performance does not always -scale in direct relationship with <delay> values.</p> -</td> -</tr> -<tr> - <td><code>-gps <device></code></td> - <td>Redirect NMEA GPS to character device.</td> - <td>Use this command to emulate an NMEA-compatible GPS unit connected to - an external character device or socket. The format of <code><device></code> must be QEMU-specific - serial device specification. See the documentation for 'serial -dev' at - <a href="http://wiki.qemu.org/download/qemu-doc.html">http://wiki.qemu.org/download/qemu-doc.html</a>. -</td> -</tr> -<tr> - <td><code>-nojni</code></td> - <td>Disable JNI checks in the Dalvik runtime.</td><td> </td></tr> -<tr> - <td><code>-qemu</code></td> - <td>Pass arguments to qemu.</td> - <td> </td></tr> -<tr> - <td><code>-qemu -h</code></td> - <td>Display qemu help.</td> - <td></td></tr> -<tr> - <td><code>-radio <device></code></td> - <td>Redirect radio mode to the specified character device.</td> - <td>The format of <code><device></code> must be QEMU-specific - serial device specification. See the documentation for 'serial -dev' at -<a href="http://wiki.qemu.org/download/qemu-doc.html">http://wiki.qemu.org/download/qemu-doc.html</a>. -</td> -</tr> -<tr> - <td><code>-timezone <timezone></code></td> - <td>Set the timezone for the emulated device to <timezone>, instead of the host's timezone.</td> - <td><code><timezone></code> must be specified in zoneinfo format. For example: -<p>"America/Los_Angeles"<br> -"Europe/Paris"</p> -</td> -</tr> -<tr> - <td><code>-version</code></td> - <td>Display the emulator's version number.</td> - <td> </td> -</tr> -<tr> - <td rowspan="12">UI</td> - <td><code>-dpi-device <dpi></code></td> - <td>Scale the resolution of the emulator to match the screen size - of a physical device.</td> - <td>The default value is 165. See also <code>-scale</code>.</td> -</tr> -<tr> - <td><code>-no-boot-anim</code></td> - <td>Disable the boot animation during emulator startup.</td> - <td>Disabling the boot animation can speed the startup time for the emulator.</td> -</tr> -<tr> - <td><code>-no-window</code></td> - <td>Disable the emulator's graphical window display.</td> - <td> </td> -</tr> -<tr> - <td><code>-scale <scale></code></td> - <td>Scale the emulator window. </td> - <td><code><scale></code> is a number between 0.1 and 3 that represents the desired scaling factor. You can - also specify scale as a DPI value if you add the suffix "dpi" to the scale value. A value of "auto" - tells the emulator to select the best window size.</td> -</tr> -<tr> - <td><code>-raw-keys</code></td> - <td>Disable Unicode keyboard reverse-mapping.</td> - <td> </td></tr> -<tr> - <td><code>-noskin</code></td> - <td>Don't use any emulator skin.</td> - <td> </td></tr> -<tr> - <td><code>-keyset <file></code></td> - <td>Use the specified keyset file instead of the default.</td> - <td>The keyset file defines the list of key bindings between the emulator and the host keyboard. - For more information, use <code>-help-keyset</code> to print information about this topic. -</td> -</tr> -<tr> - <td><code>-onion <image></code></td> - <td>Use overlay image over screen.</td> - <td>No support for JPEG. Only PNG is supported.</td></tr> -<tr> - <td><code>-onion-alpha <percent></code></td> - <td>Specify onion skin translucency value (as percent). - <td>Default is 50.</td> -</tr> -<tr> - <td><code>-onion-rotation <position></code></td> - <td>Specify onion skin rotation. - <td><code><position></code> must be one of the values 0, 1, 2, 3.</td> -</tr> -<tr> - <td><code>-skin <skinID></code></td> - <td>This emulator option is deprecated. </td> - <td>Please set skin options using AVDs, rather than by using this emulator -option. Using this option may yield unexpected and in some cases misleading -results, since the density with which to render the skin may not be defined. -AVDs let you associate each skin with a default density and override the default -as needed. For more information, see <a -href="{@docRoot}guide/developing/devices/managing-avds.html">Managing Virtual Devices -with AVD Manager</a>. -</td> -</tr> -<tr> - <td><code>-skindir <dir></code></td> - <td>This emulator option is deprecated. </td> - <td>See comments for <code>-skin</code>, above.</td></tr> -</table> +<p>Once you have determined that your CPU supports virtualization extensions, make sure you can work +within these additional requirements of running an emulator inside an accelerated virtual +machine:</p> + +<ul> + <li><strong>x86 AVD Only</strong> - You must use an AVD that is uses an x86 system image target. +AVDs that use ARM-based system images cannot be accelerated using the emulator configurations +described here.</li> + <li><strong>Not Inside a VM</strong> - You cannot run a VM-accelerated emulator inside another +virtual machine, such as a VirtualBox or VMWare-hosted virtual machine. You must run the emulator +directly on your system hardware.</li> + <li><strong>Other VM Drivers</strong> - If you are running another virtualization technology on +your system such as VirtualBox or VMWare, you may need to unload the driver for that virtual machine +hosting software before running an accelerated emulator.</li> + <li><strong>OpenGL® Graphics</strong> - Emulation of OpenGL ES graphics may not perform at the +same level as an actual device.</li> +</ul> + +<p>To use virtual machine acceleration with the emulator, you need the following version of Android +development tools. Use the <a href="{@docRoot}sdk/installing.html#AddingComponents">Android SDK +Manager</a> to install these components:</p> + +<ul> + <li>Android SDK Tools, Revision 17 or higher</li> + <li>Android x86-based system image</li> +</ul> + +<p>If your development environment meets all of the requirements for running a VM-accelerated +emulator, you can use the AVD Manager to create an x86-based AVD configuration:</p> + +<ol> + <li>In the Android SDK Manager, make sure you have an x86-based <strong>System Image</strong> + installed for your target Android version. If you do not have an x86 <strong>System + Image</strong> installed, select one in the Android SDK Manager and install it. + <p class="note"><strong>Tip:</strong> System images are listed under each API Level in the SDK + Manager. An x86 system image may not be available for all API levels.</p> + </li> + <li>Start the AVD Manager and create a new AVD with an x86 value for the +<strong>CPU/ABI</strong> field. You may need to select a specific <strong>Target</strong> value, or +select a <strong>Target</strong> value and then select a specific <strong>CPU/ABI</strong> +option.</li> + <li>Name the emulator instance and select any other configuration options.</li> + <li>Click <strong>Create AVD</strong> to save the emulator configuration.</li> +</ol> + +<h4 id="vm-windows">Configuring VM Acceleration on Windows</h4> + +<p>Virtual machine acceleration for Windows requires the installation of the Intel Hardware +Accelerated Execution Manager (Intel HAXM). The software requires an Intel CPU with +Virtualization Technology (VT) support and one of the following operating systems:</p> + +<ul> + <li>Windows 7 (32/64-bit)</li> + <li>Windows Vista (32/64-bit)</li> + <li>Windows XP (32-bit only)</li> +</ul> + +<p>To install the virtualization driver:</p> + +<ol> + <li>Start the Android SDK Manager, select <strong>Extras</strong> and then select <strong>Intel +Hardware Accelerated Execution Manager</strong>.</li> + <li>After the download completes, execute {@code +<sdk>/extras/intel/Hardware_Accelerated_Execution_Manager/IntelHAXM.exe}.</li> + <li>Follow the on-screen instructions to complete installation.</li> + <li>After installation completes, confirm that the virtualization driver is operating correctly by +opening a command prompt window and running the following command: + <pre>sc query intelhaxm</pre> + <p>You should see a status message including the following information:</p> +<pre> +SERVICE_NAME: intelhaxm + ... + STATE : 4 RUNNING + ... +</pre> + </li> +</ol> + +<p>To run an x86-based emulator with VM acceleration:</p> +<ul> + <li>If you are running the emulator from the command line, just specify an x86-based AVD: +<pre>emulator -avd <avd_name></pre> + <p class="note"><strong>Note:</strong> You must provide an x86-based AVD configuration +name, otherwise VM acceleration will not be enabled.</p> + </li> + <li>If you are running the emulator from Eclipse, run your Android application with an x86-based +AVD: + <ol> + <li>In Eclipse, click your Android project folder and then select <strong>Run > Run +Configurations...</strong></li> + <li>In the left panel of the <strong>Run Configurations</strong> dialog, select your Android +project run configuration or create a new configuration.</li> + <li>Click the <strong>Target</strong> tab.</li> + <li>Select the x86-based AVD you created previously.</li> + <li>Run your Android project using this run configuration.</li> + </ol> + </li> +</ul> + +<p>You can adjust the amount of memory available to the Intel HAXM kernel extension by re-running +its installer.</p> + +<p>You can stop using the virtualization driver by uninstalling it. Re-run the installer or use +the Control Panel to remove the software.</p> + + +<h4 id="vm-mac">Configuring VM Acceleration on Mac</h4> + +<p>Virtual machine acceleration on a Mac requires the installation of the Intel Hardware Accelerated +Execution Manager (Intel HAXM) kernel extension to allow the Android emulator to make use of CPU +virtualization extensions. The kernel extension is compatible with Mac OS X Snow Leopard (version +10.6.0) and higher.</p> + +<p>To install the Intel HAXM kernel extension:</p> + +<ol> + <li>Start the Android SDK Manager, select <strong>Extras</strong> and then select <strong>Intel +Hardware Accelerated Execution Manager</strong>. + <li>After the download completes, execute + {@code <sdk>/extras/intel/Hardware_Accelerated_Execution_Manager/IntelHAXM.dmg}.</li> + <li>Double click the <strong>IntelHAXM.mpkg</strong> icon to begin installation.</li> + <li>Follow the on-screen instructions to complete installation.</li> + <li>After installation completes, confirm that the new kernel extension is operating correctly by +opening a terminal window and running the following command: + <pre>kextstat | grep intel</pre> + <p>You should see a status message containing the following extension name, indicating that the + kernel extension is loaded:</p> + <pre>com.intel.kext.intelhaxm</pre> + </li> +</ol> + +<p>To run an x86-based emulator with VM acceleration:</p> +<ul> + <li>If you are running the emulator from the command line, just specify an x86-based AVD: +<pre>emulator -avd <avd_name></pre> + <p class="note"><strong>Note:</strong> You must provide an x86-based AVD configuration +name, otherwise VM acceleration will not be enabled.</p> + </li> + <li>If you are running the emulator from Eclipse, run your Android application with an x86-based +AVD: + <ol> + <li>In Eclipse, click your Android project folder and then select <strong>Run > Run +Configurations...</strong></li> + <li>In the left panel of the <strong>Run Configurations</strong> dialog, select your Android +project run configuration or create a new configuration.</li> + <li>Click the <strong>Target</strong> tab.</li> + <li>Select the x86-based AVD you created previously.</li> + <li>Run your Android project using this run configuration.</li> + </ol> + </li> +</ul> + +<p>You can adjust the amount of memory available to the Intel HAXM kernel extension by re-running +the installer.</p> + +<p>You can stop using the virtualization kernel driver by uninstalling it. Before removing it, shut +down any running x86 emulators. To unload the virtualization kernel driver, run the following +command in a terminal window:</p> + +<pre>sudo /System/Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh</pre> + +<h4 id="vm-linux">Configuring VM Acceleration on Linux</h4> + +<p>Linux-based systems support virtual machine acceleration through the KVM software package. Follow +<a href="https://www.google.com/?q=kvm+installation">instructions for installing KVM</a> on your +Linux system, and verify that KVM is enabled. In addition to following the installation +instructions, be aware of these configuration requirements:</p> + +<ul> + <li>Running KVM requires specific user permissions, make sure you have sufficient permissions +according to the KVM installation instructions.</li> + <li>If you use another virtualization technology in your Linux platform, unload its kernel driver +before running the x86 emulator. For example, the VirtualBox driver program is {@code vboxdrv}.</li> +</ul> + +<p>To run an x86-based emulator with VM acceleration:</p> + +<ul> + <li>If you are running the emulator from the command line, start the emulator with an x86-based +AVD and include the KVM options: +<pre>emulator -avd <avd_name> -qemu -m 512 -enable-kvm</pre> + <p class="note"><strong>Note:</strong> You must provide an x86-based AVD configuration +name, otherwise VM acceleration will not be enabled.</p> + </li> + <li>If you are running the emulator from Eclipse, run your Android application with an x86-based +AVD and include the KVM options: + <ol> + <li>In Eclipse, click your Android project folder and then select <strong>Run > Run +Configurations...</strong></li> + <li>In the left panel of the <strong>Run Configurations</strong> dialog, select your Android +project run configuration or create a new configuration.</li> + <li>Click the <strong>Target</strong> tab.</li> + <li>Select the x86-based AVD you created previously.</li> + <li>In the <strong>Additional Emulator Command Line Options</strong> field, enter: + <pre>-qemu -m 512 -enable-kvm</pre> + </li> + <li>Run your Android project using this run configuration.</li> + </ol> + </li> +</ul> + +<p class="note"><strong>Important:</strong> When using the {@code -qemu} command line option, make sure +it is the last parameter in your command. All subsequent options are interpreted as qemu-specific +parameters.</p> + + +<h2 id="sdcard">SD Card Emulation</h2> + +<p>You can create a disk image and then load it to the emulator at startup, to +simulate the presence of a user's SD card in the device. To do this, you can specify +an SD card image when you create an AVD, or you can use the mksdcard utility included +in the SDK.</p> + +<p>The following sections describe how to create an SD card disk image, how to copy +files to it, and how to load it in the emulator at startup. </p> + +<p>Note that you can only load a disk image at emulator startup. Similarly, you +can not remove a simulated SD card from a running emulator. However, you can +browse, send files to, and copy/remove files from a simulated SD card either +with adb or the emulator. </p> + +<p>The emulator supports emulated SDHC cards, so you can create an SD card image +of any size up to 128 gigabytes.</p> + + +<h3 id="sdcard-creating">Creating an SD card image</h3> + +<p>There are several ways of creating an SD card image. The easiest way is to use the +<strong>AVD Manager</strong> to create a new SD card by specifying a size when you create an AVD. +You can also use the {@code android} command line tool when creating an AVD. Just add the +<code>-c</code> option to your command: </p> + +<pre>android create avd -n <avd_name> -t <targetID> -c <size>[K|M]</pre> + +<p>The <code>-c</code> option can also be used to to specify a path to an SD card +image for the new AVD. For more information, see <a +href="{@docRoot}guide/developing/devices/managing-avds-cmdline.html">Managing Virtual Devices +from the Command Line</a>. +</p> + +<p>You can also use the mksdcard tool, included in the SDK, to create a FAT32 disk +image that you can load in the emulator at startup. You can access mksdcard in +the tools/ directory of the SDK and create a disk image like this: </p> + +<pre>mksdcard <size> <file></pre> + +<p>For example:</p> + +<pre>mksdcard 1024M sdcard1.iso</pre> + +<p>For more information, see <a +href="{@docRoot}guide/developing/tools/mksdcard.html"><code>mksdcard</code></a>.</p> + + +<h3 id="sdcard-files">Copying files to an SD card image</h3> + +<p>Once you have created the disk image, you can copy files to it prior to +loading it in the emulator. To copy files, you can mount the image as a loop +device and then copy the files to it, or you can use a utility such as {@code mtools} to +copy the files directly to the image. The {@code mtools} package is available for Linux, +Mac, and Windows.</p> + +<p>Alternatively, you can use the {@code adb push} command to move files onto an SD card image +while it is loaded in an emulator. For more information see the <a +href="{@docRoot}guide/developing/tools/adb.html#copyfiles">{@code adb push}</a> documentation.</p> + +<h3 id="sdcard-loading">Loading an SD card image</h3> +<p>By default, the emulator loads the SD card image that is stored with the active +AVD (see the <code>-avd</code> startup option).</p> + +<p>Alternatively, you can start the emulator with the +<code>-sdcard</code> flag and specify the name and path of your image (relative +to the current working directory): </p> + +<pre>emulator -sdcard <filepath></pre> -<a name="diskimages"></a> -<h2>Working with Emulator Disk Images</h2> +<h2 id="diskimages">Working with Emulator Disk Images</h2> <p>The emulator uses mountable disk images stored on your development machine to -simulate flash (or similar) partitions on an actual device. For example, it uses +simulate flash (or similar) partitions on an actual device. For example, it uses a disk image containing an emulator-specific kernel, the Android system, a ramdisk image, and writeable images for user data and simulated SD card.</p> <p>To run properly, the emulator requires access to a specific set of disk image -files. By default, the Emulator always looks for the disk images in the -private storage area of the AVD in use. If no images exist there when -the Emulator is launched, it creates the images in the AVD directory based on +files. By default, the Emulator always looks for the disk images in the +private storage area of the AVD in use. If no images exist there when +the Emulator is launched, it creates the images in the AVD directory based on default versions stored in the SDK. </p> -<p class="note"><strong>Note:</strong> The default storage location for -AVDs is in <code>~/.android/avd</code> on OS X and Linux, <code>C:\Documents and -Settings\<user>\.android\</code> on Windows XP, and +<p class="note"><strong>Note:</strong> The default storage location for +AVDs is in <code>~/.android/avd</code> on OS X and Linux, <code>C:\Documents and +Settings\<user>\.android\</code> on Windows XP, and <code>C:\Users\<user>\.android\</code> on Windows Vista.</p> <p>To let you use alternate or custom versions of the image files, the emulator provides startup options that override the default locations and filenames of -the image files. When you use the options, the emulator searches for the image +the image files. When you use one of these options, the emulator searches for the image file under the image name or location that you specify; if it can not locate the image, it reverts to using the default names and location.</p> @@ -757,20 +636,19 @@ image, it reverts to using the default names and location.</p> image files, and temporary image files. The sections below describe how to override the location/name of each type of file. </p> -<a name="defaultimages"></a> -<h3>Default Images</h3> +<h3 id="defaultimages">Default image files</h3> -<p>When the emulator launches but does not find an existing user data image in +<p>When the emulator launches, but does not find an existing user data image in the active AVD's storage area, it creates a new one from a default version -included in the SDK. The default user data image is read-only. The image +included in the SDK. The default user data image is read-only. The image files are read-only.</p> <p>The emulator provides the <code>-system <dir></code> startup option to -let you override the location under which the emulator looks for the default +let you override the location where the emulator looks for the default user data image. </p> <p>The emulator also provides a startup option that lets you override the name -of the default user data image, as described in the table below. When you use the +of the default user data image, as described in the following table. When you use the option, the emulator looks in the default directory, or in a custom location (if you specified <code>-system <dir></code>). </p> @@ -810,25 +688,24 @@ option, the emulator looks in the default directory, or in a custom location </table> -<a name="runtimeimages"></a> -<h3>Runtime Images: User Data and SD Card</h3> +<h3 id="runtimeimages">Runtime images: user data and SD card</h3> -<p>At runtime, the emulator reads and writes data on two disk images: a -user-data image and (optionally) an SD card image. This emulates the user-data +<p>At runtime, the emulator reads and writes data to two disk images: a +user-data image and (optionally) an SD card image. These images emulate the user-data partition and removable storage media on actual device. </p> -<p>The emulator provides a default user-data disk image. At startup, the emulator -creates the default image as a copy of the system user-data image (user-data.img), +<p>The emulator provides a default user-data disk image. At startup, the emulator +creates the default image as a copy of the system user-data image (user-data.img), described above. The emulator stores the new image with the files of the active AVD.</p> <!-- -<p>The emulator provides a startup option, <code>-datadir <dir></code>, +<p>The emulator provides a startup option, <code>-datadir <dir></code>, that you can use to override the location under which the emulator looks for the runtime image files. </p> --> -<p>The emulator provides startup options to let you override the actual names and storage -locations of the runtime images to load, as described in the table below. When you use one +<p>The emulator provides startup options to let you override the actual names and storage +locations of the runtime images to load, as described in the following table. When you use one of these options, the emulator looks for the specified file(s) in the current working directory, in the AVD directory, or in a custom location (if you specified a path with the filename). </p> @@ -842,7 +719,7 @@ in the AVD directory, or in a custom location (if you specified a path with the <td><code>userdata-qemu.img</code></td> <td>An image to which the emulator writes runtime user-data for a unique user.</td> <td>Override using <code>-data <filepath></code>, where <code><filepath></code> is the -path the image, relative to the current working directory. If you supply a filename only, +path the image, relative to the current working directory. If you supply a filename only, the emulator looks for the file in the current working directory. If the file at <code><filepath></code> does not exist, the emulator creates an image from the default userdata.img, stores it under the name you specified, and persists user data to it at shutdown. </td> @@ -852,7 +729,7 @@ specified, and persists user data to it at shutdown. </td> <td><code>sdcard.img</code></td> <td>An image representing an SD card inserted into the emulated device.</td> <td>Override using <code>-sdcard <filepath></code>, where <code><filepath></code> is the -path the image, relative to the current working directory. If you supply a filename only, +path the image, relative to the current working directory. If you supply a filename only, the emulator looks for the file in the current working directory. </td> </tr> @@ -864,38 +741,38 @@ the emulator looks for the file in the current working directory. </td> session-specific data. For example, it uses the image to store a unique user's installed application data, settings, databases, and files. </p> -<p>At startup, the emulator attempts to load a user-data image stored during -a previous session. It looks for the file in the current working directory, -in the AVD directory as described above, and at the custom location/name +<p>At startup, the emulator attempts to load a user-data image stored during +a previous session. It looks for the file in the current working directory, +in the AVD directory described in a previous section and at the custom location/name that you specified at startup. </p> <ul> -<li>If it finds a user-data image, it mounts the image and makes it available -to the system for reading/writing of user data. </li> +<li>If it finds a user-data image, it mounts the image and makes it available +to the system for reading and writing of user data. </li> <li>If it does not find one, it creates an image by copying the system user-data image (userdata.img), described above. At device power-off, the system persists -the user data to the image, so that it will be available in the next session. +the user data to the image, so that it will be available in the next session. Note that the emulator stores the new disk image at the location/name that you specify in <code>-data</code> startup option.</li> </ul> <p class="note"><strong>Note:</strong> Because of the AVD configurations used in the emulator, -each emulator instance now gets its own dedicated storage. There is no need +each emulator instance gets its own dedicated storage. There is no longer a need to use the <code>-d</code> option to specify an instance-specific storage area.</p> <h4>SD Card</h4> <P>Optionally, you can create a writeable disk image that the emulator can use -to simulate removeable storage in an actual device. For information about how to create an +to simulate removeable storage in an actual device. For information about how to create an emulated SD card and load it in the emulator, see <a href="#sdcard">SD Card Emulation</a></p> <p>You can also use the android tool to automatically create an SD Card image -for you, when creating an AVD. For more information, see <a +for you, when creating an AVD. For more information, see <a href="{@docRoot}guide/developing/devices/managing-avds.html">Managing Virtual Devices with AVD Manager</a>. -<a name="temporaryimages"></a> -<h3>Temporary Images</h3> + +<h3 id="temporaryimages">Temporary Images</h3> <p>The emulator creates two writeable images at startup that it deletes at device power-off. The images are: </p> @@ -909,8 +786,8 @@ device power-off. The images are: </p> persisting it at device power-off. </p> <p>The <code>/cache</code> partition image is initially empty, and is used by -the browser to cache downloaded web pages and images. The emulator provides an -<code>-cache <file></code>, which specifies the name of the file at which +the browser to cache downloaded web pages and images. The emulator provides an +<code>-cache <file></code>, which specifies the name of the file in which to persist the <code>/cache</code> image at device power-off. If <code><file> </code> does not exist, the emulator creates it as an empty file. </p> @@ -918,16 +795,14 @@ to persist the <code>/cache</code> image at device power-off. If <code><file& <code>-nocache</code> option at startup. </p> -<a name="emulatornetworking"></a> -<h2>Emulator Networking</h2> +<h2 id="emulatornetworking">Emulator Networking</h2> <p>The emulator provides versatile networking capabilities that you can use to set up complex modeling and testing environments for your application. The sections below introduce the emulator's network architecture and capabilities. </p> -<a name="networkaddresses"></a> -<h3>Network Address Space</h3> +<h3 id="networkaddresses">Network Address Space</h3> <p>Each instance of the emulator runs behind a virtual router/firewall service that isolates it from your development machine's network interfaces and settings @@ -990,14 +865,13 @@ specific to the Android emulator and will probably be very different on real devices (which are also very likely to be NAT-ed, i.e., behind a router/firewall)</p> -<a name="networkinglimitations"></a> -<h3>Local Networking Limitations</h3> -<p>Each emulator instance runs behind a virtual router, but unlike an actual -device connected to a physical router, the emulated device doesn't have access -to a physical network. Instead it runs as part of a normal application on your -development machine. This means that it is subject to the same networking -limitations as other applications on your machine:</p> +<h3 id="networkinglimitations">Local Networking Limitations</h3> + +<p>Android applications running in an emulator can connect to the network available on your +workstation. However, they connect through the emulator, not directly to hardware, and the emulator +acts like a normal application on your workstation. This means that the emulator, and thus your +Android applications, are subject to some limitations:</p> <ul> <li>Communication with the emulated device may be blocked by a firewall @@ -1016,25 +890,24 @@ host operating system and network.</p> protocols (such as ICMP, used for "ping") might not be supported. Currently, the emulator does not support IGMP or multicast. </p> -<a name="redirections"></a> -<h3>Using Network Redirections</h3> +<h3 id="redirection">Using Network Redirection</h3> <p>To communicate with an emulator instance behind its virtual router, you need -to set up network redirections on the virtual router. Clients can then connect +to set up network redirection on the virtual router. Clients can then connect to a specified guest port on the router, while the router directs traffic to/from that port to the emulated device's host port. </p> -<p>To set up the network redirections, you create a mapping of host and guest +<p>To set up the network redirection, you create a mapping of host and guest ports/addresses on the the emulator instance. There are two ways to set up -network redirections: using emulator console commands and using the ADB tool, as +network redirection: using emulator console commands and using the ADB tool, as described below. </p> -<a name="consoleredir"></a> -<h4>Setting up Redirections through the Emulator Console</h4> + +<h4 id="consoleredir">Setting up Redirection through the Emulator Console</h4> <p>Each emulator instance provides a control console the you can connect to, to issue commands that are specific to that instance. You can use the -<code>redir</code> console command to set up redirections as needed for an +<code>redir</code> console command to set up redirection as needed for an emulator instance. </p> <p>First, determine the console port number for the target emulator instance. @@ -1044,25 +917,25 @@ its console port number, as follows: </p> <pre><code>telnet localhost 5554</code></pre> -<p>Once connected, use the <code>redir</code> command to work with redirections. +<p>Once connected, use the <code>redir</code> command to work with redirection. To add a redirection, use:</p> <pre><code>add <protocol>:<host-port>:<guest-port></code> </pre> -<p>where <code><protocol></code> is either <code>tcp</code> or <code>udp</code>, -and <code><host-port></code> and <code><guest-port></code> sets the +<p>where <code><protocol></code> is either <code>tcp</code> or <code>udp</code>, +and <code><host-port></code> and <code><guest-port></code> sets the mapping between your own machine and the emulated system, respectively. </p> -<p>For example, the following command sets up a redirection that will handle all +<p>For example, the following command sets up a redirection that handles all incoming TCP connections to your host (development) machine on 127.0.0.1:5000 and will pass them through to the emulated system's 10.0.2.15:6000.:</p> <pre>redir add tcp:5000:6000</pre> <p>To delete a redirection, you can use the <code>redir del</code> command. To -list all redirections for a specific instance, you can use <code>redir -list</code>. For more information about these and other console commands, see +list all redirection for a specific instance, you can use <code>redir +list</code>. For more information about these and other console commands, see <a href="#console">Using the Emulator Console</a>. </p> <p>Note that port numbers are restricted by your local environment. this typically @@ -1071,29 +944,28 @@ administrator privileges. Also, you won't be able to set up a redirection for a host port that is already in use by another process on your machine. In that case, <code>redir</code> generates an error message to that effect. </p> -<a name="adbredir"></a> -<h4>Setting Up Redirections through ADB</h4> +<h4 id="adbredir">Setting Up Redirection through ADB</h4> <p>The Android Debug Bridge (ADB) tool provides port forwarding, an alternate -way for you to set up network redirections. For more information, see <a +way for you to set up network redirection. For more information, see <a href="{@docRoot}guide/developing/tools/adb.html#forwardports">Forwarding Ports</a> in the ADB documentation.</p> <p>Note that ADB does not currently offer any way to remove a redirection, except by killing the ADB server.</p> -<a name="dns"></a> -<h3>Configuring the Emulator's DNS Settings</h3> + +<h3 id="dns">Configuring the Emulator's DNS Settings</h3> <p>At startup, the emulator reads the list of DNS servers that your system is currently using. It then stores the IP addresses of up to four servers on this list and sets up aliases to them on the emulated addresses 10.0.2.3, 10.0.2.4, 10.0.2.5 and 10.0.2.6 as needed. </p> -<p>On Linux and OS X, the emulator obtains the DNS server addresses by parsing -the file <code>/etc/resolv.conf</code>. On Windows, the emulator obtains the -addresses by calling the <code>GetNetworkParams()</code> API. Note that this -usually means that the emulator ignores the content of your "hosts" file +<p>On Linux and OS X, the emulator obtains the DNS server addresses by parsing +the file <code>/etc/resolv.conf</code>. On Windows, the emulator obtains the +addresses by calling the <code>GetNetworkParams()</code> API. Note that this +usually means that the emulator ignores the content of your "hosts" file (<code>/etc/hosts</code> on Linux/OS X, <code>%WINDOWS%/system32/HOSTS</code> on Windows).</P> @@ -1104,8 +976,8 @@ list of server names or IP addresses. You might find this option useful if you encounter DNS resolution problems in the emulated network (for example, an "Unknown Host error" message that appears when using the web browser).</p> -<a name="proxy"></a> -<h3>Using the Emulator with a Proxy</h3> + +<h3 id="proxy">Using the Emulator with a Proxy</h3> <p>If your emulator must access the Internet through a proxy server, you can use the <code>-http-proxy <proxy></code> option when starting the emulator, to @@ -1132,18 +1004,18 @@ startup and uses its value automatically, if defined. </p> <p>You can use the <code>-verbose-proxy</code> option to diagnose proxy connection problems.</p> -<a name="connecting"></a> -<h3>Interconnecting Emulator Instances</h3> + +<h3 id="connecting">Interconnecting Emulator Instances</h3> <p>To allow one emulator instance to communicate with another, you must set up -the necessary network redirections as illustrated below. </p> +the necessary network redirection as illustrated below. </p> <p>Assume that your environment is</p> <ul> <li>A is you development machine</li> <li>B is your first emulator instance, running on A</li> - <li>C is your second emulator instance, running on A too</li> + <li>C is your second emulator instance, also running on A</li> </ul> <p>and you want to run a server on B, to which C will connect, here is how you @@ -1168,10 +1040,11 @@ B:10.0.2.15:<serverPort></code></li> <li>C connects to 10.0.2.2:8080</li> </ul> -<a name="calling"></a> -<h3>Sending a Voice Call or SMS to Another Emulator Instance</h3> +<h3 id="calling">Sending a Voice Call or SMS to Another Emulator Instance</h3> -<p>The emulator automatically forwards simulated voice calls and SMS messages from one instance to another. To send a voice call or SMS, you use the dialer application and SMS application (if available) installed on one emulator </p> +<p>The emulator automatically forwards simulated voice calls and SMS messages from one instance to +another. To send a voice call or SMS, use the dialer application or SMS application, respectively, +from one of the emulators.</p> <p>To initiate a simulated voice call to another emulator instance:</p> <ol> @@ -1186,16 +1059,23 @@ B:10.0.2.15:<serverPort></code></li> <p>You can also connect to an emulator instance's console to simulate an incoming voice call or SMS. For more information, see <a href="#telephony">Telephony Emulation</a> and <a href="#sms">SMS Emulation</a>. -<a name="console"></a> -<h2>Using the Emulator Console</h2> +<h2 id="console">Using the Emulator Console</h2> + +<p>Each running emulator instance provides a console that lets you query and control the emulated +device environment. For example, you can use the console to manage port redirection, network +characteristics, and telephony events while your application is running on the emulator. To +access the console and enter commands, use telnet to connect to the console's port number.</p> -<p>Each running emulator instance includes a console facility that lets you dynamically query and control the simulated device environment. For example, you can use the console to dynamically manage port redirections and network characteristics and simulate telephony events. To access the console and enter commands, you use telnet to connect to the console's port number. </p> <p>To connect to the console of any running emulator instance at any time, use this command: </p> <pre>telnet localhost <console-port></pre> -<p>An emulator instance occupies a pair of adjacent ports: a console port and an adb port. The port numbers differ by 1, with the adb port having the higher port number. The console of the first emulator instance running on a given machine uses console port 5554 and adb port 5555. Subsequent instances use port numbers increasing by two — for example, 5556/5557, 5558/5559, and so on. Up to 16 concurrent emulator instances can run a console facility. </p> +<p>An emulator instance occupies a pair of adjacent ports: a console port and an {@code adb} port. +The port numbers differ by 1, with the {@code adb} port having the higher port number. The console +of the first emulator instance running on a given machine uses console port 5554 and {@code adb} +port 5555. Subsequent instances use port numbers increasing by two — for example, 5556/5557, +5558/5559, and so on. Up to 16 concurrent emulator instances can run a console facility. </p> <p>To connect to the emulator console, you must specify a valid console port. If multiple emulator instances are running, you need to determine the console port of the emulator instance you want to connect to. You can find the instance's console port listed in the title of the instance window. For example, here's the window title for an instance whose console port is 5554:</p> @@ -1209,12 +1089,14 @@ B:10.0.2.15:<serverPort></code></li> <p>To exit the console session, use <code>quit</code> or <code>exit</code>.</p> -<p>The sections below describe the major functional areas of the console.</p> +<p>The following sections below describe the major functional areas of the console.</p> + -<a name="portredirection"></a> +<h3 id="portredirection">Port Redirection</h3> + +<p>You can use the console to add and remove port redirection while the emulator is running. After +you connect to the console, manage port redirection by entering the following command:</p> -<h3>Port Redirection</h3> -<p>You can use the console to add and remove port redirections while the emulator is running. After connecting to the console, you can manage port redirections in this way:</p> <pre>redir <list|add|del> </pre> <p>The <code>redir</code> command supports the subcommands listed in the table below. </p> @@ -1225,14 +1107,14 @@ B:10.0.2.15:<serverPort></code></li> <th width="30%" >Description</th> <th width="35%">Comments</th> </tr> - + <tr> <td><code>list</code></td> - <td>List the current port redirections.</td> + <td>List the current port redirection.</td> <td> </td> </tr> - + <tr> <td><code>add <protocol>:<host-port>:<guest-port></code></td> <td>Add a new port redirection.</td> @@ -1244,16 +1126,16 @@ B:10.0.2.15:<serverPort></code></li> <tr> <td><code>del <protocol>:<host-port></code></td> <td>Delete a port redirection.</td> -<td>See above for meanings of <protocol> and <host-port>.</td> +<td>The meanings of <protocol> and <host-port> are listed in the previous row.</td> </tr> </table> -<a name="geo"></a> -<h3>Geo Location Provider Emulation</h3> -<p>The console provides commands to let you set the geo position used by an emulator emulated device. -You can use the <code>geo</code> command to send a simple GPS fix to the emulator, without needing to -use NMEA 1083 formatting. The usage for the command is:</p> +<h3 id="geo">Geo Location Provider Emulation</h3> + +<p>You can use the console to set the geographic location reported to the applications running +inside an emulator. Use the <code>geo</code> command to send a simple GPS fix to the +emulator, with or without NMEA 1083 formatting:</p> <pre>geo <fix|nmea></pre> @@ -1261,11 +1143,11 @@ use NMEA 1083 formatting. The usage for the command is:</p> <table> <tr> - <th width="25%" >Subcommand - <th width="30%" >Description</th> + <th width="25%">Subcommand</th> + <th width="30%">Description</th> <th width="35%">Comments</th> </tr> - + <tr> <td><code>fix <longitude> <latitude> [<altitude>]</code></td> <td>Send a simple GPS fix to the emulator instance.</td> @@ -1278,19 +1160,21 @@ use NMEA 1083 formatting. The usage for the command is:</p> </tr> </table> -<p>You can issue the <code>geo</code> command to fix the GPS location as soon as an emulator instance is running. -The emulator creates a mock location provider that sends it to GPS-aware applications as soon as they start and -register location listeners. Any application can query the location manager to obtain the current GPS fix for the -emulated device by calling: +<p>You can issue the <code>geo</code> command as soon as an emulator instance is running. The +emulator sets the location you enter by creating a mock location provider. This provider responds to +location listeners set by applications, and also supplies the location to the {@link +android.location.LocationManager}. Any application can query the location manager to obtain the +current GPS fix for the emulated device by calling: <pre>LocationManager.getLastKnownLocation("gps")</pre> -<p>For more information about the Location Manager, see {@link android.location.LocationManager} and its methods.</p> +<p>For more information about the Location Manager, see {@link android.location.LocationManager}. +</p> -<a name="events"></a> -<h3>Hardware Events Emulation</h3> +<h3 id="events">Hardware Events Emulation</h3> -<p>You can use the <code>event</code> command to send various events to the emulator.The usage for the command is: </p> +<p>The {@code event} console commands sends hardware events to the emulator. The syntax for this +command is as follows:</p> <pre>event <send|types|codes|text></pre> @@ -1302,7 +1186,7 @@ emulated device by calling: <th width="30%" >Description</th> <th width="35%">Comments</th> </tr> - + <tr> <td><code>send <type>:<code>:<value> [...]</code></td> <td>Send one or more events to the Android kernel. </td> @@ -1315,7 +1199,7 @@ emulated device by calling: </tr> <tr> <td><code>codes <type></code></td> - <td>List all <code><codes></code> string aliases supported by the <code>event</code> + <td>List all <code><codes></code> string aliases supported by the <code>event</code> subcommands for the specified <code><type></code>.</td> <td> </td> </tr> @@ -1326,10 +1210,11 @@ emulated device by calling: </tr> </table> -<a name="power"></a> -<h3>Device Power Characteristics</h3> -<p>You can use the <code>power</code> command to control the simulated power state of the emulator instance.The usage for the command is: </p> +<h3 id="power">Device Power Characteristics</h3> + +<p>The {@code power} command controls the power state reported by the emulator to applications. The +syntax for this command is as follows: </p> <pre>power <display|ac|status|present|health|capacity></pre> @@ -1341,7 +1226,7 @@ emulated device by calling: <th width="30%" >Description</th> <th width="35%">Comments</th> </tr> - + <tr> <td><code>display</code></td> <td>Display battery and charger state.</td> @@ -1375,23 +1260,32 @@ emulated device by calling: </tr> </table> -<a name="netstatus"></a> -<h3>Network Status</h3> + +<h3 id="netstatus">Network Status</h3> <p>You can use the console to check the network status and current delay and speed characteristics. To do so, connect to the console and use the <code>netstatus</code> command. Here's an example of the command and its output. </p> <pre>network status </pre> -<a name="netdelay"></a> -<h3>Network Delay Emulation</h3> -<p>The emulator lets you simulate various network latency levels, so that you can test your application in an environment more typical of the actual conditions in which it will run. You can set a latency level or range at emulator startup or you can use the console to change the latency dynamically, while the application is running in the emulator. </p> -<p>To set latency at emulator startup, use the <code>-netdelay</code> emulator option with a supported <code><delay></code> value, as listed in the table below. Here are some examples:</p> +<h3 id="netdelay">Network Delay Emulation</h3> + +<p>The emulator lets you simulate various network latency levels, so that you can test your +application in an environment more typical of the actual conditions in which it will run. You can +set a latency level or range at emulator startup or you can use the console to change the latency, +while the application is running in the emulator. </p> + +<p>To set latency at emulator startup, use the <code>-netdelay</code> emulator option with a +supported <code><delay></code> value, as listed in the table below. Here are some +examples:</p> + <pre>emulator -netdelay gprs emulator -netdelay 40 100</pre> -<p>To make dynamic changes to network delay while the emulator is running, connect to the console and use the <code>netdelay</code> command with a supported <code><delay></code> value from the table below. </p> +<p>To make changes to network delay while the emulator is running, connect to the console and use +the <code>netdelay</code> command with a supported <code><delay></code> value from the table +below.</p> <pre>network delay gprs</pre> @@ -1401,7 +1295,7 @@ emulator -netdelay 40 100</pre> <tr> <th width="30%" >Value</th> <th width="35%" >Description</th><th width="35%">Comments</th></tr> - + <tr><td><code>gprs</code></td><td>GPRS</td> <td>(min 150, max 550)</td> </tr> @@ -1421,19 +1315,22 @@ emulator -netdelay 40 100</pre> <td> </td></tr> </table> -<a name="netspeed"></a> -<h3>Network Speed Emulation</h3> -<p>The emulator also lets you simulate various network transfer rates. -You can set a transfer rate or range at emulator startup or you can use the console to change the rate dynamically, -while the application is running in the emulator.</p> +<h3 id="netspeed">Network Speed Emulation</h3> + +<p>The emulator also lets you simulate various network transfer rates. +You can set a transfer rate or range at emulator startup or you can use the console to change the +rate, while the application is running in the emulator.</p> <p>To set the network speed at emulator startup, use the <code>-netspeed</code> emulator option with a supported <code><speed></code> value, as listed in the table below. Here are some examples:</p> + <pre>emulator -netspeed gsm emulator -netspeed 14.4 80</pre> -<p>To make dynamic changes to network speed while the emulator is running, connect to the console and use the <code>netspeed</code> command with a supported <code><speed></code> value from the table below. </p> +<p>To make changes to network speed while the emulator is running, connect to the console and use +the <code>netspeed</code> command with a supported <code><speed></code> value from the table +below.</p> <pre>network speed 14.4 80</pre> @@ -1444,7 +1341,7 @@ kilobits/sec):</p> <tr> <th width="30%">Value</th> <th width="35%">Description</th><th width="35%">Comments</th></tr> - + <tr> <td><code>gsm</code></td> <td>GSM/CSD</td><td>(Up: 14.4, down: 14.4)</td></tr> @@ -1476,14 +1373,19 @@ kilobits/sec):</p> <td>Set exact rates for upload and download separately.</td><td></td></tr> </table> -<a name="telephony"></a> -<h3>Telephony Emulation</h3> +<h3 id="telephony">Telephony Emulation</h3> + +<p>The Android emulator includes its own GSM emulated modem that lets you simulate telephony +functions in the emulator. For example, you can simulate inbound phone calls, establish data +connections and terminate them. The Android system handles simulated calls exactly as it would +actual calls. The emulator does not support call audio.</p> + +<p>You can use the {@code gsm} command to access the emulator's telephony functions after connecting +to the console. The syntax for this command is as follows:</p> -<p>The Android emulator includes its own GSM emulated modem that lets you simulate telephony functions in the emulator. For example, you can simulate inbound phone calls and establish/terminate data connections. The Android system handles simulated calls exactly as it would actual calls. The emulator does not support call audio in this release. </p> -<p>You can use the console to access the emulator's telephony functions. After connecting to the console, you can use</p> <pre>gsm <call|accept|busy|cancel|data|hold|list|voice|status> </pre> -<p>to invoke telephony functions. </p> + <p>The <code>gsm</code> command supports the subcommands listed in the table below. </p> <table> <tr> @@ -1559,11 +1461,12 @@ kilobits/sec):</p> </tr> </table> -<a name="sms"></a> -<h3>SMS Emulation</h3> +<h3 id="sms">SMS Emulation</h3> -<p>The Android emulator console lets you generate an SMS message and direct it to an emulator instance. Once you connect to an emulator instance, you can generate an emulated incoming SMS using this command:</p> +<p>The Android emulator console lets you generate an SMS message and direct it to an emulator +instance. Once you connect to an emulator instance, you can generate an emulated incoming SMS using +the following command:</p> <pre>sms send <senderPhoneNumber> <textmessage></pre> @@ -1571,11 +1474,11 @@ kilobits/sec):</p> <p>The console forwards the SMS message to the Android framework, which passes it through to an application that handles that message type. </p> -<a name="vm"></a> -<h3>VM State</h3> +<h3 id="vm">VM State</h3> -<p>You can use the <code>vm</code> command to control the VM on an emulator instance.The usage for the command is: </p> +<p>You can use the <code>vm</code> command to control the VM on an emulator instance. The syntax for +this command is as follows: </p> <pre>vm <start|stop|status></pre> @@ -1583,8 +1486,8 @@ kilobits/sec):</p> <table> <tr> - <th width="25%" >Subcommand </th> - <th width="30%" >Description</th> + <th width="25%">Subcommand</th> + <th width="30%">Description</th> <th width="35%">Comments</th> </tr> <tr> @@ -1605,11 +1508,10 @@ kilobits/sec):</p> </table> -<a name="window"></a> +<h3 id="window">Emulator Window</h3> -<h3>Emulator Window</h3> - -<p>You can use the <code>window</code> command to manage the emulator window. The usage for the command is: </p> +<p>You can use the <code>window</code> command to manage the emulator window. The syntax for this +command is as follows: </p> <pre>window <scale></pre> @@ -1617,158 +1519,53 @@ kilobits/sec):</p> <table> <tr> - <th width="25%" >Subcommand - <th width="30%" >Description</th> + <th width="25%">Subcommand</th> + <th width="30%">Description</th> <th width="35%">Comments</th> </tr> <tr> <td><code>scale <scale></code></td> <td>Scale the emulator window.</td> - <td><scale> must be a number between 0.1 and 3 that describes the desired scaling factor. You can - also specify scale as a DPI value if you add the suffix "dpi" to the scale value. A value of "auto" + <td>A number between 0.1 and 3 that sets the scaling factor. You can + also specify scale as a DPI value if you add the suffix "dpi" to the scale value. A value of "auto" tells the emulator to select the best window size.</td> </tr> </table> -<a name="terminating"></a> - -<h3>Terminating an Emulator Instance</h3> +<h3 id="terminating">Terminating an Emulator Instance</h3> <p>You can terminate an emulator instance through the console, using the <code>kill</code> command.</p> -<a name="skins"></a> - -<h2>Using Emulator Skins</h2> - -<p>The Android SDK includes several Emulator skins that you can use to control the resolution and density of the emulated device's screen. To select a specific skin for running the emulator, create an AVD that uses that skin. Please do not use deprecated emulator options such as <code>-skin</code> to control the skin used by an emulator instance. For more information about AVDs, see <a -href="{@docRoot}guide/developing/devices/index.html">Managing Virtual Devices</a>.</p> - - -<a name="multipleinstances"></a> - -<h2>Running Multiple Emulator Instances</h2> - -<p>Through the AVDs configurations used by the emulator, you can run multiple -instances of the emulator concurrently, each with its own AVD configuration and -storage area for user data, SD card, and so on. You no longer need to use the -<code>-d</code> option when launching the emulator, to point to an -instance-specific storage area. </p> - -<a name="apps"></a> - -<h2>Installing Applications on the Emulator</h2> - -<p>If you don't have access to Eclipse or the ADT Plugin, you can install -your application on the emulator <a href="{@docRoot}guide/developing/tools/adb.html#move">using -the adb utility</a>. Before installing the application, you need to build and package it -into an <code>.apk</code> as described in <a href="{@docRoot}guide/developing/building/index.html">Building and -Running Apps</a>. Once the application is installed, you can start the emulator from the command -line, as described in this document, using any startup options necessary. -When the emulator is running, you can also connect to the emulator instance's -console to issue commands as needed.</p> - -<p>As you update your code, you periodically package and install it on the emulator. -The emulator preserves the application and its state data across restarts, -in a user-data disk partition. To ensure that the application runs properly -as you update it, you may need to delete the emulator's user-data partition. -To do so, start the emulator with the <code>-wipe-data</code> option. -For more information about the user-data partition and other emulator storage, -see <a href="#diskimages">Working with Emulator Disk Images</a>.</p> +<h2 id="limitations">Emulator Limitations</h2> -<a name="sdcard"></a> -<a name="creating"></a> - -<h2>SD Card Emulation</h2> - -<p>You can create a disk image and then load it to the emulator at startup, to -simulate the presence of a user's SD card in the device. To do this, you can use -the android tool to create a new SD card image with a new AVD, or you can use -the mksdcard utility included in the SDK. </p> - -<p>The sections below describe how to create an SD card disk image, how to copy -files to it, and how to load it in the emulator at startup. </p> - -<p>Note that you can only load disk image at emulator startup. Similarly, you -can not remove a simulated SD card from a running emulator. However, you can -browse, send files to, and copy/remove files from a simulated SD card either -with adb or the emulator. </p> - -<p>The emulator supports emulated SDHC cards, so you can create an SD card image -of any size up to 128 gigabytes.</p> - -<h3 id="creatinga">Creating an SD card image using the android tool</h3> - -<p>The easiest way to create a new SD card is to use the android tool. When -creating an AVD, you simply specify the <code>-c</code> option, like this: </p> - -<pre>android create avd -n <avd_name> -t <targetID> -c <size>[K|M]</pre> - -<p>You can also use the <code>-c</code> option to specify a path to an SD card -image to use in the new AVD. For more information, see <a -href="{@docRoot}guide/developing/devices/managing-avds-cmdline.html">Managing Virtual Devices -from the Command Line</a>. -</p> - -<h3 id="creatingm">Creating an SD card image using mksdcard</h3> - -<p>You can use the mksdcard tool, included in the SDK, to create a FAT32 disk -image that you can load in the emulator at startup. You can access mksdcard in -the tools/ directory of the SDK and create a disk image like this: </p> - -<pre>mksdcard <size> <file></pre> - -<p>For example:</p> - -<pre>mksdcard 1024M sdcard1.iso</pre> - -<p>For more information, see <a href="{@docRoot}guide/developing/tools/mksdcard.html"><code>mksdcard</code></a>.</p> - -<a name="copying"></a> -<h3>Copying Files to a Disk Image</h3> - -<p>Once you have created the disk image, you can copy files to it prior to -loading it in the emulator. To copy files, you can mount the image as a loop -device and then copy the files to it, or you can use a utility such as mtools to -copy the files directly to the image. The mtools package is available for Linux, -Mac, and Windows.</p> - -<a name="loading"></a> -<a name="step3" id="step3"></a> - -<h3>Loading the Disk Image at Emulator Startup</h3> - -<p>By default, the emulator loads the SD card image that is stored with the active -AVD (see the <code>-avd</code> startup option).</p> - -<p>Alternatively, you ca start the emulator with the -<code>-sdcard</code> flag and specify the name and path of your image (relative -to the current working directory): </p> - -<pre>emulator -sdcard <filepath></pre> +<p>The functional limitations of the emulator include: </p> +<ul> + <li>No support for placing or receiving actual phone calls. You can simulate phone calls (placed + and received) through the emulator console, however. </li> + <li>No support for USB connections</li> + <li>No support for device-attached headphones</li> + <li>No support for determining network connected state</li> + <li>No support for determining battery charge level and AC charging state</li> + <li>No support for determining SD card insert/eject</li> + <li>No support for Bluetooth</li> +</ul> -<a name="troubleshooting"></a> -<h2>Troubleshooting Emulator Problems</h2> +<h2 id="troubleshooting">Troubleshooting Emulator Problems</h2> -<p>The adb utility sees the emulator as an actual physical device. For this reason, you might have to use the -d flag with some common adb commands, such as <code>install</code>. The -d flag lets you specify which of several connected devices to use as the target of a command. If you don't specify -d, the emulator will target the first device in its list. For more information about adb, see <a href="{@docRoot}guide/developing/tools/adb.html">Android Debug Bridge</a>.</p> +<p>The {@code adb} utility sees the emulator as an actual physical device. For this reason, you +might have to use the {@code -d} flag with some common {@code adb} commands, such as +<code>install</code>. The {@code -d} flag lets you specify which of several connected devices to use +as the target of a command. If you don't specify {@code -d}, the emulator targets the first +device in its list. For more information about {@code adb}, see <a +href="{@docRoot}guide/developing/tools/adb.html">Android Debug Bridge</a>.</p> -<p>For emulators running on Mac OS X, if you see an error "Warning: No DNS servers found" when starting the emulator, check to see whether you have an <code>/etc/resolv.conf</code> file. If not, please run the following line in a command window:</p> +<p>For emulators running on Mac OS X, if you see an error {@code Warning: No DNS servers found} +when starting the emulator, check to see whether you have an <code>/etc/resolv.conf</code> file. If +not, please run the following line in a command window:</p> <pre>ln -s /private/var/run/resolv.conf /etc/resolv.conf</pre> -<p>See <a href="{@docRoot}resources/faq/index.html">Frequently Asked Questions</a> for more troubleshooting information. </p> - -<a name="limitations"></a> - <h2>Emulator Limitations</h2> - <p>In this release, the limitations of the emulator include: </p> - <ul> - <li>No support for placing or receiving actual phone calls. You can simulate phone calls (placed and received) through the emulator console, however. </li> - <li>No support for USB connections</li> - <li>No support for camera/video capture (input).</li> - <li>No support for device-attached headphones</li> - <li>No support for determining connected state</li> - <li>No support for determining battery charge level and AC charging state</li> - <li>No support for determining SD card insert/eject</li> - <li>No support for Bluetooth</li> - </ul> +<p>See <a href="{@docRoot}resources/faq/index.html">Frequently Asked Questions</a> for more +troubleshooting information. </p> diff --git a/docs/html/guide/developing/devices/index.jd b/docs/html/guide/developing/devices/index.jd index a7d00f3..64651a1 100644 --- a/docs/html/guide/developing/devices/index.jd +++ b/docs/html/guide/developing/devices/index.jd @@ -7,9 +7,9 @@ page.title=Managing Virtual Devices <p>The easiest way to create an AVD is to use the graphical <a href= "{@docRoot}guide/developing/devices/managing-avds.html">AVD Manager</a>, which you launch - from Eclipse by clicking <strong>Window > Android SDK and AVD Manager</strong>. You can also start - the AVD Manager from the command line by calling the <code>android</code> tool in the <strong>tools</strong> - directory of the Android SDK.</p> + from Eclipse by clicking <strong>Window > AVD Manager</strong>. You can also start the AVD +Manager from the command line by calling the <code>android</code> tool with the <code>avd</code> +options, from the <strong><sdk>/tools/</strong> directory.</p> <p>You can also create AVDs on the command line by passing the <code>android</code> tool options. For more information on how to create AVDs in this manner, see <a href= diff --git a/docs/html/guide/developing/devices/managing-avds.jd b/docs/html/guide/developing/devices/managing-avds.jd index e70a0bb..412bd91 100644 --- a/docs/html/guide/developing/devices/managing-avds.jd +++ b/docs/html/guide/developing/devices/managing-avds.jd @@ -42,8 +42,8 @@ parent.link=index.html <li>Start the AVD Manager: <ul> - <li>In Eclipse: select <strong>Window > Android SDK and AVD Manager</strong>, or click - the Android SDK and AVD Manager icon in the Eclipse toolbar.</li> + <li>In Eclipse: select <strong>Window > AVD Manager</strong>, or click + the AVD Manager icon in the Eclipse toolbar.</li> <li>In other IDEs: Navigate to your SDK's <code>tools/</code> directory and execute the <code>android</code> tool with no arguments.</li> @@ -72,7 +72,7 @@ parent.link=index.html <li>Click <strong>Create AVD</strong>.</li> </ol> - <p>Your AVD is now ready and you can either close the SDK and AVD Manager, create more AVDs, or + <p>Your AVD is now ready and you can either close the AVD Manager, create more AVDs, or launch an emulator with the AVD by selecting a device and clicking <strong>Start</strong>.</p> <h3 id="hardwareopts">Hardware options</h3> diff --git a/docs/html/guide/developing/projects/index.jd b/docs/html/guide/developing/projects/index.jd index 63e67cd..b16e466 100644 --- a/docs/html/guide/developing/projects/index.jd +++ b/docs/html/guide/developing/projects/index.jd @@ -209,8 +209,8 @@ used.</dd> application uses code and resources from an example library project called TicTacToeLib.</p> <p>To download the sample applications and run them as projects in - your environment, use the <em>Android SDK and AVD Manager</em> to download the "Samples for - SDK API 8" (or later) component into your SDK.</p> + your environment, use the <em>Android SDK Manager</em> to download the "Samples for + SDK API 8" (or later) package into your SDK.</p> <p>For more information and to browse the code of the samples, see the <a href="{@docRoot}resources/samples/TicTacToeMain/index.html">TicTacToeMain @@ -227,8 +227,8 @@ used.</dd> <p class="note"><strong>Note:</strong> You need SDK Tools r14 or newer to use the new library project feature that generates each library project into its own JAR file. You can download the tools and platforms using the - <em>Android SDK and AVD Manager</em>, as described in - <a href="{@docRoot}sdk/adding-components.html">Adding SDK Components</a>.</p> + <em>Android SDK Manager</em>, as described in + <a href="{@docRoot}sdk/adding-components.html">Adding SDK Packages</a>.</p> <p>If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and diff --git a/docs/html/guide/developing/testing/testing_otheride.jd b/docs/html/guide/developing/testing/testing_otheride.jd index 93af979..7745ae7 100644 --- a/docs/html/guide/developing/testing/testing_otheride.jd +++ b/docs/html/guide/developing/testing/testing_otheride.jd @@ -209,7 +209,7 @@ $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAnd <p> To update a test project with the <code>android</code> tool, enter: </p> -<pre>android update-test-project -m <main_path> -p <test_path></pre> +<pre>android update test-project -m <main_path> -p <test_path></pre> <table> <tr> diff --git a/docs/html/guide/developing/tools/adt.jd b/docs/html/guide/developing/tools/adt.jd index e48a5ae..d473e85 100644 --- a/docs/html/guide/developing/tools/adt.jd +++ b/docs/html/guide/developing/tools/adt.jd @@ -102,9 +102,8 @@ Project site.</p> (<strong>Window > Open Perspective > Traceview</strong>). </li> <li><a href="{@docRoot}guide/developing/tools/android.html">android</a>: Provides access to - the Android SDK and AVD Manager. Other <code>android</code> features such as creating or - updating projects (application and library) are integrated throughout the Eclipse IDE - (<strong>Window > Android SDK and AVD Manager</strong>). </li> + the Android SDK Manager and AVD Manager. Other <code>android</code> features such as creating or + updating projects (application and library) are integrated throughout the Eclipse IDE. </li> <li><a href="{@docRoot}guide/developing/debugging/debugging-ui.html#HierarchyViewer">Hierarchy Viewer</a>: Allows you to visualize your application's view hierarchy to find inefficiencies diff --git a/docs/html/guide/developing/tools/android.jd b/docs/html/guide/developing/tools/android.jd index a67012f..295a720 100644 --- a/docs/html/guide/developing/tools/android.jd +++ b/docs/html/guide/developing/tools/android.jd @@ -15,9 +15,16 @@ Line</a>.</li> the Command Line</a>.</li> <li>Update your Android SDK with new platforms, add-ons, and documentation. See <a href= - "{@docRoot}sdk/adding-components.html">Adding SDK Components</a>.</li> + "{@docRoot}sdk/adding-components.html">Adding SDK Packages</a>.</li> </ul>If you are using Eclipse, the <code>android</code> tool's features are integrated into ADT, so you should not need to use this tool directly. + + <p class="note"><strong>Note:</strong> The documentation of options below is not exhaustive +and may be out of date. For the most current list of options, execute <code>android +--help</code>.</p> + + + <h2>Syntax</h2> <pre>android [global options] action [action options]</pre> @@ -52,6 +59,26 @@ Line</a>.</li> </tr> <tr> + <td rowspan="6"><code>avd</code></td> + + <td>None</td> + + <td>Launch the AVD Manager</td> + + <td></td> + </tr> + + <tr> + <td rowspan="6"><code>sdk</code></td> + + <td>None</td> + + <td>Launch the Android SDK Manager</td> + + <td></td> + </tr> + + <tr> <td rowspan="6"><code>create avd</code></td> <td><code>-n <name></code></td> diff --git a/docs/html/guide/developing/tools/emulator.jd b/docs/html/guide/developing/tools/emulator.jd index 5151ec1..21d4263 100644 --- a/docs/html/guide/developing/tools/emulator.jd +++ b/docs/html/guide/developing/tools/emulator.jd @@ -8,8 +8,8 @@ parent.link=index.html <h2>In this document</h2> <ol> - <li><a href="#startup-options">Emulator Startup Options</a></li> - <li><a href="#KeyMapping">Emulator Keyboard Mapping</a></li> + <li><a href="#KeyMapping">Keyboard Commands</a></li> + <li><a href="#startup-options">Command Line Parameters</a></li> </ol> <h2>See also</h2> @@ -22,30 +22,123 @@ parent.link=index.html </div> -<p>The Android SDK includes a mobile device emulator — a virtual mobile device +<p>The Android SDK includes a mobile device emulator — a virtual mobile device that runs on your computer. The emulator lets you develop and test Android applications without using a physical device.</p> -<p>When the emulator is running, you can interact with the emulated mobile -device just as you would an actual mobile device, except that you use your mouse -pointer to "touch" the touchscreen and can use some keyboard keys to -invoke certain keys on the device. </p> - -<p>This document is a reference to the available command line options and the keyboard mapping to device keys. -For a complete guide to using the Android Emulator, see +<p>This document is a reference to the available command line options and the keyboard mapping to +device keys. +For a complete guide to using the Android Emulator, see <a href="{@docRoot}guide/developing/devices/emulator.html">Using the Android Emulator</a>. -<h2 id="startup-options">Emulator Startup Options</h2> +<h2 id="KeyMapping">Keyboard Commands</h2> -<p>The emulator supports a variety of options that you can specify -when launching the emulator, to control its appearance or behavior. -Here's the command-line usage for launching the emulator with options: </p> +<p>Table 1 summarizes the mappings between the emulator keys and the keys of your keyboard.</p> + +<p class="table-caption"><strong>Table 1.</strong> Emulator keyboard mapping</p> +<table border="0" style="clear:left;"> + <tr> + <th>Emulated Device Key </th> + <th>Keyboard Key </th> + </tr> + <tr> + <td>Home</td> + <td>HOME</td> + </tr> + <tr> + <td>Menu (left softkey)</td> + <td>F2 <em>or</em> Page-up button</td> + </tr> + <tr> + <td>Star (right softkey)</td> + <td>Shift-F2 <em>or </em>Page Down</td> + </tr> + <tr> + <td>Back</td> + <td>ESC</td> + </tr> + <tr> + <td>Call/dial button </td> + <td>F3</td> + </tr> + <tr> + <td>Hangup/end call button</td> + <td>F4</td> + </tr> + <tr> + <td>Search</td> + <td>F5 </td> + </tr> + <tr> + <td>Power button</td> + <td>F7 </td> + </tr> + <tr> + <td>Audio volume up button</td> + <td>KEYPAD_PLUS, Ctrl-F5</td> + </tr> + + <tr> + <td>Audio volume down button</td> + <td>KEYPAD_MINUS, Ctrl-F6</td> + </tr> + <tr> + <td>Camera button</td> + <td>Ctrl-KEYPAD_5, Ctrl-F3</td> + </tr> + <tr> + <td>Switch to previous layout orientation (for example, portrait, landscape)</td> + <td>KEYPAD_7, Ctrl-F11</td> + </tr> + <tr> + <td>Switch to next layout orientation (for example, portrait, landscape)</td> + <td>KEYPAD_9, Ctrl-F12</td> + </tr> + <tr> + <td>Toggle cell networking on/off</td> + <td>F8</td> + </tr> + <tr> + <td>Toggle code profiling</td> + <td>F9 (only with <code>-trace</code> startup option)</td> + </tr> + <tr> + <td>Toggle fullscreen mode</td> + <td>Alt-Enter</td> + </tr> + <tr> + <td>Toggle trackball mode</td> + <td>F6</td> + </tr> + <tr> + <td>Enter trackball mode temporarily (while key is pressed)</td> + <td>Delete</td> + </tr> + <tr> + <td>DPad left/up/right/down</td> + <td>KEYPAD_4/8/6/2</td> + </tr> + <tr> + <td>DPad center click</td> + <td>KEYPAD_5</td> + </tr> + <tr> + <td>Onion alpha increase/decrease</td> + <td>KEYPAD_MULTIPLY(*) / KEYPAD_DIVIDE(/)</td> + </tr> +</table> -<pre>emulator -avd <avd_name> [-<option> [<value>]] ... [-<qemu args>]</pre> -<p class="table-caption"><strong>Table 1.</strong>Emulator startup options</p> +<h2 id="startup-options">Command Line Parameters</h2> +<p>The emulator supports a variety of options that you can specify +when launching the emulator, to control its appearance or behavior. +Here's the command-line syntax of the options available to the {@code emulator} program:</p> + +<pre>emulator -avd <avd_name> [-<option> [<value>]] ... [-<qemu args>]</pre> + +<p class="table-caption"><strong>Table 2.</strong> Emulator command line parameters</p> <table> <tr> <th width="10%" >Category</th> @@ -55,106 +148,55 @@ Here's the command-line usage for launching the emulator with options: </p> </tr> <tr> - <td rowspan="9">Help</td> - <td><code>-help</code></td> - <td>Print a list of all emulator options.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-all</code></td> - <td>Print help for all startup options.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-<option></code></td> - <td>Print help for a specific startup option.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-debug-tags</code></td> - <td>Print a list of all tags for <code>-debug <tags></code>.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-disk-images</code></td> - <td>Print help for using emulator disk images.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-environment</code></td> - <td>Print help for emulator environment variables.</td> - <td> </td> -</tr><tr> - <td><code>-help-keys</code></td> - <td>Print the current mapping of keys.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-keyset-file</code></td> - <td>Print help for defining a custom key mappings file.</td> - <td> </td> -</tr> -<tr> - <td><code>-help-virtual-device</code></td> - <td>Print help for Android Virtual Device usage.</td> - <td> </td> -</tr> -<tr> <td>AVD</td> <td><code>-avd <avd_name></code> or <br> <code>@<avd_name></code></td> <td><strong>Required</strong>. Specifies the AVD to load for this emulator instance.</td> <td>You must create an AVD configuration before launching the emulator. For - information, see <a href="{@docRoot}guide/developing/devices/managing-avds.html#createavd"> - Managing AVDs with AVD Manager</a>.</td> + information, see <a href="{@docRoot}guide/developing/devices/managing-avds.html">Managing + AVDs with AVD Manager</a>.</td> <tr> <td rowspan="7">Disk Images</td> <td><code>-cache <filepath></code></td> <td>Use <filepath> as the working cache partition image. </td> - <td>Optionally, you can specify a path relative to the current working directory. + <td>An absolute or relative path to the current working directory. If no cache file is specified, the emulator's default behavior is to use a temporary file instead. <p>For more information on disk images, use <code>-help-disk-images</code>.</p> </td></tr> <tr> <td><code>-data <filepath></code></td> - <td>Use <filepath> as the working user-data disk image. </td> - <td>Optionally, you can specify a path relative to the current working directory. - If <code>-data</code> is not used, the emulator looks for a file named "userdata-qemu.img" - in the storage area of the AVD being used (see <code>-avd</code>). + <td>Use {@code <filepath>} as the working user-data disk image. </td> + <td>Optionally, you can specify a path relative to the current working directory. + If <code>-data</code> is not used, the emulator looks for a file named {@code userdata-qemu.img} + in the storage area of the AVD being used (see <code>-avd</code>). </td></tr> <!-- <tr> <td><code>-datadir <dir></code></td> <td>Search for the user-data disk image specified in <code>-data</code> in <dir></td> - <td><code><dir></code> is a path relative to the current working directory. + <td><code><dir></code> is a path relative to the current working directory. -<p>If you do not specify <code>-datadir</code>, the emulator looks for the user-data image -in the storage area of the AVD being used (see <code>-avd</code>)</p><p>For more information +<p>If you do not specify <code>-datadir</code>, the emulator looks for the user-data image +in the storage area of the AVD being used (see <code>-avd</code>)</p><p>For more information on disk images, use <code>-help-disk-images</code>.</p> </td></tr> --> -<!-- +<!-- <tr> <td><code>-image <filepath></code></td> <td>Use <filepath> as the system image.</td> - <td>Optionally, you can specify a path relative to the current working directory. + <td>Optionally, you can specify a path relative to the current working directory. Default is <system>/system.img.</td> </tr> --> <tr> <td><code>-initdata <filepath></code></td> - <td>When resetting the user-data image (through <code>-wipe-data</code>), copy the contents + <td>When resetting the user-data image (through <code>-wipe-data</code>), copy the contents of this file to the new user-data disk image. By default, the emulator copies the <code><system>/userdata.img</code>.</td> - <td>Optionally, you can specify a path relative to the current working directory. See also <code>-wipe-data</code>. <p>For more information on disk images, use <code>-help-disk-images</code>.</p></td> -</tr> -<!-- -<tr> - <td><code>-kernel <filepath></code></td> - <td>Use <filepath> as the emulated kernel.</td> - <td>Optionally, you can specify a path relative to the current working directory. </td> + <td>Optionally, you can specify a path relative to the current working directory. See also <code>-wipe-data</code>. + <p>For more information on disk images, use <code>-help-disk-images</code>.</p></td> </tr> ---> <tr> <td><code>-nocache</code></td> <td>Start the emulator without a cache partition.</td> @@ -163,8 +205,9 @@ on disk images, use <code>-help-disk-images</code>.</p> <tr> <td><code>-ramdisk <filepath></code></td> <td>Use <filepath> as the ramdisk image.</td> - <td>Default value is <code><system>/ramdisk.img</code>. - <p>Optionally, you can specify a path relative to the current working directory. For more information on disk images, use <code>-help-disk-images</code>.</p> + <td>Default value is <code><system>/ramdisk.img</code>. + <p>Optionally, you can specify a path relative to the current working directory. + For more information on disk images, use <code>-help-disk-images</code>.</p> </td> </tr> <tr> @@ -178,17 +221,17 @@ on disk images, use <code>-help-disk-images</code>.</p> <tr> <td><code>-system <dirpath></code></td> <td>Search for system, ramdisk and user data images in <dir>.</td> - <td><code><dir></code> is a directory path relative to the current + <td><code><dir></code> is a directory path relative to the current working directory.</td> </tr> --> <tr> <td><code>-wipe-data</code></td> - <td>Reset the current user-data disk image (that is, the file specified by <code>-datadir</code> and - <code>-data</code>, or the default file). The emulator deletes all data from the user data image file, - then copies the contents of the file at <code>-inidata</code> data to the image file before starting. + <td>Reset the current user-data disk image (that is, the file specified by <code>-datadir</code> and + <code>-data</code>, or the default file). The emulator deletes all data from the user data image file, + then copies the contents of the file at <code>-inidata</code> data to the image file before starting. </td> - <td>See also <code>-initdata</code>. + <td>See also <code>-initdata</code>. <p>For more information on disk images, use <code>-help-disk-images</code>.</p> </td> </tr> @@ -196,7 +239,7 @@ on disk images, use <code>-help-disk-images</code>.</p> <td rowspan="9">Debug</td> <td><code>-debug <tags></code></td> <td>Enable/disable debug messages for the specified debug tags.</td> - <td><code><tags></code> is a space/comma/column-separated list of debug component names. + <td><code><tags></code> is a space/comma/column-separated list of debug component names. Use <code>-help-debug-tags</code> to print a list of debug component names that you can use. </td> </tr> <tr> @@ -217,16 +260,16 @@ on disk images, use <code>-help-disk-images</code>.</p> <tr> <td><code>-shell</code></td> <td>Create a root shell console on the current terminal.</td> - <td>You can use this command even if the adb daemon in the emulated system is broken. + <td>You can use this command even if the adb daemon in the emulated system is broken. Pressing Ctrl-c from the shell stops the emulator instead of the shell.</td> </tr> <tr> <td><code>-shell-serial <device></code></td> - <td>Enable the root shell (as in <code>-shell</code> and specify the QEMU character + <td>Enable the root shell (as in <code>-shell</code> and specify the QEMU character device to use for communication with the shell.</td> - <td><device> must be a QEMU device type. See the documentation for '-serial <em>dev</em>' at - <a href="http://wiki.qemu.org/download/qemu-doc.html">wiki.qemu.org</a> - for more information.</p> + <td><device> must be a QEMU device type. See the documentation for '-serial <em>dev</em>' at + <a href="http://wiki.qemu.org/download/qemu-doc.html">http://wiki.qemu.org/download/qemu-doc.html</a> + for a list of device types. <p>Here are some examples: </p> <ul> @@ -250,11 +293,11 @@ on disk images, use <code>-help-disk-images</code>.</p> <tr> <td><code>-verbose</code></td> <td>Enable verbose output.</td> - <td>Equivalent to <code>-debug-init</code>. -<p>You can define the default verbose output options used by emulator instances in the Android environment variable -ANDROID_VERBOSE. Define the options you want to use in a comma-delimited list, specifying only the stem of each option: + <td>Equivalent to <code>-debug-init</code>. +<p>You can define the default verbose output options used by emulator instances in the Android environment variable +ANDROID_VERBOSE. Define the options you want to use in a comma-delimited list, specifying only the stem of each option: <code>-debug-<tags>.</code> </p> -<p>Here's an example showing ANDROID_VERBOSE defined with the <code>-debug-init</code> and <code>-debug-modem</code> options: +<p>Here's an example showing ANDROID_VERBOSE defined with the <code>-debug-init</code> and <code>-debug-modem</code> options: <p><code>ANDROID_VERBOSE=init,modem</code></p> <p>For more information about debug tags, use <code><-help-debug-tags></code>.</p> </td> @@ -316,8 +359,9 @@ ANDROID_VERBOSE. Define the options you want to use in a comma-delimited list, s <tr> <td><code>-netdelay <delay></code></td> <td>Set network latency emulation to <delay>.</td> - <td>Default value is <code>none</code>. See the table in <a href="#netdelay">Network Delay Emulation</a> for - supported <code><delay></code> values. </td> + <td>Default value is <code>none</code>. See the table in + <a href="{@docRoot}guide/developing/devices/emulator.html#netdelay">Network Delay Emulation</a> + for supported <code><delay></code> values. </td> </tr> <tr> <td><code>-netfast</code></td> @@ -326,18 +370,19 @@ ANDROID_VERBOSE. Define the options you want to use in a comma-delimited list, s <tr> <td><code>-netspeed <speed></code></td> <td>Set network speed emulation to <speed>.</td> - <td>Default value is <code>full</code>. See the table in <a href="#netspeed">Network Speed Emulation</a> for + <td>Default value is <code>full</code>. See the table in + <a href="{@docRoot}guide/developing/devices/emulator.html#netspeed">Network Speed Emulation</a> for supported <code><speed></code> values. </td> </tr> <tr> <td><code>-port <port></code></td> <td>Set the console port number for this emulator instance to <code><port></code>.</td> - <td>The console port number must be an even integer between 5554 and 5584, inclusive. <code><port></code>+1 + <td>The console port number must be an even integer between 5554 and 5584, inclusive. <code><port></code>+1 must also be free and will be reserved for ADB.</td> </tr> <tr> <td><code>-report-console <socket></code></td> - <td>Report the assigned console port for this emulator instance to a remote third party + <td>Report the assigned console port for this emulator instance to a remote third party before starting the emulation. </td> <td><code><socket></code> must use one of these formats: @@ -347,14 +392,14 @@ ANDROID_VERBOSE. Define the options you want to use in a comma-delimited list, s <p>Use <code>-help-report-console</code></p> to view more information about this topic. </td> </tr> <tr> - <td rowspan="8">System</td> + <td rowspan="10">System</td> <td><code>-cpu-delay <delay></code></td> <td>Slow down emulated CPU speed by <delay> </td> <td>Supported values for <delay> are integers between 0 and 1000. -<p>Note that the <delay> does not correlate to clock speed or other absolute metrics -— it simply represents an abstract, relative delay factor applied non-deterministically -in the emulator. Effective performance does not always +<p>Note that the <delay> does not correlate to clock speed or other absolute metrics +— it simply represents an abstract, relative delay factor applied non-deterministically +in the emulator. Effective performance does not always scale in direct relationship with <delay> values.</p> </td> </tr> @@ -362,9 +407,9 @@ scale in direct relationship with <delay> values.</p> <td><code>-gps <device></code></td> <td>Redirect NMEA GPS to character device.</td> <td>Use this command to emulate an NMEA-compatible GPS unit connected to - an external character device or socket. The format of <code><device></code> must be QEMU-specific - serial device specification. See the documentation for 'serial -dev' at - <a href="http://www.bellard.org/qemu/qemu-doc.html#SEC10">http://www.bellard.org/qemu/qemu-doc.html#SEC10</a>. + an external character device or socket. The format of <code><device></code> must be QEMU-specific + serial device specification. See the documentation for 'serial -dev' at + <a href="http://wiki.qemu.org/download/qemu-doc.html">http://wiki.qemu.org/download/qemu-doc.html</a>. </td> </tr> <tr> @@ -372,18 +417,37 @@ scale in direct relationship with <delay> values.</p> <td>Disable JNI checks in the Dalvik runtime.</td><td> </td></tr> <tr> <td><code>-qemu</code></td> - <td>Pass arguments to qemu.</td> - <td> </td></tr> + <td>Pass arguments to the qemu emulator software.</td> + <td><p class="caution"><strong>Important:</strong> When using this option, make sure it is the + <em>last option</em> specified, since all options after it are interpretted as qemu-specific + options.</p></td></tr> +<tr> + <td><code>-qemu -enable-kvm</code></td> + <td>Enable KVM acceleration of the emulator virtual machine.</td> + <td>This option is only effective when your system is set up to use + <a href="{@docRoot}guide/developing/devices/emulator.html#vm-linux">KVM-based VM acceleration</a>. + You can optionally specify a memory size ({@code -m <size>}) for the VM, which should match + your emulator's memory size:</p> + {@code -qemu -m 512 -enable-kvm}<br> + {@code -qemu -m 1024 -enable-kvm} + </td></tr> <tr> <td><code>-qemu -h</code></td> <td>Display qemu help.</td> <td></td></tr> <tr> + <td><code>-gpu on</code></td> + <td>Turn on graphics acceleration for the emulator.</td> + <td>This option is only available for emulators using a system image with API Level 15, revision 3 + and higher. For more information, see + <a href="{@docRoot}guide/developing/devices/emulator.html#accel-graphics">Using the Android + Emulator</a>.</td></tr> +<tr> <td><code>-radio <device></code></td> <td>Redirect radio mode to the specified character device.</td> - <td>The format of <code><device></code> must be QEMU-specific - serial device specification. See the documentation for 'serial -dev' at -<a href="http://www.bellard.org/qemu/qemu-doc.html#SEC10">http://www.bellard.org/qemu/qemu-doc.html#SEC10</a>. + <td>The format of <code><device></code> must be QEMU-specific + serial device specification. See the documentation for 'serial -dev' at +<a href="http://wiki.qemu.org/download/qemu-doc.html">http://wiki.qemu.org/download/qemu-doc.html</a>. </td> </tr> <tr> @@ -419,8 +483,8 @@ scale in direct relationship with <delay> values.</p> <tr> <td><code>-scale <scale></code></td> <td>Scale the emulator window. </td> - <td><code><scale></code> is a number between 0.1 and 3 that represents the desired scaling factor. You can - also specify scale as a DPI value if you add the suffix "dpi" to the scale value. A value of "auto" + <td><code><scale></code> is a number between 0.1 and 3 that represents the desired scaling factor. You can + also specify scale as a DPI value if you add the suffix "dpi" to the scale value. A value of "auto" tells the emulator to select the best window size.</td> </tr> <tr> @@ -434,7 +498,7 @@ scale in direct relationship with <delay> values.</p> <tr> <td><code>-keyset <file></code></td> <td>Use the specified keyset file instead of the default.</td> - <td>The keyset file defines the list of key bindings between the emulator and the host keyboard. + <td>The keyset file defines the list of key bindings between the emulator and the host keyboard. For more information, use <code>-help-keyset</code> to print information about this topic. </td> </tr> @@ -460,113 +524,58 @@ option. Using this option may yield unexpected and in some cases misleading results, since the density with which to render the skin may not be defined. AVDs let you associate each skin with a default density and override the default as needed. For more information, see <a -href="{@docRoot}guide/developing/devices/managing-avds.html#createavd"> -Managing Virtual Devices with AVD Manager</a>. +href="{@docRoot}guide/developing/devices/managing-avds.html">Managing Virtual Devices +with AVD Manager</a>. </td> </tr> <tr> <td><code>-skindir <dir></code></td> <td>This emulator option is deprecated. </td> - <td>See comments for <code>-skin</code>, above.</td></tr> -</table> - - - -<h2 id="KeyMapping">Emulator Keyboard Mapping</h2> - -<p>The table below summarizes the mappings between the emulator keys and and -the keys of your keyboard. </p> -<p class="table-caption"><strong>Table 2.</strong> Emulator keyboard mapping</p> -<table border="0" style="clear:left;"> - <tr> - <th>Emulated Device Key </th> - <th>Keyboard Key </th> - </tr> - <tr> - <td>Home</td> - <td>HOME</td> - </tr> - <tr> - <td>Menu (left softkey)</td> - <td>F2 <em>or</em> Page-up button</td> - </tr> - <tr> - <td>Star (right softkey)</td> - <td>Shift-F2 <em>or </em>Page Down</td> - </tr> - <tr> - <td>Back</td> - <td>ESC</td> - </tr> - <tr> - <td>Call/dial button </td> - <td>F3</td> - </tr> - <tr> - <td>Hangup/end call button</td> - <td>F4</td> - </tr> - <tr> - <td>Search</td> - <td>F5 </td> - </tr> - <tr> - <td>Power button</td> - <td>F7 </td> - </tr> - <tr> - <td>Audio volume up button</td> - <td>KEYPAD_PLUS, Ctrl-5</td> - </tr> - - <tr> - <td>Audio volume down button</td> - <td>KEYPAD_MINUS, Ctrl-F6</td> - </tr> - <tr> - <td>Camera button</td> - <td>Ctrl-KEYPAD_5, Ctrl-F3</td> - </tr> - <tr> - <td>Switch to previous layout orientation (for example, portrait, landscape)</td> - <td>KEYPAD_7, Ctrl-F11</td> - </tr> - <tr> - <td>Switch to next layout orientation (for example, portrait, landscape)</td> - <td>KEYPAD_9, Ctrl-F12</td> - </tr> - <tr> - <td>Toggle cell networking on/off</td> - <td>F8</td> - </tr> - <tr> - <td>Toggle code profiling</td> - <td>F9 (only with <code>-trace</code> startup option)</td> - </tr> - <tr> - <td>Toggle fullscreen mode</td> - <td>Alt-Enter</td> - </tr> - <tr> - <td>Toggle trackball mode</td> - <td>F6</td> - </tr> - <tr> - <td>Enter trackball mode temporarily (while key is pressed)</td> - <td>Delete</td> - </tr> - <tr> - <td>DPad left/up/right/down</td> - <td>KEYPAD_4/8/6/2</td> - </tr> - <tr> - <td>DPad center click</td> - <td>KEYPAD_5</td> - </tr> - <tr> - <td>Onion alpha increase/decrease</td> - <td>KEYPAD_MULTIPLY(*) / KEYPAD_DIVIDE(/)</td> - </tr> + <td>See comments for <code>-skin</code>, above.</td> +</tr> +<tr> + <td rowspan="9">Help</td> + <td><code>-help</code></td> + <td>Print a list of all emulator options.</td> + <td> </td> +</tr> +<tr> + <td><code>-help-all</code></td> + <td>Print help for all startup options.</td> + <td> </td> +</tr> +<tr> + <td><code>-help-<option></code></td> + <td>Print help for a specific startup option.</td> + <td> </td> +</tr> +<tr> + <td><code>-help-debug-tags</code></td> + <td>Print a list of all tags for <code>-debug <tags></code>.</td> + <td> </td> +</tr> +<tr> + <td><code>-help-disk-images</code></td> + <td>Print help for using emulator disk images.</td> + <td> </td> + </tr> +<tr> + <td><code>-help-environment</code></td> + <td>Print help for emulator environment variables.</td> + <td> </td>s +</tr><tr> + <td><code>-help-keys</code></td> + <td>Print the current mapping of keys.</td> + <td> </td> +</tr> +<tr> + <td><code>-help-keyset-file</code></td> + <td>Print help for defining a custom key mappings file.</td> + <td> </td> +</tr> +<tr> + <td><code>-help-virtual-device</code></td> + <td>Print help for Android Virtual Device usage.</td> + <td> </td> +</tr> </table> - -<p>Note that, to use keypad keys, you must first disable NumLock on your development computer. </p> diff --git a/docs/html/guide/developing/tools/index.jd b/docs/html/guide/developing/tools/index.jd index 3d831f3..5e9f686 100644 --- a/docs/html/guide/developing/tools/index.jd +++ b/docs/html/guide/developing/tools/index.jd @@ -12,8 +12,8 @@ latest Android platform.</p> <h2 id="tools-sdk">SDK Tools</h2> <p>The SDK tools are installed with the SDK starter package and are periodically updated. The SDK tools are required if you are developing Android applications. The most important SDK tools -include the Android SDK and AVD Manager (<code>android</code>), the emulator -(<code>emulator</code>), and the Dalvik Debug Monitor Server +include the Android SDK Manager (<code>android sdk</code>), the AVD Manager (<code>android +avd</code>) the emulator (<code>emulator</code>), and the Dalvik Debug Monitor Server (<code>ddms</code>). A short summary of some frequently-used SDK tools is provided below.</p> <dl> diff --git a/docs/html/guide/developing/tools/monkeyrunner_concepts.jd b/docs/html/guide/developing/tools/monkeyrunner_concepts.jd index 499b610..346a0c6 100644 --- a/docs/html/guide/developing/tools/monkeyrunner_concepts.jd +++ b/docs/html/guide/developing/tools/monkeyrunner_concepts.jd @@ -236,7 +236,7 @@ Table 1 explains the flags and arguments. You can generate an API reference for monkeyrunner by running: </p> <pre> -monkeyrunner <format> help.py <outfile> +monkeyrunner help.py <format> <outfile> </pre> <p> The arguments are: diff --git a/docs/html/guide/developing/tools/proguard.jd b/docs/html/guide/developing/tools/proguard.jd index eca262a..ea8a1ea 100644 --- a/docs/html/guide/developing/tools/proguard.jd +++ b/docs/html/guide/developing/tools/proguard.jd @@ -39,7 +39,7 @@ parent.link=index.html sized <code>.apk</code> file that is more difficult to reverse engineer. Because ProGuard makes your application harder to reverse engineer, it is important that you use it when your application utilizes features that are sensitive to security like when you are - <a href="{@docRoot}guide/publishing/licensing.html">Licensing Your Applications</a>.</p> + <a href="{@docRoot}guide/market/licensing/index.html">Licensing Your Applications</a>.</p> <p>ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index 4a9a684..62d18ae 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -90,21 +90,20 @@ <ul> <li> <a href="<?cs var:toroot ?>guide/topics/providers/content-provider-basics.html"> - <span class="en">Content Provider Basics</span> + <span class="en">Content Provider Basics<span +class="new"> new!</span></span> </a> - <span class="new">new!</span> </li> <li> <a href="<?cs var:toroot ?>guide/topics/providers/content-provider-creating.html"> - <span class="en">Creating a Content Provider</span> + <span class="en">Creating a Content Provider<span +class="new"> new!</span></span> </a> - <span class="new">new!</span> </li> <li> <a href="<?cs var:toroot ?>guide/topics/providers/calendar-provider.html"> - <span class="en">Calendar Provider</span> + <span class="en">Calendar Provider<span class="new"> new!</span></span> </a> - <span class="new">new!</span> </li> </ul> </li> @@ -130,8 +129,8 @@ <span class="en">Input Events</span> </a></li> <li><a href="<?cs var:toroot ?>guide/topics/ui/menus.html"> - <span class="en">Menus</span> - </a> <span class="new">updated</span></li> + <span class="en">Menus<span class="new"> new!</span></span> + </a></li> <li><a href="<?cs var:toroot ?>guide/topics/ui/actionbar.html"> <span class="en">Action Bar</span> </a></li> @@ -160,6 +159,19 @@ <li><a href="<?cs var:toroot ?>guide/topics/ui/custom-components.html"> <span class="en">Custom Components</span> </a></li> + <li class="toggle-list"> + <div><a href="<?cs var:toroot ?>guide/topics/ui/accessibility/index.html"> + <span class="en">Accessibility<span class="new"> new!</span></span> + </a></div> + <ul> + <li><a href="<?cs var:toroot ?>guide/topics/ui/accessibility/apps.html"> + <span class="en">Making Applications Accessible</span> + </a></li> + <li><a href="<?cs var:toroot ?>guide/topics/ui/accessibility/services.html"> + <span class="en">Building Accessibility Services</span> + </a></li> + </ul> + </li> <li><a href="<?cs var:toroot ?>guide/topics/ui/binding.html"> <span class="en">Binding to Data with AdapterView</span> </a></li> @@ -259,13 +271,13 @@ <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/topics/graphics/index.html"> <span class="en">Graphics</span> - </a> <span class="new-child">new!</span></div> + </a></div> <ul> <li><a href="<?cs var:toroot ?>guide/topics/graphics/2d-graphics.html"> <span class="en">Canvas and Drawables</span></a></li> <li><a href="<?cs var:toroot ?>guide/topics/graphics/hardware-accel.html"> <span class="en">Hardware Acceleration</span></a> - <span class="new">new!</span></li> + </li> <li><a href="<?cs var:toroot ?>guide/topics/graphics/opengl.html"> <span class="en">OpenGL</span> </a></li> @@ -287,7 +299,6 @@ <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/topics/renderscript/index.html"> <span class="en">Renderscript</span></a> - <span class="new">updated</span> </div> <ul> <li><a href="<?cs var:toroot ?>guide/topics/renderscript/graphics.html"> @@ -318,7 +329,6 @@ </li> <li><a href="<?cs var:toroot ?>guide/topics/media/camera.html"> <span class="en">Camera</span></a> - <span class="new">new!</span> </li> <li><a href="<?cs var:toroot ?>guide/topics/media/audio-capture.html"> <span class="en">Audio Capture</span></a> @@ -332,7 +342,7 @@ <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/topics/sensors/index.html"> <span class="en">Sensors</span> - </a> <span class="new">new!</span></div> + </a></div> <ul> <li><a href="<?cs var:toroot ?>guide/topics/sensors/sensors_overview.html"> <span class="en">Sensors Overview</span> @@ -373,7 +383,7 @@ </li> <li class="toggle-list"> <div><a href="<?cs var:toroot?>guide/topics/nfc/index.html"> - <span class="en">Near Field Communication</span></a> <span class="new">updated</span> + <span class="en">Near Field Communication</span></a> </div> <ul> <li><a href="<?cs var:toroot ?>guide/topics/nfc/nfc.html">NFC Basics</a></li> @@ -381,7 +391,7 @@ </ul> </li> <li><a href="<?cs var:toroot?>guide/topics/wireless/wifip2p.html"> - <span class="en">Wi-Fi Direct</span></a> <span class="new">new!</span> + <span class="en">Wi-Fi Direct</span></a> </li> <li class="toggle-list"> <div><a href="<?cs var:toroot?>guide/topics/usb/index.html"> @@ -444,15 +454,31 @@ </li> <li> - <span class="heading"> - <span class="en">Android Market Topics</span> - </span> + <h2> + <span class="en">Google Play Topics</span> + </h2> <ul> <li><a href="<?cs var:toroot ?>guide/publishing/publishing.html"> - <span class="en">Publishing on Android Market</span> + <span class="en">Publishing on Google Play</span> </a></li> - <li><a href="<?cs var:toroot ?>guide/publishing/licensing.html"> + <li class="toggle-list"> + <div><a href="<?cs var:toroot ?>guide/market/licensing/index.html"> <span class="en">Application Licensing</span></a> + </div> + <ul> + <li><a href="<?cs var:toroot?>guide/market/licensing/overview.html"> + <span class="en">Licensing Overview</span></a> + </li> + <li><a href="<?cs var:toroot?>guide/market/licensing/setting-up.html"> + <span class="en">Setting Up for Licensing</span></a> + </li> + <li><a href="<?cs var:toroot?>guide/market/licensing/adding-licensing.html"> + <span class="en">Adding Licensing to Your App</span></a> + </li> + <li><a href="<?cs var:toroot?>guide/market/licensing/licensing-reference.html"> + <span class="en">Licensing Reference</span></a> + </li> + </ul> </li> <li class="toggle-list"> <div><a href="<?cs var:toroot?>guide/market/billing/index.html"> @@ -480,11 +506,14 @@ </ul> </li> <li><a href="<?cs var:toroot ?>guide/appendix/market-filters.html"> - <span class="en">Market Filters</span></a> + <span class="en">Filters on Google Play</span></a> </li> <li><a href="<?cs var:toroot ?>guide/market/publishing/multiple-apks.html"> <span class="en">Multiple APK Support</span></a> </li> + <li><a href="<?cs var:toroot ?>guide/market/expansion-files.html"> + <span class="en">APK Expansion Files<span class="new"> new!</span></span></a> + </li> </ul> </li> @@ -768,7 +797,7 @@ applications</span> </li> <li><a href="<?cs var:toroot ?>guide/practices/tablets-and-handsets.html"> <span class="en">Supporting Tablets and Handsets</span> - </a> <span class="new">new!</span></li> + </a></li> <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/index.html"> <span class="en">UI Guidelines</span> @@ -805,19 +834,10 @@ applications</span> <li><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/widget_design.html"> <span class="en">App Widget Design</span> </a></li> - <li><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/activity_task_design.html"> - <span class="en">Activity and Task Design</span> - </a></li> - <li><a href="<?cs var:toroot ?>guide/practices/ui_guidelines/menu_design.html"> - <span class="en">Menu Design</span> - </a></li> </ul> </li> </ul> <ul> - <li><a href="<?cs var:toroot ?>guide/practices/design/accessibility.html"> - <span class="en">Designing for Accessibility</span> - </a></li> <li class="toggle-list"> <div><a href="<?cs var:toroot ?>guide/practices/design/performance.html"> <span class="en">Designing for Performance</span> diff --git a/docs/html/guide/index.jd b/docs/html/guide/index.jd index 38f71c0..8378472 100644 --- a/docs/html/guide/index.jd +++ b/docs/html/guide/index.jd @@ -34,9 +34,9 @@ Fundamentals</a>. Then explore other topics — from designing a user interface and setting up resources to storing data and using permissions — as needed.</dd> -<dt><b>Android Market Topics</b></dt> -<dd>Documentation for topics that concern publishing and monetizing applications on Android -Market, such as how to enforce licensing policies and implement in-app billing.</dd> +<dt><b>Google Play Topics</b></dt> +<dd>Documentation for topics that concern publishing and monetizing applications on Google Play, +such as how to enforce licensing policies and implement in-app billing.</dd> <dt><b>Developing</b></dt> <dd>Directions for using Android's development and debugging tools, diff --git a/docs/html/guide/market/billing/billing_admin.jd b/docs/html/guide/market/billing/billing_admin.jd index a84eb4e..0f869ab 100755 --- a/docs/html/guide/market/billing/billing_admin.jd +++ b/docs/html/guide/market/billing/billing_admin.jd @@ -38,19 +38,19 @@ parent.link=index.html few administrative tasks, including setting up and maintaining your product list on the publisher site, registering test accounts, and handling refunds when necessary.</p> -<p>You must have an Android Market publisher account to register test accounts. And you must have a +<p>You must have a Google Play publisher account to register test accounts. And you must have a Google Checkout merchant account to create a product list and issue refunds to your users. If you -already have a publisher account on Android Market, you can use your existing account. You do not +already have a publisher account on Google Play, you can use your existing account. You do not need to register for a new account to support in-app billing. If you do not have a publisher -account, you can register as an Android Market developer and set up a publisher account at the -Android Market <a href="http://market.android.com/publish">publisher site</a>. If you do not have a +account, you can register as a Google Play developer and set up a publisher account at the +Google Play <a href="http://play.google.com/apps/publish">publisher site</a>. If you do not have a Google Checkout merchant account, you can register for one at the <a href="http://checkout.google.com">Google Checkout site</a>.</p> <h2 id="billing-list-setup">Creating a Product List</h2> -<p>The Android Market publisher site provides a product list for each of your published -applications. You can sell an item using Android Market's in-app billing feature only if the item is +<p>The Google Play publisher site provides a product list for each of your published +applications. You can sell an item using Google Play's in-app billing feature only if the item is listed on an application's product list. Each application has its own product list; you cannot sell items that are listed in another application's product list.</p> @@ -77,7 +77,7 @@ storing and delivering the digital content that you sell in your applications.</ </p> <p>You can create a product list for any published application or any draft application that's been -uploaded and saved to the Android Market site. However, you must have a Google Checkout merchant +uploaded and saved to the Google Play site. However, you must have a Google Checkout merchant account and the application's manifest must include the <code>com.android.vending.BILLING</code> permission. If an application's manifest does not include this permission, you will be able to edit existing items in the product list but you will not be able to add new items to the list. For more @@ -104,8 +104,8 @@ number of in-app items.</p> <p>To add an item to a product list using the In-app Products UI, follow these steps:</p> <ol> - <li><a href="http://market.android.com/publish">Log in</a> to your publisher account.</li> - <li>In the <strong>All Android Market listings</strong> panel, under the application name, click + <li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li> + <li>In the <strong>All Google Play listings</strong> panel, under the application name, click <strong>In-app Products</strong>.</li> <li>On the In-app Products List page, click <strong>Add in-app product</strong>.</li> <li>On the Create New In-app Product page (see figure 3), provide details about the item you are @@ -137,7 +137,7 @@ number of in-app items.</p> <li><strong>Publishing State</strong> <p>An item's publishing state can be <strong>Published</strong> or <strong>Unpublished </strong>. To be visible to a user during checkout, an item's publishing state must be set to - <strong>Published</strong> and the item's application must be published on Android Market.</p> + <strong>Published</strong> and the item's application must be published on Google Play.</p> <p class="note"><strong>Note:</strong> This is not true for test accounts. An item is visible to a test account if the application is not published and the item is published. See <a href="{@docRoot}guide/market/billing/billing_testing.html#billing-testing-real">Testing In-app @@ -167,9 +167,9 @@ number of in-app items.</p> <p>You must provide a default price in your home currency. You can also provide prices in other currencies, but you can do this only if a currency's corresponding country is listed as a target country for your application. You can specify target countries on the Edit Application - page in the Android Market developer console.</p> + page in the Google Play developer console.</p> <p>To specify prices in other currencies, you can manually enter the price for each - currency or you can click <strong>Auto Fill</strong> and let Android Market do a one-time + currency or you can click <strong>Auto Fill</strong> and let Google Play do a one-time conversion from your home currency to the currencies you are targeting (see figure 4).</p> </li> </ul> @@ -357,8 +357,8 @@ with the <em>locale</em> field.</p> <p>To import the items that are specified in your CSV file, do the following:</p> <ol> - <li><a href="http://market.android.com/publish">Log in</a> to your publisher account.</li> - <li>In the <strong>All Android Market listings</strong> panel, under the application name, click + <li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li> + <li>In the <strong>All Google Play listings</strong> panel, under the application name, click <strong>In-app Products</strong>.</li> <li>On the In-app Products List page, click <strong>Choose File</strong> and select your CSV file. @@ -381,17 +381,17 @@ a product list and you want to start managing the product list through a CSV fil <h3 id="billing-purchase-type">Choosing a Purchase Type</h3> -<p>An item's purchase type controls how Android Market manages the purchase of the item. There are +<p>An item's purchase type controls how Google Play manages the purchase of the item. There are two purchase types: "managed per user account" and "unmanaged."</p> <p>Items that are managed per user account can be purchased only once per user account. When an item -is managed per user account, Android Market permanently stores the transaction information for each -item on a per-user basis. This enables you to query Android Market with the +is managed per user account, Google Play permanently stores the transaction information for each +item on a per-user basis. This enables you to query Google Play with the <code>RESTORE_TRANSACTIONS</code> request and restore the state of the items a specific user has purchased.</p> -<p>If a user attempts to purchase a managed item that has already been purchased, Android Market -displays an "Item already purchased" error. This occurs during checkout, when Android Market +<p>If a user attempts to purchase a managed item that has already been purchased, Google Play +displays an "Item already purchased" error. This occurs during checkout, when Google Play displays the price and description information on the checkout page. When the user dismisses the error message, the checkout page disappears and the user returns to your user interface. As a best practice, your application should prevent the user from seeing this error. The sample application @@ -404,10 +404,10 @@ or application features. These items are not transient and usually need to be re user reinstalls your application, wipes the data on their device, or installs your application on a new device.</p> -<p>Items that are unmanaged do not have their transaction information stored on Android Market, -which means you cannot query Android Market to retrieve transaction information for items whose +<p>Items that are unmanaged do not have their transaction information stored on Google Play, +which means you cannot query Google Play to retrieve transaction information for items whose purchase type is listed as unmanaged. You are responsible for managing the transaction information -of unmanaged items. Also, unmanaged items can be purchased multiple times as far as Android Market +of unmanaged items. Also, unmanaged items can be purchased multiple times as far as Google Play is concerned, so it's also up to you to control how many times an unmanaged item can be purchased.</p> @@ -417,10 +417,10 @@ times.</p> <h2 id="billing-refunds">Handling Refunds</h2> -<p>In-app billing does not allow users to send a refund request to Android Market. Refunds for +<p>In-app billing does not allow users to send a refund request to Google Play. Refunds for in-app purchases must be directed to you (the application developer). You can then process the -refund through your Google Checkout merchant account. When you do this, Android Market receives a -refund notification from Google Checkout, and Android Market sends a refund message to your +refund through your Google Checkout merchant account. When you do this, Google Play receives a +refund notification from Google Checkout, and Google Play sends a refund message to your application. For more information, see <a href="{@docRoot}guide/market/billing/billing_overview.html#billing-action-notify">Handling IN_APP_NOTIFY messages</a> and <a @@ -434,9 +434,9 @@ 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 +<p>The Google Play publisher site lets you set up one or more test accounts. A test account is a regular Google account that you register on the publisher site as a test account. Test accounts are -authorized to make in-app purchases from applications that you have uploaded to the Android Market +authorized to make in-app purchases from applications that you have uploaded to the Google Play site but have not yet published.</p> <p>You can use any Google account as a test account. Test accounts are useful if you want to let @@ -458,7 +458,7 @@ accounts yourself and distribute the credentials to your developers or testers.< <p>To add test accounts to your publisher account, follow these steps:</p> <ol> - <li><a href="http://market.android.com/publish">Log in</a> to your publisher account.</li> + <li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li> <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li> <li>On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure 5).</li> @@ -480,7 +480,7 @@ support resources listed in the following table (see table 2). By directing your correct forum, you can get the support you need more quickly.</p> <p class="table-caption" id="support-table"><strong>Table 2.</strong> Developer support resources -for Android Market in-app billing.</p> +for Google Play in-app billing.</p> <table> @@ -502,8 +502,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co android</a></td> </tr> <tr> -<td>Market billing issue tracker</td> -<td><a href="http://code.google.com/p/marketbilling/issues/">Market billing +<td>Billing issue tracker</td> +<td><a href="http://code.google.com/p/marketbilling/issues/">Billing project issue tracker</a></td> <td>Bug and issue reports related specifically to in-app billing sample code.</td> </tr> diff --git a/docs/html/guide/market/billing/billing_best_practices.jd b/docs/html/guide/market/billing/billing_best_practices.jd index d9776af..e100ce5 100755 --- a/docs/html/guide/market/billing/billing_best_practices.jd +++ b/docs/html/guide/market/billing/billing_best_practices.jd @@ -32,7 +32,7 @@ parent.link=index.html <p>As you design your in-app billing implementation, be sure to follow the security and design guidelines that are discussed in this document. These guidelines are recommended best practices for -anyone who is using Android Market's in-app billing service.</p> +anyone who is using Google Play's in-app billing service.</p> <h2>Security Best Practices</h2> @@ -92,7 +92,7 @@ replay attacks.</p> nonces on the server.</p> <h4>Take action against trademark and copyright infringement</h4> -<p>If you see your content being redistributed on Android Market, act quickly and decisively. File a +<p>If you see your content being redistributed on Google Play, act quickly and decisively. File a <a href="http://market.android.com/support/bin/answer.py?hl=en&answer=141511">trademark notice of infringement</a> or a <a href="http://www.google.com/android_dmca.html">copyright notice of infringement</a>.</p> @@ -102,7 +102,7 @@ infringement</a>.</p> purchase state of the unlocked content whenever a user accesses the content. This allows you to revoke use when necessary and minimize piracy.</p> -<h4>Protect your Android Market public key</h4> +<h4>Protect your Google Play public key</h4> <p>To keep your public key safe from malicious users and hackers, do not embed it in any code as a literal string. Instead, construct the string at runtime from pieces or use bit manipulation (for example, XOR with some other string) to hide the actual key. The key itself is not secret diff --git a/docs/html/guide/market/billing/billing_integrate.jd b/docs/html/guide/market/billing/billing_integrate.jd index 6017583..4b3650f 100755 --- a/docs/html/guide/market/billing/billing_integrate.jd +++ b/docs/html/guide/market/billing/billing_integrate.jd @@ -35,8 +35,8 @@ parent.link=index.html </div> </div> -<p>Android Market In-app Billing provides a straightforward, simple interface for sending in-app -billing requests and managing in-app billing transactions using Android Market. This document helps +<p>In-app Billing on Google Play provides a straightforward, simple interface for sending in-app +billing requests and managing in-app billing transactions using Google Play. This document helps you implement in-app billing by stepping through the primary implementation tasks, using the in-app billing sample application as an example.</p> @@ -53,23 +53,23 @@ billing.</p> <li><a href="#billing-permission">Update your AndroidManifest.xml file</a>.</li> <li><a href="#billing-service">Create a Service</a> and bind it to the <code>MarketBillingService</code> so your application can send billing requests and receive - billing responses from the Android Market application.</li> + billing responses from Google Play.</li> <li><a href="#billing-broadcast-receiver">Create a BroadcastReceiver</a> to handle broadcast - intents from the Android Market application.</li> + intents from Google Play.</li> <li><a href="#billing-signatures">Create a security processing component</a> to verify the - integrity of the transaction messages that are sent by Android Market .</li> + integrity of the transaction messages that are sent by Google Play.</li> <li><a href="#billing-implement">Modify your application code</a> to support in-app billing.</li> </ol> <h2 id="billing-download">Downloading the Sample Application</h2> <p>The in-app billing sample application shows you how to perform several tasks that are common to -all Android Market in-app billing implementations, including:</p> +all in-app billing implementations, including:</p> <ul> - <li>Sending in-app billing requests to the Android Market application.</li> - <li>Handling synchronous responses from the Android Market application.</li> - <li>Handling broadcast intents (asynchronous responses) from the Android Market application.</li> + <li>Sending in-app billing requests to Google Play.</li> + <li>Handling synchronous responses from Google Play.</li> + <li>Handling broadcast intents (asynchronous responses) from Google Play.</li> <li>Using in-app billing security mechanisms to verify the integrity of billing responses.</li> <li>Creating a user interface that lets users select items for purchase.</li> </ul> @@ -91,8 +91,8 @@ application source files.</p> <tr> <td>IMarketBillingService.aidl</td> -<td>Android Interface Definition Library (AIDL) file that defines the IPC interface to Android -Market's in-app billing service (<code>MarketBillingService</code>).</td> +<td>Android Interface Definition Library (AIDL) file that defines the IPC interface to Google +Play's in-app billing service (<code>MarketBillingService</code>).</td> </tr> <tr> @@ -109,12 +109,12 @@ history.</td> <tr> <td>BillingReceiver.java</td> <td>A {@link android.content.BroadcastReceiver} that receives asynchronous response messages - (broadcast intents) from Android Market. Forwards all messages to the + (broadcast intents) from Google Play. Forwards all messages to the <code>BillingService</code>.</td> </tr> <tr> <td>BillingService.java</td> - <td>A {@link android.app.Service} that sends messages to Android Market on behalf of the + <td>A {@link android.app.Service} that sends messages to Google Play on behalf of the application by connecting (binding) to the <code>MarketBillingService</code>.</td> </tr> @@ -136,8 +136,8 @@ history.</td> <tr> <td>Consts.java</td> -<td>Defines various Android Market constants and sample application constants. All constants that -are defined by Android Market must be defined the same way in your application.</td> +<td>Defines various Google Play constants and sample application constants. All constants that +are defined by Google Play must be defined the same way in your application.</td> </tr> <tr> @@ -149,8 +149,8 @@ relies on these utility classes.</td> </table> <p>The in-app billing sample application is available as a downloadable component of the Android -SDK. To download the sample application component, launch the Android SDK and AVD Manager and then -select the "Google Market Billing package" component (see figure 1), and click <strong>Install +SDK. To download the sample application component, launch the Android SDK Manager and then +select the <strong>Google Market Billing package</strong> component (see figure 1), and click <strong>Install Selected</strong> to begin the download.</p> @@ -160,7 +160,7 @@ Selected</strong> to begin the download.</p> the AIDL file. </p> -<p>When the download is complete, the Android SDK and AVD Manager saves the component into the +<p>When the download is complete, the Android SDK Manager saves the component into the following directory:</p> <p><code><sdk>/extras/google/market_billing/</code></p> @@ -171,7 +171,7 @@ running the sample application involves three tasks:</p> <ul> <li>Configuring and building the sample application.</li> - <li>Uploading the sample application to Android Market.</li> + <li>Uploading the sample application to Google Play.</li> <li>Setting up test accounts and running the sample application.</li> </ul> @@ -186,12 +186,12 @@ your project</a>.</p> following:</p> <ol> - <li><strong>Add your Android Market public key to the sample application code.</strong> + <li><strong>Add your Google Play public key to the sample application code.</strong> <p>This enables the application to verify the signature of the transaction information that is - returned from Android Market. To add your public key to the sample application code, do the + returned from Google Play. To add your public key to the sample application code, do the following:</p> <ol> - <li>Log in to your Android Market <a href="http://market.android.com/publish">publisher + <li>Log in to your Google Play <a href="http://play.google.com/apps/publish">publisher account</a>.</li> <li>On the upper left part of the page, under your name, click <strong>Edit Profile</strong>.</li> @@ -208,7 +208,7 @@ following:</p> </ol> </li> <li><strong>Change the package name of the sample application.</strong> - <p>The current package name is <code>com.example.dungeons</code>. Android Market does not let + <p>The current package name is <code>com.example.dungeons</code>. Google Play does not let you upload applications with package names that contain <code>com.example</code>, so you must change the package name to something else.</p> </li> @@ -221,14 +221,14 @@ following:</p> <h3>Uploading the sample application</h3> <p>After you build a release version of the sample application and sign it, you need to upload it as -a draft to the Android Market publisher site. You also need to create a product list for the in-app +a draft to the Google Play publisher site. You also need to create a product list for the in-app items that are available for purchase in the sample application. The following instructions show you how to do this.</p> <ol> - <li><strong>Upload the release version of the sample application to Android Market.</strong> + <li><strong>Upload the release version of the sample application to Google Play.</strong> <p>Do not publish the sample application; leave it as an unpublished draft application. The sample application is for demonstration purposes only and should not be made publicly available - on Android Market. To learn how to upload an application to Android Market, see <a + on Google Play. To learn how to upload an application to Google Play, see <a href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading applications</a>.</p> </li> @@ -253,7 +253,7 @@ how to do this.</p> onto a device to run it. To run the sample application, do the following:</p> <ol> - <li><strong>Make sure you have at least one test account registered under your Android Market + <li><strong>Make sure you have at least one test account registered under your Google Play publisher account.</strong> <p>You cannot purchase items from yourself (Google Checkout prohibits this), so you need to create at least one test account that you can use to purchase items in the sample application. @@ -261,18 +261,18 @@ onto a device to run it. To run the sample application, do the following:</p> href="{@docRoot}guide/market/billing/billing_testing.html#billing-testing-setup">Setting up Test Accounts</a>.</p> </li> - <li><strong>Verify that your device is running a supported version of the Android Market + <li><strong>Verify that your device is running a supported version of the Google Play application or the MyApps application.</strong> <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, in-app billing - requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the - version of the Android Market application, see <a - href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android - Market</a>.</p> + requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the + version of the Google Play application, see <a + href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google + Play</a>.</p> </li> <li><strong>Install the application onto your device.</strong> - <p>Even though you uploaded the application to Android Market, the application is not published, - so you cannot download it from Android Market to a device. Instead, you must install the + <p>Even though you uploaded the application to Google Play, the application is not published, + so you cannot download it from Google Play to a device. Instead, you must install the application onto your device. To learn how to install an application onto a device, see <a href="{@docRoot}guide/developing/building/building-cmdline.html#RunningOnDevice">Running on a device</a>.</p> @@ -280,7 +280,7 @@ onto a device to run it. To run the sample application, do the following:</p> <li><strong>Make one of your test accounts the primary account on your device.</strong> <p>The primary account on your device must be one of the <a href="{@docRoot}guide/market/billing/billing_admin.html#billing-testing-setup">test accounts</a> - that you registered on the Android Market site. If the primary account on your device is not a + that you registered on the Google Play publisher site. If the primary account on your device is not a test account, you must do a factory reset of the device and then sign in with one of your test accounts. To perform a factory reset, do the following:</p> <ol> @@ -306,7 +306,7 @@ to <code>true</code> in the <code>Consts.java</code> file.</p> <h2 id="billing-add-aidl">Adding the AIDL file to your project</h2> <p>The sample application contains an Android Interface Definition Language (AIDL) file, which -defines the interface to Android Market's in-app billing service +defines the interface to Google Play's in-app billing service (<code>MarketBillingService</code>). When you add this file to your project, the Android build environment creates an interface file (<code>IMarketBillingService.java</code>). You can then use this interface to make billing requests by invoking IPC method calls.</p> @@ -333,29 +333,29 @@ the <code>gen</code> folder of your project.</p> <h2 id="billing-permission">Updating Your Application's Manifest</h2> -<p>In-app billing relies on the Android Market application, which handles all communication between -your application and the Android Market server. To use the Android Market application, your +<p>In-app billing relies on the Google Play application, which handles all communication between +your application and the Google Play server. To use the Google Play application, your application must request the proper permission. You can do this by adding the <code>com.android.vending.BILLING</code> permission to your AndroidManifest.xml file. If your application does not declare the in-app billing permission, but attempts to send billing requests, -Android Market will refuse the requests and respond with a <code>RESULT_DEVELOPER_ERROR</code> +Google Play will refuse the requests and respond with a <code>RESULT_DEVELOPER_ERROR</code> response code.</p> <p>In addition to the billing permission, you need to declare the {@link android.content.BroadcastReceiver} that you will use to receive asynchronous response messages -(broadcast intents) from Android Market, and you need to declare the {@link android.app.Service} -that you will use to bind with the <code>IMarketBillingService</code> and send messages to Android -Market. You must also declare <a +(broadcast intents) from Google Play, and you need to declare the {@link android.app.Service} +that you will use to bind with the <code>IMarketBillingService</code> and send messages to Google +Play. You must also declare <a href="{@docRoot}guide/topics/manifest/intent-filter-element.html">intent filters</a> for the {@link android.content.BroadcastReceiver} so that the Android system knows how to handle the broadcast -intents that are sent from the Android Market application.</p> +intents that are sent from the Google Play application.</p> <p>For example, here is how the in-app billing sample application declares the billing permission, the {@link android.content.BroadcastReceiver}, the {@link android.app.Service}, and the intent filters. In the sample application, <code>BillingReceiver</code> is the {@link -android.content.BroadcastReceiver} that handles broadcast intents from the Android Market +android.content.BroadcastReceiver} that handles broadcast intents from the Google Play application and <code>BillingService</code> is the {@link android.app.Service} that sends requests -to the Android Market application.</p> +to the Google Play application.</p> <pre> <?xml version="1.0" encoding="utf-8"?> @@ -391,11 +391,11 @@ to the Android Market application.</p> <h2 id="billing-service">Creating a Local Service</h2> <p>Your application must have a local {@link android.app.Service} to facilitate messaging between -your application and Android Market. At a minimum, this service must do the following:</p> +your application and Google Play. At a minimum, this service must do the following:</p> <ul> <li>Bind to the <code>MarketBillingService</code>. - <li>Send billing requests (as IPC method calls) to the Android Market application. The five types + <li>Send billing requests (as IPC method calls) to the Google Play application. The five types of billing requests include: <ul> <li><code>CHECK_BILLING_SUPPORTED</code> requests</li> @@ -474,7 +474,7 @@ The five request types are specified using the <code>BILLING_REQUEST</code> Bund key can have the following five values:</p> <ul> - <li><code>CHECK_BILLING_SUPPORTED</code>—verifies that the Android Market application + <li><code>CHECK_BILLING_SUPPORTED</code>—verifies that the Google Play application supports in-app billing.</li> <li><code>REQUEST_PURCHASE</code>—sends a purchase request for an in-app item.</li> <li><code>GET_PURCHASE_INFORMATION</code>—retrieves transaction information for a purchase @@ -510,7 +510,7 @@ application's main thread.</p> <h4>Verifying that in-app billing is supported (CHECK_BILLING_SUPPPORTED)</h4> -<p>The following code sample shows how to verify whether the Android Market application supports +<p>The following code sample shows how to verify whether the Google Play application supports in-app billing. In the sample, <code>mService</code> is an instance of the <code>MarketBillingService</code> interface.</p> @@ -533,7 +533,7 @@ android.os.Bundle} response, which contains only a single key: <code>RESPONSE_CO <li><code>RESULT_BILLING_UNAVAILABLE</code>—in-app billing is not available because the API version you specified is not recognized or the user is not eligible to make in-app purchases (for example, the user resides in a country that prohibits in-app purchases).</li> - <li><code>RESULT_ERROR</code>—there was an error connecting with the Android Market + <li><code>RESULT_ERROR</code>—there was an error connecting with the Google Play application.</li> <li><code>RESULT_DEVELOPER_ERROR</code>—the application is trying to make an in-app billing request but the application has not declared the <code>com.android.vending.BILLING</code> @@ -546,10 +546,10 @@ android.os.Bundle} response, which contains only a single key: <code>RESPONSE_CO <p>We recommend that you invoke the <code>CHECK_BILLING_SUPPORTED</code> request within a <code>RemoteException</code> block. When your code throws a <code>RemoteException</code> it -indicates that the remote method call failed, which means that the Android Market application is out +indicates that the remote method call failed, which means that the Google Play application is out of date and needs to be updated. In this case, you can provide users with an error message that contains a link to the <a -href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android Market</a> +href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google Play</a> Help topic.</p> <p>The sample application demonstrates how you can handle this error condition (see @@ -561,16 +561,16 @@ Help topic.</p> <ul> <li>Send the <code>REQUEST_PURCHASE</code> request.</li> - <li>Launch the {@link android.app.PendingIntent} that is returned from the Android Market + <li>Launch the {@link android.app.PendingIntent} that is returned from the Google Play application.</li> - <li>Handle the broadcast intents that are sent by the Android Market application.</li> + <li>Handle the broadcast intents that are sent by the Google Play application.</li> </ul> <h5>Making the request</h5> <p>You must specify four keys in the request {@link android.os.Bundle}. The following code sample shows how to set these keys and make a purchase request for a single in-app item. In the sample, -<code>mProductId</code> is the Android Market product ID of an in-app item (which is listed in the +<code>mProductId</code> is the Google Play product ID of an in-app item (which is listed in the application's <a href="{@docRoot}guide/market/billing/billing_admin.html#billing-list-setup">product list</a>), and <code>mService</code> is an instance of the <code>MarketBillingService</code> interface.</p> @@ -644,25 +644,25 @@ void startBuyPageActivity(PendingIntent pendingIntent, Intent intent) { context and not an application context. Also, you cannot use the <code>singleTop</code> <a href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">launch mode</a> to launch the pending intent. If you do either of these, the Android system will not attach the pending intent to -your application process. Instead, it will bring Android Market to the foreground, disrupting your +your application process. Instead, it will bring Google Play to the foreground, disrupting your application.</p> <h5>Handling broadcast intents</h5> <p>A <code>REQUEST_PURCHASE</code> request also triggers two asynchronous responses (broadcast -intents). First, the Android Market application sends a <code>RESPONSE_CODE</code> broadcast intent, +intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides error information about the request. If the request does not generate an error, the <code>RESPONSE_CODE</code> broadcast intent returns <code>RESULT_OK</code>, which indicates that the request was successfully sent. (To be clear, a <code>RESULT_OK</code> response does not indicate that the requested purchase was successful; it indicates that the request was sent -successfully to Android Market.)</p> +successfully to Google Play.)</p> <p>Next, when the requested transaction changes state (for example, the purchase is successfully -charged to a credit card or the user cancels the purchase), the Android Market application sends an +charged to a credit card or the user cancels the purchase), the Google Play application sends an <code>IN_APP_NOTIFY</code> broadcast intent. This message contains a notification ID, which you can use to retrieve the transaction details for the <code>REQUEST_PURCHASE</code> request.</p> -<p class="note"><strong>Note:</strong> The Android Market application also sends +<p class="note"><strong>Note:</strong> The Google Play application also sends an <code>IN_APP_NOTIFY</code> for refunds. For more information, see <a href="{@docRoot}guide/market/billing/billing_overview.html#billing-action-notify">Handling IN_APP_NOTIFY messages</a>.</p> @@ -670,7 +670,7 @@ IN_APP_NOTIFY messages</a>.</p> <p>Because the purchase process is not instantaneous and can take several seconds (or more), you must assume that a purchase request is pending from the time you receive a <code>RESULT_OK</code> message until you receive an <code>IN_APP_NOTIFY</code> message for the transaction. While the -transaction is pending, the Android Market checkout UI displays an "Authorizing purchase..." +transaction is pending, the Google Play checkout UI displays an "Authorizing purchase..." notification; however, this notification is dismissed after 60 seconds and you should not rely on this notification as your primary means of conveying transaction status to users. Instead, we recommend that you do the following:</p> @@ -693,12 +693,12 @@ status of pending and completed in-app purchases.</p> be sure that your pending status UI does not block your application. For example, you should avoid using a hovering progress wheel to convey the status of a pending transaction because a pending transaction could last a long time, particularly if a device loses network connectivity and cannot -receive transaction updates from Android Market.</p> +receive transaction updates from Google Play.</p> <p class="caution"><strong>Important:</strong> If a user purchases a managed item, you must prevent the user from purchasing the item again while the original transaction is pending. If a user -attempts to purchase a managed item twice, and the first transaction is still pending, Android -Market will display an error to the user; however, Android Market will not send an error to your +attempts to purchase a managed item twice, and the first transaction is still pending, Google +Play will display an error to the user; however, Google Play will not send an error to your application notifying you that the second purchase request was canceled. This might cause your application to get stuck in a pending state while it waits for an <code>IN_APP_NOTIFY</code> message for the second purchase request.</p> @@ -730,7 +730,7 @@ three keys that are required for all requests: <code>BILLING_REQUEST</code>, <code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional keys are then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The <code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you -must generate. The Android Market application returns this nonce with the +must generate. The Google Play application returns this nonce with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the integrity of the transaction information. The <code>NOTIFY_IDS</code> key contains an array of notification IDs, which you received in the <code>IN_APP_NOTIFY</code> broadcast intent.</p> @@ -741,9 +741,9 @@ you with the status of the request and the <code>REQUEST_ID</code> key provides request identifier for the request.</p> <p>A <code>GET_PURCHASE_INFORMATION</code> request also triggers two asynchronous responses -(broadcast intents). First, the Android Market application sends a <code>RESPONSE_CODE</code> +(broadcast intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides status and error information about the request. Next, if the -request was successful, the Android Market application sends a <code>PURCHASE_STATE_CHANGED</code> +request was successful, the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This message contains detailed transaction information. The transaction information is contained in a signed JSON string (unencrypted). The message includes the signature so you can verify the integrity of the signed string.</p> @@ -783,8 +783,8 @@ 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>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 +<p>You must send a confirmation when you receive transaction information from Google Play. If you +don't send a confirmation message, Google Play 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> @@ -792,7 +792,7 @@ 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 +will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating that you need to deliver the product.</p> <h4>Restoring transaction information (RESTORE_TRANSACTIONS)</h4> @@ -817,7 +817,7 @@ three keys that are required for all requests: <code>BILLING_REQUEST</code>, <code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional <code>REQUEST_NONCE</code> key is then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The <code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you -must generate. The Android Market application returns this nonce with the transactions information +must generate. The Google Play application returns this nonce with the transactions information contained in the <code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the integrity of the transaction information.</p> @@ -827,9 +827,9 @@ you with the status of the request and the <code>REQUEST_ID</code> key provides request identifier for the request.</p> <p>A <code>RESTORE_TRANSACTIONS</code> request also triggers two asynchronous responses (broadcast -intents). First, the Android Market application sends a <code>RESPONSE_CODE</code> broadcast intent, +intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides status and error information about the request. Next, if the request was successful, -the Android Market application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This +the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This message contains the detailed transaction information. The transaction information is contained in a signed JSON string (unencrypted). The message includes the signature so you can verify the integrity of the signed string.</p> @@ -842,7 +842,7 @@ application has been removed from a device and reinstalled.</p> <p>You may also want your {@link android.app.Service} to receive intent messages from your {@link android.content.BroadcastReceiver}. You can use these intent messages to convey the information that -was sent asynchronously from the Android Market application to your {@link +was sent asynchronously from the Google Play application to your {@link android.content.BroadcastReceiver}. To see an example of how you can send and receive these intent messages, see the <code>BillingReceiver.java</code> and <code>BillingService.java</code> files in the sample application. You can use these samples as a basis for your own implementation. However, @@ -851,16 +851,16 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D <h2 id="billing-broadcast-receiver">Creating a BroadcastReceiver</h2> -<p>The Android Market application uses broadcast intents to send asynchronous billing responses to +<p>The Google Play application uses broadcast intents to send asynchronous billing responses to your application. To receive these intent messages, you need to create a {@link android.content.BroadcastReceiver} that can handle the following intents:</p> <ul> <li>com.android.vending.billing.RESPONSE_CODE - <p>This broadcast intent contains an Android Market response code, and is sent after you make an + <p>This broadcast intent contains a Google Play response code, and is sent after you make an in-app billing request. For more information about the response codes that are sent with this response, see <a - href="{@docRoot}guide/market/billing/billing_reference.html#billing-codes">Android Market Response + href="{@docRoot}guide/market/billing/billing_reference.html#billing-codes">Google Play Response Codes for In-app Billing</a>.</p> </li> <li>com.android.vending.billing.IN_APP_NOTIFY @@ -895,18 +895,18 @@ sent in response to billing requests.</p> <td><code>com.android.vending.billing.RESPONSE_CODE</code></td> <td><code>request_id</code></td> <td>A <code>long</code> representing a request ID. A request ID identifies a specific billing - request and is returned by Android Market at the time a request is made.</td> + request and is returned by Google Play at the time a request is made.</td> </tr> <tr> <td><code>com.android.vending.billing.RESPONSE_CODE</code></td> <td><code>response_code</code></td> - <td>An <code>int</code> representing the actual Android Market server response code.</td> + <td>An <code>int</code> representing the actual Google Play server response code.</td> </tr> <tr> <td><code>com.android.vending.billing.IN_APP_NOTIFY</code></td> <td><code>notification_id</code></td> <td>A <code>String</code> representing the notification ID for a given purchase state change. - Android Market notifies you when there is a purchase state change and the notification includes a + Google Play notifies you when there is a purchase state change and the notification includes a unique notification ID. To get the details of the purchase state change, you send the notification ID with the <code>GET_PURCHASE_INFORMATION</code> request.</td> </tr> @@ -933,16 +933,16 @@ public class BillingReceiver extends BroadcastReceiver { private static final String TAG = "BillingReceiver"; - // Intent actions that we receive in the BillingReceiver from Android Market. - // These are defined by Android Market and cannot be changed. + // Intent actions that we receive in the BillingReceiver from Google Play. + // These are defined by Google Play and cannot be changed. // The sample application defines these in the Consts.java file. public static final String ACTION_NOTIFY = "com.android.vending.billing.IN_APP_NOTIFY"; public static final String ACTION_RESPONSE_CODE = "com.android.vending.billing.RESPONSE_CODE"; public static final String ACTION_PURCHASE_STATE_CHANGED = "com.android.vending.billing.PURCHASE_STATE_CHANGED"; - // The intent extras that are passed in an intent from Android Market. - // These are defined by Android Market and cannot be changed. + // The intent extras that are passed in an intent from Google Play. + // These are defined by Google Play and cannot be changed. // The sample application defines these in the Consts.java file. public static final String NOTIFICATION_ID = "notification_id"; public static final String INAPP_SIGNED_DATA = "inapp_signed_data"; @@ -974,7 +974,7 @@ public class BillingReceiver extends BroadcastReceiver { } </pre> -<p>In addition to receiving broadcast intents from the Android Market application, your {@link +<p>In addition to receiving broadcast intents from the Google Play application, your {@link android.content.BroadcastReceiver} must handle the information it received in the broadcast intents. Usually, your {@link android.content.BroadcastReceiver} does this by sending the information to a local service (discussed in the next section). The <code>BillingReceiver.java</code> file in the @@ -985,8 +985,8 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D <h2 id="billing-signatures">Verifying Signatures and Nonces</h2> -<p>Android Market's in-app billing service uses two mechanisms to help verify the integrity of the -transaction information you receive from Android Market: nonces and signatures. A nonce (number used +<p>Google Play's in-app billing service uses two mechanisms to help verify the integrity of the +transaction information you receive from Google Play: nonces and signatures. A nonce (number used once) is a cryptographically secure number that your application generates and sends with every <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, enabling you to verify that @@ -1023,12 +1023,12 @@ implementation, be sure to follow the guidelines in <a href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and Design</a> and obfuscate your code.</p> -<p>You will need to use your Android Market public key to perform the signature verification. The -following procedure shows you how to retrieve Base64-encoded public key from the Android Market +<p>You will need to use your Google Play public key to perform the signature verification. The +following procedure shows you how to retrieve Base64-encoded public key from the Google Play publisher site.</p> <ol> - <li>Log in to your <a href="http://market.android.com/publish">publisher account</a>.</li> + <li>Log in to your <a href="http://play.google.com/apps/publish">publisher account</a>.</li> <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li> <li>On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure 2).</li> @@ -1080,8 +1080,8 @@ unmanaged items is important because unmanaged items cannot be restored by using <h3>Creating a user interface for selecting items</h3> -<p>You must provide users with a means for selecting items that they want to purchase. Android -Market provides the checkout user interface (which is where the user provides a form of payment and +<p>You must provide users with a means for selecting items that they want to purchase. Google +Play provides the checkout user interface (which is where the user provides a form of payment and approves the purchase), but your application must provide a control (widget) that invokes the <code>sendBillingRequest()</code> method when a user selects an item for purchase.</p> diff --git a/docs/html/guide/market/billing/billing_overview.jd b/docs/html/guide/market/billing/billing_overview.jd index 8f9fd4c..b593811 100755 --- a/docs/html/guide/market/billing/billing_overview.jd +++ b/docs/html/guide/market/billing/billing_overview.jd @@ -38,24 +38,24 @@ parent.link=index.html </div> </div> -<p>Android Market In-app Billing is an Android Market service that provides checkout processing for +<p>In-app Billing is a Google Play service that provides checkout processing for in-app purchases. To use the service, your application sends a billing request for a specific in-app product. The service then handles all of the checkout details for the transaction, including requesting and validating the form of payment and processing the financial transaction. When the checkout process is complete, the service sends your application the purchase details, such as the order number, the order date and time, and the price paid. At no point does your application have to -handle any financial transactions; that role is provided by Android Market's in-app billing +handle any financial transactions; that role is provided by Google Play's in-app billing service.</p> <h2 id="billing-arch">In-app Billing Architecture</h2> <p>In-app billing uses an asynchronous message loop to convey billing requests and billing responses -between your application and the Android Market server. In practice, your application never directly -communicates with the Android Market server (see figure 1). Instead, your application sends billing -requests to the Android Market application over interprocess communication (IPC) and receives -purchase responses from the Android Market application in the form of asynchronous broadcast -intents. Your application does not manage any network connections between itself and the Android -Market server or use any special APIs from the Android platform.</p> +between your application and the Google Play server. In practice, your application never directly +communicates with the Google Play server (see figure 1). Instead, your application sends billing +requests to the Google Play application over interprocess communication (IPC) and receives +purchase responses from the Google Play application in the form of asynchronous broadcast +intents. Your application does not manage any network connections between itself and the Google +Play server or use any special APIs from the Android platform.</p> <p>Some in-app billing implementations may also use a private remote server to deliver content or validate transactions, but a remote server is not required to implement in-app billing. A remote @@ -70,16 +70,16 @@ to security attacks.</p> <img src="{@docRoot}images/billing_arch.png" alt="" height="582" /> <p class="img-caption"> <strong>Figure 1.</strong> Your application sends and receives billing messages through the - Android Market application, which handles all communication with the Android Market server.</p> + Google Play application, which handles all communication with the Google Play server.</p> </div> <p>A typical in-app billing implementation relies on three components:</p> <ul> <li>A {@link android.app.Service} (named <code>BillingService</code> in the sample application), - which processes purchase messages from the application and sends billing requests to Android - Market's in-app billing service.</li> + which processes purchase messages from the application and sends billing requests to the Google + Play in-app billing service.</li> <li>A {@link android.content.BroadcastReceiver} (named <code>BillingReceiver</code> in the sample - application), which receives all asynchronous billing responses from the Android Market + application), which receives all asynchronous billing responses from the Google Play application.</li> <li>A security component (named <code>Security</code> in the sample application), which performs security-related tasks, such as signature verification and nonce generation. For more information @@ -99,19 +99,19 @@ to security attacks.</p> <p>In addition to these components, your application must provide a way to store information about users' purchases and some sort of user interface that lets users select items to purchase. You do -not need to provide a checkout user interface. When a user initiates an in-app purchase, the Android -Market application presents the checkout user interface to your user. When the user completes the +not need to provide a checkout user interface. When a user initiates an in-app purchase, the Google +Play application presents the checkout user interface to your user. When the user completes the checkout process, your application resumes.</p> <h2 id="billing-msgs">In-app Billing Messages</h2> -<p>When the user initiates a purchase, your application sends billing messages to Android Market's +<p>When the user initiates a purchase, your application sends billing messages to Google Play's in-app billing service (named <code>MarketBillingService</code>) using simple IPC method calls. The -Android Market application responds to all billing requests synchronously, providing your -application with status notifications and other information. The Android Market application also +Google Play application responds to all billing requests synchronously, providing your +application with status notifications and other information. The Google Play application also responds to some billing requests asynchronously, providing your application with error messages and detailed transaction information. The following section describes the basic request-response -messaging that takes place between your application and the Android Market application.</p> +messaging that takes place between your application and the Google Play application.</p> <h3 id="billing-request">In-app billing requests</h3> @@ -133,31 +133,31 @@ Service Interface</a>. <p>One of the most important keys that every request Bundle must have is the <code>BILLING_REQUEST</code> key. This key lets you specify the type of billing request you are -making. Android Market's in-app billing service supports the following five types of billing +making. Google Play's in-app billing service supports the following five types of billing requests:</p> <ul> <li><code>CHECK_BILLING_SUPPORTED</code> - <p>This request verifies that the Android Market application supports in-app billing. You + <p>This request verifies that the Google Play application supports in-app billing. You usually send this request when your application first starts up. This request is useful if you want to enable or disable certain UI features that are relevant only to in-app billing.</p> </li> <li><code>REQUEST_PURCHASE</code> - <p>This request sends a purchase message to the Android Market application and is the foundation + <p>This request sends a purchase message to the Google Play application and is the foundation of in-app billing. You send this request when a user indicates that he or she wants to purchase - an item in your application. Android Market then handles the financial transaction by displaying + an item in your application. Google Play then handles the financial transaction by displaying the checkout user interface.</p> </li> <li><code>GET_PURCHASE_INFORMATION</code> <p>This request retrieves the details of a purchase state change. A purchase changes state when a requested purchase is billed successfully or when a user cancels a transaction during - checkout. It can also occur when a previous purchase is refunded. Android Market notifies your + checkout. It can also occur when a previous purchase is refunded. Google Play notifies your application when a purchase changes state, so you only need to send this request when there is transaction information to retrieve.</p> </li> <li><code>CONFIRM_NOTIFICATIONS</code> <p>This request acknowledges that your application received the details of a purchase state - change. Android Market sends purchase state change notifications to your application until you + change. Google Play sends purchase state change notifications to your application until you confirm that you received them.</p> </li> <li><code>RESTORE_TRANSACTIONS</code> @@ -171,7 +171,7 @@ requests:</p> <h3 id="billing-response">In-app Billing Responses</h3> -<p>The Android Market application responds to in-app billing requests with both synchronous and +<p>The Google Play application responds to in-app billing requests with both synchronous and asynchronous responses. The synchronous response is a {@link android.os.Bundle} with the following three keys:</p> @@ -196,9 +196,9 @@ include the following:</p> <ul> <li><code>com.android.vending.billing.RESPONSE_CODE</code> - <p>This response contains an Android Market server response code, and is sent after you make an + <p>This response contains a Google Play server response code, and is sent after you make an in-app billing request. A server response code can indicate that a billing request was - successfully sent to Android Market or it can indicate that some error occurred during a billing + successfully sent to Google Play or it can indicate that some error occurred during a billing request. This response is <em>not</em> used to report any purchase state changes (such as refund or purchase information). For more information about the response codes that are sent with this response, see <a @@ -253,7 +253,7 @@ broadcast intents that are sent for every request.</p> <ol> <li>Your application sends a purchase request (<code>REQUEST_PURCHASE</code> type), specifying a product ID and other parameters.</li> - <li>The Android Market application sends your application a Bundle with the following keys: + <li>The Google Play application sends your application a Bundle with the following keys: <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> @@ -262,20 +262,20 @@ broadcast intents that are sent for every request.</p> 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 + the purchase), Google Play sends your application a notification message (an <code>IN_APP_NOTIFY</code> broadcast intent). The notification message includes a notification ID, which references the transaction.</li> <li>Your application requests the transaction information by sending a <code>GET_PURCHASE_STATE_CHANGED</code> request, specifying the notification ID for the transaction.</li> - <li>The Android Market application sends a Bundle with a <code>RESPONSE_CODE</code> key and a + <li>The Google Play application sends a Bundle with a <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. - <li>Android Market sends the transaction information to your application in a + <li>Google Play sends the transaction information to your application in a <code>PURCHASE_STATE_CHANGED</code> broadcast intent.</li> <li>Your application confirms that you received the transaction information for the given notification ID by sending a confirmation message (<code>CONFIRM_NOTIFICATIONS</code> type), specifying the notification ID for which you received transaction information.</li> - <li>The Android Market application sends your application a Bundle with a + <li>The Google Play application sends your application a Bundle with a <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key.</li> </ol> @@ -284,13 +284,13 @@ broadcast intents that are sent for every request.</p> <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 +<p>Keep in mind, you must send a confirmation when you receive transaction information from Google +Play (step 8 in figure 2). If you don't send a confirmation message, Google Play 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 +will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play 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> @@ -307,7 +307,7 @@ broadcast intents that are sent for every request.</p> </div> <p>The request triggers three responses. The first is a {@link android.os.Bundle} with a -<code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. Next, the Android Market +<code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. Next, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides status information or error information about the request. As always, the <code>RESPONSE_CODE</code> message references a specific request ID, so you can determine which request a <code>RESPONSE_CODE</code> message @@ -338,18 +338,18 @@ is supported; a <code>RESULT_BILLING_UNAVAILABLE</code> response code indicates is unavailable because the API version you specified is unrecognized or the user is not eligible to make in-app purchases (for example, the user resides in a country that does not allow in-app billing). A <code>SERVER_ERROR</code> can also be returned, indicating that there was a problem with -the Android Market server.</p> +the Google Play server.</p> <h3 id="billing-action-notify">Handling IN_APP_NOTIFY messages</h3> -<p>Usually, your application receives an <code>IN_APP_NOTIFY</code> broadcast intent from Android -Market in response to a <code>REQUEST_PURCHASE</code> message (see figure 2). The +<p>Usually, your application receives an <code>IN_APP_NOTIFY</code> broadcast intent from Google +Play in response to a <code>REQUEST_PURCHASE</code> message (see figure 2). The <code>IN_APP_NOTIFY</code> broadcast intent informs your application that the state of a requested purchase has changed. To retrieve the details of that purchase, your application sends a -<code>GET_PURCHASE_INFORMATION</code> request. Android Market responds with a +<code>GET_PURCHASE_INFORMATION</code> request. Google Play 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 have received the purchase state change information.</p> +Google Play 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 @@ -358,13 +358,13 @@ 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 +<p>When Google Play 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 +intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Google +Play 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 +while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Google Play 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 @@ -390,7 +390,7 @@ IN_APP_NOTIFY messages.</p> <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> +purchase from one of the devices. In this case, Google Play sends an <code>IN_APP_NOTIFY</code> message to the second device, informing the application that there is a purchase state change. Your application can handle this message the same way it handles the response from an application-initiated <code>REQUEST_PURCHASE</code> message, so that ultimately your application @@ -400,8 +400,8 @@ href="{@docRoot}guide/market/billing/billing_admin.html#billing-purchase-type">p to "managed per user account."</p> <p>In the second case, your application can receive an <code>IN_APP_NOTIFY</code> broadcast intent -when Android Market receives a refund notification from Google Checkout. In this case, Android -Market sends an <code>IN_APP_NOTIFY</code> message to your application. Your application can handle +when Google Play receives a refund notification from Google Checkout. In this case, Google +Play sends an <code>IN_APP_NOTIFY</code> message to your application. Your application can handle this message the same way it handles responses from an application-initiated <code>REQUEST_PURCHASE</code> message so that ultimately your application receives a <code>PURCHASE_STATE_CHANGED</code> message that includes information about the item that has been @@ -417,13 +417,13 @@ 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, -Android Market signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code> -broadcast intent. Android Market uses the private key that is associated with your publisher account +Google Play signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code> +broadcast intent. Google Play uses the private key that is associated with your publisher account to create this signature. The publisher site generates an RSA key pair for each publisher account. You can find the public key portion of this key pair on your account's profile page. It is the same -public key that is used with Android Market licensing.</p> +public key that is used with Google Play licensing.</p> -<p>When Android Market signs a billing response, it includes the signed JSON string (unencrypted) +<p>When Google Play signs a billing response, it includes the signed JSON string (unencrypted) and the signature. When your application receives this signed response you can use the public key portion of your RSA key pair to verify the signature. By performing signature verification you can help detect responses that have been tampered with or that have been spoofed. You can perform this @@ -431,9 +431,9 @@ signature verification step in your application; however, if your application co remote server then we recommend that you perform the signature verification on that server.</p> <p>In-app billing also uses nonces (a random number used once) to help verify the integrity of the -purchase information that's returned from Android Market. Your application must generate a nonce and +purchase information that's returned from Google Play. Your application must generate a nonce and send it with a <code>GET_PURCHASE_INFORMATION</code> request and a <code>RESTORE_TRANSACTIONS</code> -request. When Android Market receives the request, it adds the nonce to the JSON string that +request. When Google Play receives the request, it adds the nonce to the JSON string that contains the transaction information. The JSON string is then signed and returned to your application. When your application receives the JSON string, you need to verify the nonce as well as the signature of the JSON string.</p> @@ -447,20 +447,20 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D limitations.</p> <ul> - <li>In-app billing can be implemented only in applications that you publish through Android - Market.</li> - <li>You must have a Google Checkout Merchant account to use Android Market In-app Billing.</li> + <li>In-app billing can be implemented only in applications that you publish through Google + Play.</li> + <li>You must have a Google Checkout Merchant account to use Google Play In-app Billing.</li> <li>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, in-app billing - requires version 2.3.4 (or higher) of the Android Market application.</li> + requires version 2.3.4 (or higher) of the Google Play application.</li> <li>An application can use in-app billing only if the device is running Android 1.6 (API level 4) or higher.</li> <li>You can use in-app billing to sell only digital content. You cannot use in-app billing to sell physical goods, personal services, or anything that requires physical delivery.</li> - <li>Android Market does not provide any form of content delivery. You are responsible for + <li>Google Play does not provide any form of content delivery. You are responsible for delivering the digital content that you sell in your applications.</li> <li>You cannot implement in-app billing on a device that never connects to the network. To - complete in-app purchase requests, a device must be able to access the Android Market server over + complete in-app purchase requests, a device must be able to access the Google Play server over the network. </li> </ul> diff --git a/docs/html/guide/market/billing/billing_reference.jd b/docs/html/guide/market/billing/billing_reference.jd index 5a7ba56..e8cf2ee 100755 --- a/docs/html/guide/market/billing/billing_reference.jd +++ b/docs/html/guide/market/billing/billing_reference.jd @@ -36,20 +36,20 @@ parent.link=index.html <p>The following document provides technical reference information for the following:</p> <ul> - <li><a href="#billing-codes">Android Market Server Response Codes for In-app Billing</a></li> + <li><a href="#billing-codes">Google Play Server Response Codes for In-app Billing</a></li> <li><a href="#billing-interface">In-app Billing Interface Parameters</a></li> <li><a href="#billing-intents">In-app Billing Broadcast Intents</a></li> </ul> -<h2 id="billing-codes">Android Market Server Response Codes for In-app Billing</h2> +<h2 id="billing-codes">Google Play Server Response Codes for In-app Billing</h2> -<p>The following table lists all of the server response codes that are sent from Android Market to -your application. Android Market sends these response codes asynchronously as +<p>The following table lists all of the server response codes that are sent from Google Play to +your application. Google Play sends these response codes asynchronously as <code>response_code</code> extras in the <code>com.android.vending.billing.RESPONSE_CODE</code> broadcast intent. Your application must handle all of these response codes.</p> <p class="table-caption" id="response-codes-table"><strong>Table 1.</strong> Summary of response -codes returned by Android Market.</p> +codes returned by Google Play.</p> <table> @@ -80,13 +80,13 @@ codes returned by Android Market.</p> <td><code>RESULT_BILLING_UNAVAILABLE</code></td> <td>3</td> <td>Indicates that in-app billing is not available because the <code>API_VERSION</code> that you - specified is not recognized by the Android Market application or the user is ineligible for in-app + specified is not recognized by the Google Play application or the user is ineligible for in-app billing (for example, the user resides in a country that prohibits in-app purchases).</td> </tr> <tr> <td><code>RESULT_ITEM_UNAVAILABLE</code></td> <td>4</td> - <td>Indicates that Android Market cannot find the requested item in the application's product + <td>Indicates that Google Play cannot find the requested item in the application's product list. This can happen if the product ID is misspelled in your <code>REQUEST_PURCHASE</code> request or if an item is unpublished in the application's product list.</td> </tr> @@ -108,7 +108,7 @@ purchase an item from yourself, which is not allowed by Google Checkout.</td> <h2 id="billing-interface">In-app Billing Service Interface</h2> -<p>The following section describes the interface for Android Market's in-app billing service. The +<p>The following section describes the interface for Google Play's in-app billing service. The interface is defined in the <code>IMarketBillingService.aidl</code> file, which is included with the in-app billing <a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample @@ -144,7 +144,7 @@ pairs, which are summarized in table 2.</p> <td><code>int</code></td> <td>1</td> <td>Yes</td> - <td>The version of Android Market's in-app billing service you are using. The current version is + <td>The version of Google Play's in-app billing service you are using. The current version is 1.</td> </tr> <tr> @@ -160,8 +160,8 @@ pairs, which are summarized in table 2.</p> <td>Any valid product identifier.</td> <td>Required for <code>REQUEST_PURCHASE</code> requests.</td> <td>The product ID of the item you are making a billing request for. Every in-app item that you - sell using Android Market's in-app billing service must have a unique product ID, which you - specify on the Android Market publisher site.</td> + sell using Google Play's in-app billing service must have a unique product ID, which you + specify on the Google Play publisher site.</td> </tr> <tr> <td><code>NONCE</code></td> @@ -172,7 +172,7 @@ pairs, which are summarized in table 2.</p> <td>A number used once. Your application must generate and send a nonce with each <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, so you can use this value - to verify the integrity of transaction responses form Android Market.</td> + to verify the integrity of transaction responses form Google Play.</td> </tr> <tr> <td><code>NOTIFY_IDS</code></td> @@ -202,20 +202,20 @@ pairs, which are summarized in table 2.</p> <ul> <li><code>CHECK_BILLING_SUPPORTED</code> - <p>This request verifies that the Android Market application supports in-app billing. You + <p>This request verifies that the Google Play application supports in-app billing. You usually send this request when your application first starts up. This request is useful if you want to enable or disable certain UI features that are relevant only to in-app billing.</p> </li> <li><code>REQUEST_PURCHASE</code> - <p>This request sends a purchase message to the Android Market application and is the foundation + <p>This request sends a purchase message to the Google Play application and is the foundation of in-app billing. You send this request when a user indicates that he or she wants to purchase - an item in your application. Android Market then handles the financial transaction by displaying + an item in your application. Google Play then handles the financial transaction by displaying the checkout user interface.</p> </li> <li><code>GET_PURCHASE_INFORMATION</code> <p>This request retrieves the details of a purchase state change. A purchase state change can occur when a purchase request is billed successfully or when a user cancels a transaction during - checkout. It can also occur when a previous purchase is refunded. Android Market notifies your + checkout. It can also occur when a previous purchase is refunded. Google Play notifies your application when a purchase changes state, so you only need to send this request when there is transaction information to retrieve.</p> </li> @@ -294,8 +294,8 @@ each in-app billing request type.</p> <h2 id="billing-intents">In-app Billing Broadcast Intents</h2> -<p>The following section describes the in-app billing broadcast intents that are sent by the Android -Market application. These broadcast intents inform your application about in-app billing actions +<p>The following section describes the in-app billing broadcast intents that are sent by the Google +Play application. These broadcast intents inform your application about in-app billing actions that have occurred. Your application must implement a {@link android.content.BroadcastReceiver} to receive these broadcast intents, such as the <code>BillingReceiver</code> that's shown in the in-app billing <a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample @@ -303,21 +303,21 @@ application</a>.</p> <h4>com.android.vending.billing.RESPONSE_CODE</h4> -<p>This broadcast intent contains an Android Market response code, and is sent after you make an +<p>This broadcast intent contains a Google Play response code, and is sent after you make an in-app billing request. A server response code can indicate that a billing request was successfully -sent to Android Market or it can indicate that some error occurred during a billing request. This +sent to Google Play or it can indicate that some error occurred during a billing request. This intent is not used to report any purchase state changes (such as refund or purchase information). For more information about the response codes that are sent with this response, see <a -href="#billing-codes">Android Market Response Codes for In-app Billing</a>. The sample application +href="#billing-codes">Google Play Response Codes for In-app Billing</a>. The sample application assigns this broadcast intent to a constant named <code>ACTION_RESPONSE_CODE</code>.</p> <h5>Extras</h5> <ul type="none"> <li><code>request_id</code>—a <code>long</code> representing a request ID. A request ID - identifies a specific billing request and is returned by Android Market at the time a request is + identifies a specific billing request and is returned by Google Play at the time a request is made.</li> - <li><code>response_code</code>—an <code>int</code> representing the Android Market server + <li><code>response_code</code>—an <code>int</code> representing the Google Play server response code.</li> </ul> @@ -335,7 +335,7 @@ message details. The sample application assigns this broadcast intent to a const <ul type="none"> <li><code>notification_id</code>—a <code>String</code> representing the notification ID for - a given purchase state change. Android Market notifies you when there is a purchase state change + a given purchase state change. Google Play notifies you when there is a purchase state change and the notification includes a unique notification ID. To get the details of the purchase state change, you send the notification ID with the <code>GET_PURCHASE_INFORMATION</code> request.</li> </ul> @@ -375,15 +375,15 @@ a <code>PURCHASE_STATE_CHANGED</code> intent.</p> <tr> <td>nonce</td> <td>A number used once. Your application generates the nonce and sends it with the - <code>GET_PURCHASE_INFORMATION</code> request. Android Market sends the nonce back as part of the + <code>GET_PURCHASE_INFORMATION</code> request. Google Play sends the nonce back as part of the JSON string so you can verify the integrity of the message.</td> </tr> <tr> <td>notificationId</td> <td>A unique identifier that is sent with an <code>IN_APP_NOTIFY</code> broadcast intent. Each <code>notificationId</code> corresponds to a specify message that is waiting to be retrieved on - the Android Market server. Your application sends back the <code>notificationId</code> with the - <code>GET_PURCHASE_INFORMATION</code> message so Android Market can determine which messages you + the Google Play server. Your application sends back the <code>notificationId</code> with the + <code>GET_PURCHASE_INFORMATION</code> message so Google Play can determine which messages you are retrieving.</td> </tr> <tr> @@ -398,7 +398,7 @@ a <code>PURCHASE_STATE_CHANGED</code> intent.</p> <tr> <td>productId</td> <td>The item's product identifier. Every item has a product ID, which you must specify in the - application's product list on the Android Market publisher site.</td> + application's product list on the Google Play publisher site.</td> </tr> <tr> <td>purchaseTime</td> diff --git a/docs/html/guide/market/billing/billing_testing.jd b/docs/html/guide/market/billing/billing_testing.jd index 5453047..77aa3ed 100755 --- a/docs/html/guide/market/billing/billing_testing.jd +++ b/docs/html/guide/market/billing/billing_testing.jd @@ -32,16 +32,16 @@ parent.link=index.html </div> </div> -<p>The Android Market publisher site provides several tools that help you test your in-app billing +<p>The Google Play publisher site provides several tools that help you test your in-app billing implementation before it is published. You can use these tools to create test accounts and purchase special reserved items that send static billing responses to your application.</p> <p>To test in-app billing in an application you must install the application on an Android-powered device. You cannot use the Android emulator to test in-app billing. The device you use for testing must run a standard version of the Android 1.6 or later platform (API level 4 or higher), and have -the most current version of the Android Market application installed. If a device is not running the -most current Android Market application, your application won't be able to send in-app billing -requests to Android Market. For general information about how to set up a device for use in +the most current version of the Google Play application installed. If a device is not running the +most current Google Play application, your application won't be able to send in-app billing +requests to Google Play. For general information about how to set up a device for use in developing Android applications, see <a href="{@docRoot}guide/developing/device.html">Using Hardware Devices</a>.</p> @@ -50,12 +50,12 @@ Devices</a>.</p> <h2 id="billing-testing-static">Testing in-app purchases with static responses</h2> <p>We recommend that you first test your in-app billing implementation using static responses from -Android Market. This enables you to verify that your application is handling the primary Android -Market responses correctly and that your application is able to verify signatures correctly.</p> +Google Play. This enables you to verify that your application is handling the primary Google +Play responses correctly and that your application is able to verify signatures correctly.</p> <p>To test your implementation with static responses, you make an in-app billing request using a special item that has a reserved product ID. Each reserved product ID returns a specific static -response from Android Market. No money is transferred when you make in-app billing requests with the +response from Google Play. No money is transferred when you make in-app billing requests with the reserved product IDs. Also, you cannot specify the form of payment when you make a billing request with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the product ID android.test.purchased.</p> @@ -65,7 +65,7 @@ product ID android.test.purchased.</p> <strong>Figure 1.</strong> Checkout flow for the special reserved item android.test.purchased. </p> -<p>You do not need to list the reserved products in your application's product list. Android Market +<p>You do not need to list the reserved products in your application's product list. Google Play already knows about the reserved product IDs. Also, you do not need to upload your application to the publisher site to perform static response tests with the reserved product IDs. You can simply install your application on a device, log into the device, and make billing requests using the @@ -75,24 +75,24 @@ reserved product IDs.</p> <ul> <li><strong>android.test.purchased</strong> - <p>When you make an in-app billing request with this product ID, Android Market responds as + <p>When you make an in-app billing request with this product ID, Google Play responds as though you successfully purchased an item. The response includes a JSON string, which contains fake purchase information (for example, a fake order ID). In some cases, the JSON string is signed and the response includes the signature so you can test your signature verification implementation using these responses.</p> </li> <li><strong>android.test.canceled</strong> - <p>When you make an in-app billing request with this product ID Android Market responds as + <p>When you make an in-app billing request with this product ID Google Play responds as though the purchase was canceled. This can occur when an error is encountered in the order process, such as an invalid credit card, or when you cancel a user's order before it is charged.</p> </li> <li><strong>android.test.refunded</strong> - <p>When you make an in-app billing request with this product ID, Android Market responds as - though the purchase was refunded. Refunds cannot be initiated through Android Market's in-app + <p>When you make an in-app billing request with this product ID, Google Play responds as + though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app billing service. Refunds must be initiated by you (the merchant). After you process a refund request through your Google Checkout account, a refund message is sent to your application by - Android Market. This occurs only when Android Market gets notification from Google Checkout that + Google Play. This occurs only when Google Play gets notification from Google Checkout that a refund has been made. For more information about refunds, see <a href="{@docRoot}guide/market/billing/billing_overview.html#billing-action-notify">Handling IN_APP_NOTIFY messages</a> and <a @@ -100,7 +100,7 @@ reserved product IDs.</p> Pricing</a>.</p> </li> <li><strong>android.test.item_unavailable</strong> - <p>When you make an in-app billing request with this product ID, Android Market responds as + <p>When you make an in-app billing request with this product ID, Google Play responds as though the item being purchased was not listed in your application's product list.</p> </li> </ul> @@ -185,20 +185,20 @@ application's product list you use one of the reserved product IDs.</p> <p>You do not need to use a test account if you are testing only with the reserved product IDs.</p> </li> - <li><strong>Verify that your device is running a supported version of the Android Market + <li><strong>Verify that your device is running a supported version of the Google Play application or the MyApps application.</strong> <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, in-app billing - requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the - version of the Android Market application, see <a - href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android - Market</a>.</p> + requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the + version of the Google Play application, see <a + href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google + Play</a>.</p> </li> <li><strong>Run your application and purchase the reserved product IDs.</strong></li> </ol> <p class="note"><strong>Note</strong>: Making in-app billing requests with the reserved product IDs -overrides the usual Android Market production system. When you send an in-app billing request for a +overrides the usual Google Play production system. When you send an in-app billing request for a reserved product ID, the quality of service will not be comparable to the production environment.</p> @@ -207,7 +207,7 @@ environment.</p> <p>After you finish your static response testing, and you verify that signature verification is working in your application, you can test your in-app billing implementation by making actual in-app purchases. Testing real in-app purchases enables you to test the end-to-end in-app billing -experience, including the actual responses from Android Market and the actual checkout flow that +experience, including the actual responses from Google Play and the actual checkout flow that 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 @@ -215,7 +215,7 @@ testing. You only need to upload your application as a draft application to perf 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 +register at least one test account on the Google Play publisher site. You cannot use your developer account to test the complete in-app purchase process because Google Checkout does not let you buy items from yourself. If you have not set up test accounts before, see <a href="{@docRoot}guide/market/billing/billing_admin.html#billing-testing-setup">Setting up test @@ -237,7 +237,7 @@ actual payouts to your merchant account.</p> 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 + load to your device for testing. To learn how to upload an application to Google Play, see <a href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading applications</a>.</p> </li> @@ -257,7 +257,7 @@ actual payouts to your merchant account.</p> <p>To perform end-to-end testing of in-app billing, the primary account on your device must be one of the <a href="{@docRoot}guide/market/billing/billing_admin.html#billing-testing-setup">test accounts</a> - that you registered on the Android Market site. If the primary account on your device is not a + that you registered on the Google Play site. If the primary account on your device is not a test account, you must do a factory reset of the device and then sign in with one of your test accounts. To perform a factory reset, do the following:</p> <ol> @@ -269,14 +269,14 @@ actual payouts to your merchant account.</p> device setup process.</li> </ol> </li> - <li><strong>Verify that your device is running a supported version of the Android Market + <li><strong>Verify that your device is running a supported version of the Google Play application or the MyApps application.</strong> <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, in-app billing - requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the - version of the Android Market application, see <a - href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android - Market</a>.</p> + requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the + version of the Google Play application, see <a + href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google + Play</a>.</p> </li> <li><strong>Make in-app purchases in your application.</strong></li> </ol> @@ -285,7 +285,7 @@ actual payouts to your merchant account.</p> do a factory reset, making sure you log on with your primary account first.</p> <p>When you are finished testing your in-app billing implementation, you are ready to -publish your application on Android Market. You can follow the normal steps for <a +publish your application on Google Play. You can follow the normal steps for <a href="{@docRoot}guide/publishing/preparing.html">preparing</a>, <a href="{@docRoot}guide/publishing/app-signing.html">signing</a>, and <a href="{@docRoot}guide/publishing/publishing.html">publishing your application</a>. diff --git a/docs/html/guide/market/billing/index.jd b/docs/html/guide/market/billing/index.jd index fdfa6fa..036761f 100755 --- a/docs/html/guide/market/billing/index.jd +++ b/docs/html/guide/market/billing/index.jd @@ -30,18 +30,18 @@ page.title=In-app Billing </div> </div> -<p>Android Market In-app Billing is an Android Market service that lets you sell digital content in +<p>Google Play In-app Billing is a Google Play service that lets you sell digital content in your applications. You can use the service to sell a wide range of content, including downloadable content such as media files or photos, and virtual content such as game levels or potions.</p> -<p>When you use Android Market's in-app billing service to sell an item, Android Market handles all +<p>When you use Google Play's in-app billing service to sell an item, Google Play handles all checkout details so your application never has to directly process any financial transactions. -Android Market uses the same checkout service that is used for application purchases, so your users +Google Play uses the same checkout service that is used for application purchases, so your users experience a consistent and familiar purchase flow (see figure 1). Also, the transaction fee for in-app purchases is the same as the transaction fee for application purchases (30%).</p> -<p>Any application that you publish through Android Market can implement in-app billing. No special -account or registration is required other than an Android Market publisher account and a Google +<p>Any application that you publish through Google Play can implement in-app billing. No special +account or registration is required other than a Google Play app publisher account and a Google Checkout Merchant account. Also, because the service uses no dedicated framework APIs, you can add in-app billing to any application that uses a minimum API level of 4 or higher.</p> @@ -59,11 +59,11 @@ obfuscate the sample code before you use it in a production application. For mor <img src="{@docRoot}images/billing_checkout_flow.png" height="382" id="figure1" /> <p class="img-caption"> <strong>Figure 1.</strong> Applications initiate in-app billing requests through their own UI - (first screen). Android Market responds to the request by providing the checkout user interface + (first screen). Google Play responds to the request by providing the checkout user interface (middle screen). When checkout is complete, the application resumes. </p> -<p>To learn more about Android Market's in-app billing service and start integrating it into your +<p>To learn more about Google Play's in-app billing service and start integrating it into your applications, read the following documents:</p> <dl> @@ -88,7 +88,7 @@ applications, read the following documents:</p> <dd>Learn how to set up your product list, register test accounts, and handle refunds.</dd> <dt><strong><a href="{@docRoot}guide/market/billing/billing_reference.html">In-app Billing Reference</a></strong></dt> - <dd>Get detailed information about Android Market response codes and the in-app billing + <dd>Get detailed information about Google Play response codes and the in-app billing interface.</dd> </dl> diff --git a/docs/html/guide/market/expansion-files.jd b/docs/html/guide/market/expansion-files.jd new file mode 100644 index 0000000..36b8f9c --- /dev/null +++ b/docs/html/guide/market/expansion-files.jd @@ -0,0 +1,1270 @@ +page.title=APK Expansion Files +@jd:body + + +<div id="qv-wrapper"> +<div id="qv"> +<h2>Quickview</h2> +<ul> + <li>Recommended for most apps that exceed the 50MB APK limit</li> + <li>You can provide up to 4GB of additional data for each APK</li> + <li>Google Play hosts and serves the expansion files at no charge</li> + <li>The files can be any file type you want and are saved to the device's shared storage</li> +</ul> + +<h2>In this document</h2> +<ol> + <li><a href="#Overview">Overview</a> + <ol> + <li><a href="#Filename">File name format</a></li> + <li><a href="#StorageLocation">Storage location</a></li> + <li><a href="#DownloadProcess">Download process</a></li> + <li><a href="#Checklist">Development checklist</a></li> + </ol> + </li> + <li><a href="#Rules">Rules and Limitations</a></li> + <li><a href="#Downloading">Downloading the Expansion Files</a> + <ol> + <li><a href="#AboutLibraries">About the Downloader Library</a></li> + <li><a href="#Preparing">Preparing to use the Downloader Library</a></li> + <li><a href="#Permissions">Declaring user permissions</a></li> + <li><a href="#DownloaderService">Implementing the downloader service</a></li> + <li><a href="#AlarmReceiver">Implementing the alarm receiver</a></li> + <li><a href="#Download">Starting the download</a></li> + <li><a href="#Progress">Receiving download progress</a></li> + </ol> + </li> + <li><a href="#ExpansionPolicy">Using APKExpansionPolicy</a></li> + <li><a href="#ReadingTheFile">Reading the Expansion File</a> + <ol> + <li><a href="#GettingFilenames">Getting the file names</a></li> + <li><a href="#ZipLib">Using the APK Expansion Zip Library</a></li> + </ol> + </li> + <li><a href="#Testing">Testing Your Expansion Files</a> + <ol> + <li><a href="#TestingReading">Testing file reads</a></li> + <li><a href="#TestingReading">Testing file downloads</a></li> + </ol> + </li> + <li><a href="#Updating">Updating Your Application</a></li> +</ol> + +<h2>See also</h2> +<ol> + <li><a href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a></li> + <li><a href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple +APK Support</a></li> +</ol> +</div> +</div> + + + +<p>Google Play currently requires that your APK file be no more than 50MB. For most +applications, this is plenty of space for all the application's code and assets. +However, some apps need more space for high-fidelity graphics, media files, or other large assets. +Previously, if your app exceeded 50MB, you had to host and download the additional resources +yourself when the user opens the app. Hosting and serving the extra files can be costly, and the +user experience is often less than ideal. To make this process easier for you and more pleasant +for users, Google Play allows you to attach two large expansion files that supplement your +APK.</p> + +<p>Google Play hosts the expansion files for your application and serves them to the device at +no cost to you. The expansion files are saved to the device's shared storage location (the +SD card or USB-mountable partition; also known as the "external" storage) where your app can access +them. On most devices, Google Play downloads the expansion file(s) at the same time it +downloads the APK, so your application has everything it needs when the user opens it for the +first time. In some cases, however, your application must download the files from Google Play +when your application starts.</p> + + + +<h2 id="Overview">Overview</h2> + +<p>Each time you upload an APK using the Google Play Android Developer Console, you have the option to +add one or two expansion files to the APK. Each file can be up to 2GB and it can be any format you +choose, but we recommend you use a compressed file to conserve bandwidth during the download. +Conceptually, each expansion file plays a different role:</p> + +<ul> + <li>The <strong>main</strong> expansion file is the +primary expansion file for additional resources required by your application.</li> + <li>The <strong>patch</strong> expansion file is optional and intended for small updates to the +main expansion file.</li> +</ul> + +<p>While you can use the two expansion files any way you wish, we recommend that the main +expansion file deliver the primary assets and should rarely if ever updated; the patch expansion +file should be smaller and serve as a “patch carrier,” getting updated with each major +release or as necessary.</p> + +<p>However, even if your application update requires only a new patch expansion file, you still must +upload a new APK with an updated <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code +versionCode}</a> in the manifest. (The +Developer Console does not allow you to upload an expansion file to an existing APK.)</p> + +<p class="note"><strong>Note:</strong> The patch expansion file is semantically the same as the +main expansion file—you can use each file any way you want. The system does +not use the patch expansion file to perform patching for your app. You must perform patching +yourself or be able to distinguish between the two files.</p> + + + +<h3 id="Filename">File name format</h3> + +<p>Each expansion file you upload can be any format you choose (ZIP, PDF, MP4, etc.). Regardless of +the file type, Google Play considers them opaque binary blobs and renames the files +using the following scheme:</p> + +<pre class="classic no-pretty-print"> +[main|patch].<expansion-version>.<package-name>.obb +</pre> + +<p>There are three components to this scheme:</p> + +<dl> + <dt>{@code main} or {@code patch}</dt> + <dd>Specifies whether the file is the main or patch expansion file. There can be +only one main file and one patch file for each APK.</dd> + <dt>{@code <expansion-version>}</dt> + <dd>This is an integer that matches the version code of the APK with which the expansion is +<em>first</em> associated (it matches the application's <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code android:versionCode}</a> +value). + <p>"First" is emphasized because although the Developer Console allows you to +re-use an uploaded expansion file with a new APK, the expansion file's name does not change—it +retains the version applied to it when you first uploaded the file.</p></dd> + <dt>{@code <package-name>}</dt> + <dd>Your application's Java-style package name.</dd> +</dl> + +<p>For example, suppose your APK version is 314159 and your package name is com.example.app. If you +upload a main expansion file, the file is renamed to:</p> +<pre class="classic no-pretty-print">main.314159.com.example.app.obb</pre> + + +<h3 id="StorageLocation">Storage location</h3> + +<p>When Google Play downloads your expansion files to a device, it saves them to the system's +shared storage location. To ensure proper behavior, you must not delete, move, or rename the +expansion files. In the event that your application must perform the download from Google Play +itself, you must save the files to the exact same location.</p> + +<p>The specific location for your expansion files is:</p> + +<pre class="classic no-pretty-print"> +<shared-storage>/Android/obb/<package-name>/ +</pre> + +<ul> + <li>{@code <shared-storage>} is the path to the shared storage space, available from +{@link android.os.Environment#getExternalStorageDirectory()}.</li> + <li>{@code <package-name>} is your application's Java-style package name, available +from {@link android.content.Context#getPackageName()}.</li> +</ul> + +<p>For each application, there are never more than two expansion files in this directory. +One is the main expansion file and the other is the patch expansion file (if necessary). Previous +versions are overwritten when you update your application with new expansion files.</p> + +<p>If you must unpack the contents of your expansion files, <strong>do not</strong> delete the +{@code .obb} expansion files afterwards and <strong>do not</strong> save the unpacked data +in the same directory. You should save your unpacked files in the directory +specified by {@link android.content.Context#getExternalFilesDir getExternalFilesDir()}. However, +if possible, it's best if you use an expansion file format that allows you to read directly from +the file instead of requiring you to unpack the data. For example, we've provided a library +project called the <a href="#ZipLib">APK Expansion Zip Library</a> that reads your data directly +from the ZIP file.</p> + +<p class="note"><strong>Note:</strong> Unlike APK files, any files saved on the shared storage can +be read by the user and other applications.</p> + +<p class="note"><strong>Tip:</strong> If you're packaging media files into a ZIP, you can use media +playback calls on the files with offset and length controls (such as {@link +android.media.MediaPlayer#setDataSource(FileDescriptor,long,long) MediaPlayer.setDataSource()} and +{@link android.media.SoundPool#load(FileDescriptor,long,long,int) SoundPool.load()}) without the +need to unpack your ZIP. In order for this to work, you must not perform additional compression on +the media files when creating the ZIP packages. For example, when using the <code>zip</code> tool, +you should use the <code>-n</code> option to specify the file suffixes that should not be +compressed: <br/> +<code>zip -n .mp4;.ogg main_expansion media_files</code></p> + + +<h3 id="DownloadProcess">Download process</h3> + +<p>Most of the time, Google Play downloads and saves your expansion files at the same time it +downloads the APK to the device. However, in some cases Google Play +cannot download the expansion files or the user might have deleted previously downloaded expansion +files. To handle these situations, your app must be able to download the files +itself when the main activity starts, using a URL provided by Google Play.</p> + +<p>The download process from a high level looks like this:</p> + +<ol> + <li>User selects to install your app from Google Play.</li> + <li>If Google Play is able to download the expansion files (which is the case for most +devices), it downloads them along with the APK. + <p>If Google Play is unable to download the expansion files, it downloads the +APK only.</p> + </li> + <li>When the user launches your application, your app must check whether the expansion files are +already saved on the device. + <ol> + <li>If yes, your app is ready to go.</li> + <li>If no, your app must download the expansion files over HTTP from Google Play. Your app +must send a request to the Google Play client using the Google Play's <a +href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a> service, which +responds with the name, file size, and URL for each expansion file. With this information, you then +download the files and save them to the proper <a href="#StorageLocation">storage location</a>.</li> + </ol> + </li> +</ol> + +<p class="caution"><strong>Caution:</strong> It is critical that you include the necessary code to +download the expansion files from Google Play in the event that the files are not already on the +device when your application starts. As discussed in the following section about <a +href="#Downloading">Downloading the Expansion Files</a>, we've made a library available to you that +greatly simplifies this process and performs the download from a service with a minimal amount of +code from you.</p> + + + + +<h3 id="Checklist">Development checklist</h3> + +<p>Here's a summary of the tasks you should perform to use expansion files with your +application:</p> + +<ol> + <li>First determine whether your application absolutely requires more than 50MB per installation. +Space is precious and you should keep your total application size as small as possible. If your app +uses more than 50MB in order to provide multiple versions of your graphic assets for multiple screen +densities, consider instead publishing <a +href="{@docRoot}guide/market/publishing/multiple-apks.html">multiple APKs</a> in which each APK +contains only the assets required for the screens that it targets.</li> + <li>Determine which application resources to separate from your APK and package them in a +file to use as the main expansion file. + <p>Normally, you should only use the second patch expansion file when performing updates to +the main expansion file. However, if your resources exceed the 2GB limit for the main +expansion file, you can use the patch file for the rest of your assets.</p> + </li> + <li>Develop your application such that it uses the resources from your expansion files in the +device's <a href="#StorageLocation">shared storage location</a>. + <p>Remember that you must not delete, move, or rename the expansion files.</p> + <p>If your application doesn't demand a specific format, we suggest you create ZIP files for +your expansion files, then read them using the <a href="#ZipLib">APK Expansion Zip +Library</a>.</p> + </li> + <li>Add logic to your application's main activity that checks whether the expansion files +are on the device upon start-up. If the files are not on the device, use Google Play's <a +href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a> service to request URLs +for the expansion files, then download and save them. + <p>To greatly reduce the amount of code you must write and ensure a good user experience +during the download, we recommend you use the <a href="AboutLibraries">Downloader +Library</a> to implement your download behavior.</p> + <p>If you build your own download service instead of using the library, be aware that you +must not change the name of the expansion files and must save them to the proper +<a href="#StorageLocation">storage location</a>.</p></li> +</ol> + +<p>Once you've finished your application development, follow the guide to <a href="#Testing">Testing +Your Expansion Files</a>.</p> + + + + + + +<h2 id="Rules">Rules and Limitations</h2> + +<p>Adding APK expansion files is a feature available when you upload your application using the +Developer Console. When uploading your application for the first time or updating an +application that uses expansion files, you must be aware of the following rules and limitations:</p> + +<ol type="I"> + <li>Each expansion file can be no more than 2GB.</li> + <li>In order to download your expansion files from Google Play, <strong>the user must have +acquired your application from Google Play</strong>. Google Play will not +provide the URLs for your expansion files if the application was installed by other means.</li> + <li>When performing the download from within your application, the URL that Google Play +provides for each file is unique for every download and each one expires shortly after it is given +to your application.</li> + <li>If you update your application with a new APK or upload <a +href="{@docRoot}guide/market/publishing/multiple-apks.html">multiple APKs</a> for the same +application, you can select expansion files that you've uploaded for a previous APK. <strong>The +expansion file's name does not change</strong>—it retains the version received by the APK to +which the file was originally associated.</li> + <li>If you use expansion files in combination with <a +href="{@docRoot}guide/market/publishing/multiple-apks.html">multiple APKs</a> in order to +provide different expansion files for different devices, you still must upload separate APKs +for each device in order to provide a unique <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code versionCode}</a> +value and declare different <a href="{@docRoot}guide/appendix/market-filters.html">filters</a> for +each APK.</li> + <li>You cannot issue an update to your application by changing the expansion files +alone—<strong>you must upload a new APK</strong> to update your app. If your changes only +concern the assets in your expansion files, you can update your APK simply by changing the <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code versionCode}</a> (and +perhaps also the <a href="{@docRoot}guide/topics/manifest/manifest-element.html#vname">{@code +versionName}</a>).</p></li> + <li><strong>Do not save other data into your <code>obb/</code> +directory</strong>. If you must unpack some data, save it into the location specified by {@link +android.content.Context#getExternalFilesDir getExternalFilesDir()}.</li> + <li><strong>Do not delete or rename the {@code .obb} expansion file</strong> (unless you're +performing an update). Doing so will cause Google Play (or your app itself) to repeatedly +download the expansion file.</li> + <li>When updating an expansion file manually, you must delete the previous expansion file.</li> +</ol> + + + + + + + + + +<h2 id="Downloading">Downloading the Expansion Files</h2> + +<p>In most cases, Google Play downloads and saves your expansion files to the device at the same +time it installs or updates the APK. This way, the expansion files are available when your +application launches for the first time. However, in some cases your app must download the +expansion files itself by requesting them from a URL provided to you in a response +from Google Play's <a +href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a> service.</p> + +<p>The basic logic you need to download your expansion files is the following:</p> + +<ol> + <li>When your application starts, look for the expansion files on the <a +href="#StorageLocation">shared storage location</a> (in the +<code>Android/obb/<package-name>/</code> directory). + <ol type="a"> + <li>If the expansion files are there, you're all set and your application can continue.</li> + <li>If the expansion files are <em>not</em> there: + <ol> + <li>Perform a request using Google Play's <a +href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a> to get your +app's expansion file names, sizes, and URLs.</li> + <li>Use the URLs provided by Google Play to download the expansion files and save +the expansion files. You <strong>must</strong> save the files to the <a +href="#StorageLocation">shared storage location</a> +(<code>Android/obb/<package-name>/</code>) and use the exact file name provided +by Google Play's response. + <p class="note"><strong>Note:</strong> The URL that Google Play provides for your +expansion files is unique for every download and each one expires shortly after it is given to +your application.</p> + </li> + </ol> + </li> + </ol> + </li> +</ol> + + +<p>If your application is free (not a paid app), then you probably haven't used the <a +href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a> service. It's primarily +designed for you to enforce +licensing policies for your application and ensure that the user has the right to +use your app (he or she rightfully paid for it on Google Play). In order to facilitate the +expansion file functionality, the licensing service has been enhanced to provide a response +to your application that includes the URL of your application's expansion files that are hosted +on Google Play. So, even if your application is free for users, you need to include the +License Verification Library (LVL) to use APK expansion files. Of course, if your application +is free, you don't need to enforce license verification—you simply need the +library to perform the request that returns the URL of your expansion files.</p> + +<p class="note"><strong>Note:</strong> Whether your application is free or not, Google Play +returns the expansion file URLs only if the user acquired your application from Google Play.</p> + +<p>In addition to the LVL, you need a set of code that downloads the expansion files +over an HTTP connection and saves them to the proper location on the device's shared storage. +As you build this procedure into your application, there are several issues you should take into +consideration:</p> + +<ul> + <li>The device might not have enough space for the expansion files, so you should check +before beginning the download and warn the user if there's not enough space.</li> + <li>File downloads should occur in a background service in order to avoid blocking the user +interaction and allow the user to leave your app while the download completes.</li> + <li>A variety of errors might occur during the request and download that you must +gracefully handle.</li> + <li>Network connectivity can change during the download, so you should handle such changes and +if interrupted, resume the download when possible.</li> + <li>While the download occurs in the background, you should provide a notification that +indicates the download progress, notifies the user when it's done, and takes the user back to +your application when selected.</li> +</ul> + + +<p>To simplify this work for you, we've built the <a href="#AboutLibraries">Downloader Library</a>, +which requests the expansion file URLs through the licensing service, downloads the expansion files, +performs all of the tasks listed above, and even allows your activity to pause and resume the +download. By adding the Downloader Library and a few code hooks to your application, almost all the +work to download the expansion files is already coded for you. As such, in order to provide the best +user experience with minimal effort on your behalf, we recommend you use the Downloader Library to +download your expansion files. The information in the following sections explain how to integrate +the library into your application.</p> + +<p>If you'd rather develop your own solution to download the expansion files using the Google +Play URLs, you must follow the <a href="{@docRoot}guide/market/licensing/index.html">Application +Licensing</a> documentation to perform a license request, then retrieve the expansion file names, +sizes, and URLs from the response extras. You should use the <a href="#ExpansionPolicy">{@code +APKExpansionPolicy}</a> class (included in the License Verification Library) as your licensing +policy, which captures the expansion file names, sizes, and URLs from the licensing service..</p> + + + +<h3 id="AboutLibraries">About the Downloader Library</h3> + +<p>To use APK expansion files with your application and provide the best user experience with +minimal effort on your behalf, we recommend you use the Downloader Library that's included in the +Google Market Apk Expansion package. This library downloads your expansion files in a +background service, shows a user notification with the download status, handles network +connectivity loss, resumes the download when possible, and more.</p> + +<p>To implement expansion file downloads using the Downloader Library, all you need to do is:</p> + +<ul> + <li>Extend a special {@link android.app.Service} subclass and {@link +android.content.BroadcastReceiver} subclass that each require just a few +lines of code from you.</li> + <li>Add some logic to your main activity that checks whether the expansion files have +already been downloaded and, if not, invokes the download process and displays a +progress UI.</li> + <li>Implement a callback interface with a few methods in your main activity that +receives updates about the download progress.</li> +</ul> + +<p>The following sections explain how to set up your app using the Downloader Library.</p> + + +<h3 id="Preparing">Preparing to use the Downloader Library</h3> + +<p>To use the Downloader Library, you need to +download two packages from the SDK Manager and add the appropriate libraries to your +application.</p> + +<p>First, open the <a href="{@docRoot}sdk/adding-components.html">Android SDK Manager</a>, expand +<em>Extras</em> and download:</p> +<ul> + <li><em>Google Market Licensing package</em></li> + <li><em>Google Market Apk Expansion package</em></li> +</ul> + +<p>If you're using Eclipse, create a project for each library and add it to your app:</p> +<ol> + <li>Create a new Library Project for the License Verification Library and Downloader +Library. For each library: + <ol> + <li>Begin a new Android project.</li> + <li>Select <strong>Create project from existing +source</strong> and choose the library from the {@code <sdk>/extras/google/} directory +({@code market_licensing/} for the License Verification Library or {@code +market_apk_expansion/downloader_library/} for the Downloader Library).</li> + <li>Specify a <em>Project Name</em> such as "Google Play License Library" and "Google Play +Downloader +Library"</li> + <li>Click <strong>Finish</strong>.</li> + </ol> +<p class="note"><strong>Note:</strong> The Downloader Library depends on the License +Verification Library. Be sure to add the License +Verification Library to the Downloader Library's project properties (same process as +steps 2 and 3 below).</p> + </li> + <li>Right-click the Android project in which you want to use APK expansion files and +select <strong>Properties</strong>.</li> + <li>In the <em>Library</em> panel, click <strong>Add</strong> to select and add each of the +libraries to your application.</li> +</ol> + +<p>Or, from a command line, update your project to include the libraries:</p> +<ol> + <li>Change directories to the <code><sdk>/tools/</code> directory.</li> + <li>Execute <code>android update project</code> with the {@code --library} option to add both the +LVL and the Downloader Library to your project. For example: +<pre class="no-pretty-print"> +android update project --path ~/Android/MyApp \ +--library ~/android_sdk/extras/google/market_licensing \ +--library ~/android_sdk/extras/google/market_apk_expansion/downloader_library +</pre> + </li> +</ol> + +<p>With both the License Verification Library and Downloader Library added to your +application, you'll be able to quickly integrate the ability to download expansion files from +Google Play. The format that you choose for the expansion files and how you read them +from the shared storage is a separate implementation that you should consider based on your +application needs.</p> + +<p class="note"><strong>Tip:</strong> The Apk Expansion package includes a sample +application +that shows how to use the Downloader Library in an app. The sample uses a third library +available in the Apk Expansion package called the APK Expansion Zip Library. If +you plan on +using ZIP files for your expansion files, we suggest you also add the APK Expansion Zip Library to +your application. For more information, see the section below +about <a href="#ZipLib">Using the APK Expansion Zip Library</a>.</p> + + + +<h3 id="Permissions">Declaring user permissions</h3> + +<p>In order to download the expansion files, the Downloader Library +requires several permissions that you must declare in your application's manifest file. They +are:</p> + +<pre> +<manifest ...> + <!-- Required to access Google Play Licensing --> + <uses-permission android:name="com.android.vending.CHECK_LICENSE" /> + + <!-- Required to download files from Google Play --> + <uses-permission android:name="android.permission.INTERNET" /> + + <!-- Required to keep CPU alive while downloading files (NOT to keep screen awake) --> + <uses-permission android:name="android.permission.WAKE_LOCK" /> + + <!-- Required to poll the state of the network connection and respond to changes --> + <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> + + <!-- Required to check whether Wi-Fi is enabled --> + <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/> + + <!-- Required to read and write the expansion files on shared storage --> + <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> + ... +</manifest> +</pre> + +<p class="note"><strong>Note:</strong> By default, the Downloader Library requires API +level 4, but the APK Expansion Zip Library requires API level 5.</p> + + +<h3 id="DownloaderService">Implementing the downloader service</h3> + +<p>In order to perform downloads in the background, the Downloader Library provides its +own {@link android.app.Service} subclass called {@code DownloaderService} that you should extend. In +addition to downloading the expansion files for you, the {@code DownloaderService} also:</p> + +<ul> + <li>Registers a {@link android.content.BroadcastReceiver} that listens for changes to the +device's network connectivity (the {@link android.net.ConnectivityManager#CONNECTIVITY_ACTION} +broadcast) in order to pause the download when necessary (such as due to connectivity loss) and +resume the download when possible (connectivity is acquired).</li> + <li>Schedules an {@link android.app.AlarmManager#RTC_WAKEUP} alarm to retry the download for +cases in which the service gets killed.</li> + <li>Builds a custom {@link android.app.Notification} that displays the download progress and +any errors or state changes.</li> + <li>Allows your application to manually pause and resume the download.</li> + <li>Verifies that the shared storage is mounted and available, that the files don't already exist, +and that there is enough space, all before downloading the expansion files. Then notifies the user +if any of these are not true.</li> +</ul> + +<p>All you need to do is create a class in your application that extends the {@code +DownloaderService} class and override three methods to provide specific application details:</p> + +<dl> + <dt>{@code getPublicKey()}</dt> + <dd>This must return a string that is the Base64-encoded RSA public key for your publisher +account, available from the profile page on the Developer Console (see <a +href="{@docRoot}guide/market/licensing/setting-up.html">Setting Up for Licensing</a>).</dd> + <dt>{@code getSALT()}</dt> + <dd>This must return an array of random bytes that the licensing {@code Policy} uses to +create an <a +href="{@docRoot}guide/market/licensing/adding-licensing.html#impl-Obfuscator">{@code +Obfuscator}</a>. The salt ensures that your obfuscated {@link android.content.SharedPreferences} +file in which your licensing data is saved will be unique and non-discoverable.</dd> + <dt>{@code getAlarmReceiverClassName()}</dt> + <dd>This must return the class name of the {@link android.content.BroadcastReceiver} in +your application that should receive the alarm indicating that the download should be +restarted (which might happen if the downloader service unexpectedly stops).</dd> +</dl> + +<p>For example, here's a complete implementation of {@code DownloaderService}:</p> + +<pre> +public class SampleDownloaderService extends DownloaderService { + // You must use the public key belonging to your publisher account + public static final String BASE64_PUBLIC_KEY = "YourLVLKey"; + // You should also modify this salt + public static final byte[] SALT = new byte[] { 1, 42, -12, -1, 54, 98, + -100, -12, 43, 2, -8, -4, 9, 5, -106, -107, -33, 45, -1, 84 + }; + + @Override + public String getPublicKey() { + return BASE64_PUBLIC_KEY; + } + + @Override + public byte[] getSALT() { + return SALT; + } + + @Override + public String getAlarmReceiverClassName() { + return SampleAlarmReceiver.class.getName(); + } +} +</pre> + +<p class="caution"><strong>Notice:</strong> You must update the {@code BASE64_PUBLIC_KEY} value +to be the public key belonging to your publisher account. You can find the key in the Developer +Console under your profile information. This is necessary even when testing +your downloads.</p> + +<p>Remember to declare the service in your manifest file:</p> +<pre> +<application ...> + <service android:name=".SampleDownloaderService" /> + ... +</application> +</pre> + + + +<h3 id="AlarmReceiver">Implementing the alarm receiver</h3> + +<p>In order to monitor the progress of the file downloads and restart the download if necessary, the +{@code DownloaderService} schedules an {@link android.app.AlarmManager#RTC_WAKEUP} alarm that +delivers an {@link android.content.Intent} to a {@link android.content.BroadcastReceiver} in your +application. You must define the {@link android.content.BroadcastReceiver} to call an API +from the Downloader Library that checks the status of the download and restarts +it if necessary.</p> + +<p>You simply need to override the {@link android.content.BroadcastReceiver#onReceive +onReceive()} method to call {@code +DownloaderClientMarshaller.startDownloadServiceIfRequired()}.</p> + +<p>For example:</p> + +<pre> +public class SampleAlarmReceiver extends BroadcastReceiver { + @Override + public void onReceive(Context context, Intent intent) { + try { + DownloaderClientMarshaller.startDownloadServiceIfRequired(context, intent, + SampleDownloaderService.class); + } catch (NameNotFoundException e) { + e.printStackTrace(); + } + } +} +</pre> + +<p>Notice that this is the class for which you must return the name +in your service's {@code getAlarmReceiverClassName()} method (see the previous section).</p> + +<p>Remember to declare the receiver in your manifest file:</p> +<pre> +<application ...> + <receiver android:name=".SampleAlarmReceiver" /> + ... +</application> +</pre> + + + +<h3 id="Download">Starting the download</h3> + +<p>The main activity in your application (the one started by your launcher icon) is +responsible for verifying whether the expansion files are already on the device and initiating +the download if they are not.</p> + +<p>Starting the download using the Downloader Library requires the following +procedures:</p> + +<ol> + <li>Check whether the files have been downloaded. + <p>The Downloader Library includes some APIs in the {@code Helper} class to +help with this process:</p> + <ul> + <li>{@code getExtendedAPKFileName(Context, c, boolean mainFile, int +versionCode)}</li> + <li>{@code doesFileExist(Context c, String fileName, long fileSize)}</li> + </ul> + <p>For example, the sample app provided in the Apk Expansion package calls the +following method in the activity's {@link android.app.Activity#onCreate onCreate()} method to check +whether the expansion files already exist on the device:</p> +<pre> +boolean expansionFilesDelivered() { + for (XAPKFile xf : xAPKS) { + String fileName = Helpers.getExpansionAPKFileName(this, xf.mIsBase, xf.mFileVersion); + if (!Helpers.doesFileExist(this, fileName, xf.mFileSize, false)) + return false; + } + return true; +} +</pre> + <p>In this case, each {@code XAPKFile} object holds the version number and file size of a known +expansion file and a boolean as to whether it's the main expansion file. (See the sample +application's {@code SampleDownloaderActivity} class for details.)</p> + <p>If this method returns false, then the application must begin the download.</p> + </li> + <li>Start the download by calling the static method {@code +DownloaderClientMarshaller.startDownloadServiceIfRequired(Context c, PendingIntent +notificationClient, Class<?> serviceClass)}. + <p>The method takes the following parameters:</p> + <ul> + <li><code>context</code>: Your application's {@link android.content.Context}.</li> + <li><code>notificationClient</code>: A {@link android.app.PendingIntent} to start your main +activity. This is used in the {@link android.app.Notification} that the {@code DownloaderService} +creates to show the download progress. When the user selects the notification, the system +invokes the {@link android.app.PendingIntent} you supply here and should open the activity +that shows the download progress (usually the same activity that started the download).</li> + <li><code>serviceClass</code>: The {@link java.lang.Class} object for your implementation of +{@code DownloaderService}, required to start the service and begin the download if necessary.</li> + </ul> + <p>The method returns an integer that indicates +whether or not the download is required. Possible values are:</p> + <ul> + <li>{@code NO_DOWNLOAD_REQUIRED}: Returned if the files already +exist or a download is already in progress.</li> + <li>{@code LVL_CHECK_REQUIRED}: Returned if a license verification is +required in order to acquire the expansion file URLs.</li> + <li>{@code DOWNLOAD_REQUIRED}: Returned if the expansion file URLs are already known, +but have not been downloaded.</li> + </ul> + <p>The behavior for {@code LVL_CHECK_REQUIRED} and {@code DOWNLOAD_REQUIRED} are essentially the +same and you normally don't need to be concerned about them. In your main activity that calls {@code +startDownloadServiceIfRequired()}, you can simply check whether or not the response is {@code +NO_DOWNLOAD_REQUIRED}. If the response is anything <em>other than</em> {@code NO_DOWNLOAD_REQUIRED}, +the Downloader Library begins the download and you should update your activity UI to +display the download progress (see the next step). If the response <em>is</em> {@code +NO_DOWNLOAD_REQUIRED}, then the files are available and your application can start.</p> + <p>For example:</p> +<pre> +@Override +public void onCreate(Bundle savedInstanceState) { + // Check if expansion files are available before going any further + if (!expansionFilesDelivered()) { + // Build an Intent to start this activity from the Notification + Intent notifierIntent = new Intent(this, MainActivity.getClass()); + notifierIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | + Intent.FLAG_ACTIVITY_CLEAR_TOP); + ... + PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, + notifierIntent, PendingIntent.FLAG_UPDATE_CURRENT); + + // Start the download service (if required) + int startResult = DownloaderClientMarshaller.startDownloadServiceIfRequired(this, + pendingIntent, SampleDownloaderService.class); + // If download has started, initialize this activity to show download progress + if (startResult != DownloaderClientMarshaller.NO_DOWNLOAD_REQUIRED) { + // This is where you do set up to display the download progress (next step) + ... + return; + } // If the download wasn't necessary, fall through to start the app + } + startApp(); // Expansion files are available, start the app +} +</pre> + </li> + <li>When the {@code startDownloadServiceIfRequired()} method returns anything <em>other +than</em> {@code NO_DOWNLOAD_REQUIRED}, create an instance of {@code IStub} by +calling {@code DownloaderClientMarshaller.CreateStub(IDownloaderClient client, Class<?> +downloaderService)}. The {@code IStub} provides a binding between your activity to the downloader +service such that your activity receives callbacks about the download progress. + <p>In order to instantiate your {@code IStub} by calling {@code CreateStub()}, you must pass it +an implementation of the {@code IDownloaderClient} interface and your {@code DownloaderService} +implementation. The next section about <a href="#Progress">Receiving download progress</a> discusses +the {@code IDownloaderClient} interface, which you should usually implement in your {@link +android.app.Activity} class so you can update the activity UI when the download state changes.</p> + <p>We recommend that you call {@code +CreateStub()} to instantiate your {@code IStub} during your activity's {@link +android.app.Activity#onCreate onCreate()} method, after {@code startDownloadServiceIfRequired()} +starts the download. </p> + <p>For example, in the previous code sample for {@link android.app.Activity#onCreate +onCreate()}, you can respond to the {@code startDownloadServiceIfRequired()} result like this:</p> +<pre> + // Start the download service (if required) + int startResult = DownloaderClientMarshaller.startDownloadServiceIfRequired(this, + pendingIntent, SampleDownloaderService.class); + // If download has started, initialize activity to show progress + if (startResult != DownloaderClientMarshaller.NO_DOWNLOAD_REQUIRED) { + // Instantiate a member instance of IStub + mDownloaderClientStub = DownloaderClientMarshaller.CreateStub(this, + SampleDownloaderService.class); + // Inflate layout that shows download progress + setContentView(R.layout.downloader_ui); + return; + } +</pre> + + <p>After the {@link android.app.Activity#onCreate onCreate()} method returns, your activity +receives a call to {@link android.app.Activity#onResume onResume()}, which is where you should then +call {@code connect()} on the {@code IStub}, passing it your application's {@link +android.content.Context}. Conversely, you should call +{@code disconnect()} in your activity's {@link android.app.Activity#onStop onStop()} callback.</p> +<pre> +@Override +protected void onResume() { + if (null != mDownloaderClientStub) { + mDownloaderClientStub.connect(this); + } + super.onResume(); +} + +@Override +protected void onStop() { + if (null != mDownloaderClientStub) { + mDownloaderClientStub.disconnect(this); + } + super.onStop(); +} +</pre> + <p>Calling {@code connect()} on the {@code IStub} binds your activity to the {@code +DownloaderService} such that your activity receives callbacks regarding changes to the download +state through the {@code IDownloaderClient} interface.</p> + </li> +</ol> + + + +<h3 id="Progress">Receiving download progress</h3> + +<p>To receive updates regarding the download progress and to interact with the {@code +DownloaderService}, you must implement the Downloader Library's {@code IDownloaderClient} interface. +Usually, the activity you use to start the download should implement this interface in order to +display the download progress and send requests to the service.</p> + +<p>The required interface methods for {@code IDownloaderClient} are:</p> + +<dl> + <dt>{@code onServiceConnected(Messenger m)}</dt> + <dd>After you instantiate the {@code IStub} in your activity, you'll receive a call to this +method, which passes a {@link android.os.Messenger} object that's connected with your instance +of {@code DownloaderService}. To send requests to the service, such as to pause and resume +downloads, you must call {@code DownloaderServiceMarshaller.CreateProxy()} to receive the {@code +IDownloaderService} interface connected to the service. + <p>A recommended implementation looks like this:</p> +<pre> +private IDownloaderService mRemoteService; +... + +@Override +public void onServiceConnected(Messenger m) { + mRemoteService = DownloaderServiceMarshaller.CreateProxy(m); + mRemoteService.onClientUpdated(mDownloaderClientStub.getMessenger()); +} +</pre> + <p>With the {@code IDownloaderService} object initialized, you can send commands to the +downloader service, such as to pause and resume the download ({@code requestPauseDownload()} +and {@code requestContinueDownload()}).</p> +</dd> + <dt>{@code onDownloadStateChanged(int newState)}</dt> + <dd>The download service calls this when a change in download state occurs, such as the +download begins or completes. + <p>The <code>newState</code> value will be one of several possible values specified in +by one of the {@code IDownloaderClient} class's {@code STATE_*} constants.</p> + <p>To provide a useful message to your users, you can request a corresponding string +for each state by calling {@code Helpers.getDownloaderStringResourceIDFromState()}. This +returns the resource ID for one of the strings bundled with the Downloader +Library. For example, the string "Download paused because you are roaming" corresponds to {@code +STATE_PAUSED_ROAMING}.</p></dd> + <dt>{@code onDownloadProgress(DownloadProgressInfo progress)}</dt> + <dd>The download service calls this to deliver a {@code DownloadProgressInfo} object, +which describes various information about the download progress, including estimated time remaining, +current speed, overall progress, and total so you can update the download progress UI.</dd> +</dl> +<p class="note"><strong>Tip:</strong> For examples of these callbacks that update the download +progress UI, see the {@code SampleDownloaderActivity} in the sample app provided with the +Apk Expansion package.</p> + +<p>Some public methods for the {@code IDownloaderService} interface you might find useful are:</p> + +<dl> + <dt>{@code requestPauseDownload()}</dt> + <dd>Pauses the download.</dd> + <dt>{@code requestContinueDownload()}</dt> + <dd>Resumes a paused download.</dd> + <dt>{@code setDownloadFlags(int flags)}</dt> + <dd>Sets user preferences for network types on which its OK to download the files. The +current implementation supports one flag, {@code FLAGS_DOWNLOAD_OVER_CELLULAR}, but you can add +others. By default, this flag is <em>not</em> enabled, so the user must be on Wi-Fi to download +expansion files. You might want to provide a user preference to enable downloads over +the cellular network. In which case, you can call: +<pre> +mRemoteService.setDownloadFlags(IDownloaderService.FLAGS_DOWNLOAD_OVER_CELLULAR); +</pre> +</dd> +</dl> + + + + +<h2 id="ExpansionPolicy">Using APKExpansionPolicy</h2> + +<p>If you decide to build your own downloader service instead of using the Google Play +<a href="#AboutLibraries">Downloader Library</a>, you should still use the {@code +APKExpansionPolicy} that's provided in the License Verification Library. The {@code +APKExpansionPolicy} class is nearly identical to {@code ServerManagedPolicy} (available in the +Google Play License Verification Library) but includes additional handling for the APK expansion +file response extras.</p> + +<p class="note"><strong>Note:</strong> If you <em>do use</em> the <a +href="#AboutLibraries">Downloader Library</a> as discussed in the previous section, the +library performs all interaction with the {@code APKExpansionPolicy} so you don't have to use +this class directly.</p> + +<p>The class includes methods to help you get the necessary information about the available +expansion files:</p> + +<ul> + <li>{@code getExpansionURLCount()}</li> + <li>{@code getExpansionURL(int index)}</li> + <li>{@code getExpansionFileName(int index)}</li> + <li>{@code getExpansionFileSize(int index)}</li> +</ul> + +<p>For more information about how to use the {@code APKExpansionPolicy} when you're <em>not</em> +using the <a +href="#AboutLibraries">Downloader Library</a>, see the documentation for <a +href="{@docRoot}guide/market/licensing/adding-licensing.html">Adding Licensing to Your App</a>, +which explains how to implement a license policy such as this one.</p> + + + + + + + +<h2 id="ReadingTheFile">Reading the Expansion File</h2> + +<p>Once your APK expansion files are saved on the device, how you read your files +depends on the type of file you've used. As discussed in the <a href="#Overview">overview</a>, your +expansion files can be any kind of file you +want, but are renamed using a particular <a href="#Filename">file name format</a> and are saved to +{@code <shared-storage>/Android/obb/<package-name>/}.</p> + +<p>Regardless of how you read your files, you should always first check that the external +storage is available for reading. There's a chance that the user has the storage mounted to a +computer over USB or has actually removed the SD card.</p> + +<p class="note"><strong>Note:</strong> When your application starts, you should always check whether +the external storage space is available and readable by calling {@link +android.os.Environment#getExternalStorageState()}. This returns one of several possible strings +that represent the state of the external storage. In order for it to be readable by your +application, the return value must be {@link android.os.Environment#MEDIA_MOUNTED}.</p> + + +<h3 id="GettingFilenames">Getting the file names</h3> + +<p>As described in the <a href="#Overview">overview</a>, your APK expansion files are saved +using a specific file name format:</p> + +<pre class="classic no-pretty-print"> +[main|patch].<expansion-version>.<package-name>.obb +</pre> + +<p>To get the location and names of your expansion files, you should use the +{@link android.os.Environment#getExternalStorageDirectory()} and {@link +android.content.Context#getPackageName()} methods to construct the path to your files.</p> + +<p>Here's a method you can use in your application to get an array containing the complete path +to both your expansion files:</p> + +<pre> +// The shared path to all app expansion files +private final static String EXP_PATH = "/Android/obb/"; + +static String[] getAPKExpansionFiles(Context ctx, int mainVersion, int patchVersion) { + String packageName = ctx.getPackageName(); + Vector<String> ret = new Vector<String>(); + if (Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED)) { + // Build the full path to the app's expansion files + File root = Environment.getExternalStorageDirectory(); + File expPath = new File(root.toString() + EXP_PATH + packageName); + + // Check that expansion file path exists + if (expPath.exists()) { + if ( mainVersion > 0 ) { + String strMainPath = expPath + File.separator + "main." + + mainVersion + "." + packageName + ".obb"; + File main = new File(strMainPath); + if ( main.isFile() ) { + ret.add(strMainPath); + } + } + if ( patchVersion > 0 ) { + String strPatchPath = expPath + File.separator + "patch." + + mainVersion + "." + packageName + ".obb"; + File main = new File(strPatchPath); + if ( main.isFile() ) { + ret.add(strPatchPath); + } + } + } + } + String[] retArray = new String[ret.size()]; + ret.toArray(retArray); + return retArray; +} +</pre> + +<p>You can call this method by passing it your application {@link android.content.Context} +and the desired expansion file's version.</p> + +<p>There are many ways you could determine the expansion file version number. One simple way is to +save the version in a {@link android.content.SharedPreferences} file when the download begins, by +querying the expansion file name with the {@code APKExpansionPolicy} class's {@code +getExpansionFileName(int index)} method. You can then get the version code by reading the {@link +android.content.SharedPreferences} file when you want to access the expansion +file.</p> + +<p>For more information about reading from the shared storage, see the <a +href="{@docRoot}guide/topics/data/data-storage.html#filesExternal">Data Storage</a> +documentation.</p> + + + +<h3 id="ZipLib">Using the APK Expansion Zip Library</h3> + +<div class="sidebox-wrapper"> +<div class="sidebox"> + <h3>Reading media files from a ZIP</h3> + <p>If you're using your expansion files to store media files, a ZIP file still allows you to +use Android media playback calls that provide offset and length controls (such as {@link +android.media.MediaPlayer#setDataSource(FileDescriptor,long,long) MediaPlayer.setDataSource()} and +{@link android.media.SoundPool#load(FileDescriptor,long,long,int) SoundPool.load()}). In order for +this to work, you must not perform additional compression on the media files when creating the ZIP +packages. For example, when using the <code>zip</code> tool, you should use the <code>-n</code> +option to specify the file suffixes that should not be compressed:</p> +<p><code>zip -n .mp4;.ogg main_expansion media_files</code></p> +</div> +</div> + +<p>The Google Market Apk Expansion package includes a library called the APK +Expansion Zip Library (located in {@code +<sdk>/extras/google/google_market_apk_expansion/zip_file/}). This is an optional library that +helps you read your expansion +files when they're saved as ZIP files. Using this library allows you to easily read resources from +your ZIP expansion files as a virtual file system.</p> + +<p>The APK Expansion Zip Library includes the following classes and APIs:</p> + +<dl> + <dt>{@code APKExpansionSupport}</dt> + <dd>Provides some methods to access expansion file names and ZIP files: + + <dl style="margin-top:1em"> + <dt>{@code getAPKExpansionFiles()}</dt> + <dd>The same method shown above that returns the complete file path to both expansion +files.</dd> + <dt>{@code getAPKExpansionZipFile(Context ctx, int mainVersion, int +patchVersion)}</dt> + <dd>Returns a {@code ZipResourceFile} representing the sum of both the main file and +patch file. That is, if you specify both the <code>mainVersion</code> and the +<code>patchVersion</code>, this returns a {@code ZipResourceFile} that provides read access to +all the data, with the patch file's data merged on top of the main file.</dd> + </dl> + </dd> + + <dt>{@code ZipResourceFile}</dt> + <dd>Represents a ZIP file on the shared storage and performs all the work to provide a virtual +file system based on your ZIP files. You can get an instance using {@code +APKExpansionSupport.getAPKExpansionZipFile()} or with the {@code ZipResourceFile} by passing it the +path to your expansion file. This class includes a variety of useful methods, but you generally +don't need to access most of them. A couple of important methods are: + + <dl style="margin-top:1em"> + <dt>{@code getInputStream(String assetPath)}</dt> + <dd>Provides an {@link java.io.InputStream} to read a file within the ZIP file. The +<code>assetPath</code> must be the path to the desired file, relative to +the root of the ZIP file contents.</dd> + <dt>{@code getAssetFileDescriptor(String assetPath)}</dt> + <dd>Provides an {@link android.content.res.AssetFileDescriptor} for a file within the +ZIP file. The <code>assetPath</code> must be the path to the desired file, relative to +the root of the ZIP file contents. This is useful for certain Android APIs that require an {@link +android.content.res.AssetFileDescriptor}, such as some {@link android.media.MediaPlayer} APIs.</dd> + </dl> + </dd> + + <dt>{@code APEZProvider}</dt> + <dd>Most applications don't need to use this class. This class defines a {@link +android.content.ContentProvider} that marshals the data from the ZIP files through a content +provider {@link android.net.Uri} in order to provide file access for certain Android APIs that +expect {@link android.net.Uri} access to media files. For example, this is useful if you want to +play a video with {@link android.widget.VideoView#setVideoURI VideoView.setVideoURI()}.</p></dd> +</dl> + +<h4>Reading from a ZIP file</h4> + +<p>When using the APK Expansion Zip Library, reading a file from your ZIP usually requires the +following:</p> + +<pre> +// Get a ZipResourceFile representing a merger of both the main and patch files +ZipResourceFile expansionFile = APKExpansionSupport.getAPKExpansionZipFile(appContext, + mainVersion, patchVersion); + +// Get an input stream for a known file inside the expansion file ZIPs +InputStream fileStream = expansionFile.getInputStream(pathToFileInsideZip); +</pre> + +<p>The above code provides access to any file that exists in either your main expansion file or +patch expansion file, by reading from a merged map of all the files from both files. All you +need to provide the {@code getAPKExpansionFile()} method is your application {@code +android.content.Context} and the version number for both the main expansion file and patch +expansion file.</p> + +<p>If you'd rather read from a specific expansion file, you can use the {@code +ZipResourceFile} constructor with the path to the desired expansion file:</p> + +<pre> +// Get a ZipResourceFile representing a specific expansion file +ZipResourceFile expansionFile = new ZipResourceFile(filePathToMyZip); + +// Get an input stream for a known file inside the expansion file ZIPs +InputStream fileStream = expansionFile.getInputStream(pathToFileInsideZip); +</pre> + +<p>For more information about using this library for your expansion files, look at +the sample application's {@code SampleDownloaderActivity} class, which includes additional code to +verify the downloaded files using CRC. Beware that if you use this sample as the basis for +your own implementation, it requires that you <strong>declare the byte size of your expansion +files</strong> in the {@code xAPKS} array.</p> + + + + +<h2 id="Testing">Testing Your Expansion Files</h2> + +<p>Before publishing your application, there are two things you should test: Reading the +expansion files and downloading the files.</p> + + +<h3 id="TestingReading">Testing file reads</h3> + +<p>Before you upload your application to Google Play, you +should test your application's ability to read the files from the shared storage. All you need to do +is add the files to the appropriate location on the device shared storage and launch your +application:</p> + +<ol> + <li>On your device, create the appropriate directory on the shared storage where Google +Play will save your files. + <p>For example, if your package name is {@code com.example.android}, you need to create +the directory {@code Android/obb/com.example.android/} on the shared storage space. (Plug in +your test device to your computer to mount the shared storage and manually create this +directory.)</p> + </li> + <li>Manually add the expansion files to that directory. Be sure that you rename your files to +match the <a href="#Filename">file name format</a> that Google Play will use. + <p>For example, regardless of the file type, the main expansion file for the {@code +com.example.android} application should be {@code main.0300110.com.example.android.obb}. +The version code can be whatever value you want. Just remember:</p> + <ul> + <li>The main expansion file always starts with {@code main} and the patch file starts with +{@code patch}.</li> + <li>The package name always matches that of the APK to which the file is attached on +Google Play. + </ul> + </li> + <li>Now that the expansion file(s) are on the device, you can install and run your application to +test your expansion file(s).</li> +</ol> + +<p>Here are some reminders about handling the expansion files:</p> +<ul> + <li><strong>Do not delete or rename</strong> the {@code .obb} expansion files (even if you unpack +the data to a different location). Doing so will cause Google Play (or your app itself) to +repeatedly download the expansion file.</li> + <li><strong>Do not save other data into your <code>obb/</code> +directory</strong>. If you must unpack some data, save it into the location specified by {@link +android.content.Context#getExternalFilesDir getExternalFilesDir()}.</li> +</ul> + + + +<h3 id="TestingReading">Testing file downloads</h3> + +<p>Because your application must sometimes manually download the expansion files when it first +opens, it's important that you test this process to be sure your application can successfully query +for the URLs, download the files, and save them to the device.</p> + +<p>To test your application's implementation of the manual download procedure, you must upload +your application to Google Play as a "draft" to make your expansion files available for +download:</p> + +<ol> + <li>Upload your APK and corresponding expansion files using the Google Play Developer +Console.</li> + <li>Fill in the necessary application details (title, screenshots, etc.). You can come back and +finalize these details before publishing your application. + <p>Click the <strong>Save</strong> button. <em>Do not click Publish.</em> This saves +the application as a draft, such that your application is not published for Google Play users, +but the expansion files are available for you to test the download process.</p></li> + <li>Install the application on your test device using the Eclipse tools or <a +href="{@docRoot}guide/developing/tools/adb.html">{@code adb}</a>.</li> + <li>Launch the app.</li> +</ol> + +<p>If everything works as expected, your application should begin downloading the expansion +files as soon as the main activity starts.</p> + + + + +<h2 id="Updating">Updating Your Application</h2> + +<p>One of the great benefits to using expansion files on Google Play is the ability to +update your application without re-downloading all of the original assets. Because Google Play +allows you to provide two expansion files with each APK, you can use the second file as a "patch" +that provides updates and new assets. Doing so avoids the +need to re-download the main expansion file which could be large and expensive for users.</p> + +<p>The patch expansion file is technically the same as the main expansion file and neither +the Android system nor Google Play perform actual patching between your main and patch expansion +files. Your application code must perform any necessary patches itself.</p> + +<p>If you use ZIP files as your expansion files, the <a href="#ZipLib">APK Expansion Zip +Library</a> that's included with the Apk Expansion package includes the ability to merge +your +patch file with the main expansion file.</p> + +<p class="note"><strong>Note:</strong> Even if you only need to make changes to the patch +expansion file, you must still update the APK in order for Google Play to perform an update. +If you don't require code changes in the application, you should simply update the <a +href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code versionCode}</a> in the +manifest.</p> + +<p>As long as you don't change the main expansion file that's associated with the APK +in the Developer Console, users who previously installed your application will not +download the main expansion file. Existing users receive only the updated APK and the new patch +expansion file (retaining the previous main expansion file).</p> + +<p>Here are a few issues to keep in mind regarding updates to expansion files:</p> + +<ul> + <li>There can be only two expansion files for your application at a time. One main expansion +file and one patch expansion file. During an update to a file, Google Play deletes the +previous version (and so must your application when performing manual updates).</li> + <li>When adding a patch expansion file, the Android system does not actually patch your +application or main expansion file. You must design your application to support the patch data. +However, the Apk Expansion package includes a library for using ZIP files +as expansion files, which merges the data from the patch file into the main expansion file so +you can easily read all the expansion file data.</li> +</ul> + + + +<!-- Tools are not ready. + +<h3>Using OBB tool and APIs</h3> + +<pre> +$ mkobb.sh -d /data/myfiles -k my_secret_key -o /data/data.obb +$ obbtool a -n com.example.myapp -v 1 -s seed_from_mkobb /data/data.obb +</pre> + +<pre> +storage = (StorageManager) getSystemService( STORAGE_SERVICE ); +storage.mountObb( obbFilepath, "my_secret_key", myListener ); +obbContentPath = storage.getMountedObbPath( obbFilepath ); +</pre> +--> diff --git a/docs/html/guide/market/licensing/adding-licensing.jd b/docs/html/guide/market/licensing/adding-licensing.jd new file mode 100644 index 0000000..d4dd008 --- /dev/null +++ b/docs/html/guide/market/licensing/adding-licensing.jd @@ -0,0 +1,1072 @@ +page.title=Adding Licensing to Your App +parent.title=Application Licensing +parent.link=index.html +@jd:body + + + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>In this document</h2> + <ol> + <li><a href="#manifest-permission">Adding the Licensing Permission</a></li> + <li><a href="#impl-Policy">Implementing a Policy</a> + <ol> + <li><a href="#custom-policies">Guidelines for custom policies</a></li> + <li><a href="#ServerManagedPolicy">ServerManagedPolicy</a></li> + <li><a href="#StrictPolicy">StrictPolicy</a></li> + </ol> + </li> + <li><a href="#impl-Obfuscator">Implementing an Obfuscator</a> + <ol> + <li><a href="#AESObfuscator">AESObfuscator</a></li> + </ol> + </li> + <li><a href="#impl-lc">Checking the License from an Activity</a> + <ol> + <li><a href="#lc-overview">Overview of license check and response</a></li> + <li><a href="#imports">Add imports</a></li> + <li><a href="#lc-impl">Implement LicenseCheckerCallback as a private inner class</a></li> + <li><a href="#thread-handler">Create a Handler for posting from LicenseCheckerCallback +to the UI thread</a></li> + <li><a href="#lc-lcc">Instantiate LicenseChecker and LicenseCheckerCallback</a></li> + <li><a href="#check-access">Call checkAccess() to initiate the license check</a></li> + <li><a href="#account-key">Embed your public key for licensing</a></li> + <li><a href="#handler-cleanup">Call your LicenseChecker's onDestroy() method +to close IPC connections</a></li> + </ol> + </li> + <li><a href="#impl-DeviceLimiter">Implementing a DeviceLimiter</a></li> + <li><a href="#app-obfuscation">Obfuscating Your Code</a></li> + <li><a href="#app-publishing">Publishing a Licensed Application</a> + <ol> + <li><a href="#">Removing Copy Protection</a></li> + </ol> + </li> + <li><a href="#support">Where to Get Support</a></li> +</ol> + +</div> +</div> + + + +<p>After you've set up a publisher account and development environment (see <a +href="setting-up.html">Setting Up for Licensing</a>), you are ready to add license verification to +your app with the License Verification Library (LVL).</p> + +<p>Adding license verification with the LVL involves these tasks:</p> + +<ol> +<li><a href="#manifest-permission">Adding the licensing permission</a> your application's manifest.</li> +<li><a href="#impl-Policy">Implementing a Policy</a> — you can choose one of the full implementations provided in the LVL or create your own.</li> +<li><a href="#impl-Obfuscator">Implementing an Obfuscator</a>, if your {@code Policy} will cache any +license response data. </li> +<li><a href="#impl-lc">Adding code to check the license</a> in your application's main +Activity.</li> +<li><a href="#impl-DeviceLimiter">Implementing a DeviceLimiter</a> (optional and not recommended for +most applications).</li> +</ol> + +<p>The sections below describe these tasks. When you are done with the +integration, you should be able to compile your application successfully and you +can begin testing, as described in <a +href="{@docRoot}guide/market/licensing/setting-up.html#test-env">Setting Up the Test +Environment</a>.</p> + +<p>For an overview of the full set of source files included in the LVL, see <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#lvl-summary">Summary of LVL Classes +and Interfaces</a>.</p> + + +<h2 id="manifest-permission">Adding the Licensing Permission</h2> + +<p>To use the Google Play application for sending a license check to the +server, your application must request the proper permission, +<code>com.android.vending.CHECK_LICENSE</code>. If your application does +not declare the licensing permission but attempts to initiate a license check, +the LVL throws a security exception.</p> + +<p>To request the licensing permission in your application, declare a <a +href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a> +element as a child of <code><manifest></code>, as follows: </p> + +<p style="margin-left:2em;"><code><uses-permission +android:name="com.android.vending.CHECK_LICENSE"></code></p> + +<p>For example, here's how the LVL sample application declares the permission: +</p> + +<pre><?xml version="1.0" encoding="utf-8"?> + +<manifest xmlns:android="http://schemas.android.com/apk/res/android" ..."> + <!-- Devices >= 3 have version of Google Play that supports licensing. --> + <uses-sdk android:minSdkVersion="3" /> + <!-- Required permission to check licensing. --> + <uses-permission android:name="com.android.vending.CHECK_LICENSE" /> + ... +</manifest> +</pre> + +<p class="note"><strong>Note:</strong> Currently, you cannot declare the +<code>CHECK_LICENSE</code> permission in the LVL library project's manifest, +because the SDK Tools will not merge it into the manifests of dependent +applications. Instead, you must declare the permission in each dependent +application's manifest. </p> + + +<h2 id="impl-Policy">Implementing a Policy</h2> + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>ServerManagedPolicy</h2> + +<p>The LVL includes a complete {@code Policy} implementation called ServerManagedPolicy +that makes use of license-management settings provided by the Google Play +server. </p> + +<p style="margin-top:.5em;">Use of ServerManagedPolicy as the basis for your +Policy is strongly recommended. For more information, see <a +href="#ServerManagedPolicy">ServerManagedPolicy</a> section, below.</p> + +</div> +</div> + +<p>Google Play licensing service does not itself determine whether a +given user with a given license should be granted access to your application. +Rather, that responsibility is left to a {@code Policy} implementation that you provide +in your application.</p> + +<p>Policy is an interface declared by the LVL that is designed to hold your +application's logic for allowing or disallowing user access, based on the result +of a license check. To use the LVL, your application <em>must</em> provide an +implementation of {@code Policy}. </p> + +<p>The {@code Policy} interface declares two methods, <code>allowAccess()</code> and +<code>processServerResponse()</code>, which are called by a {@code LicenseChecker} +instance when processing a response from the license server. It also declares an +enum called <code>LicenseResponse</code>, which specifies the license response +value passed in calls to <code>processServerResponse()</code>. </p> + +<ul> +<li><code>processServerResponse()</code> lets you preprocess the raw response +data received from the licensing server, prior to determining whether to grant +access. + +<p>A typical implementation would extract some or all fields from the license +response and store the data locally to a persistent store, such as through +{@link android.content.SharedPreferences} storage, to ensure that the data is +accessible across application invocations and device power cycles. For example, +a {@code Policy} would maintain the timestamp of the last successful license check, the +retry count, the license validity period, and similar information in a +persistent store, rather than resetting the values each time the application is +launched.</p> + +<p>When storing response data locally, the {@code Policy} must ensure that the data is +obfuscated (see <a href="#impl-Obfuscator">Implementing an Obfuscator</a>, +below).</p></li> + +<li><code>allowAccess()</code> determines whether to grant the user access to +your application, based on any available license response data (from the +licensing server or from cache) or other application-specific information. For +example, your implementation of <code>allowAccess()</code> could take into +account additional criteria, such as usage or other data retrieved from a +backend server. In all cases, an implementation of <code>allowAccess()</code> +should only return <code>true</code> if the user is licensed to use the +application, as determined by the licensing server, or if there is a transient +network or system problem that prevents the license check from completing. In +such cases, your implementation can maintain a count of retry responses and +provisionally allow access until the next license check is complete.</li> + +</ul> + +<p>To simplify the process of adding licensing to your application and to +provide an illustration of how a {@code Policy} should be designed, the LVL includes +two full {@code Policy} implementations that you can use without modification or +adapt to your needs:</p> + +<ul> +<li><a href="#ServerManagedPolicy">ServerManagedPolicy</a>, a flexible {@code Policy} +that uses server-provided settings and cached responses to manage access across +varied network conditions, and</li> +<li><a href="#StrictPolicy">StrictPolicy</a>, which does not cache any response +data and allows access <em>only</em> if the server returns a licensed +response.</li> +</ul> + +<p>For most applications, the use of ServerManagedPolicy is highly +recommended. ServerManagedPolicy is the LVL default and is integrated with +the LVL sample application.</p> + + +<h3 id="custom-policies">Guidelines for custom policies</h3> + +<p>In your licensing implementation, you can use one of the complete policies +provided in the LVL (ServerManagedPolicy or StrictPolicy) or you can create a +custom policy. For any type of custom policy, there are several important design +points to understand and account for in your implementation.</p> + +<p>The licensing server applies general request limits to guard against overuse +of resources that could result in denial of service. When an application exceeds +the request limit, the licensing server returns a 503 response, which gets +passed through to your application as a general server error. This means that no +license response will be available to the user until the limit is reset, which +can affect the user for an indefinite period.</p> + +<p>If you are designing a custom policy, we recommend that the {@code Policy}: +<ol> +<!-- <li>Limits the number of points at which your app calls for a license check +to the minimum. </li> --> +<li>Caches (and properly obfuscates) the most recent successful license response +in local persistent storage.</li> +<li>Returns the cached response for all license checks, for as long as the +cached response is valid, rather than making a request to the licensing server. +Setting the response validity according to the server-provided <code>VT</code> +extra is highly recommended. See <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server Response Extras</a> +for more information.</li> +<li>Uses an exponential backoff period, if retrying any requests the result in +errors. Note that the Google Play client automatically retries failed +requests, so in most cases there is no need for your {@code Policy} to retry them.</li> +<li>Provides for a "grace period" that allows the user to access your +application for a limited time or number of uses, while a license check is being +retried. The grace period benefits the user by allowing access until the next +license check can be completed successfully and it benefits you by placing a +hard limit on access to your application when there is no valid license response +available.</li> +</ol> + +<p>Designing your {@code Policy} according to the guidelines listed above is critical, +because it ensures the best possible experience for users while giving you +effective control over your application even in error conditions. </p> + +<p>Note that any {@code Policy} can use settings provided by the licensing server to +help manage validity and caching, retry grace period, and more. Extracting the +server-provided settings is straightforward and making use of them is highly +recommended. See the ServerManagedPolicy implementation for an example of how to +extract and use the extras. For a list of server settings and information about +how to use them, see <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server Response +Extras</a>.</p> + +<h3 id="ServerManagedPolicy">ServerManagedPolicy</h3> + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>Server Response Extras</h2> + +<p>For certain types of licensing responses, the licensing server appends extra +settings to the responses, to help the application manage licensing effectively. +</p> + +<p style="margin-top:.5em;">See <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server Response Extras</a> +for +a list of settings and <code>ServerManagedPolicy.java</code> for information +about how a {@code Policy} can use the extras.</p> + +</div> +</div> + +<p>The LVL includes a full and recommended implementation of the {@code Policy} +interface called ServerManagedPolicy. The implementation is integrated with the +LVL classes and serves as the default {@code Policy} in the library. </p> + +<p>ServerManagedPolicy provides all of the handling for license and retry +responses. It caches all of the response data locally in a +{@link android.content.SharedPreferences} file, obfuscating it with the +application's {@code Obfuscator} implementation. This ensures that the license response +data is secure and persists across device power cycles. ServerManagedPolicy +provides concrete implementations of the interface methods +<code>processServerResponse()</code> and <code>allowAccess()</code> and also +includes a set of supporting methods and types for managing license +responses.</p> + +<p>Importantly, a key feature of ServerMangedPolicy is its use of +server-provided settings as the basis for managing licensing across an +application's refund period and through varying network and error conditions. +When an application contacts the Google Play server for a license check, the +server appends several settings as key-value pairs in the extras field of certain +license response types. For example, the server provides recommended values for the +application's license validity period, retry grace period, and maximum allowable +retry count, among others. ServerManagedPolicy extracts the values from the +license response in its <code>processServerResponse()</code> method and checks +them in its <code>allowAccess()</code> method. For a list of the server-provided +settings used by ServerManagedPolicy, see <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server Response +Extras</a>.</p> + +<p>For convenience, best performance, and the benefit of using license settings +from the Google Play server, <strong>using ServerManagedPolicy as your +licensing {@code Policy} is strongly recommended</strong>. </p> + +<p>If you are concerned about the security of license response data that is +stored locally in {@link android.content.SharedPreferences}, you can use a stronger obfuscation +algorithm or design a stricter {@code Policy} that does not store license data. The LVL +includes an example of such a {@code Policy} — see <a +href="#StrictPolicy">StrictPolicy</a> for more information.</p> + +<p>To use ServerManagedPolicy, simply import it to your Activity, create an +instance, and pass a reference to the instance when constructing your +{@code LicenseChecker}. See <a href="#lc-lcc">Instantiate LicenseChecker and +LicenseCheckerCallback</a> for more information. </p> + +<h3 id="StrictPolicy">StrictPolicy</h3> + +<p>The LVL includes an alternative full implementation of the {@code Policy} interface +called StrictPolicy. The StrictPolicy implementation provides a more restrictive +Policy than ServerManagedPolicy, in that it does not allow the user to access +the application unless a license response is received from the server at the +time of access that indicates that the user is licensed.</p> + +<p>The principal feature of StrictPolicy is that it does not store <em>any</em> +license response data locally, in a persistent store. Because no data is stored, +retry requests are not tracked and cached responses can not be used to fulfill +license checks. The {@code Policy} allows access only if:</p> + +<ul> +<li>The license response is received from the licensing server, and </li> +<li>The license response indicates that the user is licensed to access the +application. </li> +</ul> + +<p>Using StrictPolicy is appropriate if your primary concern is to ensure that, +in all possible cases, no user will be allowed to access the application unless +the user is confirmed to be licensed at the time of use. Additionally, the +Policy offers slightly more security than ServerManagedPolicy — since +there is no data cached locally, there is no way a malicious user could tamper +with the cached data and obtain access to the application.</p> + +<p>At the same time, this {@code Policy} presents a challenge for normal users, since it +means that they won't be able to access the application when there is no network +(cell or Wi-Fi) connection available. Another side-effect is that your +application will send more license check requests to the server, since using a +cached response is not possible.</p> + +<p>Overall, this policy represents a tradeoff of some degree of user convenience +for absolute security and control over access. Consider the tradeoff carefully +before using this {@code Policy}.</p> + +<p>To use StrictPolicy, simply import it to your Activity, create an instance, +and pass a reference to it when constructing your {@code LicenseChecker}. See +<a href="#lc-lcc">Instantiate LicenseChecker and LicenseCheckerCallback</a> +for more information. </p> + +<h2 id="impl-Obfuscator">Implementing an Obfuscator</h2> + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>AESObfuscator</h2> + +<p>The LVL includes a full {@code Obfuscator} implementation in the +<code>AESObfuscator.java</code> file. The {@code Obfuscator} uses AES encryption to +obfuscate/unobfuscate data. If you are using a {@code Policy} (such as +ServerManagedPolicy) that caches license response data, using AESObfuscator as +basis for your {@code Obfuscator} implementation is highly recommended. </p> + +</div> +</div> + +<p>A typical {@code Policy} implementation needs to save the license response data for +an application to a persistent store, so that it is accessible across +application invocations and device power cycles. For example, a {@code Policy} would +maintain the timestamp of the last successful license check, the retry count, +the license validity period, and similar information in a persistent store, +rather than resetting the values each time the application is launched. The +default {@code Policy} included in the LVL, ServerManagedPolicy, stores license response +data in a {@link android.content.SharedPreferences} instance, to ensure that the +data is persistent. </p> + +<p>Because the {@code Policy} will use stored license response data to determine whether +to allow or disallow access to the application, it <em>must</em> ensure that any +stored data is secure and cannot be reused or manipulated by a root user on a +device. Specifically, the {@code Policy} must always obfuscate the data before storing +it, using a key that is unique for the application and device. Obfuscating using +a key that is both application-specific and device-specific is critical, because +it prevents the obfuscated data from being shared among applications and +devices.</p> + +<p>The LVL assists the application with storing its license response data in a +secure, persistent manner. First, it provides an {@code Obfuscator} +interface that lets your application supply the obfuscation algorithm of its +choice for stored data. Building on that, the LVL provides the helper class +PreferenceObfuscator, which handles most of the work of calling the +application's {@code Obfuscator} class and reading and writing the obfuscated data in a +{@link android.content.SharedPreferences} instance. </p> + +<p>The LVL provides a full {@code Obfuscator} implementation called +AESObfuscator that uses AES encryption to obfuscate data. You can +use AESObfuscator in your application without modification or you +can adapt it to your needs. For more information, see the next section.</p> + + +<h3 id="AESObfuscator">AESObfuscator</h3> + +<p>The LVL includes a full and recommended implementation of the {@code Obfuscator} +interface called AESObfuscator. The implementation is integrated with the +LVL sample application and serves as the default {@code Obfuscator} in the library. </p> + +<p>AESObfuscator provides secure obfuscation of data by using AES to +encrypt and decrypt the data as it is written to or read from storage. +The {@code Obfuscator} seeds the encryption using three data fields provided +by the application: </p> + +<ol> +<li>A salt — an array of random bytes to use for each (un)obfuscation. </li> +<li>An application identifier string, typically the package name of the application.</li> +<li>A device identifier string, derived from as many device-specific sources +as possible, so as to make it as unique.</li> +</ol> + +<p>To use AESObfuscator, first import it to your Activity. Declare a private +static final array to hold the salt bytes and initialize it to 20 randomly +generated bytes.</p> + +<pre> ... + // Generate 20 random bytes, and put them here. + private static final byte[] SALT = new byte[] { + -46, 65, 30, -128, -103, -57, 74, -64, 51, 88, -95, + -45, 77, -117, -36, -113, -11, 32, -64, 89 + }; + ... +</pre> + +<p>Next, declare a variable to hold a device identifier and generate a value for +it in any way needed. For example, the sample application included in the LVL +queries the system settings for the +<code>android.Settings.Secure.ANDROID_ID</code>, which is unique to each device. +</p> + +<p>Note that, depending on the APIs you use, your application might need to +request additional permissions in order to acquire device-specific information. +For example, to query the {@link android.telephony.TelephonyManager} to obtain +the device IMEI or related data, the application will also need to request the +<code>android.permission.READ_PHONE_STATE</code> permission in its manifest.</p> + +<p>Before requesting new permissions for the <em>sole purpose</em> of acquiring +device-specific information for use in your {@code Obfuscator}, consider +how doing so might affect your application or its filtering on Google Play +(since some permissions can cause the SDK build tools to add +the associated <code><uses-feature></code>).</p> + +<p>Finally, construct an instance of AESObfuscator, passing the salt, +application identifier, and device identifier. You can construct the instance +directly, while constructing your {@code Policy} and {@code LicenseChecker}. For example:</p> + +<pre> ... + // Construct the LicenseChecker with a Policy. + mChecker = new LicenseChecker( + this, new ServerManagedPolicy(this, + new AESObfuscator(SALT, getPackageName(), deviceId)), + BASE64_PUBLIC_KEY // Your public licensing key. + ); + ... +</pre> + +<p>For a complete example, see MainActivity in the LVL sample application.</p> + + +<h2 id="impl-lc">Checking the License from an Activity</h2> + +<p>Once you've implemented a {@code Policy} for managing access to your application, the +next step is to add a license check to your application, which initiates a query +to the licensing server if needed and manages access to the application based on +the license response. All of the work of adding the license check and handling +the response takes place in your main {@link android.app.Activity} source file. +</p> + +<p>To add the license check and handle the response, you must:</p> + +<ol> + <li><a href="#imports">Add imports</a></li> + <li><a href="#lc-impl">Implement LicenseCheckerCallback</a> as a private inner class</li> + <li><a href="#thread-handler">Create a Handler</a> for posting from LicenseCheckerCallback to the UI thread</li> + <li><a href="#lc-lcc">Instantiate LicenseChecker</a> and LicenseCheckerCallback</li> + <li><a href="#check-access">Call checkAccess()</a> to initiate the license check</li> + <li><a href="#account-key">Embed your public key</a> for licensing</li> + <li><a href="#handler-cleanup">Call your LicenseChecker's onDestroy() method</a> to close IPC connections.</li> +</ol> + +<p>The sections below describe these tasks. </p> + +<h3 id="lc-overview">Overview of license check and response</h3> + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>Example: MainActivity</h2> + +<p>The sample application included with the LVL provides a full example of how +to initiate a license check and handle the result, in the +<code>MainActivity.java</code> file.</p> + +</div> +</div> + +<p>In most cases, you should add the license check to your application's main +{@link android.app.Activity}, in the {@link android.app.Activity#onCreate onCreate()} method. This +ensures that when the user launches your application directly, the license check +will be invoked immediately. In some cases, you can add license checks in other +locations as well. For example, if your application includes multiple Activity +components that other applications can start by {@link android.content.Intent}, +you could add license checks in those Activities.</p> + +<p>A license check consists of two main actions: </p> + +<ul> +<li>A call to a method to initiate the license check — in the LVL, this is +a call to the <code>checkAccess()</code> method of a {@code LicenseChecker} object that +you construct.</li> +<li>A callback that returns the result of the license check. In the LVL, this is +a <code>LicenseCheckerCallback</code> interface that you implement. The +interface declares two methods, <code>allow()</code> and +<code>dontAllow()</code>, which are invoked by the library based on to the +result of the license check. You implement these two methods with whatever logic +you need, to allow or disallow the user access to your application. Note that +these methods do not determine <em>whether</em> to allow access — that +determination is the responsibility of your {@code Policy} implementation. Rather, these +methods simply provide the application behaviors for <em>how</em> to allow and +disallow access (and handle application errors). + <p>The <code>allow()</code> and <code>dontAllow()</code> methods do provide a "reason" +for their response, which can be one of the {@code Policy} values, {@code LICENSED}, +{@code NOT_LICENSED}, or {@code RETRY}. In particular, you should handle the case in which +the method receives the {@code RETRY} response for {@code dontAllow()} and provide the user with an +"Retry" button, which might have happened because the service was unavailable during the +request.</p></li> +</ul> + +<div style="margin-bottom:2em;"> + +<img src="{@docRoot}images/licensing_flow.png" style="text-align:left;margin-bottom:0;margin-left:3em;" /> +<div style="margin:.5em 0 1.5em 2em;padding:0"><strong>Figure 6.</strong> Overview of a +typical license check interaction.</div> +</div> + +<p>The diagram above illustrates how a typical license check takes place: </p> + +<ol> +<li>Code in the application's main Activity instantiates {@code LicenseCheckerCallback} +and {@code LicenseChecker} objects. When constructing {@code LicenseChecker}, the code passes in +{@link android.content.Context}, a {@code Policy} implementation to use, and the +publisher account's public key for licensing as parameters. </li> +<li>The code then calls the <code>checkAccess()</code> method on the +{@code LicenseChecker} object. The method implementation calls the {@code Policy} to determine +whether there is a valid license response cached locally, in +{@link android.content.SharedPreferences}. + <ul> + <li>If so, the <code>checkAccess()</code> implementation calls + <code>allow()</code>.</li> + <li>Otherwise, the {@code LicenseChecker} initiates a license check request that is sent + to the licensing server.</li> + </ul> + +<p class="note"><strong>Note:</strong> The licensing server always returns +<code>LICENSED</code> when you perform a license check of a draft application.</p> +</li> +<li>When a response is received, {@code LicenseChecker} creates a LicenseValidator that +verifies the signed license data and extracts the fields of the response, then +passes them to your {@code Policy} for further evaluation. + <ul> + <li>If the license is valid, the {@code Policy} caches the response in +{@link android.content.SharedPreferences} and notifies the validator, which then calls the +<code>allow()</code> method on the {@code LicenseCheckerCallback} object. </li> + <li>If the license not valid, the {@code Policy} notifies the validator, which calls +the <code>dontAllow()</code> method on {@code LicenseCheckerCallback}. </li> + </ul> +</li> +<li>In case of a recoverable local or server error, such as when the network is +not available to send the request, {@code LicenseChecker} passes a {@code RETRY} response to +your {@code Policy} object's <code>processServerResponse()</code> method. + <p>Also, both the {@code allow()} and {@code dontAllow()} callback methods receive a +<code>reason</code> argument. The {@code allow()} method's reason is usually {@code +Policy.LICENSED} or {@code Policy.RETRY} and the {@code dontAllow()} reason is usually {@code +Policy.NOT_LICENSED} or {@code Policy.RETRY}. These response values are useful so you can show +an appropriate response for the user, such as by providing a "Retry" button when {@code +dontAllow()} responds with {@code Policy.RETRY}, which might have been because the service was +unavailable.</p></li> +<li>In case of a application error, such as when the application attempts to +check the license of an invalid package name, {@code LicenseChecker} passes an error +response to the LicenseCheckerCallback's <code>applicationError()</code> +method. </li> +</ol> + +<p>Note that, in addition to initiating the license check and handling the +result, which are described in the sections below, your application also needs +to provide a <a href="#impl-Policy">Policy implementation</a> and, if the {@code Policy} +stores response data (such as ServerManagedPolicy), an <a +href="#impl-Obfuscator">Obfuscator</a> implementation. </p> + + +<h3 id="imports">Add imports</h3> + +<p>First, open the class file of the application's main Activity and import +{@code LicenseChecker} and {@code LicenseCheckerCallback} from the LVL package.</p> + +<pre> import com.android.vending.licensing.LicenseChecker; + import com.android.vending.licensing.LicenseCheckerCallback;</pre> + +<p>If you are using the default {@code Policy} implementation provided with the LVL, +ServerManagedPolicy, import it also, together with the AESObfuscator. If you are +using a custom {@code Policy} or {@code Obfuscator}, import those instead. </p> + +<pre> import com.android.vending.licensing.ServerManagedPolicy; + import com.android.vending.licensing.AESObfuscator;</pre> + +<h3 id="lc-impl">Implement LicenseCheckerCallback as a private inner class</h3> + +<p>{@code LicenseCheckerCallback} is an interface provided by the LVL for handling +result of a license check. To support licensing using the LVL, you must +implement {@code LicenseCheckerCallback} and +its methods to allow or disallow access to the application.</p> + +<p>The result of a license check is always a call to one of the +{@code LicenseCheckerCallback} methods, made based on the validation of the response +payload, the server response code itself, and any additional processing provided +by your {@code Policy}. Your application can implement the methods in any way needed. In +general, it's best to keep the methods simple, limiting them to managing UI +state and application access. If you want to add further processing of license +responses, such as by contacting a backend server or applying custom constraints, +you should consider incorporating that code into your {@code Policy}, rather than +putting it in the {@code LicenseCheckerCallback} methods. </p> + +<p>In most cases, you should declare your implementation of +{@code LicenseCheckerCallback} as a private class inside your application's main +Activity class. </p> + +<p>Implement the <code>allow()</code> and <code>dontAllow()</code> methods as +needed. To start with, you can use simple result-handling behaviors in the +methods, such as displaying the license result in a dialog. This helps you get +your application running sooner and can assist with debugging. Later, after you +have determined the exact behaviors you want, you can add more complex handling. +</p> + +<p>Some suggestions for handling unlicensed responses in +<code>dontAllow()</code> include: </p> + +<ul> +<li>Display a "Try again" dialog to the user, including a button to initiate a +new license check if the <code>reason</code> supplied is {@code Policy.RETRY}. </li> +<li>Display a "Purchase this application" dialog, including a button that +deep-links the user to the application's details page on Google Play, from which the +use can purchase the application. For more information on how to set up such +links, see <a +href="{@docRoot}guide/publishing/publishing.html#marketintent">Linking to your apps +on Google Play</a>. </li> +<li>Display a Toast notification that indicates that the features of the +application are limited because it is not licensed. </li> +</ul> + +<p>The example below shows how the LVL sample application implements +{@code LicenseCheckerCallback}, with methods that display the license check result in a +dialog. </p> + +<pre> +private class MyLicenseCheckerCallback implements LicenseCheckerCallback { + public void allow(int reason) { + if (isFinishing()) { + // Don't update UI if Activity is finishing. + return; + } + // Should allow user access. + displayResult(getString(R.string.allow)); + } + + public void dontAllow(int reason) { + if (isFinishing()) { + // Don't update UI if Activity is finishing. + return; + } + displayResult(getString(R.string.dont_allow)); + + if (reason == Policy.RETRY) { + // If the reason received from the policy is RETRY, it was probably + // due to a loss of connection with the service, so we should give the + // user a chance to retry. So show a dialog to retry. + showDialog(DIALOG_RETRY); + } else { + // Otherwise, the user is not licensed to use this app. + // Your response should always inform the user that the application + // is not licensed, but your behavior at that point can vary. You might + // provide the user a limited access version of your app or you can + // take them to Google Play to purchase the app. + showDialog(DIALOG_GOTOMARKET); + } + } +} +</pre> + +<p>Additionally, you should implement the <code>applicationError()</code> +method, which the LVL calls to let your application handle errors that are not +retryable. For a list of such errors, see <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#server-response-codes">Server +Response Codes</a> in the <a +href="guide/market/licensing/licensing-reference.html">Licensing Reference</a>. You can implement +the method in any way needed. In most cases, the +method should log the error code and call <code>dontAllow()</code>.</p> + +<h3 id="thread-handler">Create a Handler for posting from LicenseCheckerCallback +to the UI thread</h3> + +<p>During a license check, the LVL passes the request to the Google Play +application, which handles communication with the licensing server. The LVL +passes the request over asynchronous IPC (using {@link android.os.Binder}) so +the actual processing and network communication do not take place on a thread +managed by your application. Similarly, when the Google Play application +receives the result, it invokes a callback method over IPC, which in turn +executes in an IPC thread pool in your application's process.</p> + +<p>The {@code LicenseChecker} class manages your application's IPC communication with +the Google Play application, including the call that sends the request and +the callback that receives the response. {@code LicenseChecker} also tracks open license +requests and manages their timeouts. </p> + +<p>So that it can handle timeouts properly and also process incoming responses +without affecting your application's UI thread, {@code LicenseChecker} spawns a +background thread at instantiation. In the thread it does all processing of +license check results, whether the result is a response received from the server +or a timeout error. At the conclusion of processing, the LVL calls your +{@code LicenseCheckerCallback} methods from the background thread. </p> + +<p>To your application, this means that:</p> + +<ol> +<li>Your {@code LicenseCheckerCallback} methods will be invoked, in many cases, from a +background thread.</li> +<li>Those methods won't be able to update state or invoke any processing in the +UI thread, unless you create a Handler in the UI thread and have your callback +methods post to the Handler.</li> +</ol> + +<p>If you want your {@code LicenseCheckerCallback} methods to update the UI thread, +instantiate a {@link android.os.Handler} in the main Activity's +{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, +as shown below. In this example, the LVL sample application's +{@code LicenseCheckerCallback} methods (see above) call <code>displayResult()</code> to +update the UI thread through the Handler's +{@link android.os.Handler#post(java.lang.Runnable) post()} method.</p> + +<pre>private Handler mHandler; + + @Override + public void onCreate(Bundle savedInstanceState) { + ... + mHandler = new Handler(); + } +</pre> + +<p>Then, in your {@code LicenseCheckerCallback} methods, you can use Handler methods to +post Runnable or Message objects to the Handler. Here's how the sample +application included in the LVL posts a Runnable to a Handler in the UI thread +to display the license status.</p> + +<pre> private void displayResult(final String result) { + mHandler.post(new Runnable() { + public void run() { + mStatusText.setText(result); + setProgressBarIndeterminateVisibility(false); + mCheckLicenseButton.setEnabled(true); + } + }); + } +</pre> + +<h3 id="lc-lcc">Instantiate LicenseChecker and LicenseCheckerCallback</h3> + +<p>In the main Activity's +{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, +create private instances of LicenseCheckerCallback and {@code LicenseChecker}. You must +instantiate {@code LicenseCheckerCallback} first, because you need to pass a reference +to that instance when you call the constructor for {@code LicenseChecker}. </p> + +<p>When you instantiate {@code LicenseChecker}, you need to pass in these parameters:</p> + +<ul> +<li>The application {@link android.content.Context}</li> +<li>A reference to the {@code Policy} implementation to use for the license check. In +most cases, you would use the default {@code Policy} implementation provided by the LVL, +ServerManagedPolicy. </li> +<li>The String variable holding your publisher account's public key for +licensing. </li> +</ul> + +<p>If you are using ServerManagedPolicy, you won't need to access the class +directly, so you can instantiate it in the {@code LicenseChecker} constructor, +as shown in the example below. Note that you need to pass a reference to a new +Obfuscator instance when you construct ServerManagedPolicy.</p> + +<p>The example below shows the instantiation of {@code LicenseChecker} and +{@code LicenseCheckerCallback} from the <code>onCreate()</code> method of an Activity +class. </p> + +<pre>public class MainActivity extends Activity { + ... + private LicenseCheckerCallback mLicenseCheckerCallback; + private LicenseChecker mChecker; + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + ... + // Construct the LicenseCheckerCallback. The library calls this when done. + mLicenseCheckerCallback = new MyLicenseCheckerCallback(); + + // Construct the LicenseChecker with a Policy. + mChecker = new LicenseChecker( + this, new ServerManagedPolicy(this, + new AESObfuscator(SALT, getPackageName(), deviceId)), + BASE64_PUBLIC_KEY // Your public licensing key. + ); + ... + } +} +</pre> + + +<p>Note that {@code LicenseChecker} calls the {@code LicenseCheckerCallback} methods from the UI +thread <em>only</em> if there is valid license response cached locally. If the +license check is sent to the server, the callbacks always originate from the +background thread, even for network errors. </p> + + +<h3 id="check-access">Call checkAccess() to initiate the license check</h3> + +<p>In your main Activity, add a call to the <code>checkAccess()</code> method of the +{@code LicenseChecker} instance. In the call, pass a reference to your +{@code LicenseCheckerCallback} instance as a parameter. If you need to handle any +special UI effects or state management before the call, you might find it useful +to call <code>checkAccess()</code> from a wrapper method. For example, the LVL +sample application calls <code>checkAccess()</code> from a +<code>doCheck()</code> wrapper method:</p> + +<pre> @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + ... + // Call a wrapper method that initiates the license check + doCheck(); + ... + } + ... + private void doCheck() { + mCheckLicenseButton.setEnabled(false); + setProgressBarIndeterminateVisibility(true); + mStatusText.setText(R.string.checking_license); + mChecker.checkAccess(mLicenseCheckerCallback); + } +</pre> + + +<h3 id="account-key">Embed your public key for licensing</h3> + +<p>For each publisher account, the Google Play service automatically +generates a 2048-bit RSA public/private key pair that is used exclusively for +licensing. The key pair is uniquely associated with the publisher account and is +shared across all applications that are published through the account. Although +associated with a publisher account, the key pair is <em>not</em> the same as +the key that you use to sign your applications (or derived from it).</p> + +<p>The Google Play publisher site exposes the public key for licensing to any +developer signed in to the publisher account, but it keeps the private key +hidden from all users in a secure location. When an application requests a +license check for an application published in your account, the licensing server +signs the license response using the private key of your account's key pair. +When the LVL receives the response, it uses the public key provided by the +application to verify the signature of the license response. </p> + +<p>To add licensing to an application, you must obtain your publisher account's +public key for licensing and copy it into your application. Here's how to find +your account's public key for licensing:</p> + +<ol> +<li>Go to the Google Play <a +href="http://play.google.com/apps/publish">publisher site</a> and sign in. +Make sure that you sign in to the account from which the application you are +licensing is published (or will be published). </li> +<li>In the account home page, locate the "Edit profile" link and click it. </li> +<li>In the Edit Profile page, locate the "Licensing" pane, shown below. Your +public key for licensing is given in the "Public key" text box. </li> +</ol> + +<p>To add the public key to your application, simply copy/paste the key string +from the text box into your application as the value of the String variable +<code>BASE64_PUBLIC_KEY</code>. When you are copying, make sure that you have +selected the entire key string, without omitting any characters. </p> + +<p>Here's an example from the LVL sample application:</p> + +<pre> public class MainActivity extends Activity { + private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example + ... + } +</pre> + +<h3 id="handler-cleanup">Call your LicenseChecker's onDestroy() method +to close IPC connections</h3> + +<p>Finally, to let the LVL clean up before your application +{@link android.content.Context} changes, add a call to the {@code LicenseChecker}'s +<code>onDestroy()</code> method from your Activity's +{@link android.app.Activity#onDestroy()} implementation. The call causes the +{@code LicenseChecker} to properly close any open IPC connection to the Google Play +application's ILicensingService and removes any local references to the service +and handler.</p> + +<p>Failing to call the {@code LicenseChecker}'s <code>onDestroy()</code> method +can lead to problems over the lifecycle of your application. For example, if the +user changes screen orientation while a license check is active, the application +{@link android.content.Context} is destroyed. If your application does not +properly close the {@code LicenseChecker}'s IPC connection, your application will crash +when the response is received. Similarly, if the user exits your application +while a license check is in progress, your application will crash when the +response is received, unless it has properly called the +{@code LicenseChecker}'s <code>onDestroy()</code> method to disconnect from the service. +</p> + +<p>Here's an example from the sample application included in the LVL, where +<code>mChecker</code> is the {@code LicenseChecker} instance:</p> + +<pre> @Override + protected void onDestroy() { + super.onDestroy(); + mChecker.onDestroy(); + ... + } +</pre> + +<p>If you are extending or modifying {@code LicenseChecker}, you might also need to call +the {@code LicenseChecker}'s <code>finishCheck()</code> method, to clean up any open IPC +connections.</p> + +<h2 id="impl-DeviceLimiter">Implementing a DeviceLimiter</h2> + +<p>In some cases, you might want your {@code Policy} to limit the number of actual +devices that are permitted to use a single license. This would prevent a user +from moving a licensed application onto a number of devices and using the +application on those devices under the same account ID. It would also prevent a +user from "sharing" the application by providing the account information +associated with the license to other individuals, who could then sign in to that +account on their devices and access the license to the application. </p> + +<p>The LVL supports per-device licensing by providing a +<code>DeviceLimiter</code> interface, which declares a single method, +<code>allowDeviceAccess()</code>. When a LicenseValidator is handling a response +from the licensing server, it calls <code>allowDeviceAccess()</code>, passing a +user ID string extracted from the response.</p> + +<p>If you do not want to support device limitation, <strong>no work is +required</strong> — the {@code LicenseChecker} class automatically uses a default +implementation called NullDeviceLimiter. As the name suggests, NullDeviceLimiter +is a "no-op" class whose <code>allowDeviceAccess()</code> method simply returns +a <code>LICENSED</code> response for all users and devices. </p> + +<div style="border-left:4px solid #FFCF00;margin:1em;padding: 0 0 0 .5em"> +<p><strong>Caution:</strong> Per-device licensing is <em>not recommended for +most applications</em> because:</p> +<ul> +<li>It requires that you provide a backend server to manage a users and devices +mapping, and </li> +<li>It could inadvertently result in a user being denied access to an +application that they have legitimately purchased on another device.</li> +</ul> +</div> + + + + + + + + + + + +<h2 id="app-obfuscation">Obfuscating Your Code</h2> + +<p>To ensure the security of your application, particularly for a paid +application that uses licensing and/or custom constraints and protections, it's +very important to obfuscate your application code. Properly obfuscating your +code makes it more difficult for a malicious user to decompile the application's +bytecode, modify it — such as by removing the license check — +and then recompile it.</p> + +<p>Several obfuscator programs are available for Android applications, including +<a href="http://proguard.sourceforge.net/">ProGuard</a>, which also offers +code-optimization features. The use of ProGuard or a similar program to obfuscate +your code is <em>strongly recommended</em> for all applications that use Google +Play Licensing. </p> + +<h2 id="app-publishing">Publishing a Licensed Application</h2> + +<p>When you are finished testing your license implementation, you are ready to +publish the application on Google Play. Follow the normal steps to <a +href="{@docRoot}guide/publishing/preparing.html">prepare</a>, <a +href="{@docRoot}guide/publishing/app-signing.html">sign</a>, and then <a +href="{@docRoot}guide/publishing/publishing.html">publish the application</a>. +</p> + +<h3>Removing Copy Protection</h3> + +<p>After uploading your licensed application, remember to remove copy protection +from the application, if it is currently used. To check and remove copy +protection, sign in to the publisher site and go the application's upload +details page. In the Publishing options section, make sure that the Copy +Protection radio button selection is "Off".</p> + + +<h2 id="support">Where to Get Support</h2> + +<p>If you have questions or encounter problems while implementing or deploying +publishing in your applications, please use the support resources listed in the +table below. By directing your queries to the correct forum, you can get the +support you need more quickly. </p> + +<p class="table-caption"><strong>Table 2.</strong> Developer support resources +for Google Play Licensing Service.</p> + +<table> + +<tr> +<th>Support Type</th> +<th>Resource</th> +<th>Range of Topics</th> +</tr> +<tr> +<td rowspan="2">Development and testing issues</td> +<td>Google Groups: <a +href="http://groups.google.com/group/android-developers">android-developers</a> +</td> +<td rowspan="2">LVL download and integration, library projects, {@code Policy} +questions, user experience ideas, handling of responses, {@code Obfuscator}, IPC, test +environment setup</td> +</tr> +<tr> +<td>Stack Overflow: <a +href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.com/questions/tagged/android</a></td> +</tr> +<tr> +<td rowspan="2">Accounts, publishing, and deployment issues</td> +<td><a href="http://www.google.com/support/forum/p/Android+Market">Google Play +Help Forum</a></td> +<td rowspan="2">Publisher accounts, licensing key pair, test accounts, server +responses, test responses, application deployment and results</td> +</tr> +<tr> +<td><a +href="http://market.android.com/support/bin/answer.py?answer=186113">Market +Licensing Support FAQ</a></td> +</tr> +<tr> +<td>LVL issue tracker</td> +<td><a href="http://code.google.com/p/marketlicensing/issues/">Marketlicensing +project issue tracker</a></td> +<td>Bug and issue reports related specifically to the LVL source code classes +and interface implementations</td> +</tr> + +</table> + +<p>For general information about how to post to the groups listed above, see <a +href="{@docRoot}resources/community-groups.html">Developer Forums</a> document +in the Resources tab.</p> + + diff --git a/docs/html/guide/market/licensing/index.jd b/docs/html/guide/market/licensing/index.jd new file mode 100644 index 0000000..1f15303 --- /dev/null +++ b/docs/html/guide/market/licensing/index.jd @@ -0,0 +1,61 @@ +page.title=Application Licensing +@jd:body + + +<p>Google Play offers a licensing service that lets you enforce licensing policies for +applications that you publish on Google Play. With Google Play Licensing, your application can +query Google Play at run time to obtain the licensing status for the current user, then allow or +disallow further use as appropriate. </p> + +<p>Using the service, you can apply a flexible licensing policy on an application-by-application +basis—each application can enforce licensing in the way most appropriate for it. If necessary, +an application can apply custom constraints based on the licensing status obtained from Google Play. +For example, an application can check the licensing status and then apply custom constraints +that allow the user to run it unlicensed for a specific validity period. An application can also +restrict use of the application to a specific device, in addition to any other constraints. </p> + +<p>The licensing service is a secure means of controlling access to your applications. When an +application checks the licensing status, the Google Play server signs the licensing status +response using a key pair that is uniquely associated with the publisher account. Your application +stores the public key in its compiled <code>.apk</code> file and uses it to verify the licensing +status response.</p> + +<p>Any application that you publish through Google Play can use the Google Play Licensing +service. No special account or registration is needed. Additionally, because the service uses no +dedicated framework APIs, you can add licensing to any application that uses a minimum API level of +3 or higher.</p> + +<p class="note"><strong>Note:</strong> The Google Play Licensing service is primarily intended +for paid applications that wish to verify that the current user did in fact pay for the application +on Google Play. However, any application (including free apps) may use the licensing service +to initiate the download of an APK expansion file. In which case, the request that your application +sends to the licensing service is not to check whether the user paid for the app, but to request the +URL of the expansion files. For information about downloading expansion files for your application, +read the guide to <a href="{@docRoot}guide/market/expansion-files.html">APK Expansion Files</a>.</p> + + +<p>To learn more about Google Play's application licensing service and start integrating it into +your applications, read the following documents:</p> + +<dl> + <dt><strong><a href="{@docRoot}guide/market/licensing/overview.html">Licensing +Overview</a></strong></dt> + <dd>Describes how the service works and what a typical licensing implementation looks +like.</dd> + <dt><strong><a href="{@docRoot}guide/market/licensing/setting-up.html">Setting Up for +Licensing</a></strong></dt> + <dd>Explains how to set up your Google Play account, development environment, and +testing environment in order to add licensing to your app.</dd> + <dt><strong><a href="{@docRoot}guide/market/licensing/adding-licensing.html">Adding +Licensing to Your App</a></strong></dt> + <dd>Provides a step-by-step guide to add licensing verification to your application.</dd> + <dt><strong><a href="{@docRoot}guide/market/licensing/licensing-reference.html">Licensing +Reference</a></strong></dt> + <dd>Provides detailed information about the licensing library's classes and the service response +codes.</dd> +</dl> + + + + + diff --git a/docs/html/guide/market/licensing/licensing-reference.jd b/docs/html/guide/market/licensing/licensing-reference.jd new file mode 100644 index 0000000..0a7e033 --- /dev/null +++ b/docs/html/guide/market/licensing/licensing-reference.jd @@ -0,0 +1,439 @@ +page.title=Licensing Reference +parent.title=Application Licensing +parent.link=index.html +@jd:body + + + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>In this document</h2> + <ol> + <li><a href="#lvl-summary">LVL Classes and Interfaces</a></li> + <li><a href="#server-response-codes">Server Response Codes</a></li> + <li><a href="#extras">Server Response Extras</a></li> + </ol> + +</div> +</div> + + +<h2 id="lvl-summary">LVL Classes and Interfaces</h2> + +<p>Table 1 lists all of the source files in the License Verification +Library (LVL) available through the Android SDK. All of the files are part of +the <code>com.android.vending.licensing</code> package.</p> + +<p class="table-caption"><strong>Table 1.</strong> Summary of LVL library +classes and interfaces.</p> + +<div style="width:99%"> +<table width="100%"> + +<tr> +<th width="15%">Category</th> +<th width="20%">Name</th> +<th width="100%">Description</th> +</tr> + +<tr> +<td rowspan="2">License check and result</td> +<td>LicenseChecker</td> +<td>Class that you instantiate (or subclass) to initiate a license check.</td> +</tr> +<tr> +<td><em>LicenseCheckerCallback</em></td> +<td>Interface that you implement to handle result of the license check.</td> +</tr> + +<tr> +<td rowspan="3" width="15%">Policy</td> +<td width="20%"><em>Policy</em></td> +<td width="100%">Interface that you implement to determine whether to allow +access to the application, based on the license response. </td> +</tr> +<tr> +<td>ServerManagedPolicy</td> +<td width="100%">Default {@code Policy} implementation. Uses settings provided by the +licensing server to manage local storage of license data, license validity, +retry.</td> +</tr> +<tr> +<td>StrictPolicy</td> +<td>Alternative {@code Policy} implementation. Enforces licensing based on a direct +license response from the server only. No caching or request retry.</td> +</tr> + +<tr> +<td rowspan="2" width="15%">Data obfuscation <br><em>(optional)</em></td> +<td width="20%"><em>Obfuscator</em></td> +<td width="100%">Interface that you implement if you are using a {@code Policy} (such as +ServerManagedPolicy) that caches license response data in a persistent store. +Applies an obfuscation algorithm to encode and decode data being written or +read.</td> +</tr> +<tr> +<td>AESObfuscator</td> +<td>Default Obfuscator implementation that uses AES encryption/decryption +algorithm to obfuscate/unobfuscate data.</td> +</tr> + +<tr> +<td rowspan="2" width="15%">Device limitation<br><em>(optional)</em></td> +<td width="20%"><em>DeviceLimiter</em></td> +<td width="100%">Interface that you implement if you want to restrict use of an +application to a specific device. Called from LicenseValidator. Implementing +DeviceLimiter is not recommended for most applications because it requires a +backend server and may cause the user to lose access to licensed applications, +unless designed with care.</td> +</tr> +<tr> +<td>NullDeviceLimiter</td> +<td>Default DeviceLimiter implementation that is a no-op (allows access to all +devices).</td> +</tr> + +<tr> +<td rowspan="6" width="15%">Library core, no integration needed</td> +<td width="20%">ResponseData</td> +<td width="100%">Class that holds the fields of a license response.</td> +</tr> +<tr> +<td>LicenseValidator</td> +<td>Class that decrypts and verifies a response received from the licensing +server.</td> +</tr> +<tr> +<td>ValidationException</td> +<td>Class that indicates errors that occur when validating the integrity of data +managed by an Obfuscator.</td> +</tr> +<tr> +<td>PreferenceObfuscator</td> +<td>Utility class that writes/reads obfuscated data to the system's +{@link android.content.SharedPreferences} store.</td> +</tr> +<tr> +<td><em>ILicensingService</em></td> +<td>One-way IPC interface over which a license check request is passed to the +Google Play client.</td> +</tr> +<tr> +<td><em>ILicenseResultListener</em></td> +<td>One-way IPC callback implementation over which the application receives an +asynchronous response from the licensing server.</td> +</tr> + +</table> +</div> + + +<h2 id="server-response-codes">Server Response Codes</h2> + +<p>Table 2 lists all of the license response codes supported by the +licensing server. In general, an application should handle all of these response +codes. By default, the LicenseValidator class in the LVL provides all of the +necessary handling of these response codes for you. </p> + +<p class="table-caption"><strong>Table 2.</strong> Summary of response codes +returned by the Google Play server in a license response.</p> + +<table> + +<tr> +<th>Response Code</th> +<th>Description</th> +<th>Signed?</th> +<th>Extras</th> +<th>Comments</th> +</tr> +<tr> +<td>{@code LICENSED}</td> +<td>The application is licensed to the user. The user has purchased the +application or the application only exists as a draft.</td> +<td>Yes</td> +<td><code>VT</code>, <code>GT</code>, <code>GR</code></td> +<td><em>Allow access according to {@code Policy} constraints.</em></td> +</tr> +<tr> +<td>{@code LICENSED_OLD_KEY}</td> +<td>The application is licensed to the user, but there is an updated application +version available that is signed with a different key. </td> +<td>Yes </td> +<td><code>VT</code>, <code>GT</code>, <code>GR</code>, <code>UT</code></td> +<td><em>Optionally allow access according to {@code Policy} constraints.</em> +<p style="margin-top:.5em;">Can indicate that the key pair used by the installed +application version is invalid or compromised. The application can allow access +if needed or inform the user that an upgrade is available and limit further use +until upgrade.</p> +</td> +</tr> +<tr> +<td>{@code NOT_LICENSED}</td> +<td>The application is not licensed to the user.</td> +<td>No</td> +<td></td> +<td><em>Do not allow access.</em></td> +</tr> +<tr> +<td>{@code ERROR_CONTACTING_SERVER}</td> +<td>Local error — the Google Play application was not able to reach the +licensing server, possibly because of network availability problems. </td> +<td>No</td> +<td></td> +<td><em>Retry the license check according to {@code Policy} retry limits.</em></td> +</tr> +<tr> +<td>{@code ERROR_SERVER_FAILURE}</td> +<td>Server error — the server could not load the publisher account's key +pair for licensing.</td> +<td>No</td> +<td></td> +<td><em>Retry the license check according to {@code Policy} retry limits.</em> +</td> +</tr> +<tr> +<td>{@code ERROR_INVALID_PACKAGE_NAME}</td> +<td>Local error — the application requested a license check for a package +that is not installed on the device. </td> +<td>No </td> +<td></td> +<td><em>Do not retry the license check.</em> +<p style="margin-top:.5em;">Typically caused by a development error.</p> +</td> +</tr> +<tr> +<td>{@code ERROR_NON_MATCHING_UID}</td> +<td>Local error — the application requested a license check for a package +whose UID (package, user ID pair) does not match that of the requesting +application. </td> +<td>No </td> +<td></td> +<td><em>Do not retry the license check.</em> +<p style="margin-top:.5em;">Typically caused by a development error.</p> +</td> +</tr> +<tr> +<td>{@code ERROR_NOT_MARKET_MANAGED}</td> +<td>Server error — the application (package name) was not recognized by +Google Play. </td> +<td>No</td> +<td></td> +<td><em>Do not retry the license check.</em> +<p style="margin-top:.5em;">Can indicate that the application was not published +through Google Play or that there is an development error in the licensing +implementation.</p> +</td> +</tr> + +</table> + +<p class="note"><strong>Note:</strong> As documented in <a +href="{@docRoot}guide/market/licensing/setting-up.html#test-env"> +Setting Up The Testing Environment</a>, the response code can be manually +overridden for the application developer and any registered test users via the +Google Play publisher site. +<br/><br/> +Additionally, as noted above, applications that are in draft mode (in other +words, applications that have been uploaded but have <em>never</em> been +published) will return {@code LICENSED} for all users, even if not listed as a test +user. Since the application has never been offered for download, it is assumed +that any users running it must have obtained it from an authorized channel for +testing purposes.</p> + + + + +<h2 id="extras">Server Response Extras</h2> + +<p>To assist your application in managing access to the application across the application refund +period and provide other information, The licensing server includes several pieces of +information in the license responses. Specifically, the service provides recommended values for the +application's license validity period, retry grace period, maximum allowable retry count, and other +settings. If your application uses <a href="{@docRoot}guide/market/expansion-files.html">APK +expansion files</a>, the response also includes the file names, sizes, and URLs. The server appends +the settings as key-value pairs in the license response "extras" field. </p> + +<p>Any {@code Policy} implementation can extract the extras settings from the license +response and use them as needed. The LVL default {@code Policy} implementation, <a +href="{@docRoot}guide/market/licensing/adding-licensing.html#ServerManagedPolicy">{@code +ServerManagedPolicy}</a>, serves as a working +implementation and an illustration of how to obtain, store, and use the +settings. </p> + +<p class="table-caption"><strong>Table 3.</strong> Summary of +license-management settings supplied by the Google Play server in a license +response.</p> + +<table> +<tr> +<th>Extra</th><th>Description</th> +</tr> + +<tr> + <td>{@code VT}</td> + <td>License validity timestamp. Specifies the date/time at which the current +(cached) license response expires and must be rechecked on the licensing server. See the section +below about <a href="#VT">License validity period</a>. + </td> +</tr> +<tr> + <td>{@code GT}</td> + <td>Grace period timestamp. Specifies the end of the period during which a +Policy may allow access to the application, even though the response status is +{@code RETRY}. <p>The value is managed by the server, however a typical value would be 5 +or more days. See the section +below about <a href="#GTGR">Retry period and maximum retry count</a>.</p></td> +</tr> +<tr> + <td>{@code GR}</td> + <td>Maximum retries count. Specifies how many consecutive {@code RETRY} license checks +the {@code Policy} should allow, before denying the user access to the application. +<p>The value is managed by the server, however a typical value would be "10" or +higher. See the section +below about <a href="#GTGR">Retry period and maximum retry count</a>.</p></td> +</tr> +<tr> + <td>{@code UT}</td> + <td>Update timestamp. Specifies the day/time when the most recent update to +this application was uploaded and published. <p>The server returns this extra +only for {@code LICENSED_OLD_KEYS} responses, to allow the {@code Policy} to determine how much +time has elapsed since an update was published with new licensing keys before +denying the user access to the application. </p></td> +</tr> + + +<!-- APK EXPANSION FILE RESPONSES --> + +<tr> + <td>{@code FILE_URL1} or {@code FILE_URL2}</td> + <td>The URL for an expansion file (1 is for the main file, 2 is the patch file). Use this to +download the file over HTTP.</td> +</tr> +<tr> + <td>{@code FILE_NAME1} or {@code FILE_NAME2}</td> + <td>The expansion file's name (1 is for the main file, 2 is the patch file). You must use this +name when saving the file on the device.</td> +</tr> +<tr> + <td>{@code FILE_SIZE1} or {@code FILE_SIZE2}</td> + <td>The size of the file in bytes (1 is for the main file, 2 is the patch file). Use this to +assist with downloading and to ensure that enough space is available on the device's shared +storage location before downloading.</td> +</tr> + +</table> + + + +<h4 id="VT">License validity period</h4> + +<p>The Google Play licensing server sets a license validity period for all +downloaded applications. The period expresses the interval of time over which an +application's license status should be considered as unchanging and cacheable by +a licensing {@code Policy} in the application. The licensing server includes the +validity period in its response to all license checks, appending an +end-of-validity timestamp to the response as an extra under the key {@code VT}. A +{@code Policy} can extract the VT key value and use it to conditionally allow access to +the application without rechecking the license, until the validity period +expires. </p> + +<p>The license validity signals to a licensing {@code Policy} when it must recheck the +licensing status with the licensing server. It is <em>not</em> intended to imply +whether an application is actually licensed for use. That is, when an +application's license validity period expires, this does not mean that the +application is no longer licensed for use — rather, it indicates only that +the {@code Policy} must recheck the licensing status with the server. It follows that, +as long as the license validity period has not expired, it is acceptable for the +{@code Policy} to cache the initial license status locally and return the cached license +status instead of sending a new license check to the server.</p> + +<p>The licensing server manages the validity period as a means of helping the +application properly enforce licensing across the refund period offered by +Google Play for paid applications. It sets the validity period based on +whether the application was purchased and, if so, how long ago. Specifically, +the server sets a validity period as follows:</p> + +<ul> +<li>For a paid application, the server sets the initial license validity period +so that the license response remains valid for as long as the application is +refundable. A licensing {@code Policy} in the application may cache the +result of the initial license check and does not need to recheck the license +until the validity period has expired.</li> +<li>When an application is no longer refundable, the server +sets a longer validity period — typically a number of days. </li> + +<!-- TODO: Verify the following behavior is still true w/ OBB: --> +<li>For a free application, the server sets the validity period to a very high +value (<code>long.MAX_VALUE</code>). This ensures that, provided the {@code Policy} has +cached the validity timestamp locally, it will not need to recheck the +license status of the application in the future.</li> +</ul> + +<p>The {@code ServerManagedPolicy} implementation uses the extracted timestamp +(<code>mValidityTimestamp</code>) as a primary condition for determining whether +to recheck the license status with the server before allowing the user access to +the application. </p> + + +<h4 id="GTGR">Retry period and maximum retry count</h4> + +<p>In some cases, system or network conditions can prevent an application's +license check from reaching the licensing server, or prevent the server's +response from reaching the Google Play client application. For example, the +user might launch an application when there is no cell network or data +connection available—such as when on an airplane—or when the +network connection is unstable or the cell signal is weak. </p> + +<p>When network problems prevent or interrupt a license check, the Google +Play client notifies the application by returning a {@code RETRY} response code to +the {@code Policy}'s <code>processServerResponse()</code> method. In the case of system +problems, such as when the application is unable to bind with Google Play's +{@code ILicensingService} implementation, the {@code LicenseChecker} library itself calls the +Policy <code>processServerResonse()</code> method with a {@code RETRY} response code. +</p> + +<p>In general, the {@code RETRY} response code is a signal to the application that an +error has occurred that has prevented a license check from completing. + +<p>The Google Play server helps an application to manage licensing under +error conditions by setting a retry "grace period" and a recommended maximum +retries count. The server includes these values in all license check responses, +appending them as extras under the keys {@code GT} and {@code GR}. </p> + +<p>The application {@code Policy} can extract the {@code GT} and {@code GR} extras and use them to +conditionally allow access to the application, as follows:</p> + +<ul> +<li>For a license check that results in a {@code RETRY} response, the {@code Policy} should +cache the {@code RETRY} response code and increment a count of {@code RETRY} responses.</li> +<li>The {@code Policy} should allow the user to access the application, provided that +either the retry grace period is still active or the maximum retries count has +not been reached.</li> +</ul> + +<p>The {@code ServerManagedPolicy} uses the server-supplied {@code GT} and {@code GR} values as +described above. The example below shows the conditional handling of the retry +responses in the <code>allow()</code> method. The count of {@code RETRY} responses is +maintained in the <code>processServerResponse()</code> method, not shown. </p> + + +<pre> +public boolean allowAccess() { + long ts = System.currentTimeMillis(); + if (mLastResponse == LicenseResponse.LICENSED) { + // Check if the LICENSED response occurred within the validity timeout. + if (ts <= mValidityTimestamp) { + // Cached LICENSED response is still valid. + return true; + } + } else if (mLastResponse == LicenseResponse.RETRY && + ts < mLastResponseTime + MILLIS_PER_MINUTE) { + // Only allow access if we are within the retry period or we haven't used up our + // max retries. + return (ts <= mRetryUntil || mRetryCount <= mMaxRetries); + } + return false; +}</pre> + diff --git a/docs/html/guide/market/licensing/overview.jd b/docs/html/guide/market/licensing/overview.jd new file mode 100644 index 0000000..e7e23f8 --- /dev/null +++ b/docs/html/guide/market/licensing/overview.jd @@ -0,0 +1,246 @@ +page.title=Licensing Overview +parent.title=Application Licensing +parent.link=index.html +@jd:body + + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>Quickview</h2> + <ul> + <li>Licensing allows you to verify your app was purchased from Google Play</li> + <li>Your app maintains control of how it enforces its licensing status</li> + <li>The service is free for all developers who publish on Google Play</li> + </ul> + + <h2>In this document</h2> + <ol> + <li><a href="#Secure">License Responses are Secure</a></li> + <li><a href="#LVL">Licensing Verification Library</a></li> + <li><a href="#Reqs">Requirements and Limitations</a></li> + <li><a href="#CopyProtection">Replacement for Copy Protection</a></li> +</ol> + +</div> +</div> + + +<p>Google Play Licensing is a network-based service that lets an application query a trusted +Google Play licensing server to determine whether the application is licensed to the current +device user. The licensing service is based on the capability of the Google Play licensing server +to determine whether a given user is licensed to use a given application. Google Play considers a +user to be licensed if the user is a recorded purchaser of the application.</p> + +<p>The request starts when your application makes a request to a service hosted by +the Google Play client application. The Google Play application then sends a request to +the licensing server and receives the result. The Google Play application sends +the result to your application, which can allow or disallow further use of the +application as needed.</p> + +<p class="note"><strong>Note:</strong> If a paid application has been uploaded to Google Play but +saved only as a draft application (the app is unpublished), the licensing server considers all users +to be licensed users of the application (because it's not even possible to purchase the app). +This exception is necessary in order for you to perform testing of your licensing +implementation.</p> + + +<div class="figure" style="width:469px"> +<img src="{@docRoot}images/licensing_arch.png" alt=""/> +<p class="img-caption"><strong>Figure 1.</strong> Your application initiates a +license check through the License Verification Library and the Google Play +client, which handles communication with the Google Play server.</p> +</div> + + +<p>To properly identify the user and determine the license status, the licensing server requires +information about the application and user—your application and the Google Play client work +together to assemble the information and the Google Play client passes it to the server. </p> + +<p>To help you add licensing to your application, the Android SDK provides a downloadable set of +library sources that you can include in your application project: the Google Market +Licensing package. The License Verification Library (LVL) is a library you can add to your +application that +handles all of the licensing-related communication with the Google Play licensing service. With +the LVL added to your application, your application can determine its licensing status for the +current user by simply calling a method and implementing a callback that receives the status +response.</p> + +<p>Your application does not query the licensing server +directly, but instead calls the Google Play client over remote IPC to +initiate a license request. In the license request:</p> + +<ul> +<li>Your application provides: its package name, a nonce that is later used to +validate any response from the server, and a callback over which the +response can be returned asynchronously.</li> +<li>The Google Play client collects the necessary information about the user and the device, +such as the device's primary Google account username, IMSI, and other +information. It then sends the license check request to the server on behalf of +your application.</li> +<li>The Google Play server evaluates the request using all available information, attempting +to establish the user's identity to a sufficient level of confidence. The server +then checks the user identity against purchase records for your application and +returns a license response, which the Google Play client returns to your +application over the IPC callback.</li> +</ul> + +<p>You can choose when, and how often, you want your application to check its +license and you have full control over how it handles the response, verifies the +signed response data, and enforces access controls.</p> + +<p>Notice that during a license check, your application does not manage any +network connections or use any licensing related APIs in the Android platform.</p> + + + + +<h2 id="Secure">License Responses are Secure</h2> + +<p>To ensure the integrity of each license query, the server signs the license +response data using an RSA key pair that is shared exclusively between the Google Play +server and you.</p> + +<p>The licensing service generates a single licensing key pair for each +publisher account and exposes the public key in your account's profile page. You must copy the +public key from the web site and embed it in your application source code. The server retains the +private key internally and uses it to sign license responses for the applications you +publish with that account.</p> + +<p>When your application receives a signed response, it uses the embedded public +key to verify the data. The use of public key cryptography in the licensing +service makes it possible for the application to detect responses that have been +tampered with or that are spoofed.</p> + + + + +<h2 id="LVL">Licensing Verification Library</h2> + +<p>The Android SDK provides a downloadable package called the Google Market Licensing package, +which includes the License Verification Library (LVL). The LVL greatly simplifies the process of +adding licensing to your application and helps ensure a more secure, robust implementation for your +application. The LVL provides internal classes that handle most of the standard operations of a +license query, such as contacting the Google Play client to initiate a license request and +verifying and validating the responses. It also exposes interfaces that let you easily plug in your +custom code for defining licensing policy and managing access as needed by your application. The key +LVL interfaces are: </p> + +<dl> +<dt>{@code Policy}</dt> + <dd>Your implementation determines whether to allow access to the +application, based on the license response received from the server and any +other data available (such as from a backend server associated with your +application). The implementation can evaluate the various fields of the license +response and apply other constraints, if needed. The implementation also lets +you manage the handling of license checks that result in errors, such as network +errors.</dd> + +<dt>{@code LicenseCheckerCallback}</dt> + <dd>Your implementation manages access to the +application, based on the result of the {@code Policy} object's handling of the license +response. Your implementation can manage access in any way needed, including +displaying the license result in the UI or directing the user to purchase the +application (if not currently licensed).</dd> +</dl> + + +<p>To help you get started with a {@code Policy}, the LVL provides two fully complete +{@code Policy} implementations that you can use without modification or adapt to your +needs:</p> + +<dl> +<dt><a href="adding-licensing.html#ServerManagedPolicy">{@code ServerManagedPolicy}</a></dt> + <dd>A flexible {@code Policy} +that uses settings provided by the licensing server to manage response caching +and access to the application while the device is offline (such as when the +user is on an airplane). For most applications, the use of +{@code ServerManagedPolicy} is highly recommended.</dd> + +<dt><a href="adding-licensing.html#StrictPolicy">{@code StrictPolicy}</a></dt> + <dd>A restrictive {@code Policy} that +does not cache any response data and allows the application access <em>only</em> +when the server returns a licensed response.</dd> +</dl> + +<p>The LVL is available as a downloadable package of the Android SDK. The +package includes both the LVL itself and an example application that shows how +the library should be integrated with your application and how your application +should manage response data, UI interaction, and error conditions. </p> + +<p>The LVL sources are provided as an Android <em>library project</em>, which +means that you can maintain a single set of library sources and share them +across multiple applications. A full test environment is also available through +the SDK, so you can develop and test the licensing implementation in your +applications before publishing them, even if you don't have access to a +physical device.</p> + + + + +<h2 id="Reqs">Requirements and Limitations</h2> + +<p>Google Play Licensing is designed to let you apply license controls to +applications that you publish through Google Play. The service is not +designed to let you control access to applications that are not published +through Google Play or that are run on devices that do not offer the Google +Play client. </p> + +<p>Here are some points to keep in mind as you implement licensing in your +application: </p> + +<ul> +<li>An application can use the service only if the Google Play client is +installed on its host device and the device is running Android 1.5 (API level 3) +or higher.</li> +<li>To complete a license check, the licensing server must be accessible over +the network. You can implement license caching behaviors to manage access to your application when +there is no network connectivity. </li> +<li>The security of your application's licensing controls ultimately relies on +the design of your implementation itself. The service provides the building +blocks that let you securely check licensing, but the actual enforcement and +handling of the license are factors are up to you. By following the best +practices in the following documents, you can help ensure that your implementation will be +secure.</li> +<li>Adding licensing to an application does not affect the way the application +functions when run on a device that does not offer Google Play.</li> +<li>You can implement licensing controls for a free app, but only if you're using the service to +provide <a +href="{@docRoot}guide/market/expansion-files.html">APK expansion files</a>.</li> +</ul> + + + +<h2 id="CopyProtection">Replacement for Copy Protection</h2> + +<p>Google Play Licensing is a flexible, secure mechanism for controlling +access to your applications. It effectively replaces the Copy Protection +mechanism offered on Google Play and gives you wider distribution +potential for your applications. </p> + +<ul> +<li>A limitation of the legacy Copy Protection mechanism on Google Play is +that applications using it can be installed only on compatible devices that +provide a secure internal storage environment. For example, a copy-protected +application cannot be downloaded from Google Play to a device that provides root +access, and the application cannot be installed to a device's SD card. </li> +<li>With Google Play licensing, you can move to a license-based model in +which access is not bound to the characteristics of the host device, but to your +publisher account on Google Play and the licensing policy that you define. +Your application can be installed and controlled on any compatible device on +any storage, including SD card.</li> +</ul> + +<p>Although no license mechanism can completely prevent all unauthorized use, +the licensing service lets you control access for most types of normal usage, +across all compatible devices, locked or unlocked, that run Android 1.5 or +higher version of the platform.</p> + +<p>To begin adding application licensing to your application, continue to <a +href="{@docRoot}guide/market/licensing/setting-up.html">Setting Up for Licensing</a>.</p> + + + + + + diff --git a/docs/html/guide/market/licensing/setting-up.jd b/docs/html/guide/market/licensing/setting-up.jd new file mode 100644 index 0000000..0de7819 --- /dev/null +++ b/docs/html/guide/market/licensing/setting-up.jd @@ -0,0 +1,701 @@ +page.title=Setting Up for Licensing +parent.title=Application Licensing +parent.link=index.html +@jd:body + + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>In this document</h2> + <ol> + <li><a href="#account">Setting Up a Publisher Account</a></li> + <li><a href="#dev-setup">Setting Up the Development Environment</a> + <ol> + <li><a href="#runtime-setup">Setting up the runtime environment</a></li> + <li><a href="#download-lvl">Downloading the LVL</a></li> + <li><a href="#lvl-setup">Setting Up the Licensing Verification Library</a></li> + <li><a href="#add-library">Including the LVL library project sources in your +application</a></li> + </ol> + </li> + <li><a href="#test-env">Setting Up the Testing Environment</a> + <ol> + <li><a href="#test-response">Setting test responses for license checks</a></li> + <li><a href="#test-acct-setup">Setting up test accounts</a></li> + <li><a href="#acct-signin">Signing in to an authorized account in the runtime +environment</a></li> + </ol> + </li> +</ol> +</div> +</div> + +<p>Before you start adding license verification to your application, you need to set up your Google +Play publishing account, your development environment, and test accounts required to verify +your implementation.</p> + + +<h2 id="account">Setting Up a Publisher Account</h2> + +<p>If you don't already have a publisher account for Google Play, you need to register for one +using your Google account and agree to the terms of service on the Google Play publisher site:</p> + +<p style="margin-left:2em;"><a +href="http://play.google.com/apps/publish">http://play.google.com/apps/publish</a> +</p> + +<p>For more information, see <a +href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play</a>.</p> + +<p>If you already have a publisher account on Google Play, use your existing +account to set up licensing.</p> + +<p>Using your publisher account on Google Play, you can:</p> + +<ul> +<li>Obtain a public key for licensing</li> +<li>Debug and test an application's licensing implementation, prior to +publishing the application</li> +<li>Publish the applications to which you have added licensing support</li> +</ul> + +<h4>Administrative settings for licensing</h4> + +<p>You can manage several +administrative controls for Google Play licensing on the publisher site. The controls are available +in the Edit Profile page, in the "Licensing" panel, shown in figure 1. The controls +let you: </p> + +<ul> +<li>Set up multiple "test accounts," identified by email address. The licensing +server allows users signed in to test accounts on a device or emulator to send +license checks and receive static test responses.</li> +<li>Obtain the account's public key for licensing. When you are implementing +licensing in an application, you must copy the public key string into the +application.</li> +<li>Configure static test responses that the server sends, when it receives a +license check for an application uploaded to the publisher account, from a user +signed in to the publisher account or a test account.</li> +</ul> + + +<img src="{@docRoot}images/licensing_public_key.png" alt=""/> +<p class="img-caption"><strong>Figure 1.</strong> The Licensing +panel of your account's Edit Profile page lets you manage administrative +settings for licensing.</p> + +<p>For more information about how to work with test accounts and static test +responses, see <a href="#test-env">Setting Up a Testing Environment</a>, below. + + + +<h2 id="dev-setup">Setting Up the Development Environment</h2> + +<p>Setting up your environment for licensing involves these tasks:</p> + +<ol> +<li><a href="#runtime-setup">Setting up the runtime environment</a> for development</li> +<li><a href="#download-lvl">Downloading the LVL</a> into your SDK </li> +<li><a href="#lvl-setup">Setting up the Licensing Verification Library</a></li> +<li><a href="#add-library">Including the LVL library project in your application</a></li> +</ol> + +<p>The sections below describe these tasks. When you are done with setup, +you can begin <a href="{@docRoot}guide/market/licensing/adding-licensing.html">Adding +Licensing to Your App</a>.</p> + +<p>To get started, you need to set up a proper runtime environment on which +you can run, debug, and test your application's implementation of license +checking and enforcement. </p> + + +<h3 id="runtime-setup">Setting up the runtime environment</h3> + +<p>As described earlier, applications check licensing status not by contacting +the licensing server directly, but by binding to a service provided by the +Google Play application and initiating a license check request. The Google +Play service then handles the direct communication with the licensing server +and finally routes the response back to your application. To debug and test +licensing in your application, you need to set up a runtime environment that +includes the necessary Google Play service, so that your application is able +to send license check requests to the licensing server. </p> + +<p>There are two types of runtime environment that you can use: </p> + +<ul> +<li>An Android-powered device that includes the Google Play application, or</li> +<li>An Android emulator running the Google APIs Add-on, API level 8 (release 2) +or higher</li> +</ul> + +<h4 id="runtime-device">Running on a device</h4> + +<p>To use an Android-powered device for +debugging and testing licensing, the device must:</p> + +<ul> +<li>Run a compatible version of Android 1.5 or later (API level +3 or higher) platform, <em>and</em> </li> +<li>Run a system image on which the Google Play client application +is preinstalled. </li> +</ul> + +<p>If Google Play is not preinstalled in the system image, your application won't +be able to communicate with the Google Play licensing server. </p> + +<p>For general information about how to set up a device for use in developing +Android applications, see <a +href="{@docRoot}guide/developing/device.html">Using Hardware Devices</a>.</p> + +<h4 id="runtime-emulator">Running on an Android emulator</h4> + +<p>If you don't have a device available, you can use an Android emulator for debugging and testing +licensing.</p> + +<p>Because the Android platforms provided in the Android SDK <em>do +not</em> include Google Play, you need to download the Google APIs Add-On +platform, API level 8 (or higher), from the SDK repository. After downloading +the add-on, you need to create an AVD configuration that uses that system image. +</p> + +<p>The Google APIs Add-On does not include the full Google Play client. +However, it does provide: </p> + +<ul> +<li>An Google Play background service that implements the +<code>ILicensingService</code> remote interface, so that your application can +send license checks over the network to the licensing server. </li> +<li>A set of underlying account services that let you add an a Google account on +the AVD and sign in using your publisher account or test account credentials. +<p>Signing in using your publisher or test account enables you to debug and test +your application without having publish it. For more information see <a +href="#acct-signin">Signing in to an authorized account</a>, below.</p></li> +</ul> + +<p>Several versions of the Google APIs add-on are available through the SDK Manager, but only +the version for Android 2.2 and higher includes the necessary Google +Play services.</p> + +<p>To set up an emulator for adding licensing to an application, follow +these steps: </p> + +<ol> + <li>Launch the Android SDK Manager (available under the Eclipse <strong>Window</strong> +menu or by executing {@code <sdk>/tools/android sdk}).</li> + <li>Select and download <strong>Google APIs</strong> for the Android version you'd like to target +(must be Android 2.2 or higher).</li> + <li>When the download is complete, open the AVD Manager (available under the Eclipse +<strong>Window</strong> +menu or by executing {@code <sdk>/tools/android avd}).</li> + <li>Click +<strong>New</strong> and set the configuration details for the new AVD. </li> + <li>In the dialog that appears, assign a descriptive name to the AVD and then +use the Target menu to choose the <strong>Google APIs</strong> as +the system image to run on the new AVD. Set the other configuration details as +needed and then click <strong>Create AVD</strong> to finish. The SDK tools +create the new AVD configuration, which then appears in the list of available +Android Virtual Devices.</li> +</ol> + +<p>If you are not familiar with AVDs or how to use them, see <a +href="{@docRoot}guide/developing/devices/index.html">Managing Virtual Devices</a>.</p> + +<h4 id="project-update">Updating your project configuration</h4> + +<p>After you set up a runtime environment that meets the requirements described +above — either on an actual device or on an emulator — make sure to +update your application project or build scripts as needed, so that your compiled +<code>.apk</code> files that use licensing are deployed into that environment. +In particular, if you are developing in Eclipse, make sure that you set up a +Run/Debug Configuration that targets the appropriate device or AVD. </p> + +<p>You do not need to make any changes to your application's +build configuration, provided that the project is already configured to compile +against a standard Android 1.5 (API level 3) or higher library. For example: + +<ul> +<li>If you have an existing application that is compiled against +the Android 1.5 library, you do not need to make any changes to your +build configuration to support licensing. The build target meets the minimum +requirements for licensing, so you would continue building +against the same version of the Android platform.</li> + +<li>Similarly, if you are building against Android 1.5 (API level 3) but +are using an emulator running the Google APIs Add-On API 8 as the application's +runtime environment, there is no need to change your application's build +configuration. </li> +</ul> + +<p>In general, adding licensing to an application should have no impact +whatsoever on the application's build configuration.</p> + + +<h3 id="download-lvl">Downloading the LVL</h3> + +<p>The License Verification Library (LVL) is a collection of helper classes that +greatly simplify the work that you need to do to add licensing to your +application. In all cases, we recommend that you download the LVL and use it as +the basis for the licensing implementation in your application.</p> + +<p>The LVL is available as a downloadable package of the Android SDK. The +package includes: </p> + +<ul> +<li>The LVL sources, stored inside an Android library project. </li> +<li>An example application called "sample" that depends on the LVL library +project. The example illustrates how an application uses the library helper +classes to check and enforce licensing.</li> +</ul> + +<p>To download the LVL package into your development environment, use the +Android SDK Manager. Launch the Android SDK Manager and then +select the <strong>Google Market Licensing</strong> package, as shown in figure 2. +Accept the terms and click <strong>Install Selected</strong> to begin the download. </p> + +<img src="{@docRoot}images/licensing_package.png" alt=""/> +<p class="img-caption"><strong>Figure 2.</strong> The Licensing package contains the LVL and +the LVL sample application.</p> + +<p>When the download is complete, the Android SDK Manager installs both +the LVL library project and the example application into these directories: </p> + +<p style="margin-left:2em"><code><<em>sdk</em>>/extras/google/market_licensing/library/</code> + (the LVL library project)<br /> +<code><<em>sdk</em>>/extras/google/market_licensing/sample/</code> (the example +application)</p> + +<p>If you aren't familiar with how to download packess into your SDK, see the +<a href="{@docRoot}sdk/adding-components.html">Adding SDK Packages</a> +document. </p> + + +<h3 id="lvl-setup">Setting Up the Licensing Verification Library</h3> + +<p>After downloading the LVL to your computer, you need to set it up in your +development environment, either as an Android library project or by +copying (or importing) the library sources directly into your existing +application package. In general, using the LVL as a library project is recommended, +since it lets you reuse your licensing code across multiple applications and +maintain it more easily over time. Note that the LVL is not designed to be +compiled separately and added to an application as a static .jar file. </p> + +<h4>Moving the library sources to a new location</h4> + +<p>Because you will be customizing the LVL sources to some extent, you should +make sure to <em>move or copy</em> the library sources (the entire +directory at <code><<em>sdk</em>>/market_licensing/library/</code>) +to a working directory outside of the SDK. You should then use the relocated +sources as your working set. If you are using a source-code management +system, add and track the sources that are in the working location rather +than those in default location in the SDK. </p> + +<p>Moving the library sources is important is because, when you later update the +Licensing package, the SDK installs the new files to the same location as +the older files. Moving your working library files to a safe location ensures +that your work won't be inadvertently overwritten should you download a new +version of the LVL.</p> + +<h4>Creating the LVL as a library project</h4> + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>Working with library projects</h2> + +<p>The LVL is provided as an Android library project, which means that you can +share its code and resources across multiple applications. </p> + +<p style="margin-top:.5em;">If you aren't familiar with library projects or how +to use them, see <a href="{@docRoot}guide/developing/projects/index.html#LibraryProjects"> +Managing Projects</a>. +</p> +</div> +</div> + +<p>The recommended way of using the LVL is setting it up as a new Android +<em>library project</em>. A library project is a type of development project +that holds shared Android source code and resources. Other Android application +projects can reference the library project and, at build time, include its +compiled sources in their <code>.apk</code> files. In the context of licensing, +this means that you can do most of your licensing development once, in a library +project, then include the library sources in your various application projects. +In this way, you can easily maintain a uniform implementation of licensing +across all of your projects and maintain it centrally. </p> + +<p>The LVL is provided as a configured library project — once you have +downloaded it, you can start using it right away. </p> + +<p>If you are working in Eclipse with ADT, you need to add the LVL to your +workspace as a new development project, in the same way as you would a new +application project. </p> + +<ol> +<li>Use the New Project Wizard to create a new +project from existing sources. Select the LVL's <code>library</code> directory +(the directory containing the library's AndroidManifest.xml file) as the project +root.</li> +<li>When you are creating the library project, you can select any application +name, package, and set other fields as needed. </li> +<li>For the library's build target, select Android 1.5 (API level 3) or higher.</li> +</ol> + +<p> When created, the project is +predefined as a library project in its <code>project.properties</code> file, so +no further configuration is needed. </p> + +<p>For more information about how to create an application project or work with +library projects in Eclipse, see <a +href="{@docRoot}guide/developing/projects/projects-eclipse.html">Managing Projects from +Eclipse with ADT</a>.</p> + + +<h4>Copying the LVL sources to your application</h4> + +<p>As an alternative to adding the LVL as a library project, you can copy the +library sources directly into your application. To do so, copy (or import) the +LVL's <code>library/src/com</code> directory into your application's +<code>src/</code> directory.</p> + +<p>If you add the LVL sources directly to your application, you can skip the +next section and start working with the library, as described in <a +href="{@docRoot}guide/market/licensing/adding-licensing.html">Adding +Licensing to Your App</a>.</p> + + +<h3 id="add-library">Including the LVL library project sources in your +application</h3> + +<p>If you want to use the LVL sources as a library project, you need to add a +reference to the LVL library project in your application project properties. This tells +build tools to include the LVL library project sources in your application at +compile time. The process for adding a reference to a library project depends +on your development environment, as described below.</p> + +<p> If you are developing in Eclipse with ADT, you should already have added the +library project to your workspace, as described in the previous section. If you +haven't done that already, do it now before continuing. </p> + +<p>Next, open the application's project properties window, as shown below. +Select the "Android" properties group and click <strong>Add</strong>, then +choose the LVL library project (com_android_vending_licensing) and click +<strong>OK</strong>. For more information, see +<a href="{@docRoot}guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject"> +Managing Projects from Eclipse with ADT</a></p>. + + +<img src="{@docRoot}images/licensing_add_library.png" alt=""/> +<p class="img-caption"><strong>Figure 3.</strong> If you are +working in Eclipse with ADT, you can add the LVL library project to your +application from the application's project properties.</p> + + +<p>If you are developing using the SDK command-line tools, navigate to the +directory containing your application project and open the +<code>project.properties</code> file. Add a line to the file that specifies the +<code>android.library.reference.<n></code> key and the path to the +library. For example: </p> + +<pre>android.library.reference.1=path/to/library_project</pre> + +<p>Alternatively, you can use this command to update the project +properties, including the reference to the library project:</p> + +<pre class="no-pretty-print" style="color:black">android update lib-project +--target <em><target_ID></em> \ +--path <em>path/to/my/app_project</em> \ +--library <em>path/to/my/library_project</em> +</pre> + +<p>For more information about working with library projects, +see <a href="{@docRoot}guide/developing/projects/projects-cmdline.html#SettingUpLibraryProject"> +Setting up a Library Project</a>.</p> + + + + + + + + + + + + + + + + + + + + + +<h2 id="test-env">Setting Up the Testing Environment</h2> + +<p>The Google Play publisher site provides configuration tools that let you +and others test licensing on your application before it is published. As you are +implementing licensing, you can make use of the publisher site tools to test +your application's Policy and handling of different licensing responses and +error conditions.</p> + +<p>The main components of the test environment for licensing include: </p> + +<ul> +<li>A "Test response" configuration in your publisher account that lets you +set the static licensing response returned, when the server processes a +license check for an application uploaded to the publisher account, from a user +signed in to the publisher account or a test account.</li> +<li>An optional set of test accounts that will receive the static test +response when they check the license of an application that you have uploaded +(regardless whether the application is published or not).</li> +<li>A runtime environment for the application that includes the Google Play +application or Google APIs Add-On, on which the user is signed in to the +publisher account or one of the test accounts.</li> +</ul> + +<p>Setting up the test environment properly involves:</p> + +<ol> +<li><a href="#test-response">Setting static test responses</a> that are returned by the licensing server.</li> +<li><a href="#test-acct-setup">Setting up test accounts</a> as needed.</li> +<li><a href="#acct-signin">Signing in</a> properly to an emulator or device, before initiating a license check test.</li> +</ol> + +<p>The sections below provide more information.</p> + + +<h3 id="test-response">Setting test responses for license checks</h3> + +<p>Google Play provides a configuration setting in your publisher account +that lets you override the normal processing of a license check and return a +specified static response code. The setting is for testing only and applies +<em>only</em> to license checks for applications that you have uploaded, made by +any user signed in to an emulator or device using the credentials of the +publisher account or a registered test account. For other users, the server +always processes license checks according to normal rules. </p> + +<p>To set a test response for your account, sign in to your publisher account +and click "Edit Profile". In the Edit Profile page, locate the Test Response +menu in the Licensing panel, shown below. You can select from the full set of +valid server response codes to control the response or condition you want to +test in your application.</p> + +<p>In general, you should make sure to test your application's licensing +implementation with every response code available in the Test Response menu. +For a description of the codes, see <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#server-response-codes">Server +Response Codes</a> in the <a +href="{@docRoot}guide/market/licensing/licensing-reference.html">Licensing Reference</a>.</p> + +<img src="{@docRoot}images/licensing_test_response.png" alt=""/> +<p class="img-caption"><strong>Figure 4.</strong> The Licensing +panel of your account's Edit Profile page, showing the Test Accounts field and the +Test Response menu.</p> + +<p>Note that the test response that you configure applies account-wide — +that is, it applies not to a single application, but to <em>all</em> +applications associated with the publisher account. If you are testing multiple +applications at once, changing the test response will affect all of those +applications on their next license check (if the user is signed in to +the emulator or device using the publisher account or a test account).</p> + +<p>Before you can successfully receive a test response for a license check, +you must sign in to the device or emulator on which the application +is installed, and from which it is querying the server. Specifically, you must +sign using either your publisher account or one of the test accounts that you +have set up. For more information about test accounts, see the next section.</p> + +<p>See <a +href="{@docRoot}guide/market/licensing/licensing-reference.html#server-response-codes">Server +Response Codes</a> for a list of +test responses available and their meanings. </p> + + +<h3 id="test-acct-setup">Setting up test accounts</h3> + +<p>In some cases, you might want to let multiple teams of developers test +licensing on applications that will ultimately be published through your +publisher account, but without giving them access to your publisher account's +sign-in credentials. To meet that need, the Google Play publisher site lets +you set up one or more optional <em>test accounts</em> — accounts that are +authorized to query the licensing server and receive static test responses from +your publisher account.</p> + +<p>Test accounts are standard Google accounts that you register on your +publisher account, such that they will receive the test response for +applications that you have uploaded. Developers can then sign in to their +devices or emulators using the test account credentials and initiate license +checks from installed applications. When the licensing server receives a license +check from a user of a test account, it returns the static test response +configured for the publisher account. </p> + +<p>Necessarily, there are limitations on the access and permissions given to +users signed in through test accounts, including:</p> + +<ul> +<li>Test account users can query the licensing server only for applications that +are already uploaded to the publisher account. </li> +<li>Test account users do not have permission to upload applications to your +publisher account.</li> +<li>Test account users do not have permission to set the publisher account's +static test response.</li> +</ul> + +<p>The table below summarizes the differences in capabilities, between the +publisher account, a test account, and any other account.</p> + +<p class="table-caption" id="acct-types-table"><strong>Table 1.</strong> +Differences in account types for testing licensing.</p> + +<table> +<tr> +<th>Account Type</th> +<th>Can check license before upload?</th> +<th>Can receive test response?</th> +<th>Can set test response?</th> +</tr> + +<tr> +<td>Publisher account</td> +<td>Yes</td> +<td>Yes</td> +<td>Yes</td> +</tr> + +<tr> +<td>Test account</td> +<td>No</td> +<td>Yes</td> +<td>No</td> +</tr> + +<tr> +<td>Other</td> +<td>No</td> +<td>No</td> +<td>No</td> +</tr> +</table> + +<h4 id="reg-test-acct">Registering test accounts on the publisher account</h4> + +<p>To get started, you need to register each test account in your publisher +account. As shown in Figure 4, you +register test accounts in the Licensing panel of your publisher account's Edit +Profile page. Simply enter the accounts as a comma-delimited list and click +<strong>Save</strong> to save your profile changes.</p> + +<p>You can use any Google account as a test account. If you want to own and +control the test accounts, you can create the accounts yourself and distribute +the credentials to your developers or testers.</p> + +<h4 id="test-app-upload">Handling application upload and distribution for test +account users</h4> + +<p>As mentioned above, users of test accounts can only receive static test +responses for applications that are uploaded to the publisher account. Since +those users do not have permission to upload applications, as the publisher you +will need to work with those users to collect apps for upload and distribute +uploaded apps for testing. You can handle collection and distribution in any way +that is convenient. </p> + +<p>Once an application is uploaded and becomes known to the licensing server, +developers and testers can continue modify the application in their local +development environment, without having to upload new versions. You only need to +upload a new version if the local application increments the +<code>versionCode</code> attribute in the manifest file. </p> + +<h4 id="test-key">Distributing your public key to test account users</h4> + +<p>The licensing server handles static test responses in the normal way, +including signing the license response data, adding extras parameters, and so +on. To support developers who are implementing licensing using test accounts, +rather than the publisher account, you will need to distribute +your public key to them. Developers without access to the publisher site do not +have access to your public key, and without the key they won't be able to +verify license responses. </p> + +<p>Note that if you decide to generate a new licensing key pair for your account +for some reason, you need to notify all users of test accounts. For +testers, you can embed the new key in the application package and distribute it +to users. For developers, you will need to distribute the new key to them +directly. </p> + + +<h3 id="acct-signin">Signing in to an authorized account in the runtime +environment</h3> + +<p>The licensing service is designed to determine whether a given user is +licensed to use a given application — during a license check, the Google +Play application gathers the user ID from the primary account on the system +and sends it to the server, together with the package name of the application +and other information. However, if there is no user information available, the +license check cannot succeed, so the Google Play application terminates the +request and returns an error to the application. </p> + +<p>During testing, to ensure that your application can successfully query the +licensing server, you must make sure that you sign in to an account <em>on the +device or emulator</em> using:</p> + +<ul> +<li>The credentials of a publisher account, or</li> +<li>The credentials of a test account that is registered with a publisher +account</li> +</ul> + + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>Signing in to a Google account on an emulator</h2> + +<p>If you are testing licensing on an emulator, you need to sign in to a Google +account on the emulator. If you do not see an option to create a new Google +account, the problem might be that your AVD is running a standard Android system +image, rather than the Google APIs Add-On, API 8 (release 2) or higher. </p> + +<p style="margin-top:.5em;">For more information, see <a +href="#runtime-setup">Setting up the runtime environment</a>, above.</p> + +</div> +</div> + +<p>Signing in using a publisher account offers the advantage of letting your +applications receive static test responses even before the applications are +uploaded to the publisher site.</p> + +<p>If you are part of a larger organization or are working with external groups +on applications that will be published through your site, you will more likely +want to distribute test accounts instead, then use those to sign in during +testing. </p> + +<p>To sign in on a device or emulator, follow the steps below. The preferred +approach is to sign in as the primary account — however, if there are +other accounts already in use on the device or emulator, you can create an +additional account and sign in to it using the publisher or test account +credentials. </p> + +<ol> +<li>Open Settings > Accounts & sync</li> +<li>Select <strong>Add Account</strong> and choose to add a Google account. +</li> +<li>Select <strong>Next</strong> and then <strong>Sign in</strong>.</li> +<li>Enter the username and password of either the publisher account or a test +account that is registered in the publisher account.</li> +<li>Select <strong>Sign in</strong>. The system signs you in to the new +account.</li> +</ol> + +<p>Once you are signed in, you can begin testing licensing in your application +(if you have completed the LVL integration steps above). When your application +initiates a license check, it will receive a response containing the static test +response configured on the publisher account. </p> + +<p>Note that, if you are using an emulator, you will need to sign in to the +publisher account or test account each time you wipe data when restarting the +emulator.</p> + +<p>Once you've completed the setup procedures, continue to <a +href="{@docRoot}guide/market/licensing/adding-licensing.html">Adding Licensing to Your App</a>.</p> + + + diff --git a/docs/html/guide/market/publishing/multiple-apks.jd b/docs/html/guide/market/publishing/multiple-apks.jd index ff70e85..e7cfa33 100644 --- a/docs/html/guide/market/publishing/multiple-apks.jd +++ b/docs/html/guide/market/publishing/multiple-apks.jd @@ -45,7 +45,7 @@ support all desired devices with a single APK</li> <h2>See also</h2> <ol> - <li><a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a></li> + <li><a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</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> @@ -55,10 +55,10 @@ Package</a></li> </div> </div> -<p>Multiple APK support is a feature in Android Market that allows you to publish different APKs +<p>Multiple APK support is a feature on Google Play 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 +Google Play 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> @@ -73,8 +73,8 @@ 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 +you publish your application for as many devices as possible, Google Play allows you to +publish multiple APKs under the same application listing. Google Play then supplies each APK to the appropriate devices based on configuration support you've declared in the manifest file of each APK.</p> @@ -86,7 +86,7 @@ APK.</p> <li>Support different platform versions with each APK.</li> </ul> -<p>Currently, these are the only device characteristics that Android Market supports for publishing +<p>Currently, these are the only device characteristics that Google Play supports for publishing multiple APKs as the same application.</p> <p class="note"><strong>Note:</strong> You should generally use multiple APKs to support @@ -100,8 +100,8 @@ 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> +<p>Before you start publishing multiple APKs on Google Play, you must understand a few +concepts regarding how the Google Play publisher site works.</p> <h3 id="Active">Active APKs</h3> @@ -111,20 +111,20 @@ concepts regarding how the Android Market publisher site works.</p> <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 + <p>When your application is new or you have unpublished it from Google Play, 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 +Active, making them available on Google Play. 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 +Google Play—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 +of the APKs are available on Google Play. 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 +only saves all your changes, but also publishes them to Google Play. 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> +APKs, clicking <strong>Save</strong> makes all those changes live on Google Play.</p> </div> </div> @@ -135,14 +135,14 @@ moves into the list of <em>Active</em> APKs. This list allows you to preview whi 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 +Google Play 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 +<p>The Google Play 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> @@ -164,21 +164,21 @@ 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 +<p>The concept for using multiple APKs on Google Play is that you have just one entry in +Google Play 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 + <li>All users see only one version of your application on Google Play, 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 +published, Google Play 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> @@ -192,8 +192,8 @@ 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 +href="{@docRoot}guide/appendix/market-filters.html">Google Play filters</a> that are specified by +elements in the manifest file of each APK. However, Google Play allows you to publish multiple APKs only when each APK uses filters to support a variation of the following device characteristics:</p> @@ -229,7 +229,7 @@ with a single APK.</p> 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 +9), Google Play 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 @@ -266,7 +266,7 @@ with a higher <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min 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 +filter. This ensures that when a device receives a system update, Google Play 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> @@ -286,8 +286,8 @@ higher, as per the previous note).</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 +href="{@docRoot}guide/appendix/market-filters.html">Google Play filters</a>—but are not +listed above—are still applied for each APK as usual. However, Google Play 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 @@ -312,7 +312,7 @@ 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> +the <a href="#SupportedFilters">supported Google Play 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 @@ -330,11 +330,11 @@ 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> +supported API levels (no other <a href="#SupportedFilters">supported 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 +Google Play only if the version code for the APK on Google Play 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> @@ -365,7 +365,7 @@ increase from the lower API level to the higher API level.</li> </ul> -<p>Failure to abide by the above rules results in an error on the Android Market publisher site +<p>Failure to abide by the above rules results in an error on the Google Play publisher site when you activate your APKs—you will be unable to publish your application until you resolve the error.</p> @@ -377,7 +377,7 @@ in warnings rather than errors. Warnings can be caused by the following:</p> 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 +application on Google Play. 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 @@ -467,8 +467,8 @@ 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 +<p class="note"><strong>Note:</strong> When you increase the version code for an APK, Google +Play 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> @@ -507,7 +507,7 @@ 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 +publishing an application on Google Play. 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> @@ -542,7 +542,7 @@ setup, the user receives your application and it runs using the resources optimi 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 +permissions that the user has not agreed to, so Google Play 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> @@ -586,7 +586,7 @@ public void onSurfaceChanged(GL10 gl, int w, int h) { <h3 id="ScreenOptions">Supporting multiple screens</h3> -<p>Unless your APK file exceeds the Android Market size limit of 50MB, supporting multiple screens +<p>Unless your APK file exceeds the Google Play 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> diff --git a/docs/html/guide/practices/compatibility.jd b/docs/html/guide/practices/compatibility.jd index bb7a72e..5e514c4 100644 --- a/docs/html/guide/practices/compatibility.jd +++ b/docs/html/guide/practices/compatibility.jd @@ -7,7 +7,7 @@ page.title=Android Compatibility <h2>See also</h2> <ol> <li><a -href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a></li> +href="{@docRoot}guide/appendix/market-filters.html">Filtering on Google Play</a></li> <li><a href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">Providing Alternative Resources</a></li> <li><a @@ -39,7 +39,7 @@ variety of hardware.</p> your apps to do that, while at the same time letting you maintain control of what types of devices your app is available to. With a bit of forethought and some minor changes in your app's manifest file, you can ensure that users -whose devices can’t run your app will never see it in the Android Market, and +whose devices can’t run your app will never see it on Google Play, and will not get in trouble by downloading it. This page explains how you can control which devices have access to your apps, and how to prepare your apps to make sure they reach the right audience.</p> @@ -64,7 +64,7 @@ every class and every API for that API level.</p> corresponding hardware or feature. But that’s not a problem: we also designed Android to prevent apps from being visible to devices which don’t have features the apps require. We’ve built support for this right into the SDK tools, and -it’s part of the Android platform itself, as well as Android Market.</p> +it’s part of the Android platform itself, as well as part of Google Play.</p> <p>As a developer, you have complete control of how and where your apps are available. Android provides tools as a first-class part of the platform that let @@ -79,9 +79,9 @@ only the devices capable of running them.</p> <li>You state the features your app requires by declaring <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a> elements its manifest file.</li> -<li>Devices are required to declare the features they include to Android -Market.</li> -<li>Android Market uses your app’s stated requirements to filter it from devices +<li>Devices are required to declare the features they include to Google +Play.</li> +<li>Google Play uses your app’s stated requirements to filter it from devices that don’t meet those requirements.</li> </ol> @@ -103,24 +103,24 @@ instead use the fine-grained controls Android provides.</p> <div class="sidebox-wrapper"> <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;">Filtering on Android Market</p> + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> + <p style="color:#669999;">Filtering on Google Play</p> - <p>Android Market filters the applications that are visible to users, so + <p>Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with their devices.</p> - <p style="margin-top:1em;">One of the ways Market filters applications is by -feature compatibility. To do this, Market checks the + <p style="margin-top:1em;">One of the ways Google Play filters applications is by +feature compatibility. To do this, Google Play checks the <code><uses-feature></code> elements in each application's manifest, to -establish the app's feature needs. Market then shows or hides the application to +establish the app's feature needs. Google Play then shows or hides the application to each user, based on a comparison with the features available on the user's device. <p style="margin-top:1em;">For information about other filters that you can use to control the availability of your apps, see the -<a href="{@docRoot}guide/appendix/market-filters.html">Market -Filters</a> document.</p> +<a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> +document.</p> </div> </div> @@ -142,8 +142,8 @@ future versions, new feature IDs will be added as well.</p> <p>When you write your application, you specify which features your app requires by listing their feature IDs in <code><uses-feature></code> elements in -the <code>AndroidManifest.xml</code> file. This is the information that Android -Market uses to match your app to devices that can run it. For instance, if you +the <code>AndroidManifest.xml</code> file. This is the information that Google +Play uses to match your app to devices that can run it. For instance, if you state that your app requires android.software.live_wallpapers, it won’t be shown to devices that don’t support Live Wallpapers.</p> @@ -170,12 +170,12 @@ audience size and minimizing development costs.</p> business or legal reasons. For instance, an app that displays train schedules for the London Underground is unlikely to be useful to users outside the United Kingdom. Other apps might not be permitted in certain countries for business or -legal reasons. For cases such as these, Android Market itself provides +legal reasons. For cases such as these, Google Play itself provides developers with filtering options that allow them control their app’s availability for non-technical reasons.</p> -<p>The help information for Android Market provides full details, but in a -nutshell, developers can use the Market publisher UI to:</p> +<p>The help information for Google Play provides full details, but in a +nutshell, developers can use the Google Play publisher UI to:</p> <ul> <li>List the countries an app is available in.</li> @@ -185,7 +185,7 @@ nutshell, developers can use the Market publisher UI to:</p> <p>Filtering for technical compatibility (such as required hardware components) is always based on information contained within your <code>.apk</code> file. But filtering for non-technical reasons (such as geographic restrictions) is always -handled in the Market user interface.</p> +handled in the Google Play user interface.</p> <h3 id="futureproofing">Future-proofing</h3> @@ -206,7 +206,7 @@ capability, though a (fixed-focus) camera was still required. Some apps such as barcode scanners do not function as well with cameras that do not auto-focus. To prevent users from having a bad experience with those apps, existing apps that obtain permission to use the Camera were assumed by default to require -auto-focus. This allowed Android Market to filter those apps from devices that +auto-focus. This allowed Google Play to filter those apps from devices that lack auto-focus.</li> <li>Android 2.2, meanwhile, allowed the microphone to be optional on some diff --git a/docs/html/guide/practices/design/accessibility.html b/docs/html/guide/practices/design/accessibility.html new file mode 100644 index 0000000..0fa7b32 --- /dev/null +++ b/docs/html/guide/practices/design/accessibility.html @@ -0,0 +1,11 @@ +<html> +<head> +<meta http-equiv="refresh" +content="0;url=http://developer.android.com/guide/topics/ui/accessibility/index.html"> +<title>Redirecting...</title> +</head> +<body> +<p>You should be redirected. Please <a +href="http://developer.android.com/guide/topics/ui/accessibility/index.html">click here</a>.</p> +</body> +</html>
\ No newline at end of file diff --git a/docs/html/guide/practices/design/accessibility.jd b/docs/html/guide/practices/design/accessibility.jd deleted file mode 100644 index a66a974..0000000 --- a/docs/html/guide/practices/design/accessibility.jd +++ /dev/null @@ -1,353 +0,0 @@ -page.title=Designing for Accessibility -@jd:body - - -<div id="qv-wrapper"> -<div id="qv"> - - <h2>Quickview</h2> - <ul> - <li>To make your application more accessible, you should make sure your UI is navigable -using a directional controller and your widgets provide content descriptions</li> - <li>If you implement a custom view, you should ensure that it delivers the appropriate -accessibility events during user interaction</li> - </ul> - - <h2>In this document</h2> - <ol> - <li><a href="#Navigation">Allow Navigation with a Directional Controller</a> - <ol> - <li><a href="#FocusOrder">Controlling focus order</a></li> - <li><a href="#ClickingDpad">Clicking with a directional controller</a></li> - </ol> - </li> - <li><a href="#LabelInputs">Label Your Input Widgets</a></li> - <li><a href="#UiBestPractices">Follow Android UI Best Practices</a></li> - <li><a href="#CustomViews">Send Accessibility Events from Custom View Components</a></li> - <li><a href="#Test">Test Your Application’s Accessibility</a></li> - </ol> - - <h2>Key classes</h2> - <ol> - <li>{@link android.view.accessibility.AccessibilityEvent}</li> - <li>{@link android.view.accessibility.AccessibilityEventSource}</li> - </ol> - - <h2>Related samples</h2> - <ol> - <li><a -href="{@docRoot}resources/samples/AccessibilityService/index.html">Accessibility Service</a></li> - </ol> - -</div> -</div> - - - -<p>Many Android users have disabilities that require them to interact with their Android devices in -different ways. These include users who have visual, physical or age-related disabilities that -prevent them from fully using or seeing a touchscreen.</p> - -<p>Android provides an accessibility layer that helps these users navigate their Android-powered -devices more easily. Android's accessibility services provide things like text-to-speech, haptic -feedback, and trackball/d-pad navigation that augment the user experience.</p> - -<p>Your application should follow the guidelines in this document to ensure that it provides a -good experience for users with disabilities. Following these two basic rules will solve most -access-related problems:</p> - -<ul> -<li>Make all of your user interface controls accessible with a trackball or directional -controller (d-pad).</li> -<li>Label your {@link android.widget.ImageButton}, {@link android.widget.EditText}, and other input -widgets using the <a -href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">{@code -android:contentDescription}</a> attribute.</li> -</ul> - - - -<h2 id="Navigation">Allow Navigation with a Directional Controller</h2> - -<p>Many Android devices come with some sort of directional controller, such as:</p> -<ul> -<li>A clickable trackball that users can move in any direction</li> -<li>A clickable d-pad that allows users to navigate in four directions.</li> -<li>Arrow keys and an OK button that’s equivalent to clicking a trackball or d-pad.</li> -</ul> - -<p>All of these directional controllers allow users to navigate the screen without using the -touchscreen. On some devices, a user can also navigate to the top or bottom of a list by holding -down the <em>alt</em> key while pressing a discrete key for up or down.</p> - -<p>A directional controller is the primary means of navigation for users with visual or some -physical impairments (and also for users without impairments when using devices that don't -have a touchscreen). You should verify that all UI controls in your application are -accessible without using the touchscreen and that clicking with the center button (or OK button) has -the same effect as touching the controls on the touchscreen.</p> - -<p>A UI control (also called a "widget") is accessible using directional controls when it's -"focusable" property is "true." This means that users can focus on the widget using the directional -controls and then interact with it. Widgets provided by the Android APIs are focusable by default -and visually indicate focus by changing the widget visual appearance in some way.</p> - -<p>Android provides several APIs that let you control whether a widget is focusable and even -request that a widget be given focus. Such methods include:</p> - -<ul> - <li>{@link android.view.View#setFocusable setFocusable()}</li> - <li>{@link android.view.View#isFocusable isFocusable()}</li> - <li>{@link android.view.View#requestFocus requestFocus()}</li> -</ul> - -<p>When working with a view that is not focusable by default, you can make it focusable from the XML -layout file by setting the <a -href="{@docRoot}reference/android/view/View.html#attr_android:focusable">{@code -android:focusable}</a> attribute to {@code "true"}.</p> - - - -<h3 id="FocusOrder">Controlling focus order</h3> - -<p>When the user navigates in any direction using the directional controls, focus is passed from one -view to another, as determined by the focus ordering. The ordering of the focus movement is based on -an algorithm that finds the nearest neighbor in a given direction. In rare cases, the default -algorithm may not match the order that you intended for your UI. In these situations, you can -provide explicit overrides to the ordering using the following XML attributes in the layout -file:</p> - -<dl> - <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown" ->{@code android:nextFocusDown}</a></dt> - <dd>Defines the next view to receive focus when the user navigates down.</dd> - <a><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusLeft" ->{@code android:nextFocusLeft}</a></dt> - <dd>Defines the next view to receive focus when the user navigates left.</dd> - <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusRight" ->{@code android:nextFocusRight}</a></dt> - <dd>Defines the next view to receive focus when the user navigates right.</dd> - <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp" ->{@code android:nextFocusUp}</a></dt> - <dd>Defines the next view to receive focus when the user navigates up.</dd> -</dl> - -<p>For example, here is an XML layout that contains a focusable {@link android.widget.TextView}. -While the {@link android.widget.TextView} is located to the right of the {@link -android.widget.EditText}, it can now be reached by pressing the down arrow when focus is on the -{@link android.widget.EditText}: </p> - -<pre> -<LinearLayout android:orientation="horizontal" - ... > - <EditText android:id="@+id/edit" - android:nextFocusDown=”@+id/text” - ... /> - <TextView android:id="@+id/text" - android:focusable=”true” - android:text="Hello, I am a focusable TextView" - android:nextFocusUp=”@id/edit” - ... /> -</LinearLayout> -</pre> - -<p>When modifying this ordering, be sure that the navigation works as expected in all directions -from each widget and when navigating in reverse (to get back to where you came from).</p> - -<p>You can also modify the focus ordering at runtime, using methods in the {@link -android.view.View} class, such as {@link android.view.View#setNextFocusDownId -setNextFocusDownId()} and {@link android.view.View#setNextFocusRightId -setNextFocusRightId()}.</p> - - -<h3 id="ClickingDpad">Clicking with a directional controller</h3> - -<p>On most devices, clicking a view using a directional controller sends a {@link -android.view.KeyEvent} with {@link android.view.KeyEvent#KEYCODE_DPAD_CENTER} to the view currently -in focus. Make sure this event has the same effect as touching the view on the touchscreen. All -standard Android views already handle {@link android.view.KeyEvent#KEYCODE_DPAD_CENTER} -appropriately.</p> - -<p>If possible, also treat the {@link android.view.KeyEvent#KEYCODE_ENTER} event the same as -{@link android.view.KeyEvent#KEYCODE_DPAD_CENTER}. That makes interaction much easier from a full -keyboard.</p> - - - - -<h2 id="LabelInputs">Label Your Input Widgets</h2> - -<p>Many input widgets rely on visual cues to inform the user of their meaning. For example, a -notepad application might use an {@link android.widget.ImageButton} with a picture of a plus sign to -indicate that the user can add a new note. Or, an {@link android.widget.EditText} may have -a label near it that indicates its purpose. When a visually impaired user accesses your -application, these visual cues are often useless.</p> - -<p>To provide textual information about these widgets (as an alternative to the visual cues), you -should use the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription" ->{@code android:contentDescription}</a> attribute. The text you provide in this attribute -is not visible on the screen, but if a user has enabled accessibility speech tools then the -description in this attribute is read aloud to the user.</p> - -<p>You should set the <a -href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription" >{@code -android:contentDescription}</a> attribute on every {@link android.widget.ImageButton}, {@link -android.widget.EditText}, {@link android.widget.CheckBox}, and on any other input widgets that might -benefit users with extra information.</p> - -<p>For example, the following {@link android.widget.ImageButton} sets the content description for -the plus button to the {@code add_note} string resource, which might be defined in English as -“Add note":</p> - -<pre> -<ImageButton - android:id=”@+id/add_entry_button” - android:src=”@drawable/plus” - android:contentDescription=”@string/add_note”/> -</pre> - -<p>This way, when using speech accessibility tools, the user hears "Add note" when focused on -this widget.</p> - - - -<h2 id="UiBestPractices">Follow Android UI Best Practices</h2> - -<p>You can make it easier for users to learn how to use your application by developing a user -interface that complies with Android's standard interaction patterns, instead of creating your own -or using interaction patterns from another platform. This consistency is especially important for -many disabled users, as they may have less contextual information available to try to understand -your application’s interface.</p> - -<p>Specifically, you should:</p> - -<ul> -<li>Use the platform's built-in widgets and layouts whenever possible, as these views provide -accessibility support by default.</li> -<li>Use the <a href="{@docRoot}guide/topics/ui/menus.html#options-menu">Options Menu</a> as an -alternative to complex touchscreen tasks.</li> -<li>Make sure the BACK button correctly moves the user back one logical step in the <a -href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">task's back stack</a> or the -activity's back stack of fragments (when <a -href="{@docRoot}guide/topics/fundamentals/fragments.html#Transactions">performing fragment -transactions</a>), as appropriate.</li> -</ul> - - - -<h2 id="CustomViews">Send Accessibility Events from Custom View Components</h2> - -<p>If your application requires that you create a <a -href="{@docRoot}guide/topics/ui/custom-components.html">custom view component</a>, you may need to -do some additional work to ensure that your view is accessible. Specifically, you should make sure -that your view implements the {@link android.view.accessibility.AccessibilityEventSource} -interface and emits {@link android.view.accessibility.AccessibilityEvent}s at the proper times, -and that each {@link android.view.accessibility.AccessibilityEvent} contains relevant information -about the state of the view.</p> - -<p>Events are emitted whenever something notable happens in the user interface. Currently, there -are five types of accessibility events that a view should send to the system as the user interacts -with it:</p> - -<dl> -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_CLICKED}</dt> -<dd>Indicates that the user clicked on the view (for example, the user selects a button).</dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_LONG_CLICKED}</dt> -<dd>Indicates that the user performed a long press on the view. </dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_SELECTED}</dt> -<dd>Indicates that the user selected an item from within the view. This is usually used in the -context of an {@link android.widget.AdapterView}.</dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_FOCUSED}</dt> -<dd>Indicates that the user moved the focus to the view.</dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED}</dt> -<dd>Indicates that the text or contents of the view changed.</dd> -</dl> - - -<p>The basic {@link android.view.View} class implements {@link -android.view.accessibility.AccessibilityEventSource} and emits these events at the proper time in -the standard cases. Your custom view should extend from {@link android.view.View} (or one of its -subclasses) to take advantage of these default implementations.</p> - -<p>Depending on the specifics of your custom view, your view may need to emit one of these events at -a different time than the default {@link android.view.View} implementation. To do so, simply call -{@link android.view.accessibility.AccessibilityEventSource#sendAccessibilityEvent -sendAccessibilityEvent()} with the specific event type at the correct time.</p> - -<p>For example, say you are implementing a custom slider bar that allows the user to select a -numeric value by pressing the left or right arrows. This view should emit an event of type {@link -android.view.accessibility.AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED} whenever the slider value -changes:</p> - -<pre> -@Override -public boolean onKeyUp (int keyCode, KeyEvent event) { - if (keyCode == KeyEvent.KEYCODE_DPAD_LEFT) { - mCurrentValue--; - sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED); - return true; - } - ... -} -</pre> - -<p>Each {@link android.view.accessibility.AccessibilityEvent} has a set of required properties that -describe the current state of the view. These properties include things like the view’s class name, -text and checked state. The specific properties required for each event type are described in the -{@link android.view.accessibility.AccessibilityEvent} documentation. The {@link android.view.View} -implementation will fill in default values for these properties. Most of these values, like the -class name and event timestamp, will not need to be changed. However, depending on the specifics of -your custom view, you may want to provide a different value for one or more of the properties. For -example, your view may have additional state information that you want to add to the event text.</p> - -<p>The {@link android.view.View#dispatchPopulateAccessibilityEvent -dispatchPopulateAccessibilityEvent()} method in {@link android.view.View} provides a hook for making -changes to the {@link android.view.accessibility.AccessibilityEvent} object before it is -emitted.</p> - -<p>In the above slider bar example, the view should add the current value of the slider bar to the -text of the event:</p> - -<pre> -@Override -public boolean dispatchPopulateAccessibilityEvent(final AccessibilityEvent event) { - super.dispatchPopulateAccessibilityEvent(event); - if (!isShown()) { - return false; - } - CharSequence text = String.valueOf(mCurrentValue); - if (text.length() > AccessibilityEvent.MAX_TEXT_LENGTH) { - text = text.subSequence(0, AccessiblityEvent.MAX_TEXT_LENGTH); - } - event.getText().add(text); - return true; -} -</pre> - - -<h2 id="Test">Test Your Application’s Accessibility</h2> - -<p>You can simulate the experience for many users by enabling an accessibility service that speaks -as you move around the screen. One such service is <a -href="https://market.android.com/details?id=com.google.android.marvin.talkback">TalkBack</a>, by the -<a href="http://code.google.com/p/eyes-free/">Eyes-Free Project</a>. It comes preinstalled on many -Android-powered devices, but is also available for free from <a -href="https://market.android.com/details?id=com.google.android.marvin.talkback">Android -Market</a>.</p> - -<p>This service requires that you have a text-to-speech engine installed on your phone. You can -verify if you have one installed in the <strong>Text-to-speech</strong> settings menu by selecting -<strong>Listen to an example</strong>. If you do not hear anything spoken, install the required -voice data by selecting <strong>Install voice data</strong>.</p> - -<p>Once text-to-speech is functioning correctly, you can enable TalkBack (or another accessibility -service) in the <strong>Accessibility</strong> settings menu. Enable both -<strong>Accessibility</strong> and <strong>TalkBack</strong>. As you navigate about the device, you -should now hear spoken feedback.</p> - -<p>You can now attempt to use your application as a blind user would. As you move around using only -the directional controller, make sure that the spoken feedback you hear makes sense and is -sufficient to navigate the application without any visual cues.</p> diff --git a/docs/html/guide/practices/optimizing-for-3.0.jd b/docs/html/guide/practices/optimizing-for-3.0.jd index 39662f1..d6c621e 100644 --- a/docs/html/guide/practices/optimizing-for-3.0.jd +++ b/docs/html/guide/practices/optimizing-for-3.0.jd @@ -108,7 +108,7 @@ SDK with the new platform:</p> SDK starter package now</a>.)</p> <ol> - <li><a href="{@docRoot}sdk/adding-components.html#launching">Launch the Android SDK and AVD + <li><a href="{@docRoot}sdk/adding-components.html#launching">Launch the Android SDK Manager</a> and install the following: <ul> <li>SDK Platform Android 3.0</li> @@ -147,7 +147,7 @@ Android 3.0, the emulator is still best way to evaluate your application's appea functionality on Android 3.0.</p> <p class="note"><strong>Tip:</strong> To improve the startup time for the emulator, enable snapshots -for the AVD when you create it with the SDK and AVD Manager (there's a checkbox in the AVD creator +for the AVD when you create it with the AVD Manager (there's a checkbox in the AVD creator to <strong>Enable</strong> snapshots). Then, start the AVD from the AVD manager and check <b>Launch from snapshot</b> and <b>Save to snapshot</b>. This way, when you close the emulator, a snapshot of the AVD state is saved and used to quickly relaunch the AVD next time. However, when you choose to @@ -281,7 +281,7 @@ to help you add features from Android 3.0 without requiring you to change your < href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code android:minSdkVersion}</a> or build target, we're providing a static library called the <a href="{@docRoot}sdk/compatibility-library.html">Compatibility Library</a> -(downloadable from the AVD and SDK Manager).</p> +(downloadable from the Android SDK Manager).</p> <p>This 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 some updated classes. By @@ -421,7 +421,7 @@ href="{@docRoot}sdk/android-3.0.html">Android 3.0 Platform</a> document.</p> href="{@docRoot}sdk/android-3.0.html#api">Android 3.0 Platform</a> document also have accompanying samples that allow you to preview the effects and can help you understand how to use them. To get the samples, download them from the SDK repository <a href="{@docRoot}sdk/adding-components.html" ->using the Android SDK and AVD Manager</a>. After downloading the samples ("Samples for SDK API +>using the Android SDK Manager</a>. After downloading the samples ("Samples for SDK API 11"), you can find them in <code><sdk_root>/samples/android-11/</code>. The following list provides links to the browsable source code for some of the samples:</p> @@ -481,7 +481,7 @@ and densities.</p> configurations of screen size and density, you can instead choose to limit the distribution of your application to certain types of screens, such as only tablets or only mobile devices. To do so, you can add elements to your Android manifest file that enable filtering based on screen configuration -by external services such as Android Market.</p> +by external services such as Google Play.</p> <p>However, before you decide to restrict your application to certain screen configurations, you should understand the techniques for <a @@ -517,14 +517,14 @@ screens, you can declare the element in your manifest like this:</p> </manifest> </pre> -<p>External services such as Android Market read this manifest element and use it to ensure that +<p>External services such as Google Play read this manifest element and use it to ensure that your application is available only to devices with an extra large screen.</p> <p class="note"><strong>Note:</strong> If you use the <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>}</a> element for the reverse scenario (when your application is not compatible 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 +external services such as Google Play <strong>do not</strong> apply filtering. Your application will still be available to larger screens, but when it runs, it will not fill the screen—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. If you want to prevent your application from being downloaded on @@ -541,7 +541,7 @@ larger devices to download the version designed for smaller screens. In such a c use the <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code <compatible-screens>}</a> element to manage the distribution of your application based on the combination of screen size and density. External services such as -Android Market uses this information to apply filtering to your application, so that only devices +Google Play uses this information to apply filtering to your application, so that only devices that have a screen configuration with which you declare compatibility can download your application.</p> @@ -551,7 +551,7 @@ which each specify a screen configuration with which your application is compati the {@code android:screenSize} and {@code android:screenDensity} attributes. Each {@code <screen>} element <strong>must include both attributes</strong> to specify an individual screen configuration—if either attribute is missing, then the element is invalid -(external services such as Android Market will ignore it).</p> +(external services such as Google Play will ignore it).</p> <p>For example, if your application is compatible with only small and normal screens, regardless of screen density, then you must specify eight different {@code <screen>} elements, @@ -613,7 +613,7 @@ orientation, you should update your application to support landscape.</p></li> <li><a href="#Telephony">Not all devices have telephony or other features</a> <p>If your application declares the {@code "android.hardware.telephony"} feature in the manifest, then it will not be available to devices that do not offer telephony (such as tablets), based on -Android Market filtering. If your application can function properly without telephony, you should +Google Play filtering. If your application can function properly without telephony, you should update your application to gracefully disable the telephony features when not available on a device.</p></li> </ul> @@ -682,7 +682,7 @@ your applications. For example:</p> <pre><uses-feature android:name="android.hardware.telephony" /></pre> <p>By default, this declares that your application <em>requires</em> telephony features. So, -external services such as Android Market use this information to filter your application from +external services such as Google Play use this information to filter your application from devices that do not offer telephony.</p> <p>If, however, your application uses, but does not require the feature, you should diff --git a/docs/html/guide/practices/screens-distribution.jd b/docs/html/guide/practices/screens-distribution.jd index 60c9c95..a7c4a8e 100644 --- a/docs/html/guide/practices/screens-distribution.jd +++ b/docs/html/guide/practices/screens-distribution.jd @@ -37,7 +37,7 @@ href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for And configurations of screen size and density, you can instead choose to limit the distribution of your application to certain types of screens, such as only tablets and other large devices or only handsets and similar-sized devices. To do so, you can enable filtering by external services such as -Android Market by adding elements to your manifest file that specify the screen configurations your +Google Play by adding elements to your manifest file that specify the screen configurations your application supports.</p> <p>However, before you decide to restrict your application to certain screen configurations, you @@ -58,7 +58,7 @@ might discover that your application can't scale up well or perhaps you've decid versions of your application for different screen configurations. In such a case, you can use the <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code <compatible-screens>}</a> element to manage the distribution of your application based on -combinations of screen size and density. External services such as Android Market use this +combinations of screen size and density. External services such as Google Play use this information to apply filtering to your application, so that only devices that have a screen configuration with which you declare compatibility can download your application.</p> @@ -68,7 +68,7 @@ configuration with which you declare compatibility can download your application compatible, using both the {@code android:screenSize} and {@code android:screenDensity} attributes. Each {@code <screen>} element <strong>must include both attributes</strong> to specify an individual screen configuration—if either attribute is missing, then the element is invalid -(external services such as Android Market will ignore it).</p> +(external services such as Google Play will ignore it).</p> <p>For example, if your application is compatible with only small and normal size screens, regardless of screen density, you must specify eight different {@code <screen>} elements, @@ -173,7 +173,7 @@ Tools for Managing Screen Sizes</a>.</p> href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>}</a> element for the reverse scenario (when your application is not compatible 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 +external services such as Google Play <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 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 @@ -197,13 +197,13 @@ 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 +<p>Although we recommend that you publish one APK for your application, Google Play 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 +screen configuration, Google Play 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 @@ -212,5 +212,5 @@ APK that can support a wide range of device configurations</strong>. Supporting 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 +<p>If you need more information about how to publish multiple APKs on Google Play, read <a href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> diff --git a/docs/html/guide/practices/screens_support.jd b/docs/html/guide/practices/screens_support.jd index fb121bd..a870b22 100644 --- a/docs/html/guide/practices/screens_support.jd +++ b/docs/html/guide/practices/screens_support.jd @@ -882,8 +882,8 @@ 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 +to enable filtering for your application on services such as Google Play. However, +<strong>Google Play 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> @@ -1242,12 +1242,12 @@ have to buy various devices just to test your application's screen support.</p> <p>To set up an environment for testing your application's screen support, you should create a series of AVDs (Android Virtual Devices), using emulator skins and screen configurations that emulate the screen sizes and densities you want your application to support. To do so, you can use -the Android SDK and AVD Manager to create the AVDs and launch them with a graphical interface.</p> +the AVD Manager to create the AVDs and launch them with a graphical interface.</p> -<p>To launch the Android SDK and AVD Manager, execute the {@code +<p>To launch the Android SDK Manager, execute the {@code SDK Manager.exe} from your Android SDK directory (on Windows only) or execute {@code android} from -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> +the {@code <sdk>/tools/} directory (on all platforms). Figure 6 shows the AVD +Manager with a selection of AVDs, for testing various screen configurations.</p> <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> @@ -1340,7 +1340,7 @@ dashboard.</p> <div class="figure" style="width:204px"> <img src="{@docRoot}images/screens_support/avd-start.png" alt="" /> <p class="img-caption"><strong>Figure 7.</strong> - Size and density options you can set, when starting an AVD from the Android SDK and AVD + Size and density options you can set, when starting an AVD from the AVD Manager.</p> </div> @@ -1349,12 +1349,12 @@ up to run at a physical size that closely matches an actual device. This makes it a lot easier to compare the results at various sizes and densities. To do so you need to know the approximate density, in dpi, of your computer monitor (for instance, a 30" Dell monitor has a density of about 96 dpi). When you launch an AVD -from the Android SDK and AVD Manager, you can specify the screen size for the emulator and your +from the AVD Manager, you can specify the screen size for the emulator and your monitor dpi in the Launch Options, as shown in figure 7.</p> <p>If you would like to test your application on a screen that uses a resolution or density not supported by the built-in skins, you can create an AVD that uses a custom resolution -or density. When creating the AVD from the Android SDK and AVD Manager, specify the Resolution, +or density. When creating the AVD from the AVD Manager, specify the Resolution, instead of selecting a Built-in Skin.</p> <p>If you are launching your AVD from the command line, you can specify the scale for diff --git a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd index 9be72ee..8e4528e 100644 --- a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd +++ b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd @@ -3,6 +3,43 @@ parent.title=UI Guidelines parent.link=index.html @jd:body + + + +<div id="deprecatedSticker"> + <a href="#" + onclick="$('#naMessage').show();$('#deprecatedSticker').hide();return false"> + <strong>This doc is deprecated</strong></a> +</div> + + +<div id="naMessage" style="display:block"> +<div><p><strong>This document has been deprecated.</strong></p> + <p>For information about designing an activity structure and navigation, read the design guidelines +for <a href="{@docRoot}design/patterns/app-structure.html">App Structure</a> and +<a href="{@docRoot}design/patterns/navigation.html">Navigation</a>, or the developer guide +about <a +href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a>.</p> + + <input style="margin-top:1em;padding:5px" type="button" + value="That's nice, but I still want to read this document" +onclick="$('#naMessage').hide();$('#deprecatedSticker').show()" /> +</div> +</div> + + + + + + + + + + + + + + <div id="qv-wrapper"> <div id="qv"> @@ -886,7 +923,7 @@ href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent Fi You can perform this test when initializing the user interface. For instance, you could disable the user control that initiates the Intent object, or display a message to the user that lets them go - to a location, such as the Market, to download its application. + to a location, such as Google Play, to download its application. In this way, your code can start the activity (using either startActivity() or startActivityForResult()) only if the intent has tested to resolve to an activity that is actually present. diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd index 6b686b1..4b6768f 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd @@ -49,9 +49,9 @@ across the range of devices on which your application can be installed. See <a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html#design-tips">Tips for Designers</a> for suggestions on how to work with multiple sets of icons.</p> -<p>A high-resolution version of your application launcher icon is also required by Android Market +<p>A high-resolution version of your application launcher icon is also required by Google Play for use in application listings. For more details on this, see <a -href="#icons_in_market">Application Icons in Android Market</a> below.</p> +href="#icons_in_market">Application Icons on Google Play</a> below.</p> <p class="note"><strong>Note:</strong> @@ -81,7 +81,7 @@ need to review the old guidelines, see the <ol> <li>Promote the brand and tell the story of the app.</li> - <li>Help users discover the app in Android Market.</li> + <li>Help users discover the app on Google Play.</li> <li>Function well in the Launcher.</li> </ol> @@ -100,19 +100,19 @@ app is about. Thus, you should:</p> </ul> -<h3 id="help_users_discover">Help users discover the app in Android Market</h3> +<h3 id="help_users_discover">Help users discover the app on Google Play</h3> -<p>App launcher icons are the first look that prospective users will get of your app in Android -Market. A high quality app icon can influence users to find out more as they scroll through lists of +<p>App launcher icons are the first look that prospective users will get of your app on Google Play. +A high quality app icon can influence users to find out more as they scroll through lists of applications.</p> <p>Quality matters here. A well-designed icon can be a strong signal that your app is of similarly high quality. Consider working with an icon designer to develop the app’s launcher icon.</p> -<p class="note"><strong>Note:</strong> Android Market requires a high-resolution version of your -icon; for more details on this, see <a href="#icons_in_market">Application Icons in Android -Market</a> below.</p> +<p class="note"><strong>Note:</strong> Google Play requires a high-resolution version of your +icon; for more details on this, see <a href="#icons_in_market">Application Icons in Google +Play</a> below.</p> <h3 id="function_well_in_launcher">Function well in the Launcher</h3> @@ -239,21 +239,21 @@ This padding can also be used to make room for a subtle drop shadow, which can h that launcher icons are legible across on any background color.</p> -<h3 id="icons_in_market">Application Icons in Android Market</h3> +<h3 id="icons_in_market">Application Icons on Google Play</h3> <p>If you are <a href="{@docRoot}guide/publishing/publishing.html">publishing your application on -Android Market</a>, you will also need to provide a 512 x 512 pixel, high-resolution application icon -in the <a href="http://market.android.com/publish">developer console</a> at upload time. This icon -will be used in various locations in Android Market and does not replace your launcher icon.</p> +Google Play</a>, you will also need to provide a 512 x 512 pixel, high-resolution application icon +in the <a href="http://play.google.com/apps/publish">developer console</a> at upload time. This icon +will be used in various locations on Google Play and does not replace your launcher icon.</p> <p>For tips and recommendations on creating high-resolution launcher icons that can easily be scaled up to 512x512, see <a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html#design-tips"> Tips for Designers</a>.</p> -<p>For information and specifications about high-resolution application icons in Android Market, see +<p>For information and specifications about high-resolution application icons on Google Play, see the following article:</p> <p style="margin-left:2em"><a href="http://market.android.com/support/bin/answer.py?answer=1078870"> -Graphic Assets for your Application (Android Market Help) »</a> +Graphic Assets for your Application (Google Play Help) »</a> <br><br> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd index ea036cd..85a3cc8 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd @@ -56,13 +56,13 @@ suggestions on how to work with multiple sets of icons.</p> -<h2 id="market">Application Icons in Android Market</h2> +<h2 id="market">Application Icons on Google Play</h2> <p>If you are <a href="{@docRoot}guide/publishing/publishing.html">publishing -your application on Android Market</a>, you will also need to provide a 512x512 +your application on Google Play</a>, you will also need to provide a 512x512 pixel, high-resolution application icon in the <a -href="http://market.android.com/publish">developer console</a> at upload-time. -This icon will be used in various locations in Android Market and does +href="http://play.google.com/apps/publish">developer console</a> at upload-time. +This icon will be used in various locations on Google Play and does not replace your launcher icon.</p> <p>For tips and recommendations on creating high-resolution launcher icons that @@ -71,11 +71,11 @@ can easily be scaled up to 512x512, see Tips for Designers</a>.</p> <p>For information and specifications about high-resolution application -icons in Android Market, see the following article:</p> +icons on Google Play, see the following article:</p> <p style="margin-left:2em"><a href="http://market.android.com/support/bin/answer.py?answer=1078870"> - Graphic Assets for your Application (Android Market Help) »</a> + Graphic Assets for your Application (Google Play Help) »</a> diff --git a/docs/html/guide/practices/ui_guidelines/index.jd b/docs/html/guide/practices/ui_guidelines/index.jd index 3255275..24fb855 100644 --- a/docs/html/guide/practices/ui_guidelines/index.jd +++ b/docs/html/guide/practices/ui_guidelines/index.jd @@ -39,26 +39,6 @@ at a glance, on a user's Home screen. These design guidelines describe how to design widgets that fit with others on the Home screen. They include links to graphics files and templates that will make your designer's life easier.</dd> </dl> - <dl> - <dt><a href="{@docRoot}guide/practices/ui_guidelines/activity_task_design.html">Activity and Task Design Guidelines</a> </dt> - <dd>Activities are the basic, independent building blocks of applications. - As you design your application's UI and feature set, you are free to - re-use activities from other applications as if they were yours, - to enrich and extend your application. These guidelines - describe how activities work, illustrates them with examples, and - describes important underlying principles and mechanisms, such as - multitasking, activity reuse, intents, the activity stack, and - tasks. It covers this all from a high-level design perspective. -</dd> - <dt><a href="{@docRoot}guide/practices/ui_guidelines/menu_design.html">Menu Design Guidelines</a> </dt> - <dd>Android applications make use of Option menus and Context menus - that enable users to perform operations and navigate to other parts - of your application or to other applications. These guidelines describe - the difference between Options anontext menus, how to arrange - menu items, when to put commands on-screen, and other details about - menu design. -</dd> -</dl> diff --git a/docs/html/guide/practices/ui_guidelines/menu_design.jd b/docs/html/guide/practices/ui_guidelines/menu_design.jd index 7576b6c..b4e2ea7 100644 --- a/docs/html/guide/practices/ui_guidelines/menu_design.jd +++ b/docs/html/guide/practices/ui_guidelines/menu_design.jd @@ -2,7 +2,38 @@ page.title=Menu Design Guidelines parent.title=UI Guidelines parent.link=index.html @jd:body + + + + +<div id="deprecatedSticker"> + <a href="#" + onclick="$('#naMessage').show();$('#deprecatedSticker').hide();return false"> + <strong>This doc is deprecated</strong></a> +</div> + + +<div id="naMessage" style="display:block"> +<div><p><strong>This document has been deprecated.</strong></p> + <p>For design guidelines about adding user actions and other options, read the design guidelines +for <a href="{@docRoot}design/patterns/actionbar.html">Action Bar</a> or the developer guide about +<a href="{@docRoot}guide/topics/ui/menus.html">Menus</a>.</p> + + <input style="margin-top:1em;padding:5px" type="button" + value="That's nice, but I still want to read this document" +onclick="$('#naMessage').hide();$('#deprecatedSticker').show()" /> +</div> +</div> + + + + + + + + + <div id="qv-wrapper"> <div id="qv"> diff --git a/docs/html/guide/publishing/app-signing.jd b/docs/html/guide/publishing/app-signing.jd index 9abcdf7..5bd9be55 100644 --- a/docs/html/guide/publishing/app-signing.jd +++ b/docs/html/guide/publishing/app-signing.jd @@ -66,7 +66,7 @@ on an emulator or a device if it is not signed.</li> application's signer certificate expires after the application is installed, the application will continue to function normally.</li> <li>You can use standard tools — Keytool and Jarsigner — to generate keys and -sign your application .apk files.</li> +sign your application {@code .apk} files.</li> <li>After you sign your application for release, we recommend that you use the <code>zipalign</code> tool to optimize the final APK package.</li> </ul> @@ -82,7 +82,7 @@ run it or debug it on an emulator or device.</p> use to build your application. There are two build modes: <em>debug mode</em> and <em>release mode</em>. You use debug mode when you are developing and testing your application. You use release mode when you want to build a release version of your application that you can -distribute directly to users or publish on an application marketplace such as Android Market.</p> +distribute directly to users or publish on an application marketplace such as Google Play.</p> <p>When you build in <em>debug mode</em> the Android SDK build tools use the Keytool utility (included in the JDK) to create a debug key. Because the SDK build tools created the debug key, @@ -158,10 +158,10 @@ you should ensure that your key's validity period exceeds the expected lifespan of <em>all versions of all of the applications</em>, including dependent applications that may be added to the suite in the future. </li> -<li>If you plan to publish your application(s) on Android Market, the +<li>If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period -ending after 22 October 2033. The Market server enforces this requirement -to ensure that users can seamlessly upgrade Market applications when +ending after 22 October 2033. Google Play enforces this requirement +to ensure that users can seamlessly upgrade applications when new versions are available. </li> </ul> @@ -186,9 +186,9 @@ to the Keytool in the JDK.</p> <p>The Android build tools provide a debug signing mode that makes it easier for you to develop and debug your application, while still meeting the Android system -requirement for signing your .apk. +requirement for signing your APK. When using debug mode to build your app, the SDK tools invoke Keytool to automatically create -a debug keystore and key. This debug key is then used to automatically sign the .apk, so +a debug keystore and key. This debug key is then used to automatically sign the APK, so you do not need to sign the package with your own key.</p> <p>The SDK tools create the debug keystore/key with predetermined names/passwords:</p> @@ -215,19 +215,19 @@ to the public when signed with the debug certificate.</p> <p>If you are developing in Eclipse/ADT (and have set up Keytool and Jarsigner as described above in <a href="#setup">Basic Setup for Signing</a>), signing in debug mode is enabled by default. When you run or debug your -application, ADT signs the .apk with the debug certificate, runs {@code zipalign} on the -package, then installs it on +application, ADT signs the {@code .apk} file with the debug certificate, runs {@code zipalign} on +the package, then installs it on the selected emulator or connected device. No specific action on your part is needed, provided ADT has access to Keytool.</p> <h3>Ant Users</h3> -<p>If you are using Ant to build your .apk files, debug signing mode +<p>If you are using Ant to build your {@code .apk} file, debug signing mode is enabled by using the <code>debug</code> option with the <code>ant</code> command (assuming that you are using a <code>build.xml</code> file generated by the <code>android</code> tool). When you run <code>ant debug</code> to -compile your app, the build script generates a keystore/key and signs the .apk for you. -The script then also aligns the .apk with the <code>zipalign</code> tool. +compile your app, the build script generates a keystore/key and signs the APK for you. +The script then also aligns the APK with the <code>zipalign</code> tool. No other action on your part is needed. Read <a href="{@docRoot}guide/developing/building/building-cmdline.html#DebugMode">Building and Running Apps on the Command Line</a> for more information.</p> @@ -292,7 +292,7 @@ key is one that:</p> with the application</li> <li>Has a validity period that exceeds the expected lifespan of the application or application suite. A validity period of more than 25 years is recommended. -<p>If you plan to publish your application(s) on Android Market, note that a +<p>If you plan to publish your application(s) on Google Play, note that a validity period ending after 22 October 2033 is a requirement. You can not upload an application if it is signed with a key whose validity expires before that date. </p></li> @@ -383,8 +383,8 @@ will use later, to refer to this keystore when signing your application. </p> <p>For more information about Keytool, see the documentation at <a -href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security"> -http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security</a></p> +href="http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html"> +http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html</a></p> @@ -399,11 +399,11 @@ You can not release your application unsigned, or signed with the debug key.</p> <h4>With Eclipse</h4> -<p>To export an <em>unsigned</em> .apk from Eclipse, right-click the project in the Package +<p>To export an <em>unsigned</em> APK from Eclipse, right-click the project in the Package Explorer and select <strong>Android Tools</strong> > <strong>Export Unsigned Application -Package</strong>. Then specify the file location for the unsigned .apk. -(Alternatively, open your <code>AndroidManifest.xml</code> file in Eclipse, open -the <em>Overview</em> tab, and click <strong>Export an unsigned .apk</strong>.)</p> +Package</strong>. Then specify the file location for the unsigned APK. +(Alternatively, open your <code>AndroidManifest.xml</code> file in Eclipse, select +the <strong>Manifest</strong> tab, and click <strong>Export an unsigned APK</strong>.)</p> <p>Note that you can combine the compiling and signing steps with the Export Wizard. See <a href="#ExportWizard">Compiling and signing with Eclipse ADT</a>.</p> @@ -414,11 +414,11 @@ the <em>Overview</em> tab, and click <strong>Export an unsigned .apk</strong>.)< with the <code>ant</code> command. For example, if you are running Ant from the directory containing your {@code build.xml} file, the command would look like this:</p> -<pre>ant release</pre> +<pre>$ ant release</pre> -<p>By default, the build script compiles the application .apk without signing it. The output file +<p>By default, the build script compiles the application APK without signing it. The output file in your project {@code bin/} will be <code><em><your_project_name></em>-unsigned.apk</code>. -Because the application .apk is still unsigned, you must manually sign it with your private +Because the application APK is still unsigned, you must manually sign it with your private key and then align it using {@code zipalign}.</p> <p>However, the Ant build script can also perform the signing @@ -443,8 +443,8 @@ machine, as described in <a href="#setup">Basic Setup</a>. Also, make sure that the keystore containing your private key is available.</p> <p>To sign your application, you run Jarsigner, referencing both the -application's .apk and the keystore containing the private key with which to -sign the .apk. The table below shows the options you could use. </p> +application's APK and the keystore containing the private key with which to +sign the APK. The table below shows the options you could use. </p> <table> <tr> @@ -459,6 +459,14 @@ the keystore containing your private key.</td> <td><code>-verbose</code></td><td>Enable verbose output.</td> </tr> <tr> +<td><code>-sigalg</code></td><td>The name of the signature algorithim to use in signing the APK. +Use the value {@code MD5withRSA}.</td> +</tr> +<tr> +<td><code>-digestalg</code></td><td>The message digest algorithim to use in processing the entries +of an APK. Use the value {@code SHA1}.</td> +</tr> +<tr> <td><code>-storepass <password></code></td><td><p>The password for the keystore. </p><p>As a security precaution, do not include this option in your command line unless you are working at a secure computer. @@ -478,19 +486,23 @@ way, your password is not stored in your shell history.</p></td> <code>my_application.apk</code>, using the example keystore created above. </p> -<pre>$ jarsigner -verbose -keystore my-release-key.keystore +<pre>$ jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name</pre> <p>Running the example command above, Jarsigner prompts you to provide -passwords for the keystore and key. It then modifies the .apk -in-place, meaning the .apk is now signed. Note that you can sign an -.apk multiple times with different keys.</p> +passwords for the keystore and key. It then modifies the APK +in-place, meaning the APK is now signed. Note that you can sign an +APK multiple times with different keys.</p> + +<p class="caution"><strong>Caution:</strong> As of JDK 7, the default signing algorithim has +changed, requiring you to specify the signature and digest algorithims ({@code -sigalg} and {@code +-digestalg}) when you sign an APK.</p> -<p>To verify that your .apk is signed, you can use a command like this:</p> +<p>To verify that your APK is signed, you can use a command like this:</p> <pre>$ jarsigner -verify my_signed.apk</pre> -<p>If the .apk is signed properly, Jarsigner prints "jar verified". +<p>If the APK is signed properly, Jarsigner prints "jar verified". If you want more details, you can try one of these commands:</p> <pre>$ jarsigner -verify -verbose my_application.apk</pre> @@ -502,19 +514,19 @@ If you want more details, you can try one of these commands:</p> <p>The command above, with the <code>-certs</code> option added, will show you the "CN=" line that describes who created the key.</p> -<p class="note"><strong>Note:</strong> If you see "CN=Android Debug", this means the .apk was +<p class="note"><strong>Note:</strong> If you see "CN=Android Debug", this means the APK was signed with the debug key generated by the Android SDK. If you intend to release your application, you must sign it with your private key instead of the debug key.</p> <p>For more information about Jarsigner, see the documentation at -<a href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security"> -http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security</a></p> +<a href="http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html"> +http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html</a></p> <h3 id="align">4. Align the final APK package</h3> -<p>Once you have signed the .apk with your private key, run <code>zipalign</code> on the file. +<p>Once you have signed the APK with your private key, run <code>zipalign</code> on the file. This tool ensures that all uncompressed data starts with a particular byte alignment, relative to the start of the file. Ensuring alignment at 4-byte boundaries provides a performance optimization when installed on a device. When aligned, the Android @@ -524,16 +536,16 @@ of the data from the package. The benefit is a reduction in the amount of RAM consumed by the running application.</p> <p>The <code>zipalign</code> tool is provided with the Android SDK, inside the -<code>tools/</code> directory. To align your signed .apk, execute:</p> +<code>tools/</code> directory. To align your signed APK, execute:</p> -<pre>zipalign -v 4 <em>your_project_name</em>-unaligned.apk <em>your_project_name</em>.apk</pre> +<pre>$ zipalign -v 4 <em>your_project_name</em>-unaligned.apk <em>your_project_name</em>.apk</pre> <p>The {@code -v} flag turns on verbose output (optional). {@code 4} is the byte-alignment (don't use anything other than 4). The first file argument is -your signed .apk (the input) and the second file is the destination .apk file (the output). -If you're overriding an existing .apk, add the {@code -f} flag.</p> +your signed {@code .apk} file (the input) and the second file is the destination {@code .apk} file +(the output). If you're overriding an existing APK, add the {@code -f} flag.</p> -<p class="caution"><strong>Caution:</strong> Your input .apk must be signed with your +<p class="caution"><strong>Caution:</strong> Your input APK must be signed with your private key <strong>before</strong> you optimize the package with {@code zipalign}. If you sign it after using {@code zipalign}, it will undo the alignment.</p> @@ -544,7 +556,7 @@ If you sign it after using {@code zipalign}, it will undo the alignment.</p> <h3 id="ExportWizard">Compile and sign with Eclipse ADT</h3> <p>If you are using Eclipse with the ADT plugin, you can use the Export Wizard to -export a <em>signed</em> .apk (and even create a new keystore, +export a <em>signed</em> APK (and even create a new keystore, if necessary). The Export Wizard performs all the interaction with the Keytool and Jarsigner for you, which allows you to sign the package using a GUI instead of performing the manual procedures to compile, sign, @@ -554,7 +566,7 @@ Because the Export Wizard uses both Keytool and Jarsigner, you should ensure that they are accessible on your computer, as described above in the <a href="#setup">Basic Setup for Signing</a>.</p> -<p>To create a signed and aligned .apk in Eclipse:</p> +<p>To create a signed and aligned APK in Eclipse:</p> <ol> <li>Select the project in the Package @@ -563,7 +575,7 @@ Explorer and select <strong>File > Export</strong>.</li> and click <strong>Next</strong>. <p>The Export Android Application wizard now starts, which will guide you through the process of signing your application, - including steps for selecting the private key with which to sign the .apk + including steps for selecting the private key with which to sign the APK (or creating a new keystore and private key).</p> <li>Complete the Export Wizard and your application will be compiled, signed, aligned, and ready for distribution.</li> diff --git a/docs/html/guide/publishing/licensing.html b/docs/html/guide/publishing/licensing.html new file mode 100644 index 0000000..8e97f32 --- /dev/null +++ b/docs/html/guide/publishing/licensing.html @@ -0,0 +1,11 @@ +<html> +<head> +<meta http-equiv="refresh" +content="0;url=http://developer.android.com/guide/market/licensing/index.html"> +<title>Redirecting...</title> +</head> +<body> +<p>You should have been redirected. Please <a +href="http://developer.android.com/guide/market/licensing/index.html">click here</a>.</p> +</body> +</html>
\ No newline at end of file diff --git a/docs/html/guide/publishing/licensing.jd b/docs/html/guide/publishing/licensing.jd deleted file mode 100644 index 609241b..0000000 --- a/docs/html/guide/publishing/licensing.jd +++ /dev/null @@ -1,2388 +0,0 @@ -page.title=Application Licensing -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - - <h2>Quickview</h2> - <ul> - <li>Licensing lets you protect your application on any device that includes Android Market.</li> - <li>Your app maintains control of how it enforces its licensing status. </li> - <li>Adding licensing to an app is straightforward, using the library available through the SDK.</li> - <li>The service is free and is available to all developers who publish on Android Market. </li> - </ul> - - <h2>In this document</h2> - <ol> - <li><a href="#account">Setting Up A Publisher Account</a></li> - <li><a href="#dev-setup">Setting Up the Development Environment</a></li> - <li><a href="#app-integration">Integrating the LVL with Your Application</a> - <ol> - <li><a href="#add-library">Including the LVL</a></li> - <li><a href="#manifest-permission">Adding the licensing permission</a></li> - <li><a href="#impl-Policy">Implementing a Policy</a></li> - <li><a href="#impl-Obfuscator">Implementing an Obfuscator</a></li> - <li><a href="#impl-lc">Checking the license</a></li> - <li><a href="#impl-DeviceLimiter">Implementing a DeviceLimiter</a></li> - </ol></li> - <li><a href="#test-env">Setting Up the Test Environment</a> - <ol> - <li><a href="#test-response">Test responses</a></li> - <li><a href="#test-acct-setup">Test accounts</a></li> - <li><a href="#acct-signin">Signing in on a device or emulator</a></li> - </ol></li> - <li><a href="#app-obfuscation">Obfuscating Your Application</a></li> - <li><a href="#app-publishing">Publishing a Licensed Application</a></li> - <li><a href="#support">Where to Get Support</a></li> - </ol> - - <h2>Appendix</h2> - <ol> - <li><a href="#lvl-summary">Summary of LVL Classes and Interfaces</a></li> - <li><a href="#server-response-codes">Server Response Codes</a></li> - <li><a href="#extras">Server Response Extras</a></li> - </ol> - -</div> -</div> - -<p>Android Market offers a licensing service that lets you enforce licensing -policies for paid applications that you publish through Android Market. With -Android Market Licensing, your applications can query Android Market at run time to -obtain their licensing status for the current user, then allow or disallow -further use as appropriate. </p> - -<p>Using the service, you can apply a flexible licensing policy on an -application-by-application basis — each application can enforce licensing -in the way most appropriate for it. If necessary, an application can apply custom -constraints based on the licensing status obtained from Android Market. -For example, an application can check the licensing status and then apply custom -constraints that allow the user to run it unlicensed for a specific number -of times, or for a specific validity period. An application can also restrict use of the -application to a specific device, in addition to any other constraints. </p> - -<p>The licensing service is a secure means of controlling access to your -applications. When an application checks the licensing status, the Market server -signs the licensing status response using a key pair that is uniquely associated -with the publisher account. Your application stores the public key in its -compiled <code>.apk</code> file and uses it to verify the licensing status -response.</p> - -<p>Any application that you publish through Android Market can use the Android -Market Licensing service. No special account or registration is needed. -Additionally, because the service uses no dedicated framework APIs, you can add -licensing to any legacy application that uses a minimum API level of 3 or -higher.</p> - -<p>To help you add licensing to your application, the Android SDK provides -library sources that you can include in your application project. The -License Verification Library (LVL) handles all of -the licensing-related communication with the Android Market client and the -licensing service. With the LVL integrated, your application can determine its -licensing status for the current user by simply calling a library checker method -and implementing a callback that receives the status.</p> - -<p>This document explains how the licensing service works and how to add it to -your application. </p> - - -<h2 id="overview">Overview</h2> - -<p>Android Market Licensing is a network-based service that lets an application -on an Android-powered device query a trusted licensing server, to determine -whether the application is licensed to the current device user. After receiving -the server response, the application can then allow or disallow further use of -the application as needed. In the service, the role of the licensing server is -to provide the license status for the current user; the application itself is -responsible for querying the server and conditionally granting access to the -application. </p> - -<h4>Application, Android Market client, and server</h4> - -<p>The licensing service is based on the capability of the Android Market server -to determine whether a given user is licensed to use a given application. The licensing server -considers a user to be licensed if the user is a recorded purchaser of an application. If a paid -application has been uploaded to Android Market but saved only as a draft application (in -other words, the app is unpublished), the licensing server considers all users to be licensed users -of the application. Keep in mind, you cannot implement Android Market Licensing in a free -application.</p> - -<p>To properly identify -the user and determine the license status, the server requires information about -the application and user — the application and the Android Market client -work together to assemble the information and pass it to the server. </p> - -<p>In the licensing service, an application does not query the licensing server -directly, but instead calls the Android Market client over remote IPC to -initiate a license request. In the license request:</p> - -<ul> -<li>The application provides its package name and a nonce that is later used to -validate any response from the server, as well as a callback over which the -response can be returned asynchronously.</li> -<li>The Android Market client, which has greater permissions than the -application, collects the necessary information about the user and the device, -such as the device's primary Google account username, IMSI, and other -information. It then sends the license check request to the server on behalf of -the application.</li> -<li>The server evaluates the request using all available information, attempting -to establish the user's identity to a sufficient level of confidence. The server -then checks the user identity against purchase records for the application and -returns a license response, which the Android Market client returns to the -application over the IPC callback.</li> -</ul> - -<p>Notice that during a license check, the application does not manage any -network connections or use any licensing related APIs in the Android platform. -</p> - -<div class="figure" style="width:469px"> -<img src="{@docRoot}images/licensing_arch.png" alt=""/> -<p class="img-caption"><strong>Figure 1.</strong> Your application initiates a -license check through the LVL and the Android Market -client, which handles communication with the Market server.</p> -</div> - -<h4>License responses secured through public key cryptography</h4> - -<p>To ensure the integrity of each license query, the server signs the license -response data using an RSA key pair that is shared exclusively between the -server and the application publisher.</p> - -<p>The licensing service generates a single licensing key pair for each -publisher account and exposes the public key in the account's profile page. The -publisher copies the public key and embeds it in the application source code, -then compiles and publishes the <code>.apk.</code> The server retains the -private key internally and uses it to sign license responses for applications -published on that account. </p> - -<p>When the application receives a signed response, it uses the embedded public -key to verify the data. The use of public key cryptography in the licensing -service makes it possible for the application to detect responses that have been -tampered with or that are spoofed.</p> - -<h4>Use of licensing in your application</h4> - -<p>To use licensing in your application, add code to the application to -initiate a license check request and handle the response when it is received. -You can choose when, and how often, you want your application to check its -license and you have full control over how it handles the response, verifies the -signed response data, and enforces access controls. </p> - -<p>To simplify the process of adding support for licensing, download and -integrate the Licensing Verification Library, described below. Integration is -straightforward.</p> - -<p>When you are finished integrating the LVL, use a test environment -provided by the publisher site to test your application's handling of server -responses. </p> - -<p>Finally, publish the application <code>.apk</code> on Market using the -normal process. If you previously used the copy-protection provided by Android -Market, you can remove it from applications that use licensing. </p> - -<h4>Licensing Verification Library simplifies implementation</h4> - -<p>The Android SDK includes a License Verification Library (LVL) that you can -download and use as the basis for your application's licensing implementation. -The LVL greatly simplifies the process of adding licensing to your application -and helps ensure a more secure, robust implementation for your application. The -LVL provides internal classes that handle most of the standard operations of a -license query, such as contacting Android Market to initiate a license request -and verifying and validating the responses. It also exposes key interfaces that -let you easily plug in your custom code for defining licensing policy and -managing access as needed by your application. The key LVL interfaces are: </p> - -<ul> -<li>Policy — your implementation determines whether to allow access to the -application, based on the license response received from the server and any -other data available (such as from a backend server associated with your -application). The implementation can evaluate the various fields of the license -response and apply other constraints, if needed. The implementation also lets -you manage the handling of license checks that result in errors, such as network -errors.</li> -<li>LicenseCheckerCallback — your implementation manages access to the -application, based on the result of the Policy's handling of the license -response. Your implementation can manage access in any way needed, including -displaying the license result in the UI or directing the user to purchase the -application (if not currently licensed). </li> -</ul> - -<p>To help you get started with a Policy, the LVL provides two fully complete -Policy implementations that you can use without modification or adapt to your -needs:</p> - -<ul> -<li><a href="#ServerManagedPolicy">ServerManagedPolicy</a> is a flexible Policy -that uses settings provided by the licensing server to manage response caching -and access to the application while the device is offline (such as when the -user is on an airplane). For most applications, the use of -ServerManagedPolicy is highly recommended. </li> -<li><a href="#StrictPolicy">StrictPolicy</a> is a restrictive Policy that -does not cache any response data and allows the application access <em>only</em> -when the server returns a licensed response.</li> -</ul> - -<p>The LVL is available as a downloadable component of the Android SDK. The -component includes both the LVL itself and an example application that shows how -the library should be integrated with your application and how your application -should manage response data, UI interaction, and error conditions. </p> - -<p>The LVL sources are provided as an Android <em>library project</em>, which -means that you can maintain a single set of library sources and share them -across multiple applications. A full test environment is also available through -the SDK, so you can develop and test the licensing implementation in your -applications before publishing them, even if you don't have access to a -physical device.</p> - -<h4>Requirements and limitations</h4> - -<p>Android Market Licensing is designed to let you apply license controls to -applications that you publish through Android Market. The service is not -designed to let you control access to applications that are not published -through Android Market or that are run on devices that do not offer the Android -Market client. </p> - -<p>Here are some points to keep in mind as you implement licensing in your -application: </p> - -<ul> -<li>Only paid applications published through Market can use the -service.</li> -<li>An application can use the service only if the Android Market client is -installed on its host device and the device is running Android 1.5 (API level 3) -or higher.</li> -<li>To complete a license check, the licensing server must be accessible over -the network. You can implement license caching behaviors to manage access when -there is no network connectivity. </li> -<li>The security of your application's licensing controls ultimately relies on -the design of your implementation itself. The service provides the building -blocks that let you securely check licensing, but the actual enforcement and -handling of the license are factors in your control. By following the best -practices in this document, you can help ensure that your implementation will be -secure.</li> -<li>Adding licensing to an application does not affect the way the application -functions when run on a device that does not offer Android Market.</li> -<li>Licensing is currently for paid apps only, since draft apps are -licensed for all users. If your application is already published as a free app, -you won't be able to upload a new version that uses licensing.</li> -</ul> - -<h4>Replacement for Copy Protection</h4> - -<p>Android Market Licensing is a flexible, secure mechanism for controlling -access to your applications. It effectively replaces the Copy Protection -mechanism offered on Android Market and gives you wider distribution -potential for your applications. </p> - -<ul> -<li>A limitation of the legacy Copy Protection mechanism on Android Market is -that applications using it can be installed only on compatible devices that -provide a secure internal storage environment. For example, a copy-protected -application cannot be downloaded from Market to a device that provides root -access, and the application cannot be installed to a device's SD card. </li> -<li>With Android Market licensing, you can move to a license-based model in -which access is not bound to the characteristics of the host device, but to your -publisher account on Android Market and the licensing policy that you define. -Your application can be installed and controlled on any compatible device on -any storage, including SD card.</li> -</ul> - -<p>Although no license mechanism can completely prevent all unauthorized use, -the licensing service lets you control access for most types of normal usage, -across all compatible devices, locked or unlocked, that run Android 1.5 or -higher version of the platform.</p> - -<p>The sections below describe how to add Android Market licensing to your -applications. </p> - -<h2 id="account">Setting Up a Publisher Account</h2> - -<p>Android Market licensing lets you manage access to applications that -users have downloaded from Android Market. To use licensing in an application, -you need to have a publisher account on Android Market so that you can -publish the application to users. </p> - -<p>If you don't already have a publisher account, you need to register for one -using your Google account and agree to the terms of service. Once you are -registered, you can upload applications at your convenience and begin debugging -and testing your licensing implementation. For more information about publishing -on Android Market, see <a -href="{@docRoot}guide/publishing/publishing.html">Publishing Your -Applications</a></p> - -<p>To register as an Android Market developer and set up your publisher account, -visit the Android Market publisher site:</p> - -<p style="margin-left:2em;"><a -href="http://market.android.com/publish">http://market.android.com/publish</a> -</p> - -<p>If you already have a publisher account on Android Market, use your existing -account to set up licensing. You <em>do not</em> need to register for a new -account to support licensing (and doing so is not recommended, especially if you -are adding licensing support to applications that you have already published). -In all cases, if you have published applications, you manage licensing for those -applications through the account on which the applications are published. </p> - -<p>Once your publisher account is set up, use the account to:</p> - -<ul> -<li>Obtain a public key for licensing</li> -<li>Debug and test an application's licensing implementation, prior to -publishing the application</li> -<li>Publish the applications to which you have added licensing support</li> -</ul> - -<h4>Administrative settings for licensing</h4> - -<p>Once you are signed into your publisher account, you can manage several -administrative controls for Android Market licensing. The controls are available -in the Edit Profile page, in the "Licensing" panel, shown below. The controls -let you: </p> - -<ul> -<li>Set up multiple "test accounts", identified by email address. The licensing -server allows users signed into test accounts on a device or emulator to send -license checks and receive static test responses.</li> -<li>Obtain the account's public key for licensing. When you are implementing -licensing in an application, you must copy the public key string into the -application.</li> -<li>Configure static test responses that the server sends, when it receives a -license check for an application uploaded to the publisher account, from a user -signed in to the publisher account or a test account.</li> -</ul> - -<div style="margin-bottom:2em;"> - -<img src="{@docRoot}images/licensing_public_key.png" style="text-align:left;margin-bottom:0;" /> -<div style="margin:0 2em;padding:0"><strong>Figure 2.</strong> The Licensing -panel of your account's Edit Profile page lets you manage administrative -settings for licensing.</div> -</div> - -<p>For more information about how to work with test accounts and static test -responses, see <a href="#test-env">Setting Up a Testing Environment</a>, below. - -<h2 id="dev-setup">Setting Up the Development Environment</h2> - -<p>Once you've set up your publisher account on Android Market, the next step is -to set up your development environment for licensing. </p> - -<p>Setting up your environment for licensing involves these tasks:</p> - -<ol> -<li><a href="#download-sdk">Downloading the latest SDK</a>, if you haven't already done so </li> -<li><a href="#runtime-setup">Setting up the runtime environment</a> for development</li> -<li><a href="#download-lvl">Downloading the Market Licensing component</a> into your SDK </li> -<li><a href="#lvl-setup">Setting up the Licensing Verification Library</a></li> -<li><a href="#add-library">Including the LVL library project in your application</a></li> -</ol> - -<p>The sections below describe these tasks. When you are done with setup, -you can begin <a href="#app-integration">integrating the LVL into your applications</a>.</p> - -<p>To get started, you need to set up a proper runtime environment on which -you can run, debug and test your application's implementation of license -checking and enforcement. </p> - - -<h3 id="download-sdk">Downloading the latest SDK</h3> - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>Licensing sample application</h2> - -<p>To work with Android Market licensing, you need a functioning Android -application to which you can add licensing support. </p> - -<p style="margin-top:.5em;">If you are new to Android -and don't yet have a functioning application, the LVL component includes a sample -application that you can set up as a new application project. The sample provides -a complete, working example of how licensing works. For more information, see <a -href="#download-lvl">Downloading the LVL</a>.</p> - -</div> -</div> - -<p>If you haven't done so, you need to download the Android SDK before you can -develop Android applications. The SDK provides the tools that you need to build -and debug Android applications, including applications that use Android Market -licensing. For complete information, including installation instructions, see -the <a href="{@docRoot}sdk/index.html">Android SDK</a>. </p> - -<p>If you have already installed the SDK, make sure to update the -SDK tools and ADT Plugin to the latest versions. You can update the SDK tools -using the Android SDK and AVD Manager and ADT through <strong>Help</strong> > -<strong>Software Updates...</strong> in Eclipse. </p> - -<p>After you've installed the latest SDK and tools, set up your development -environment as described below. </p> - - -<h3 id="runtime-setup">Setting up the runtime environment</h3> - -<p>As described earlier, applications check licensing status not by contacting -the licensing server directly, but by binding to a service provided by the -Android Market application and initiating a license check request. The Android -Market service then handles the direct communication with the licensing server -and finally routes the response back to your application. To debug and test -licensing in your application, you need to set up a runtime environment that -includes the necessary Android Market service, so that your application is able -to send license check requests to the licensing server. </p> - -<p>There are two types of runtime environment that you can use: </p> - -<ul> -<li>An Android-powered device that includes the Android Market application, or</li> -<li>An Android emulator running the Google APIs Add-on, API level 8 (release 2) -or higher</li> -</ul> - -<p>The sections below provide more information. </p> - -<h4 id="runtime-device">Running on a device</h4> - -<p>You can use an Android-powered device as the runtime environment for -debugging and testing licensing on your application.</p> - -<p>The device you use must:</p> - -<ul> -<li>Run a standard version of the Android 1.5 or later (API level -3 or higher) platform, <em>and</em> </li> -<li>Run a system image on which the Android Market client application -is preinstalled. </li> -</ul> - -<p>If Android Market is not preinstalled in the system image, your application won't -be able to communicate with the Android Market licensing server. </p> - -<p>For general information about how to set up a device for use in developing -Android applications, see <a -href="{@docRoot}guide/developing/device.html">Developing on a Device</a>.</p> - -<h4 id="runtime-emulator">Running on an Android emulator</h4> - -<p>You can also use an Android emulator as your runtime -environment for debugging and testing licensing.</p> - -<p>Because the standard Android platforms provided in the Android SDK <em>do -not</em> include Android Market, you need to download the Google APIs Add-On -platform, API Level 8 (or higher), from the SDK repository. After downloading -the add-on, you need to create an AVD configuration that uses that system image. -</p> - -<p>The Google APIs Add-On does not include the full Android Market client. -However, it does provide: </p> - -<ul> -<li>An Android Market background service that implements the -ILicensingService remote interface, so that your application can -send license checks over the network to the licensing server. </li> -<li>A set of underlying account services that let you add an a Google account on -the AVD and sign in using your publisher account or test account credentials. -Signing in using your publisher or test account enables you to debug and test -your application without having publish it. For more information see <a -href="#acct-signin">Signing in to an authorized account</a>, below.</li> -</ul> - -<p>Several versions of the add-on are available in the SDK repository, but only -<strong>Google APIs Add-On, API 8 (release 2) or higher</strong> version of the -add-on includes the necessary Android Market services. This means that you -cannot use Google APIs Add-On API 7 or lower as a runtime environment for -developing licensing on an emulator.</p> - -<div style="margin-bottom:2em;"> - -<img src="{@docRoot}images/licensing_gapis_8.png" style="text-align:left;margin-bottom:0;" /> -<div style="margin:0 2em;padding:0"><strong>Figure 3.</strong> Google APIs -Add-On, API 8 (release 2) or higher lets you debug and test your licensing -implementation in an emulator.</div> -</div> - -<p>To set up an emulator for adding licensing to an application, follow -these steps: </p> - -<ol> - <li>Launch the Android SDK and AVD Manager. </li> - <li>In the <strong>Available Packages</strong> panel, select and download the -SDK component "Google APIs (Google Inc.) - API Level 8" (or higher) from the SDK -repository, as shown in the figure above. - <p>When the download is complete, use the Android SDK and AVD Manager to -create a new AVD based on that component, described next.</p></li> - <li>In the <strong>Virtual -Devices</strong> panel of the Android SDK and AVD Manager, click -<strong>New</strong> and set the configuration details for the new AVD. </li> - <li>In the dialog that appears, assign a descriptive name to the AVD and then -use the "Target" menu to choose the "Google APIs (Google Inc.) - API Level 8" as -the system image to run on the new AVD. Set the other configuration details as -needed and then click <strong>Create AVD</strong> to finish. The SDK tools -create the new AVD configuration, which then appears in the list of available -Android Virtual Devices.</li> -</ol> - -<p>If you are not familiar with AVDs or how to use them, see <a -href="{@docRoot}guide/developing/devices/index.html">Managing Virtual Devices</a>.</p> - -<h4 id="project-update">Updating your project configuration</h4> - -<p>After you set up a runtime environment that meets the requirements described -above — either on an actual device or on an emulator — make sure to -update your application project or build scripts as needed, so that your compiled -<code>.apk</code> files that use licensing are deployed into that environment. -In particular, if you are developing in Eclipse, make sure that you set up a -Run/Debug Configuration that targets the appropriate device or AVD. </p> - -<p>You do not need to make any changes to your application's -build configuration, provided that the project is already configured to compile -against a standard Android 1.5 (API level 3) or higher library. For example: - -<ul> -<li>If you have an existing application that is compiled against -the Android 1.5 library, you do not need to make any changes to your -build configuration to support licensing. The build target meets the minimum -requirements for licensing, so you would continue building -against the same version of the Android platform.</li> - -<li>Similarly, if you are building against Android 1.5 (API level 3) but -are using an emulator running the Google APIs Add-On API 8 as the application's -runtime environment, there is no need to change your application's build -configuration. </li> -</ul> - -<p>In general, adding licensing to an application should have no impact -whatsoever on the application's build configuration.</p> - - -<h3 id="download-lvl">Downloading the LVL</h3> - -<p>The License Verification Library (LVL) is a collection of helper classes that -greatly simplify the work that you need to do to add licensing to your -application. In all cases, we recommend that you download the LVL and use it as -the basis for the licensing implementation in your application.</p> - -<p>The LVL is available as a downloadable component of the Android SDK. The -component includes: </p> - -<ul> -<li>The LVL sources, stored inside an Android library project. </li> -<li>An example application called "sample" that depends on the LVL library -project. The example illustrates how an application uses the library helper -classes to check and enforce licensing.</li> -</ul> - -<p>To download the LVL component into your development environment, use the -Android SDK and AVD Manager. Launch the Android SDK and AVD Manager and then -select the "Market Licensing" component, as shown in the figure below. -Accept the terms and click <strong>Install Selected</strong> to begin the download. </p> - -<div style="margin-bottom:2em;"> - -<img src="{@docRoot}images/licensing_package.png" style="text-align:left;margin-bottom:0;" /> -<div style="margin:0 2em;padding:0"><strong>Figure 4.</strong> The Market -Licensing package contains the LVL and the LVL sample application. </div> -</div> - -<p>When the download is complete, the Android SDK and AVD Manager installs both -the LVL library project and the example application into these directories: </p> - -<p style="margin-left:2em"><code><<em>sdk</em>>/extras/google/market_licensing/library/</code> - (the LVL library project)<br /> -<code><<em>sdk</em>>/extras/google/market_licensing/sample/</code> (the example -application)</p> - -<p>If you aren't familiar with how to download components into your SDK, see the -<a href="{@docRoot}sdk/adding-components.html">Adding SDK Components</a> -document. </p> - - -<h3 id="lvl-setup">Setting Up the Licensing Verification Library</h3> - -<p>After downloading the LVL to your computer, you need to set it up in your -development environment, either as an Android library project or by -copying (or importing) the library sources directly into your existing -application package. In general, using the LVL as a library project is recommended, -since it lets you reuse your licensing code across multiple applications and -maintain it more easily over time. Note that the LVL is not designed to be -compiled separately and added to an application as a static .jar file. </p> - -<h4>Moving the library sources to a new location</h4> - -<p>Because you will be customizing the LVL sources to some extent, you should -make sure to <em>move or copy</em> the library sources (the entire -directory at <code><<em>sdk</em>>/market_licensing/library/</code>) -to a working directory outside of the SDK. You should then use the relocated -sources as your working set. If you are using a source-code management -system, add and track the sources that are in the working location rather -than those in default location in the SDK. </p> - -<p>Moving the library sources is important is because, when you later update the -Market licensing package, the SDK installs the new files to the same location as -the older files. Moving your working library files to a safe location ensures -that your work won't be inadvertently overwritten should you download a new -version of the LVL.</p> - -<h4>Creating the LVL as a library project</h4> - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>Working with library projects</h2> - -<p>The LVL is provided as an Android library project, which means that you can -share its code and resources across multiple applications. </p> - -<p style="margin-top:.5em;">If you aren't familiar with library projects or how -to use them, see <a href="{@docRoot}guide/developing/projects/index.html#LibraryProjects"> -Managing Projects</a>. -</p> -</div> -</div> - -<p>The recommended way of using the LVL is setting it up as a new Android -<em>library project</em>. A library project is a type of development project -that holds shared Android source code and resources. Other Android application -projects can reference the library project and, at build time, include its -compiled sources in their <code>.apk</code> files. In the context of licensing, -this means that you can do most of your licensing development once, in a library -project, then include the library sources in your various application projects. -In this way, you can easily maintain a uniform implementation of licensing -across all of your projects and maintain it centrally. </p> - -<p>The LVL is provided as a configured library project — once you have -downloaded it, you can start using it right away. </p> - -<p>If you are working in Eclipse with ADT, you need to add the LVL to your -workspace as a new development project, in the same way as you would a new -application project. </p> - -<ol> -<li>Use the New Project Wizard to create a new -project from existing sources. Select the LVL's <code>library</code> directory -(the directory containing the library's AndroidManifest.xml file) as the project -root.</li> -<li>When you are creating the library project, you can select any application -name, package, and set other fields as needed. </li> -<li>For the library's build target, select Android 1.5 (API level 3) or higher.</li> -</ol> - -<p> When created, the project is -predefined as a library project in its <code>project.properties</code> file, so -no further configuration is needed. </p> - -<p>For more information about how to create an application project or work with -library projects in Eclipse, see <a -href="{@docRoot}guide/developing/projects/projects-eclipse.html">Managing Projects from -Eclipse with ADT</a></p>. - -<h4>Copying the LVL sources to your application</h4> - -<p>As an alternative to adding the LVL as a library project, you can copy the -library sources directly into your application. To do so, copy (or import) the -LVL's <code>library/src/com</code> directory into your application's -<code>src/</code> directory.</p> - -<p>If you add the LVL sources directly to your application, you can skip the -next section and start working with the library, as described in <a -href="#app-integration"></a>.</p> - - -<h3 id="add-library">Including the LVL library project sources in your -application</h3> - -<p>If you want to use the LVL sources as a library project, you need to add a -reference to the LVL library project in your application project properties. This tells -build tools to include the LVL library project sources in your application at -compile time. The process for adding a reference to a library project depends -on your development environment, as described below.</p> - -<p> If you are developing in Eclipse with ADT, you should already have added the -library project to your workspace, as described in the previous section. If you -haven't done that already, do it now before continuing. </p> - -<p>Next, open the application's project properties window, as shown below. -Select the "Android" properties group and click <strong>Add</strong>, then -choose the LVL library project (com_android_vending_licensing) and click -<strong>OK</strong>. For more information, see -<a href="{@docRoot}guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject"> -Managing Projects from Eclipse with ADT</a></p>. - -<div style="margin-bottom:2em;"> - -<img src="{@docRoot}images/licensing_add_library.png" style="text-align:left;margin-bottom:0;" /> -<div style="margin:0 2em;padding:0"><strong>Figure 5.</strong> If you are -working in Eclipse with ADT, you can add the LVL library project to your -application from the application's project properties.</div> -</div> - -<p>If you are developing using the SDK command-line tools, navigate to the -directory containing your application project and open the -<code>project.properties</code> file. Add a line to the file that specifies the -<code>android.library.reference.<n></code> key and the path to the -library. For example: </p> - -<pre>android.library.reference.1=path/to/library_project</pre> - -<p>Alternatively, you can use this command to update the project -properties, including the reference to the library project:</p> - -<pre class="no-pretty-print" style="color:black">android update lib-project ---target <em><target_ID></em> \ ---path <em>path/to/my/app_project</em> \ ---library <em>path/to/my/library_project</em> -</pre> - -<p>For more information about working with library projects, -see <a href="{@docRoot}guide/developing/projects/projects-cmdline.html#SettingUpLibraryProject"> -Managing Projects from the Command Line</a></p>. - - -<h2 id="app-integration">Integrating the LVL with Your Application</h2> - -<p>Once you've followed the steps above to set up a publisher account and -development environment, you are ready to begin integrating the LVL with your -application. </p> - -<p>Integrating the LVL with your application code involves these tasks:</p> - -<ol> -<li><a href="#manifest-permission">Adding the licensing permission</a> your application's manifest.</li> -<li><a href="#impl-Policy">Implementing a Policy</a> — you can choose one of the full implementations provided in the LVL or create your own.</li> -<li><a href="#impl-Obfuscator">Implementing an Obfuscator</a>, if your Policy will cache any license response data. </li> -<li><a href="#impl-lc">Adding code to check the license</a> in your application's main Activity</li> -<li><a href="#impl-DeviceLimiter">Implementing a DeviceLimiter</a> (optional and not recommended for most applications)</li> -</ol> - -<p>The sections below describe these tasks. When you are done with the -integration, you should be able to compile your application successfully and you -can begin testing, as described in <a href="#test-env">Setting Up the Test -Environment</a>.</p> - -<p>For an overview of the full set of source files included in the LVL, see <a -href="#lvl-summary">Summary of LVL Classes and Interfaces</a>.</p> - - -<h3 id="manifest-permission">Adding the licensing permission to your -AndroidManifest.xml</h3> - -<p>To use the Android Market application for sending a license check to the -server, your application must request the proper permission, -<code>com.android.vending.CHECK_LICENSE</code>. If your application does -not declare the licensing permission but attempts to initiate a license check, -the LVL throws a security exception.</p> - -<p>To request the licensing permission in your application, declare a <a -href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a> -element as a child of <code><manifest></code>, as follows: </p> - -<p style="margin-left:2em;"><code><uses-permission -android:name="com.android.vending.CHECK_LICENSE"></code></p> - -<p>For example, here's how the LVL sample application declares the permission: -</p> - -<pre><?xml version="1.0" encoding="utf-8"?> - -<manifest xmlns:android="http://schemas.android.com/apk/res/android" ..."> - <!-- Devices >= 3 have version of Android Market that supports licensing. --> - <uses-sdk android:minSdkVersion="3" /> - <!-- Required permission to check licensing. --> - <uses-permission android:name="com.android.vending.CHECK_LICENSE" /> - ... -</manifest> -</pre> - -<p class="note"><strong>Note:</strong> Currently, you cannot declare the -<code>CHECK_LICENSE</code> permission in the LVL library project's manifest, -because the SDK Tools will not merge it into the manifests of dependent -applications. Instead, you must declare the permission in each dependent -application's manifest. </p> - - -<h3 id="impl-Policy">Implementing a Policy</h3> - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>ServerManagedPolicy</h2> - -<p>The LVL includes a complete Policy implementation called ServerManagedPolicy -that makes use of license-management settings provided by the Android Market -server. </p> - -<p style="margin-top:.5em;">Use of ServerManagedPolicy as the basis for your -Policy is strongly recommended. For more information, see <a -href="#ServerManagedPolicy">ServerManagedPolicy</a> section, below.</p> - -</div> -</div> - -<p>Android Market licensing service does not itself determine whether a -given user with a given license should be granted access to your application. -Rather, that responsibility is left to a Policy implementation that you provide -in your application.</p> - -<p>Policy is an interface declared by the LVL that is designed to hold your -application's logic for allowing or disallowing user access, based on the result -of a license check. To use the LVL, your application <em>must</em> provide an -implementation of Policy. </p> - -<p>The Policy interface declares two methods, <code>allowAccess()</code> and -<code>processServerResponse()</code>, which are called by a LicenseChecker -instance when processing a response from the license server. It also declares an -enum called <code>LicenseResponse</code>, which specifies the license response -value passed in calls to <code>processServerResponse()</code>. </p> - -<ul> -<li><code>processServerResponse()</code> lets you preprocess the raw response -data received from the licensing server, prior to determining whether to grant -access. - -<p>A typical implementation would extract some or all fields from the license -response and store the data locally to a persistent store, such as through -{@link android.content.SharedPreferences} storage, to ensure that the data is -accessible across application invocations and device power cycles. For example, -a Policy would maintain the timestamp of last successful license check, the -retry count, the license validity period, and similar information in a -persistent store, rather than resetting the values each time the application is -launched.</p> - -<p>When storing response data locally, the Policy must ensure that the data is -obfuscated (see <a href="#impl-Obfuscator">Implementing an Obfuscator</a>, -below).</p></li> - -<li><code>allowAccess()</code> determines whether to grant the user access to -your application, based on any available license response data (from the -licensing server or from cache) or other application-specific information. For -example, your implementation of <code>allowAccess()</code> could take into -account additional criteria, such as usage or other data retrieved from a -backend server. In all cases, an implementation of <code>allowAccess()</code> -should only return <code>true</code> if the user is licensed to use the -application, as determined by the licensing server, or if there is a transient -network or system problem that prevents the license check from completing. In -such cases, your implementation can maintain a count of retry responses and -provisionally allow access until the next license check is complete.</li> - -</ul> - -<p>To simplify the process of adding licensing to your application and to -provide an illustration of how a Policy should be designed, the LVL includes -two full Policy implementations that you can use without modification or -adapt to your needs:</p> - -<ul> -<li><a href="#ServerManagedPolicy">ServerManagedPolicy</a>, a flexible Policy -that uses server-provided settings and cached responses to manage access across -varied network conditions, and</li> -<li><a href="#StrictPolicy">StrictPolicy</a>, which does not cache any response -data and allows access <em>only</em> if the server returns a licensed -response.</li> -</ul> - -<p>For most applications, the use of ServerManagedPolicy is highly -recommended. ServerManagedPolicy is the LVL default and is integrated with -the LVL sample application.</p> - - -<h4 id="custom-policies">Guidelines for custom policies</h4> - -<p>In your licensing implementation, you can use one of the complete policies -provided in the LVL (ServerManagedPolicy or StrictPolicy) or you can create a -custom policy. For any type of custom policy, there are several important design -points to understand and account for in your implementation.</p> - -<p>The licensing server applies general request limits to guard against overuse -of resources that could result in denial of service. When an application exceeds -the request limit, the licensing server returns a 503 response, which gets -passed through to your application as a general server error. This means that no -license response will be available to the user until the limit is reset, which -can affect the user for an indefinite period.</p> - -<p>If you are designing a custom policy, we recommend that the Policy: -<ol> -<!-- <li>Limits the number of points at which your app calls for a license check -to the minimum. </li> --> -<li>Caches (and properly obfuscates) the most recent successful license response -in local persistent storage.</li> -<li>Returns the cached response for all license checks, for as long as the -cached response is valid, rather than making a request to the licensing server. -Setting the response validity according to the server-provided <code>VT</code> -extra is highly recommended. See <a href="#extras">Server Response Extras</a> -for more information.</li> -<li>Uses an exponential backoff period, if retrying any requests the result in -errors. Note that the Android Market client automatically retries failed -requests, so in most cases there is no need for your Policy to retry them.</li> -<li>Provides for a "grace period" that allows the user to access your -application for a limited time or number of uses, while a license check is being -retried. The grace period benefits the user by allowing access until the next -license check can be completed successfully and it benefits you by placing a -hard limit on access to your application when there is no valid license response -available.</li> -</ol> - -<p>Designing your Policy according to the guidelines listed above is critical, -because it ensures the best possible experience for users while giving you -effective control over your application even in error conditions. </p> - -<p>Note that any Policy can use settings provided by the licensing server to -help manage validity and caching, retry grace period, and more. Extracting the -server-provided settings is straightforward and making use of them is highly -recommended. See the ServerManagedPolicy implementation for an example of how to -extract and use the extras. For a list of server settings and information about -how to use them, see <a href="#extras">Server Response Extras</a> in the -Appendix of this document.</p> - -<h4 id="ServerManagedPolicy">ServerManagedPolicy</h4> - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>Server Response Extras</h2> - -<p>For certain types of licensing responses, the licensing server appends extra -settings to the responses, to help the application manage licensing effectively. -</p> - -<p style="margin-top:.5em;">See <a href="#extras">Server Response Extras</a> for -a list of settings and <code>ServerManagedPolicy.java</code> for information -about how a Policy can use the extras.</p> - -</div> -</div> - -<p>The LVL includes a full and recommended implementation of the Policy -interface called ServerManagedPolicy. The implementation is integrated with the -LVL classes and serves as the default Policy in the library. </p> - -<p>ServerManagedPolicy provides all of the handling for license and retry -responses. It caches all of the response data locally in a -{@link android.content.SharedPreferences} file, obfuscating it with the -application's Obfuscator implementation. This ensures that the license response -data is secure and persists across device power cycles. ServerManagedPolicy -provides concrete implementations of the interface methods -<code>processServerResponse()</code> and <code>allowAccess()</code> and also -includes a set of supporting methods and types for managing license -responses.</p> - -<p>Importantly, a key feature of ServerMangedPolicy is its use of -server-provided settings as the basis for managing licensing across an -application's refund period and through varying network and error conditions. -When an application contacts the Android Market server for a license check, the -server appends several settings as key-value pairs in the extras field of certain -license response types. For example, the server provides recommended values for the -application's license validity period, retry grace period, and maximum allowable -retry count, among others. ServerManagedPolicy extracts the values from the -license response in its <code>processServerResponse()</code> method and checks -them in its <code>allowAccess()</code> method. For a list of the server-provided -settings used by ServerManagedPolicy, see <a href="#extras">Server Response -Extras</a> in the Appendix of this document.</p> - -<p>For convenience, best performance, and the benefit of using license settings -from the Android Market server, <strong>using ServerManagedPolicy as your -licensing Policy is strongly recommended</strong>. </p> - -<p>If you are concerned about the security of license response data that is -stored locally in SharedPreferences, you can use a stronger obfuscation -algorithm or design a stricter Policy that does not store license data. The LVL -includes an example of such a Policy — see <a -href="#StrictPolicy">StrictPolicy</a> for more information.</p> - -<p>To use ServerManagedPolicy, simply import it to your Activity, create an -instance, and pass a reference to the instance when constructing your -LicenseChecker. See <a href="#lc-lcc">Instantiate LicenseChecker and -LicenseCheckerCallback</a> for more information. </p> - -<h4 id="StrictPolicy">StrictPolicy</h4> - -<p>The LVL includes an alternative full implementation of the Policy interface -called StrictPolicy. The StrictPolicy implementation provides a more restrictive -Policy than ServerManagedPolicy, in that it does not allow the user to access -the application unless a license response is received from the server at the -time of access that indicates that the user is licensed.</p> - -<p>The principal feature of StrictPolicy is that it does not store <em>any</em> -license response data locally, in a persistent store. Because no data is stored, -retry requests are not tracked and cached responses can not be used to fulfill -license checks. The Policy allows access only if:</p> - -<ul> -<li>The license response is received from the licensing server, and </li> -<li>The license response indicates that the user is licensed to access the -application. </li> -</ul> - -<p>Using StrictPolicy is appropriate if your primary concern is to ensure that, -in all possible cases, no user will be allowed to access the application unless -the user is confirmed to be licensed at the time of use. Additionally, the -Policy offers slightly more security than ServerManagedPolicy — since -there is no data cached locally, there is no way a malicious user could tamper -with the cached data and obtain access to the application.</p> - -<p>At the same time, this Policy presents a challenge for normal users, since it -means that they won't be able to access the application when there is no network -(cell or wi-fi) connection available. Another side-effect is that your -application will send more license check requests to the server, since using a -cached response is not possible.</p> - -<p>Overall, this policy represents a tradeoff of some degree of user convenience -for absolute security and control over access. Consider the tradeoff carefully -before using this Policy.</p> - -<p>To use StrictPolicy, simply import it to your Activity, create an instance, -and pass a reference to it when constructing your LicenseChecker. See -<a href="#lc-lcc">Instantiate LicenseChecker and LicenseCheckerCallback</a> -for more information. </p> - -<h3 id="impl-Obfuscator">Implementing an Obfuscator</h3> - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>AESObfuscator</h2> - -<p>The LVL includes a full Obfuscator implementation in the -<code>AESObfuscator.java</code> file. The Obfuscator uses AES encryption to -obfuscate/unobfuscate data. If you are using a Policy (such as -ServerManagedPolicy) that caches license response data, using AESObfuscator as -basis for your Obfuscator implementation is highly recommended. </p> - -</div> -</div> - -<p>A typical Policy implementation needs to save the license response data for -an application to a persistent store, so that it is accessible across -application invocations and device power cycles. For example, a Policy would -maintain the timestamp of the last successful license check, the retry count, -the license validity period, and similar information in a persistent store, -rather than resetting the values each time the application is launched. The -default Policy included in the LVL, ServerManagedPolicy, stores license response -data in a {@link android.content.SharedPreferences} instance, to ensure that the -data is persistent. </p> - -<p>Because the Policy will use stored license response data to determine whether -to allow or disallow access to the application, it <em>must</em> ensure that any -stored data is secure and cannot be reused or manipulated by a root user on a -device. Specifically, the Policy must always obfuscate the data before storing -it, using a key that is unique for the application and device. Obfuscating using -a key that is both application-specific and device-specific is critical, because -it prevents the obfuscated data from being shared among applications and -devices.</p> - -<p>The LVL assists the application with storing its license response data in a -secure, persistent manner. First, it provides an Obfuscator -interface that lets your application supply the obfuscation algorithm of its -choice for stored data. Building on that, the LVL provides the helper class -PreferenceObfuscator, which handles most of the work of calling the -application's Obfuscator class and reading and writing the obfuscated data in a -SharedPreferences instance. </p> - -<p>The LVL provides a full Obfuscator implementation called -AESObfuscator that uses AES encryption to obfuscate data. You can -use AESObfuscator in your application without modification or you -can adapt it to your needs. For more information, see the next section.</p> - - -<h4 id="AESObfuscator">AESObfuscator</h4> - -<p>The LVL includes a full and recommended implementation of the Obfuscator -interface called AESObfuscator. The implementation is integrated with the -LVL sample application and serves as the default Obfuscator in the library. </p> - -<p>AESObfuscator provides secure obfuscation of data by using AES to -encrypt and decrypt the data as it is written to or read from storage. -The Obfuscator seeds the encryption using three data fields provided -by the application: </p> - -<ol> -<li>A salt — an array of random bytes to use for each (un)obfuscation. </li> -<li>An application identifier string, typically the package name of the application.</li> -<li>A device identifier string, derived from as many device-specific sources -as possible, so as to make it as unique.</li> -</ol> - -<p>To use AESObfuscator, first import it to your Activity. Declare a private -static final array to hold the salt bytes and initialize it to 20 randomly -generated bytes.</p> - -<pre> ... - // Generate 20 random bytes, and put them here. - private static final byte[] SALT = new byte[] { - -46, 65, 30, -128, -103, -57, 74, -64, 51, 88, -95, - -45, 77, -117, -36, -113, -11, 32, -64, 89 - }; - ... -</pre> - -<p>Next, declare a variable to hold a device identifier and generate a value for -it in any way needed. For example, the sample application included in the LVL -queries the system settings for the -<code>android.Settings.Secure.ANDROID_ID</code>, which is unique to each device. -</p> - -<p>Note that, depending on the APIs you use, your application might need to -request additional permissions in order to acquire device-specific information. -For example, to query the {@link android.telephony.TelephonyManager} to obtain -the device IMEI or related data, the application will also need to request the -<code>android.permission.READ_PHONE_STATE</code> permission in its manifest.</p> - -<p>Before requesting new permissions for the <em>sole purpose</em> of acquiring -device-specific information for use in your Obfuscator, consider -how doing so might affect your application or its filtering on Android Market -(since some permissions can cause the SDK build tools to add -the associated <code><uses-feature></code>).</p> - -<p>Finally, construct an instance of AESObfuscator, passing the salt, -application identifier, and device identifier. You can construct the instance -directly, while constructing your Policy and LicenseChecker. For example:</p> - -<pre> ... - // Construct the LicenseChecker with a Policy. - mChecker = new LicenseChecker( - this, new ServerManagedPolicy(this, - new AESObfuscator(SALT, getPackageName(), deviceId)), - BASE64_PUBLIC_KEY // Your public licensing key. - ); - ... -</pre> - -<p>For a complete example, see MainActivity in the LVL sample application.</p> - - -<h3 id="impl-lc">Checking the license from your application's main Activity</h3> - -<p>Once you've implemented a Policy for managing access to your application, the -next step is to add a license check to your application, which initiates a query -to the licensing server if needed and manages access to the application based on -the license response. All of the work of adding the license check and handling -the response takes place in your main {@link android.app.Activity} source file. -</p> - -<p>To add the license check and handle the response, you must:</p> - -<ol> - <li><a href="#imports">Add imports</a></li> - <li><a href="#lc-impl">Implement LicenseCheckerCallback</a> as a private inner class</li> - <li><a href="#thread-handler">Create a Handler</a> for posting from LicenseCheckerCallback to the UI thread</li> - <li><a href="#lc-lcc">Instantiate LicenseChecker</a> and LicenseCheckerCallback</li> - <li><a href="#check-access">Call checkAccess()</a> to initiate the license check</li> - <li><a href="#account-key">Embed your public key</a> for licensing</li> - <li><a href="#handler-cleanup">Call your LicenseChecker's onDestroy() method</a> to close IPC connections.</li> -</ol> - -<p>The sections below describe these tasks. </p> - -<h4 id="lc-overview">Overview of license check and response</h4> - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>Example: MainActivity</h2> - -<p>The sample application included with the LVL provides a full example of how -to initiate a license check and handle the result, in the -<code>MainActivity.java</code> file.</p> - -</div> -</div> - -<p>In most cases, you should add the license check to your application's main -{@link android.app.Activity}, in the <code>onCreate()</code> method. This -ensures that when the user launches your application directly, the license check -will be invoked immediately. In some cases, you can add license checks in other -locations as well. For example, if your application includes multiple Activity -components that other applications can start by {@link android.content.Intent}, -you could add license checks in those Activities.</p> - -<p>A license check consists of two main actions: </p> - -<ul> -<li>A call to a method to initiate the license check — in the LVL, this is -a call to the <code>checkAccess()</code> method of a LicenseChecker object that -you construct.</li> -<li>A callback that returns the result of the license check. In the LVL, this is -a <code>LicenseCheckerCallback</code> interface that you implement. The -interface declares two methods, <code>allow()</code> and -<code>dontAllow()</code>, which are invoked by the library based on to the -result of the license check. You implement those two methods with whatever logic -you need, to allow or disallow the user access to your application. Note that -these methods do not determine <em>whether</em> to allow access — that -determination is the responsibility of your Policy implementation. Rather, these -methods simply provide the application behaviors for <em>how</em> to allow and -disallow access (and handle application errors).</li> -</ul> - -<div style="margin-bottom:2em;"> - -<img src="{@docRoot}images/licensing_flow.png" style="text-align:left;margin-bottom:0;margin-left:3em;" /> -<div style="margin:.5em 0 1.5em 2em;padding:0"><strong>Figure 6.</strong> Overview of a -typical license check interaction.</div> -</div> - -<p>The diagram above illustrates how a typical license check takes place: </p> - -<ol> -<li>Code in the application's main Activity instantiates LicenseCheckerCallback -and LicenseChecker objects. When constructing LicenseChecker, the code passes in -{@link android.content.Context}, a Policy implementation to use, and the -publisher account's public key for licensing as parameters. </li> -<li>The code then calls the <code>checkAccess()</code> method on the -LicenseChecker object. The method implementation calls the Policy to determine -whether there is a valid license response cached locally, in -{@link android.content.SharedPreferences}. -<ul> -<li>If so, the <code>checkAccess()</code> implementation calls -<code>allow()</code>.</li> -<li>Otherwise, the LicenseChecker initiates a license check request that is sent -to the licensing server.</li> -</ul> -<p class="note"><strong>Note:</strong> The licensing server always returns -<code>LICENSED</code> when you perform a license check of a draft application.</p> -</li> -<li>When a response is received, LicenseChecker creates a LicenseValidator that -verifies the signed license data and extracts the fields of the response, then -passes them to your Policy for further evaluation. - <ul> - <li>If the license is valid, the Policy caches the response in -SharedPreferences and notifies the validator, which then calls the -<code>allow()</code> method on the LicenseCheckerCallback object. </li> - <li>If the license not valid, the Policy notifies the validator, which calls -the <code>dontAllow()</code> method on LicenseCheckerCallback. </li> - </ul> -</li> -<li>In case of a recoverable local or server error, such as when the network is -not available to send the request, LicenseChecker passes a RETRY response to -your Policy's <code>processServerResponse()</code> method. </li> -<li>In case of a application error, such as when the application attempts to -check the license of an invalid package name, LicenseChecker passes an error -response to the LicenseCheckerCallback's <code>applicationError()</code> -method. </li> -</ol> - -<p>Note that, in addition to initiating the license check and handling the -result, which are described in the sections below, your application also needs -to provide a <a href="#impl-Policy">Policy implementation</a> and, if the Policy -stores response data (such as ServerManagedPolicy), an <a -href="#impl-Obfuscator">Obfuscator</a> implementation. </p> - - -<h4 id="imports">Add imports</h4> - -<p>First, open the class file of the application's main Activity and import -LicenseChecker and LicenseCheckerCallback from the LVL package.</p> - -<pre> import com.android.vending.licensing.LicenseChecker; - import com.android.vending.licensing.LicenseCheckerCallback;</pre> - -<p>If you are using the default Policy implementation provided with the LVL, -ServerManagedPolicy, import it also, together with the AESObfuscator. If you are -using a custom Policy or Obfuscator, import those instead. </p> - -<pre> import com.android.vending.licensing.ServerManagedPolicy; - import com.android.vending.licensing.AESObfuscator;</pre> - -<h4 id="lc-impl">Implement LicenseCheckerCallback as a private inner class</h4> - -<p>LicenseCheckerCallback is an interface provided by the LVL for handling -result of a license check. To support licensing using the LVL, you must -implement LicenseCheckerCallback and -its methods to allow or disallow access to the application.</p> - -<p>The result of a license check is always a call to one of the -LicenseCheckerCallback methods, made based on the validation of the response -payload, the server response code itself, and any additional processing provided -by your Policy. Your application can implement the methods in any way needed. In -general, it's best to keep the methods simple, limiting them to managing UI -state and application access. If you want to add further processing of license -responses, such as by contacting a backend server or applying custom constraints, -you should consider incorporating that code into your Policy, rather than -putting it in the LicenseCheckerCallback methods. </p> - -<p>In most cases, you should declare your implementation of -LicenseCheckerCallback as a private class inside your application's main -Activity class. </p> - -<p>Implement the <code>allow()</code> and <code>dontAllow()</code> methods as -needed. To start with, you can use simple result-handling behaviors in the -methods, such as displaying the license result in a dialog. This helps you get -your application running sooner and can assist with debugging. Later, after you -have determined the exact behaviors you want, you can add more complex handling. -</p> - -<p>Some suggestions for handling unlicensed responses in -<code>dontAllow()</code> include: </p> - -<ul> -<li>Display a "Try again" dialog to the user, including a button to initiate a -new license check. </li> -<li>Display a "Purchase this application" dialog, including a button that -deep-links the user to the application's details page on Market, from which the -use can purchase the application. For more information on how to set up such -links, see <a -href="{@docRoot}guide/publishing/publishing.html#marketintent">Using Intents to -Launch the Market Application on a Device</a>. </li> -<li>Display a Toast notification that indicates that the features of the -application are limited because it is not licensed. </li> -</ul> - -<p>The example below shows how the LVL sample application implements -LicenseCheckerCallback, with methods that display the license check result in a -dialog. </p> - -<pre> private class MyLicenseCheckerCallback implements LicenseCheckerCallback { - public void allow() { - if (isFinishing()) { - // Don't update UI if Activity is finishing. - return; - } - // Should allow user access. - displayResult(getString(R.string.allow)); - } - - public void dontAllow() { - if (isFinishing()) { - // Don't update UI if Activity is finishing. - return; - } - displayResult(getString(R.string.dont_allow)); - // Should not allow access. An app can handle as needed, - // typically by informing the user that the app is not licensed - // and then shutting down the app or limiting the user to a - // restricted set of features. - // In this example, we show a dialog that takes the user to Market. - showDialog(0); - } - } -</pre> - -<p>Additionally, you should implement the <code>applicationError()</code> -method, which the LVL calls to let your application handle errors that are not -retryable. For a list of such errors, see <a -href="#server-response-codes">Server Response Codes</a> in the Appendix of this -document. You can implement the method in any way needed. In most cases, the -method should log the error code and call <code>dontAllow()</code>.</p> - -<h4 id="thread-handler">Create a Handler for posting from LicenseCheckerCallback -to the UI thread</h4> - -<p>During a license check, the LVL passes the request to the Android Market -application, which handles communication with the licensing server. The LVL -passes the request over asynchronous IPC (using {@link android.os.Binder}) so -the actual processing and network communication do not take place on a thread -managed by your application. Similarly, when the Android Market application -receives the result, it invokes a callback method over IPC, which in turn -executes in an IPC thread pool in your application's process.</p> - -<p>The LicenseChecker class manages your application's IPC communication with -the Android Market application, including the call that sends the request and -the callback that receives the response. LicenseChecker also tracks open license -requests and manages their timeouts. </p> - -<p>So that it can handle timeouts properly and also process incoming responses -without affecting your application's UI thread, LicenseChecker spawns a -background thread at instantiation. In the thread it does all processing of -license check results, whether the result is a response received from the server -or a timeout error. At the conclusion of processing, the LVL calls your -LicenseCheckerCallback methods from the background thread. </p> - -<p>To your application, this means that:</p> - -<ol> -<li>Your LicenseCheckerCallback methods will be invoked, in many cases, from a -background thread.</li> -<li>Those methods won't be able to update state or invoke any processing in the -UI thread, unless you create a Handler in the UI thread and have your callback -methods post to the Handler.</li> -</ol> - -<p>If you want your LicenseCheckerCallback methods to update the UI thread, -instantiate a {@link android.os.Handler} in the main Activity's -{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, -as shown below. In this example, the LVL sample application's -LicenseCheckerCallback methods (see above) call <code>displayResult()</code> to -update the UI thread through the Handler's -{@link android.os.Handler#post(java.lang.Runnable) post()} method.</p> - -<pre>private Handler mHandler; - - @Override - public void onCreate(Bundle savedInstanceState) { - ... - mHandler = new Handler(); - } -</pre> - -<p>Then, in your LicenseCheckerCallback methods, you can use Handler methods to -post Runnable or Message objects to the Handler. Here's how the sample -application included in the LVL posts a Runnable to a Handler in the UI thread -to display the license status.</p> - -<pre> private void displayResult(final String result) { - mHandler.post(new Runnable() { - public void run() { - mStatusText.setText(result); - setProgressBarIndeterminateVisibility(false); - mCheckLicenseButton.setEnabled(true); - } - }); - } -</pre> - -<h4 id="lc-lcc">Instantiate LicenseChecker and LicenseCheckerCallback</h4> - -<p>In the main Activity's -{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, -create private instances of LicenseCheckerCallback and LicenseChecker. You must -instantiate LicenseCheckerCallback first, because you need to pass a reference -to that instance when you call the contructor for LicenseChecker. </p> - -<p>When you instantiate LicenseChecker, you need to pass in these parameters:</p> - -<ul> -<li>The application {@link android.content.Context}</li> -<li>A reference to the Policy implementation to use for the license check. In -most cases, you would use the default Policy implementation provided by the LVL, -ServerManagedPolicy. </li> -<li>The String variable holding your publisher account's public key for -licensing. </li> -</ul> - -<p>If you are using ServerManagedPolicy, you won't need to access the class -directly, so you can instantiate it in the LicenseChecker constructor, -as shown in the example below. Note that you need to pass a reference to a new -Obfuscator instance when you construct ServerManagedPolicy.</p> - -<p>The example below shows the instantiation of LicenseChecker and -LicenseCheckerCallback from the <code>onCreate()</code> method of an Activity -class. </p> - -<pre>public class MainActivity extends Activity { - ... - private LicenseCheckerCallback mLicenseCheckerCallback; - private LicenseChecker mChecker; - - @Override - public void onCreate(Bundle savedInstanceState) { - super.onCreate(savedInstanceState); - ... - // Construct the LicenseCheckerCallback. The library calls this when done. - mLicenseCheckerCallback = new MyLicenseCheckerCallback(); - - // Construct the LicenseChecker with a Policy. - mChecker = new LicenseChecker( - this, new ServerManagedPolicy(this, - new AESObfuscator(SALT, getPackageName(), deviceId)), - BASE64_PUBLIC_KEY // Your public licensing key. - ); - ... - } -} -</pre> - - -<p>Note that LicenseChecker calls the LicenseCheckerCallback methods from the UI -thread <em>only</em> if there is valid license response cached locally. If the -license check is sent to the server, the callbacks always originate from the -background thread, even for network errors. </p> - - -<h4 id="check-access">Call checkAccess() to initiate the license check</h4> - -<p>In your main Activity, add a call to the <code>checkAccess()</code> method of the -LicenseChecker instance. In the call, pass a reference to your -LicenseCheckerCallback instance as a parameter. If you need to handle any -special UI effects or state management before the call, you might find it useful -to call <code>checkAccess()</code> from a wrapper method. For example, the LVL -sample application calls <code>checkAccess()</code> from a -<code>doCheck()</code> wrapper method:</p> - -<pre> @Override - public void onCreate(Bundle savedInstanceState) { - super.onCreate(savedInstanceState); - ... - // Call a wrapper method that initiates the license check - doCheck(); - ... - } - ... - private void doCheck() { - mCheckLicenseButton.setEnabled(false); - setProgressBarIndeterminateVisibility(true); - mStatusText.setText(R.string.checking_license); - mChecker.checkAccess(mLicenseCheckerCallback); - } -</pre> - - -<h4 id="account-key">Embed your public key for licensing</h4> - -<p>For each publisher account, the Android Market service automatically -generates a 2048-bit RSA public/private key pair that is used exclusively for -licensing. The key pair is uniquely associated with the publisher account and is -shared across all applications that are published through the account. Although -associated with a publisher account, the key pair is <em>not</em> the same as -the key that you use to sign your applications (or derived from it).</p> - -<p>The Android Market publisher site exposes the public key for licensing to any -developer signed in to the publisher account, but it keeps the private key -hidden from all users in a secure location. When an application requests a -license check for an application published in your account, the licensing server -signs the license response using the private key of your account's key pair. -When the LVL receives the response, it uses the public key provided by the -application to verify the signature of the license response. </p> - -<p>To add licensing to an application, you must obtain your publisher account's -public key for licensing and copy it into your application. Here's how to find -your account's public key for licensing:</p> - -<ol> -<li>Go to the Android Market <a -href="http://market.android.com/publish">publisher site</a> and sign in. -Make sure that you sign in to the account from which the application you are -licensing is published (or will be published). </li> -<li>In the account home page, locate the "Edit profile" link and click it. </li> -<li>In the Edit Profile page, locate the "Licensing" pane, shown below. Your -public key for licensing is given in the "Public key" text box. </li> -</ol> - -<p>To add the public key to your application, simply copy/paste the key string -from the text box into your application as the value of the String variable -<code>BASE64_PUBLIC_KEY</code>. When you are copying, make sure that you have -selected the entire key string, without omitting any characters. </p> - -<p>Here's an example from the LVL sample application:</p> - -<pre> public class MainActivity extends Activity { - private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example - ... - } -</pre> - -<h4 id="handler-cleanup">Call your LicenseChecker's onDestroy() method -to close IPC connections</h4> - -<p>Finally, to let the LVL clean up before your application -{@link android.content.Context} changes, add a call to the LicenseChecker's -<code>onDestroy()</code> method from your Activity's -{@link android.app.Activity#onDestroy()} implementation. The call causes the -LicenseChecker to properly close any open IPC connection to the Android Market -application's ILicensingService and removes any local references to the service -and handler.</p> - -<p>Failing to call the LicenseChecker's <code>onDestroy()</code> method -can lead to problems over the lifecycle of your application. For example, if the -user changes screen orientation while a license check is active, the application -{@link android.content.Context} is destroyed. If your application does not -properly close the LicenseChecker's IPC connection, your application will crash -when the response is received. Similarly, if the user exits your application -while a license check is in progress, your application will crash when the -response is received, unless it has properly called the -LicenseChecker's <code>onDestroy()</code> method to disconnect from the service. -</p> - -<p>Here's an example from the sample application included in the LVL, where -<code>mChecker</code> is the LicenseChecker instance:</p> - -<pre> @Override - protected void onDestroy() { - super.onDestroy(); - mChecker.onDestroy(); - ... - } -</pre> - -<p>If you are extending or modifying LicenseChecker, you might also need to call -the LicenseChecker's <code>finishCheck()</code> method, to clean up any open IPC -connections.</p> - -<h3 id="impl-DeviceLimiter">Implementing a DeviceLimiter</h3> - -<p>In some cases, you might want your Policy to limit the number of actual -devices that are permitted to use a single license. This would prevent a user -from moving a licensed application onto a number of devices and using the -application on those devices under the same account ID. It would also prevent a -user from "sharing" the application by providing the account information -associated with the license to other individuals, who could then sign in to that -account on their devices and access the license to the application. </p> - -<p>The LVL supports per-device licensing by providing a -<code>DeviceLimiter</code> interface, which declares a single method, -<code>allowDeviceAccess()</code>. When a LicenseValidator is handling a response -from the licensing server, it calls <code>allowDeviceAccess()</code>, passing a -user ID string extracted from the response.</p> - -<p>If you do not want to support device limitation, <strong>no work is -required</strong> — the LicenseChecker class automatically uses a default -implementation called NullDeviceLimiter. As the name suggests, NullDeviceLimiter -is a "no-op" class whose <code>allowDeviceAccess()</code> method simply returns -a <code>LICENSED</code> response for all users and devices. </p> - -<div style="border-left:4px solid #FFCF00;margin:1em;padding: 0 0 0 .5em"> -<p><strong>Caution:</strong> Per-device licensing is <em>not recommended for -most applications</em> because:</p> -<ul> -<li>It requires that you provide a backend server to manage a users and devices -mapping, and </li> -<li>It could inadvertently result in a user being denied access to an -application that they have legitimately purchased on another device.</li> -</ul> -</div> - - -<h2 id="test-env">Setting Up the Testing Environment</h2> - -<p>The Android Market publisher site provides configuration tools that let you -and others test licensing on your application before it is published. As you are -implementing licensing, you can make use of the publisher site tools to test -your application's Policy and handling of different licensing responses and -error conditions.</p> - -<p>The main components of the test environment for licensing include: </p> - -<ul> -<li>A "Test response" configuration in your publisher account that lets you -set the static licensing response returned, when the server processes a -license check for an application uploaded to the publisher account, from a user -signed in to the publisher account or a test account.</li> -<li>An optional set of test accounts that will receive the static test -response when they check the license of an application that you have uploaded -(regardless whether the application is published or not).</li> -<li>A runtime environment for the application that includes the Android Market -application or Google APIs Add-On, on which the user is signed in to the -publisher account or one of the test accounts.</li> -</ul> - -<p>Setting up the test environment properly involves:</p> - -<ol> -<li><a href="#test-response">Setting static test responses</a> that are returned by the licensing server.</li> -<li><a href="#test-acct-setup">Setting up test accounts</a> as needed.</li> -<li><a href="#acct-signin">Signing in</a> properly to an emulator or device, before initiating a license check test.</li> -</ol> - -<p>The sections below provide more information.</p> - - -<h3 id="test-response">Setting test responses for license checks</h3> - -<p>Android Market provides a configuration setting in your publisher account -that lets you override the normal processing of a license check and return a -specified static response code. The setting is for testing only and applies -<em>only</em> to license checks for applications that you have uploaded, made by -any user signed in to an emulator or device using the credentials of the -publisher account or a registered test account. For other users, the server -always processes license checks according to normal rules. </p> - -<p>To set a test response for your account, sign in to your publisher account -and click "Edit Profile". In the Edit Profile page, locate the Test Response -menu in the Licensing panel, shown below. You can select from the full set of -valid server response codes to control the response or condition you want to -test in your application.</p> - -<p>In general, you should make sure to test your application's licensing -implementation with every response code available in the Test Response menu. -For a description of the codes, see <a href="#server-response-codes">Server -Response Codes</a> in the Appendix of this document.</p> - -<div style="margin-bottom:2em;" id="licensing_test_response"> - -<img src="{@docRoot}images/licensing_test_response.png" style="text-align:left;margin-bottom:0;" /> -<div style="margin:0 2em;padding:0"><strong>Figure 7.</strong> The Licensing -panel of your account's Edit Profile page, showing the Test Accounts field and the -Test Response menu.</div> -</div> - -<p>Note that the test response that you configure applies account-wide — -that is, it applies not to a single application, but to <em>all</em> -applications associated with the publisher account. If you are testing multiple -applications at once, changing the test response will affect all of those -applications on their next license check (if the user is signed into -the emulator or device using the publisher account or a test account).</p> - -<p>Before you can successfully receive a test response for a license check, -you must sign in to the device or emulator on which the application -is installed, and from which it is querying the server. Specifically, you must -sign using either your publisher account or one of the test accounts that you -have set up. For more information about test accounts, see the next section.</p> - -<p>See <a href="#server-response-codes">Server Response Codes</a> for a list of -test responses available and their meanings. </p> - - -<h3 id="test-acct-setup">Setting up test accounts</h3> - -<p>In some cases, you might want to let multiple teams of developers test -licensing on applications that will ultimately be published through your -publisher account, but without giving them access to your publisher account's -sign-in credentials. To meet that need, the Android Market publisher site lets -you set up one or more optional <em>test accounts</em> — accounts that are -authorized to query the licensing server and receive static test responses from -your publisher account.</p> - -<p>Test accounts are standard Google accounts that you register on your -publisher account, such that they will receive the test response for -applications that you have uploaded. Developers can then sign in to their -devices or emulators using the test account credentials and initiate license -checks from installed applications. When the licensing server receives a license -check from a user of a test account, it returns the static test response -configured for the publisher account. </p> - -<p>Necessarily, there are limitations on the access and permissions given to -users signed in through test accounts, including:</p> - -<ul> -<li>Test account users can query the licensing server only for applications that -are already uploaded to the publisher account. </li> -<li>Test account users do not have permission to upload applications to your -publisher account.</li> -<li>Test account users do not have permission to set the publisher account's -static test response.</li> -</ul> - -<p>The table below summarizes the differences in capabilities, between the -publisher account, a test account, and any other account.</p> - -<p class="table-caption" id="acct-types-table"><strong>Table 1.</strong> -Differences in account types for testing licensing.</p> - -<table> -<tr> -<th>Account Type</th> -<th>Can check license before upload?</th> -<th>Can receive test response?</th> -<th>Can set test response?</th> -</tr> - -<tr> -<td>Publisher account</td> -<td>Yes</td> -<td>Yes</td> -<td>Yes</td> -</tr> - -<tr> -<td>Test account</td> -<td>No</td> -<td>Yes</td> -<td>No</td> -</tr> - -<tr> -<td>Other</td> -<td>No</td> -<td>No</td> -<td>No</td> -</tr> -</table> - -<h4 id="reg-test-acct">Registering test accounts on the publisher account</h4> - -<p>To get started, you need to register each test account in your publisher -account. As shown in <a href="#licensing_test_response">Figure 7</a>, above, you -register test accounts in the Licensing panel of your publisher account's Edit -Profile page. Simply enter the accounts as a comma-delimited list and click -<strong>Save</strong> to save your profile changes.</p> - -<p>You can use any Google account as a test account. If you want to own and -control the test accounts, you can create the accounts yourself and distribute -the credentials to your developers or testers.</p> - -<h4 id="test-app-upload">Handling application upload and distribution for test -account users</h4> - -<p>As mentioned above, users of test accounts can only receive static test -responses for applications that are uploaded to the publisher account. Since -those users do not have permission to upload applications, as the publisher you -will need to work with those users to collect apps for upload and distribute -uploaded apps for testing. You can handle collection and distribution in any way -that is convenient. </p> - -<p>Once an application is uploaded and becomes known to the licensing server, -developers and testers can continue modify the application in their local -development environment, without having to upload new versions. You only need to -upload a new version if the local application increments the -<code>versionCode</code> attribute in the manifest file. </p> - -<h4 id="test-key">Distributing your public key to test account users</h4> - -<p>The licensing server handles static test responses in the normal way, -including signing the license response data, adding extras parameters, and so -on. To support developers who are implementing licensing using test accounts, -rather than the publisher account, you will need to distribute -your public key to them. Developers without access to the publisher site do not -have access to your public key, and without the key they won't be able to -verify license responses. </p> - -<p>Note that if you decide to generate a new licensing key pair for your account -for some reason, you need to notify all users of test accounts. For -testers, you can embed the new key in the application package and distribute it -to users. For developers, you will need to distribute the new key to them -directly. </p> - - -<h3 id="acct-signin">Signing in to an authorized account in the runtime -environment</h3> - -<p>The licensing service is designed to determine whether a given user is -licensed to use a given application — during a license check, the Android -Market application gathers the user ID from the primary account on the system -and sends it to the server, together with the package name of the application -and other information. However, if there is no user information available, the -license check cannot succeed, so the Android Market application terminates the -request and returns an error to the application. </p> - -<p>During testing, to ensure that your application can successfully query the -licensing server, you must make sure that you sign in to an account <em>on the -device or emulator</em> using:</p> - -<ul> -<li>The credentials of a publisher account, or</li> -<li>The credentials of a test account that is registered with a publisher -account</li> -</ul> - - -<div class="sidebox-wrapper"> -<div class="sidebox"> -<h2>Signing in to a Google account on an emulator</h2> - -<p>If you are testing licensing on an emulator, you need to sign in to a Google -account on the emulator. If you do not see an option to create a new Google -account, the problem might be that your AVD is running a standard Android system -image, rather than the Google APIs Add-On, API 8 (release 2) or higher. </p> - -<p style="margin-top:.5em;">For more information, see <a -href="#runtime-setup">Setting up the runtime environment</a>, above.</p> - -</div> -</div> - -<p>Signing in using a publisher account offers the advantage of letting your -applications receive static test responses even before the applications are -uploaded to the publisher site.</p> - -<p>If you are part of a larger organization or are working with external groups -on applications that will be published through your site, you will more likely -want to distribute test accounts instead, then use those to sign in during -testing. </p> - -<p>To sign in on a device or emulator, follow the steps below. The preferred -approach is to sign in as the primary account — however, if there are -other accounts already in use on the device or emulator, you can create an -additional account and sign in to it using the publisher or test account -credentials. </p> - -<ol> -<li>Open Settings > Accounts & sync</li> -<li>Select <strong>Add Account</strong> and choose to add a "Google" account. -</li> -<li>Select <strong>Next</strong> and then <strong>Sign in</strong>.</li> -<li>Enter the username and password of either the publisher account or a test -account that is registered in the publisher account.</li> -<li>Select <strong>Sign in</strong>. The system signs you in to the new -account.</li> -</ol> - -<p>Once you are signed in, you can begin testing licensing in your application -(if you have completed the LVL integration steps above). When your application -initiates a license check, it will receive a response containing the static test -response configured on the publisher account. </p> - -<p>Note that, if you are using an emulator, you will need to sign in to the -publisher account or test account each time you wipe data when restarting the -emulator.</p> - -<div style="margin:2em 1em 1em 1em;"> - -<img src="{@docRoot}images/licensing_device_signin.png" style="text-align:left;" /> -<div style="margin:.25em 1.25em;padding:0"><strong>Figure 8.</strong> Example of -setting up a Google account on a device or emulator.</div> -</div> - -<h2 id="app-obfuscation">Obfuscating Your Application</h2> - -<p>To ensure the security of your application, particularly for a paid -application that uses licensing and/or custom constraints and protections, it's -very important to obfuscate your application code. Properly obfuscating your -code makes it more difficult for a malicious user to decompile the application's -bytecode, modify it — such as by removing the license check — -and then recompile it.</p> - -<p>Several obfuscator programs are available for Android applications, including -<a href="http://proguard.sourceforge.net/">ProGuard</a>, which also offers -code-optimization features. The use of ProGuard or a similar program to obfuscate -your code is <em>strongly recommended</em> for all applications that use Android -Market Licensing. </p> - -<h2 id="app-publishing">Publishing a Licensed Application</h2> - -<p>When you are finished testing your license implementation, you are ready to -publish the application on Android Market. Follow the normal steps to <a -href="{@docRoot}guide/publishing/preparing.html">prepare</a>, <a -href="{@docRoot}guide/publishing/app-signing.html">sign</a>, and then <a -href="{@docRoot}guide/publishing/publishing.html">publish the application</a>. -</p> - -<h4>Removing Copy Protection</h4> - -<p>After uploading your licensed application, remember to remove copy protection -from the application, if it is currently used. To check and remove copy -protection, sign in to the publisher site and go the application's upload -details page. In the Publishing options section, make sure that the Copy -Protection radio button selection is "Off".</p> - -<h4>Considerations for Free Apps</h4> - -<p>Licensing is currently supported only for paid applications. If you already -published your application as free, you won't be able to upload an updated -version that includes licensing (that is, an application that uses the same -package name and that includes the <a href="#manifest-permission">licensing -permission</a>). Here are some points to keep in mind:</p> - -<ul> -<li>If you want to offer a free version of your application that provides a -reduced feature set (or that offers the full feature set for trial period), the -free version of your application must not include the licensing permission and -must use a different package name than the paid version of the app.</li> -<li>If you want to offer a paid version of your free application that uses -licensing, you can do so under a new package name.</li> -</ul> - -<h2 id="support">Where to Get Support</h2> - -<p>If you have questions or encounter problems while implementing or deploying -publishing in your applications, please use the support resources listed in the -table below. By directing your queries to the correct forum, you can get the -support you need more quickly. </p> - -<p class="table-caption"><strong>Table 2.</strong> Developer support resources -for Android Market Licensing Service.</p> - -<table> - -<tr> -<th>Support Type</th> -<th>Resource</th> -<th>Range of Topics</th> -</tr> -<tr> -<td rowspan="2">Development and testing issues</td> -<td>Google Groups: <a -href="http://groups.google.com/group/android-developers">android-developers</a> -</td> -<td rowspan="2">LVL download and integration, library projects, Policy -questions, user experience ideas, handling of responses, Obfuscator, IPC, test -environment setup</td> -</tr> -<tr> -<td>Stack Overflow: <a -href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.com/questions/tagged/android</a></td> -</tr> -<tr> -<td rowspan="2">Accounts, publishing, and deployment issues</td> -<td><a href="http://www.google.com/support/forum/p/Android+Market">Android -Market Help Forum</a></td> -<td rowspan="2">Publisher accounts, licensing key pair, test accounts, server -responses, test responses, application deployment and results</td> -</tr> -<tr> -<td><a -href="http://market.android.com/support/bin/answer.py?answer=186113">Market -Licensing Support FAQ</a></td> -</tr> -<tr> -<td>LVL issue tracker</td> -<td><a href="http://code.google.com/p/marketlicensing/issues/">Marketlicensing -project issue tracker</a></td> -<td>Bug and issue reports related specifically to the LVL source code classes -and interface implementations</td> -</tr> - -</table> - -<p>For general information about how to post to the groups listed above, see <a -href="{@docRoot}resources/community-groups.html">Developer Forums</a> document -in the Resources tab.</p> - -<h2 id="lvl-summary">Summary of LVL Classes and Interfaces</h2> - -<p>The table below lists all of the source files in the License Verification -Library (LVL) available through the Android SDK. All of the files are part of -the <code>com.android.vending.licensing</code> package.</p> - -<p class="table-caption"><strong>Table A-1.</strong> Summary of LVL library -classes and interfaces.</p> - -<div style="width:99%"> -<table width="100%"> - -<tr> -<th width="15%">Category</th> -<th width="20%">Name</th> -<th width="100%">Description</th> -</tr> - -<tr> -<td rowspan="2">License check and result</td> -<td>LicenseChecker</td> -<td>Class that you instantiate (or subclass) to initiate a license check.</td> -</tr> -<tr> -<td><em>LicenseCheckerCallback</em></td> -<td>Interface that you implement to handle result of the license check.</td> -</tr> - -<tr> -<td rowspan="3" width="15%">Policy</td> -<td width="20%"><em>Policy</em></td> -<td width="100%">Interface that you implement to determine whether to allow -access to the application, based on the license response. </td> -</tr> -<tr> -<td>ServerManagedPolicy</td> -<td width="100%">Default Policy implementation. Uses settings provided by the -licensing server to manage local storage of license data, license validity, -retry.</td> -</tr> -<tr> -<td>StrictPolicy</td> -<td>Alternative Policy implementation. Enforces licensing based on a direct -license response from the server only. No caching or request retry.</td> -</tr> - -<tr> -<td rowspan="2" width="15%">Data obfuscation <br><em>(optional)</em></td> -<td width="20%"><em>Obfuscator</em></td> -<td width="100%">Interface that you implement if you are using a Policy (such as -ServerManagedPolicy) that caches license response data in a persistent store. -Applies an obfuscation algorithm to encode and decode data being written or -read.</td> -</tr> -<tr> -<td>AESObfuscator</td> -<td>Default Obfuscator implementation that uses AES encryption/decryption -algorithm to obfuscate/unobfuscate data.</td> -</tr> - -<tr> -<td rowspan="2" width="15%">Device limitation<br><em>(optional)</em></td> -<td width="20%"><em>DeviceLimiter</em></td> -<td width="100%">Interface that you implement if you want to restrict use of an -application to a specific device. Called from LicenseValidator. Implementing -DeviceLimiter is not recommended for most applications because it requires a -backend server and may cause the user to lose access to licensed applications, -unless designed with care.</td> -</tr> -<tr> -<td>NullDeviceLimiter</td> -<td>Default DeviceLimiter implementation that is a no-op (allows access to all -devices).</td> -</tr> - -<tr> -<td rowspan="6" width="15%">Library core, no integration needed</td> -<td width="20%">ResponseData</td> -<td width="100%">Class that holds the fields of a license response.</td> -</tr> -<tr> -<td>LicenseValidator</td> -<td>Class that decrypts and verifies a response received from the licensing -server.</td> -</tr> -<tr> -<td>ValidationException</td> -<td>Class that indicates errors that occur when validating the integrity of data -managed by an Obfuscator.</td> -</tr> -<tr> -<td>PreferenceObfuscator</td> -<td>Utility class that writes/reads obfuscated data to the system's -{@link android.content.SharedPreferences} store.</td> -</tr> -<tr> -<td><em>ILicensingService</em></td> -<td>One-way IPC interface over which a license check request is passed to the -Android Market client.</td> -</tr> -<tr> -<td><em>ILicenseResultListener</em></td> -<td>One-way IPC callback implementation over which the application receives an -asynchronous response from the licensing server.</td> -</tr> - -</table> -</div> - - -<h2 id="server-response-codes">Server Response Codes</h2> - -<p>The table below lists all of the license response codes supported by the -licensing server. In general, an application should handle all of these response -codes. By default, the LicenseValidator class in the LVL provides all of the -necessary handling of these response codes for you. </p> - -<p class="table-caption"><strong>Table A-2.</strong> Summary of response codes -returned by the Android Market server in a license response.</p> - -<table> - -<tr> -<th>Response Code</th> -<th>Description</th> -<th>Signed?</th> -<th>Extras</th> -<th>Comments</th> -</tr> -<tr> -<td>LICENSED</td> -<td>The application is licensed to the user. The user has purchased the -application or the application only exists as a draft.</td> -<td>Yes</td> -<td><code>VT</code>, <code>GT</code>, <code>GR</code></td> -<td><em>Allow access according to Policy constraints.</em></td> -</tr> -<tr> -<td>LICENSED_OLD_KEY</td> -<td>The application is licensed to the user, but there is an updated application -version available that is signed with a different key. </td> -<td>Yes </td> -<td><code>VT</code>, <code>GT</code>, <code>GR</code>, <code>UT</code></td> -<td><em>Optionally allow access according to Policy constraints.</em> -<p style="margin-top:.5em;">Can indicate that the key pair used by the installed -application version is invalid or compromised. The application can allow access -if needed or inform the user that an upgrade is available and limit further use -until upgrade.</p> -</td> -</tr> -<tr> -<td>NOT_LICENSED</td> -<td>The application is not licensed to the user.</td> -<td>No</td> -<td></td> -<td><em>Do not allow access.</em></td> -</tr> -<tr> -<td>ERROR_CONTACTING_SERVER</td> -<td>Local error — the Android Market application was not able to reach the -licensing server, possibly because of network availability problems. </td> -<td>No</td> -<td></td> -<td><em>Retry the license check according to Policy retry limits.</em></td> -</tr> -<tr> -<td>ERROR_SERVER_FAILURE</td> -<td>Server error — the server could not load the publisher account's key -pair for licensing.</td> -<td>No</td> -<td></td> -<td><em>Retry the license check according to Policy retry limits.</em> -</td> -</tr> -<tr> -<td>ERROR_INVALID_PACKAGE_NAME</td> -<td>Local error — the application requested a license check for a package -that is not installed on the device. </td> -<td>No </td> -<td></td> -<td><em>Do not retry the license check.</em> -<p style="margin-top:.5em;">Typically caused by a development error.</p> -</td> -</tr> -<tr> -<td>ERROR_NON_MATCHING_UID</td> -<td>Local error — the application requested a license check for a package -whose UID (package, user ID pair) does not match that of the requesting -application. </td> -<td>No </td> -<td></td> -<td><em>Do not retry the license check.</em> -<p style="margin-top:.5em;">Typically caused by a development error.</p> -</td> -</tr> -<tr> -<td>ERROR_NOT_MARKET_MANAGED</td> -<td>Server error — the application (package name) was not recognized by -Android Market. </td> -<td>No</td> -<td></td> -<td><em>Do not retry the license check.</em> -<p style="margin-top:.5em;">Can indicate that the application was not published -through Android Market or that there is an development error in the licensing -implementation.</p> -</td> -</tr> - -</table> - -<p class="note"><strong>Note:</strong> As documented in <a href="#test-env"> -Setting Up The Testing Environment</a>, the response code can be manually -overridden for the application developer and any registered test users via the -Android Market publisher site. -<br/><br/> -Additionally, as noted above, applications that are in draft mode (in other -words, applicaitons that have been uploaded but have <em>never</em> been -published) will return LICENSED for all users, even if not listed as a test -user. Since the application has never been offered for download, it is assumed -that any users running it must have obtained it from an authorized channel for -testing purposes.</p> - -<h2 id="extras">Server Response Extras</h2> - -<p>The licensing server includes several settings in certain types of license -responses, to assist the application and its Policy in managing access to the -application across the 24-hour refund period and other conditions. Specifically, -the server provides recommended values for the application's license validity -period, retry grace period, maximum allowable retry count, and other settings. -The server appends the settings as key-value pairs in the license response -"extras" field. </p> - -<p>Any Policy implementation can extract the extras settings from the license -response and use them as needed. The LVL default Policy implementation, <a -href="#ServerManagedPolicy">ServerManagedPolicy</a>, serves as a working -implementation and an illustration of how to obtain, store, and use the -settings. </p> - -<p class="table-caption"><strong>Table A-3.</strong> Summary of -license-management settings supplied by the Android Market server in a license -response.</p> - -<table> -<tr> -<th>Extra</th><th>Description</th> -</tr> - -<tr> - <td>VT</td> - <td>License validity timestamp. Specifies the date/time at which the current -(cached) license response expires and must be rechecked on the licensing server. - </td> -</tr> -<tr> - <td>GT</td> - <td>Grace period timestamp. Specifies the end of the period during which a -Policy may allow access to the application, even though the response status is -RETRY. <p>The value is managed by the server, however a typical value would be 5 -or more days.</p></td> -</tr> -<tr> - <td>GR</td> - <td>Maximum retries count. Specifies how many consecutive RETRY license checks -the Policy should allow, before denying the user access to the application. -<p>The value is managed by the server, however a typical value would be "10" or -higher.</p></td> -</tr> -<tr> - <td>UT</td> - <td>Update timestamp. Specifies the day/time when the most recent update to -this application was uploaded and published. <p>The server returns this extra -only for LICENSED_OLD_KEYS responses, to allow the Policy to determine how much -time has elapsed since an update was published with new licensing keys before -denying the user access to the application. </p></td> -</tr> - -</table> - -<p>The sections below provide more information about the server-provided -settings and how to use them. </p> - -<h4>License validity period</h4> - -<p>The Android Market licensing server sets a license validity period for all -downloaded applications. The period expresses the interval of time over which an -application's license status should be considered as unchanging and cacheable by -a licensing Policy in the application. The licensing server includes the -validity period in its response to all license checks, appending an -end-of-validity timestamp to the response as an extra under the key "VT". A -Policy can extract the VT key value and use it to conditionally allow access to -the application without rechecking the license, until the validity period -expires. </p> - -<p>The license validity signals to a licensing Policy when it must recheck the -licensing status with the licensing server. It is <em>not</em> intended to imply -whether an application is actually licensed for use. That is, when an -application's license validity period expires, this does not mean that the -application is no longer licensed for use — rather, it indicates only that -the Policy must recheck the licensing status with the server. It follows that, -as long as the license validity period is not expired, it is acceptable for the -Policy to cache the initial license status locally and return the cached license -status instead of sending a new license check to the server.</p> - -<p>The licensing server manages the validity period as a means of helping the -application properly enforce licensing across the refund period offered by -Android Market for paid applications. It sets the validity period based on -whether the application was purchased and, if so, how long ago. Specifically, -the server sets a validity period as follows:</p> - -<ul> -<li>For a paid application, the server sets the initial license validity period -so that the license response remains valid for as long as the application is -refundable. A licensing Policy in the application may cache the -result of the initial license check and does not need to recheck the license -until the validity period has expired.</li> -<li>When an application is no longer refundable, the server -sets a longer validity period — typically a number of days. </li> -<li>For a free application, the server sets the validity period to a very high -value (<code>long.MAX_VALUE</code>). This ensures that, provided the Policy has -cached the validity timestamp locally, it will not need to recheck the -license status of the application in the future.</li> -</ul> - -<p>The ServerManagedPolicy implementation uses the extracted timestamp -(<code>mValidityTimestamp</code>) as a primary condition for determining whether -to recheck the license status with the server before allowing the user access to -the application. </p> - -<h4>Retry period and maximum retry count</h4> - -<p>In some cases, system or network conditions can prevent an application's -license check from reaching the licensing server, or prevent the server's -response from reaching the Android Market client application. For example, the -user might launch an application when there is no cell network or data -connection available — such as when on an airplane — or when the -network connection is unstable or the cell signal is weak. </p> - -<p>When network problems prevent or interrupt a license check, the Android -Market client notifies the application by returning a "RETRY" response code to -the Policy's <code>processServerResponse()</code> method. In the case of system -problems, such as when the application is unable to bind with Android Market's -ILicensingService implementation, the LicenseChecker library itself calls the -Policy <code>processServerResonse()</code> method with a "RETRY" response code. -</p> - -<p>In general, the RETRY response code is a signal to the application that an -error has occurred that has prevented a license check from completing. - -<p>The Android Market server helps an application to manage licensing under -error conditions by setting a retry "grace period" and a recommended maximum -retries count. The server includes these values in all license check responses, -appending them as extras under the keys "GT" and "GR". </p> - -<p>The application Policy can extract the GT and GR extras and use them to -conditionally allow access to the application, as follows:</p> - -<ul> -<li>For a license check that results in a RETRY response, the Policy should -cache the RETRY response code and increment a count of RETRY responses.</li> -<li>The Policy should allow the user to access the application, provided that -either the retry grace period is still active or the maximum retries count has -not been reached.</li> -</ul> - -<p>The ServerManagedPolicy uses the server-supplied GT and GR values as -described above. The example below shows the conditional handling of the retry -responses in the <code>allow()</code> method. The count of RETRY responses is -maintained in the <code>processServerResponse()</code> method, not shown. </p> - - -<pre> public boolean allowAccess() { - long ts = System.currentTimeMillis(); - if (mLastResponse == LicenseResponse.LICENSED) { - // Check if the LICENSED response occurred within the validity timeout. - if (ts <= mValidityTimestamp) { - // Cached LICENSED response is still valid. - return true; - } - } else if (mLastResponse == LicenseResponse.RETRY && - ts < mLastResponseTime + MILLIS_PER_MINUTE) { - // Only allow access if we are within the retry period or we haven't used up our - // max retries. - return (ts <= mRetryUntil || mRetryCount <= mMaxRetries); - } - return false; - }</pre> - diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd index 83aa5ee..fe56352 100644 --- a/docs/html/guide/publishing/preparing.jd +++ b/docs/html/guide/publishing/preparing.jd @@ -22,7 +22,7 @@ page.title=Preparing for Release <ol> <li><a href="{@docRoot}guide/publishing/publishing_overview.html">Publishing Overview</a></li> <li><a href="{@docRoot}guide/publishing/app-signing.html">Signing Your Applications</a></li> - <li><a href="{@docRoot}guide/publishing/publishing.html">Publishing on Android Market</a></li> + <li><a href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play</a></li> </ol> </div> </div> @@ -39,13 +39,13 @@ similar to the debug build process and can be done using JDK and Android SDK too tasks serve as a final check, ensuring that your application performs as expected under real-world conditions. When you are finished preparing your application for release you have a signed <code>.apk</code> file, which you can distribute directly to users or distribute through an -application marketplace such as Android Market.</p> +application marketplace such as Google Play.</p> <p>This document summarizes the main tasks you need to perform to prepare your application for release. The tasks that are described in this document apply to all Android applications regardless -how they are released or distributed to users. If you are releasing your application through Android -Market, you should also read <a href="{@docRoot}guide/publishing/publishing.html">Publishing on -Android Market</a> to be sure your release-ready application satisfies all Android Market +how they are released or distributed to users. If you are releasing your application through Google +Play, you should also read <a href="{@docRoot}guide/publishing/publishing.html">Publishing on +Google Play</a> to be sure your release-ready application satisfies all Google Play requirements.</p> <p class="note"><strong>Note:</strong> As a best practice, your application should meet all of your @@ -89,9 +89,9 @@ line.</p> <p>To prepare your application for release you typically perform five main tasks (see figure 2). Each main task may include one or more smaller tasks depending on how you are releasing your -application. For example, if you are releasing your application through Android Market you may want +application. For example, if you are releasing your application through Google Play you may want to add special filtering rules to your manifest while you are configuring your application for -release. Similarly, to meet Android Market publishing guidelines you may have to prepare screenshots +release. Similarly, to meet Google Play publishing guidelines you may have to prepare screenshots and create promotional text while you are gathering materials for release.</p> <p>You usually perform the tasks listed in figure 2 after you have throroughly debugged and tested @@ -137,9 +137,9 @@ key</a>.</p> href="{@docRoot}guide/practices/ui_guidelines/icon_design_launcher.html">icon guidelines</a>. Your application's icon helps users identify your application on a device's Home screen and in the Launcher window. It also appears in Manage Applications, My Downloads, and -elsewhere. In addition, publishing services such as Android Market display your icon to users.</p> +elsewhere. In addition, publishing services such as Google Play display your icon to users.</p> -<p class="note"><strong>Note:</strong> If you are releasing your application on Android Market, you +<p class="note"><strong>Note:</strong> If you are releasing your application on Google Play, you need to create a high resolution version of your icon. See <a href="https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870">Graphic @@ -154,7 +154,7 @@ with your application.</p> <h4>Miscellaneous Materials</h4> <p>You might also have to prepare promotional and marketing materials to publicize your application. -For example, if you are releasing your application on Android Market you will need to prepare some +For example, if you are releasing your application on Google Play you will need to prepare some promotional text and you will need to create screenshots of your application. For more information, see <a href="https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870"> @@ -242,11 +242,11 @@ tasks:</p> </ul> <p>There are several additional manifest elements that you can set if you are releasing your -application on Android Market. For example, the <code>android:minSdkVersion</code> and +application on Google Play. For example, the <code>android:minSdkVersion</code> and <code>android:targetSdkVersion</code> attributes, which are located in the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"> <uses-sdk></a> element. For more -information about these and other Android Market settings, see <a -href="{@docRoot}/guide//appendix/market-filters.html">Market Filters</a>.</p> +information about these and other Google Play settings, see <a +href="{@docRoot}/guide//appendix/market-filters.html">Filters on Google Play</a>.</p> <h4>Address compatibility issues</h4> @@ -283,15 +283,15 @@ doing the following:</p> <p>If your application accesses remote servers or services, make sure you are using the production URL or path for the server or service and not a test URL or path.</p> -<h4>Implement Licensing (if you are releasing on Android Market)</h4> +<h4>Implement Licensing (if you are releasing on Google Play)</h4> -<p>If you are releasing a paid application through Android Market, consider adding support for -Android Market Licensing. Licensing lets you control access to your application based on whether the -current user has purchased it. Using Android Market Licensing is optional even if you are -releasing your app through Android Market.</p> +<p>If you are releasing a paid application through Google Play, consider adding support for +Google Play Licensing. Licensing lets you control access to your application based on whether the +current user has purchased it. Using Google Play Licensing is optional even if you are +releasing your app through Google Play.</p> -<p>For more information about Android Market Licensing Service and how to use it in your -application, see <a href="{@docRoot}guide/publishing/licensing.html">Application Licensing</a>.</p> +<p>For more information about Google Play Licensing Service and how to use it in your +application, see <a href="{@docRoot}guide/market/licensing.html">Application Licensing</a>.</p> <h2 id="publishing-build">Building Your Application for Release</h2> @@ -352,7 +352,7 @@ a summary of common Android situations that you should consider when you are tes done testing and you are satisfied that the release version of your application behaves correctly, you can release your application to users. For more information, see <a href="{@docRoot}guide/publishing/publishing_overview.html#publishing-release">Releasing Your -Application to Users</a>. If you are publishing your application on Android Market, see -<a href="{@docRoot}guide/publishing/publishing.html">Publishing on Android Market</a>.</p> +Application to Users</a>. If you are publishing your application on Google Play, see +<a href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play</a>.</p> diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd index 49b34d8..b9513ab 100644 --- a/docs/html/guide/publishing/publishing.jd +++ b/docs/html/guide/publishing/publishing.jd @@ -1,4 +1,4 @@ -page.title=Publishing on Android Market +page.title=Publishing on Google Play @jd:body <div id="qv-wrapper"> @@ -7,25 +7,25 @@ page.title=Publishing on Android Market <h2>Quickview</h2> <ul> -<li>Learn how to publish and update apps on Android Market.</li> -<li>Find out how to create links to apps that are published on Android Market.</li> -<li>Learn about Android Market features.</li> +<li>Learn how to publish and update apps on Google Play.</li> +<li>Find out how to create links to apps that are published on Google Play.</li> +<li>Learn about Google Play features.</li> </ul> <h2>In this document</h2> <ol> -<li><a href="#overview">About Android Market</a> -<li><A href="#marketpublish">Publishing Apps on Android Market</a></li> -<li><a href="#marketupgrade">Publishing Updates on Android Market</a></li> -<li><a href="#marketLicensing">Using Android Market Licensing Service</a></li> -<li><a href="#marketinappbilling">Using Android Market In-app Billing</a></li> -<li><a href="#marketintent">Linking to Your Apps on Android Market</a> +<li><a href="#overview">About Google Play</a> +<li><A href="#marketpublish">Publishing Apps on Google Play</a></li> +<li><a href="#marketupgrade">Publishing Updates on Google Play</a></li> +<li><a href="#marketLicensing">Using Google Play Licensing Service</a></li> +<li><a href="#marketinappbilling">Using Google Play In-app Billing</a></li> +<li><a href="#marketintent">Linking to Your Apps on Google Play</a> <ol> <li><a href="#OpeningDetails">Opening an app's details page</a></li> <li><a href="#PerformingSearch">Performing a search</a></li> - <li><a href="#BuildaButton">Build an Android Market button</a></li> + <li><a href="#BuildaButton">Build a Google Play button</a></li> <li><a href="#UriSummary">Summary of URI formats</a></li> </ol> </li> @@ -41,9 +41,9 @@ 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 5px;"> - <h2 style="color:#669999;">Already know about Android Market and want to get started?</h2> - <p>Go to <a href="http://market.android.com/publish">Android Market</a>, create a developer + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0 5px;"> + <h2 style="color:#669999;">Already know about Google Play and want to get started?</h2> + <p>Go to <a href="http://play.google.com/apps/publish">Google Play</a>, create a developer account, and upload your application. For more information about required assets, listing details, and publishing options, see <a href="http://market.android.com/support/bin/answer.py?answer=113469">Upload @@ -55,78 +55,78 @@ Applications</a>.</p> </div> <p>One of the most effective ways to get your application into users' hands is to -publish it on an application marketplace like Android Market. Publishing on Android Market is a +publish it on an application marketplace like Google Play. Publishing on Google Play is a straightforward process that you can do in just a few simple steps—register, configure, upload, and publish. Registration takes only a few minutes and needs to be done only once. -The configuration and publishing steps can all be done through the Android Market Developer Console -after you register as an Android Market developer.</p> +The configuration and publishing steps can all be done through the Google Play Android Developer Console +after you register as a Google Play developer.</p> -<p>To start publishing on Android Market, first read this topic and then go to the <a -href="https://market.android.com/publish/signup">Android Market publisher site</a> and register as -an Android Market developer.</p> +<p>To start publishing on Google Play, first read this topic and then go to the <a +href="https://play.google.com/apps/publish">Google Play Android Developer Console</a> and register as +a Google Play developer.</p> -<h2 id="overview">About Android Market</h2> +<h2 id="overview">About Google Play</h2> -<p>Android Market is a robust publishing platform that helps you publicize, sell, and distribute +<p>Google Play is a robust publishing platform that helps you publicize, sell, and distribute your Android applications to users around the world. When you release your applications through -Android Market you have access to a suite of developer tools that let you analyze your sales, +Google Play you have access to a suite of developer tools that let you analyze your sales, identify market trends, and control who your applications are being distributed to. You also have access to several revenue-enhancing features, such as <a href="{@docRoot}guide/market/billing/index.html">in-app billing</a> and -<a href="{@docRoot}guide/publishing/licensing.html">application licensing</a>.</p> +<a href="{@docRoot}guide/market/licensing/index.html">application licensing</a>.</p> -<p>Before you can publish applications on Android Market, you need to <a -href="http://market.android.com/publish">register</a> as an Android Market developer. During the +<p>Before you can publish applications on Google Play, you need to <a +href="http://play.google.com/apps/publish">register</a> as a Google Play developer. During the registration process you will need to create a developer profile, pay a registration fee, and agree -to the <a href="http://www.android.com/us/developer-distribution-agreement.html">Android Market -Developer Distribution Agreement</a>. After you register you can access the Android Market Developer +to the <a href="http://www.android.com/us/developer-distribution-agreement.html">Google Play +Developer Distribution Agreement</a>. After you register you can access the Developer Console, where you can upload applications, configure publishing options, and monitor publishing data. If you want to sell your applications or use the in-app billing feature, you will also need to set up a Google Checkout merchant account. For more information about the registration process, see <a href="https://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=113468"> Developer Registration</a>.</p> -<h2 id="marketpublish">Publishing Apps on Android Market</h2> +<h2 id="marketpublish">Publishing Apps on Google Play</h2> -<p>Publishing your application on Android Market is a simple process that involves three basic +<p>Publishing your application on Google Play is a simple process that involves three basic tasks (see figure 1):</p> <ul> <li>Creating various graphical assets that -accompany your app on Android Market.</li> - <li>Using the Android Market <a -href="http://market.android.com/publish">Developer Console</a> to configure publishing options, -specify listing details, and upload your app and graphical assets to Android Market.</li> +accompany your app on Google Play.</li> + <li>Using the Google Play <a +href="http://play.google.com/apps/publish">Developer Console</a> to configure publishing options, +specify listing details, and upload your app and graphical assets to Google Play.</li> <li>Reviewing your publishing settings and changing the release status of your app from Unpublished to Published.</li> </ul> <img src="{@docRoot}images/publishing/publishing_android_market.png" - alt="Shows the three steps that are required to publish on Android Market" + alt="Shows the three steps that are required to publish on Google Play" height="168" id="figure1" /> <p class="img-caption"> - <strong>Figure 1.</strong> To publish apps on Android Market you must first <a + <strong>Figure 1.</strong> To publish apps on Google Play you must first <a href="{@docRoot}guide/publishing/preparing.html">prepare your app for release</a> and then perform three simple tasks. </p> <p class="caution"><strong>Important:</strong> You must <a href="{@docRoot}guide/publishing/preparing.html">prepare your application for release</a> before you -can publish it on Android Market. When you prepare your application for release you configure it for +can publish it on Google Play. When you prepare your application for release you configure it for release and build it in release mode. Building in release mode signs your application's {@code .apk} -file with your private release key. You cannot publish an application on Android Market unless it is +file with your private release key. You cannot publish an application on Google Play unless it is signed with your own private release key.</p> <h3>Preparing promotional materials</h3> -<p>To fully leverage the marketing and publicity capabilities of Android Market, you need to create -several graphical assets that accompany your app on Android Market, such as screenshots, videos, +<p>To fully leverage the marketing and publicity capabilities of Google Play, you need to create +several graphical assets that accompany your app on Google Play, such as screenshots, videos, promotional graphics, and promotional text. At a minimum you must provide two screenshots of your application and a high resolution application icon. The screenshots are displayed on the details -page for your application in Android Market, and the high resolution application icon is displayed -in various locations throughout Android Market. The high resolution icon does not replace the +page for your application on Google Play, and the high resolution application icon is displayed +in various locations throughout Google Play. The high resolution icon does not replace the launcher icon for your application, rather, it serves as a supplemental icon and should look the same as your launcher icon. Promotional video, graphics, and text are optional, although we strongly recommended that you prepare these for your @@ -136,8 +136,8 @@ Assets for your Application</a>.</p> <h3>Configuring options and uploading assets</h3> -<p>Android Market lets you target your application to a worldwide pool of users and devices. To -reach these users you can use the Android Market Developer Console to configure various publishing +<p>Google Play lets you target your application to a worldwide pool of users and devices. To +reach these users you can use the Developer Console to configure various publishing options and listing details for your app. For example, you can choose the <a href="http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=138294&topic= 2365624&ctx=topic">countries</a> you want to reach, the listing languages you want to use, and the @@ -155,11 +155,11 @@ href="http://grendel.sea.corp.google.com:48014/guide/market/billing/billing_admi app.</p> <p>When you are finished setting publishing options and listing details, you can upload your assets -and your application to Android Market. You can also upload your application as a draft +and your application to Google Play. You can also upload your application as a draft (unpublished) application, which lets you do final testing before you publish it for final release.</p> -<p>To learn more about Android Market publishing settings, see the following resources:</p> +<p>To learn more about Google Play publishing settings, see the following resources:</p> <ul> <li><a @@ -181,20 +181,20 @@ pricing, payouts, and exchange rates work.</li> <p>When you are satisfied that your publishing settings are correctly configured and your uploaded application is ready to be released to the public, you can simply click <strong>Publish</strong> in the Developer Console to make your app available for download -around the world. Keep in mind, it can take several hours for your app to appear on Android -Market after you click <strong>Publish</strong> in the Developer Console.</p> +around the world. Keep in mind, it can take several hours for your app to appear on Google +Play after you click <strong>Publish</strong> in the Developer Console.</p> <h3>Controlling Distribution to Devices</h3> <p>If your application targets different device configurations, you can control which Android-powered -devices have access to your application on Android Market by -using Android Market filters. Filtering compares device configurations that you declare in your +devices have access to your application on Google Play by +using Google Play filters. Filtering compares device configurations that you declare in your app's manifest file to the configuration defined by a device. For example, if you declare the camera -filter in your manifest, only those devices that have a camera will see your app on Android -Market. Filters must be configured in your application's manifest file when you are <a +filter in your manifest, only those devices that have a camera will see your app on Google +Play. Filters must be configured in your application's manifest file when you are <a href="{@docRoot}guide/publishing/preparing.html">preparing your app for release</a> (that is, before -you upload your app to Android Market). For more information, see <a -href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a>.</p> +you upload your app to Google Play). For more information, see <a +href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a>.</p> <p>You can also use the multiple APK feature to distribute different {@code .apk} files under the same application listing and the same package name; however, you should use this option only as a last @@ -205,17 +205,17 @@ few cases, however, a single APK is unable to support all device configurations, resources make the APK file too big (greater than 50MB) or other technical challenges prevent a single APK from working on all devices. Although we encourage you to develop and publish a single APK 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 +not possible. To help you publish your application for as many devices as possible, Google Play +allows you to publish multiple APKs under the same application listing. Google Play then supplies each APK to the appropriate devices based on configuration support you've declared in the manifest file of each APK. To use this feature, you need to build your separate {@code .apk} files when you are <a href="{@docRoot}guide/publishing/preparing.html">preparing your app for release</a> (that is, before -you upload your app to Android Market). For more information, see <a +you upload your app to Google Play). For more information, see <a href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> -<h2 id="marketupgrade">Publishing Updates on Android Market</h2> +<h2 id="marketupgrade">Publishing Updates on Google Play</h2> -<p>At any time after publishing an application on Android Market, you can upload +<p>At any time after publishing an application on Google Play, you can upload and publish an update to the same application package. When you publish an update to an application, users who have already installed the application may receive a notification that an update is @@ -228,49 +228,49 @@ attributes in the <a href="{@docRoot}guide/topics/manifest/manifest-element.html"><code><manifest></code></a> element of the manifest file. Also, the package name must be the same as the existing version and the {@code .apk} file must be signed with the same private key. If the package name and signing -certificate do <em>not</em> match those of the existing version, Market will +certificate do <em>not</em> match those of the existing version, Google Play will consider it a new application, publish it as such, and will not offer it to existing users as an update.</p> -<p>If you plan to publish your application on Android Market, you must make sure - that it meets the requirements listed below, which are enforced by the Market - server when you upload the application.</p> +<p>If you plan to publish your application on Google Play, you must make sure + that it meets the requirements listed below, which are enforced by Google Play + when you upload the application.</p> -<h2 id="marketLicensing">Using Android Market Licensing Service</h2> +<h2 id="marketLicensing">Using Google Play Licensing Service</h2> -<p>Android Market offers a licensing service that lets you enforce licensing -policies for paid applications that you publish through Android Market. With -Android Market Licensing, your applications can query Android Market at runtime +<p>Google Play offers a licensing service that lets you enforce licensing +policies for paid applications that you publish through Google Play. With +Google Play Licensing, your applications can query Google Play at runtime to obtain the licensing status for the current user, then allow or disallow further use of the application as appropriate. Using the service, you can apply a flexible licensing policy on an application-by-application basis—each application can enforce its licensing status in the way most appropriate for it. </p> -<p>Any application that you publish through Android Market can use the Android -Market Licensing Service. The service uses no dedicated framework APIs, so you can +<p>Any application that you publish through Google Play can use the Google +Play Licensing Service. The service uses no dedicated framework APIs, so you can add licensing to any application that uses a minimum API Level of 3 or higher.</p> -<p>For complete information about Android Market Licensing Service and how to +<p>For complete information about Google Play Licensing Service and how to use it in your application, read <a -href="{@docRoot}guide/publishing/licensing.html">Application Licensing</a>.</p> +href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a>.</p> -<h2 id="marketinappbilling">Using Android Market In-app Billing</h2> +<h2 id="marketinappbilling">Using Google Play In-app Billing</h2> -<p><a href="{@docRoot}guide/market/billing/billing_overview.html">Android Market In-app Billing</a> -is an Android Market service that lets you sell digital content in your applications. You can use +<p><a href="{@docRoot}guide/market/billing/billing_overview.html">Google Play In-app Billing</a> +is a Google Play service that lets you sell digital content in your applications. You can use the service to sell a wide range of content, including downloadable content such as media files or photos, and virtual content such as game levels or potions.</p> -<p>When you use Android Market's in-app billing service to sell an item, Android Market handles all +<p>When you use Google Play's in-app billing service to sell an item, Google Play handles all billing details so your application never has to directly process any financial transactions. -Android Market uses the same checkout service that is used for application purchases, so your users +Google Play uses the same checkout service that is used for application purchases, so your users experience a consistent and familiar purchase flow (see figure 1). Also, the transaction fee for in-app purchases is the same as the transaction fee for application purchases (30%).</p> -<p>Any application that you publish through Android Market can implement in-app billing. No special -account or registration is required other than an Android Market publisher account and a Google +<p>Any application that you publish through Google Play can implement in-app billing. No special +account or registration is required other than a Google Play publisher account and a Google Checkout Merchant account. Also, because the service uses no dedicated framework APIs, you can add in-app billing to any application that uses a minimum API level of 4 or higher.</p> @@ -282,58 +282,59 @@ also contains examples of the database, user interface, and business logic you m implement in-app billing. For more information about the in-app billing feature, see the <a href="{@docRoot}guide/market/billing/index.html">In-app Billing documentation</a>.</p> -<h2 id="marketintent">Linking to Your Apps on Android Market</h2> +<h2 id="marketintent">Linking to Your Apps on Google Play</h2> -<p>To help users discover your published applications, you can use two special Android Market URIs +<p>To help users discover your published applications, you can use two special Google Play 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 create a button in your application or a +applications on Google Play. You can use these URIs to create a button in your application or a link on a web page that:</p> <ul> - <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 + <li>Opens your application's details page in the Google Play application or web site.</li> + <li>Searches for all your published applications in the Google Play application or web site.</li> </ul> -<p>You can launch the Android Market application or web site in the following ways:</p> +<p>You can launch the Google Play 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.</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> +Google Play application on the user's device.</li> + <li>Provide a link on a web page that opens the Google Play web site (but will also +open the Google Play application if clicked from a device).</li> </ul> <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 from your application, the prefix for the intent's data +<p>To open the Google Play 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 Android Market from your web site, the prefix for the link URI is:</p> +<p>To open Google Play store 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 style="margin-left:2em"><code>http://play.google.com/store/</code></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 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 +<p class="note"><strong>Note:</strong> If you create a link to open Google Play from your web +site and the user selects it from an Android-powered device, the device's Google Play application will +resolve the link so the user can use the Google Play application on the device instead of opening the web +site. As such, you should always use {@code http://play.google.com/store/apps/...} 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> +{@code market://} URIs in an intent, so that the Google Play application always opens.</p> <h3 id="OpeningDetails">Opening an app's details page</h3> <p>As described above, you can open the details page for a specific application either on the -Android Market application or the Android Market web site. The details page allows the user to see +Google Play application or the Google Play web site. The details page allows the user to see the application description, screenshots, reviews and more, and choose to install it.</p> <p>The format for the URI that opens the details page is:</p> -<p style="margin-left:2em"><code><URI_prefix><b>details?id=</b><package_name></code></p> +<p style="margin-left:2em"><code><URI_prefix><b>apps/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 @@ -341,26 +342,28 @@ 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.</p> +<p>For example: <code>http://play.google.com/store/apps/details?id=com.example.myapp</code></p> + <h4>Opening the app details page from your Android app</h4> -<p>To open the Android Market details page from your application, +<p>To open the Google Play 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 -Android Market:</p> +Google Play:</p> <pre> Intent intent = new Intent(Intent.ACTION_VIEW); -intent.setData(Uri.parse("market://details?id=com.android.example")); +intent.setData(Uri.parse("market://details?id=com.example.android")); startActivity(intent); </pre> -<p>This will open the Android Market application on the device to view the {@code -com.android.example} application.</p> +<p>This will open the Google Play application on the device to view the {@code +com.example.android} application.</p> <h4>Opening the app details page from a web site</h4> @@ -369,32 +372,32 @@ com.android.example} application.</p> format:</p> <p style="margin-left:2em"> - <code>http://market.android.com/details?id=<package_name></code> + <code>http://play.google.com/store/apps/details?id=<package_name></code> </p> -<p>For example, here's a link that opens an application's details page on Android Market:</p> +<p>For example, here's a link that opens an application's details page on Google Play:</p> <pre> -<a href="http://market.android.com/details?id=com.android.example">App Link</a> +<a href="http://play.google.com/store/apps/details?id=com.example.android">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 +<p>When clicked from a desktop web browser, this opens the Google Play web site to view the +{@code com.example.android} application. When clicked from an Android-powered device, users are +given the option to use either their web browser or the Google Play application to view the application.</p> <h3 id="PerformingSearch">Performing a search</h3> -<p>To initiate a search in Android Market, the format for the URI is:</p> +<p>To initiate a search on Google Play, the format for the URI is:</p> <p style="margin-left:2em"> <code><URI_prefix><b>search?q=</b><query></code> </p> -<p>The <code><query></code> is a placeholder for the search query to execute in Android -Market. The query can be a raw text string or you can include a parameter that performs a search +<p>The <code><query></code> is a placeholder for the search query to execute in Google +Play. The query can be a raw text string or you can include a parameter that performs a search based on the publisher name:</p> <ul> @@ -410,14 +413,14 @@ by the publisher name: <h4>Searching from your Android app</h4> -<p>To initiate a search on Android Market from your application, create an intent with the +<p>To initiate a search on Google Play 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> <p>The query may include the {@code pub:} parameter described above.</p> -<p>For example, here's how you can initiate a search in the Android Market application, based on the +<p>For example, here's how you can initiate a search in the Google Play application, based on the publisher name:</p> <pre> @@ -426,46 +429,46 @@ intent.setData(Uri.parse("market://search?q=pub:Your Publisher Name")); startActivity(intent); </pre> -<p>This opens the Android Market application to perform the search. The search result shows all +<p>This opens the Google Play 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 from a web site</h4> -<p>To initiate a search on Android Market from your web site, create a link with a URI in this +<p>To initiate a search on Google Play from your web site, create a link with a URI in this format:</p> <p style="margin-left:2em"> - <code>http://market.android.com/search?q=<query></code> + <code>http://play.google.com/store/search?q=<query></code> </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 Android Market, based on the +<p>For example, here's a link that initiates a search on Google Play, based on the publisher name:</p> <pre> -<a href="http://market.android.com/search?q=pub:Your Publisher Name">Search Link</a> +<a href="http://play.google.com/store/search?q=pub:Your Publisher Name">Search Link</a> </pre> -<p>When clicked from a desktop web browser, this opens the Android Market web site and performs the +<p>When clicked from a desktop web browser, this opens the Google Play 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> +web browser or the Google Play application to perform the search.</p> -<h3 id="BuildaButton">Build an Android Market button</h3> +<h3 id="BuildaButton">Build a Google Play button</h3> -<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>Use the following form to create a button for your web site that takes users to your application +on Google Play. Input either your application's package name or your publisher name and the button +will take users to Google Play 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 Google Play +application will respond to show users your application(s).</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> +<p>This form offers two styles of the official brand badge each at recommended sizes. You can pick +between either "Get it on Google Play" or "Android app on Google Play." You should not modify the +badge images in any way. For more usage guidelines, +see the <a href="http://www.android.com/branding.html">Android Brand Guidelines</a>.</p> <style type="text/css"> @@ -507,33 +510,44 @@ div.button-row input { // variables for creating 'try it out' demo button var imagePath = "http://www.android.com/images/brand/" -var linkStart = "<a href=\"http://market.android.com/"; +var linkStart = "<a href=\"http://play.google.com/store/"; var imageStart = "\">\n" - + " <img src=\"" + imagePath; -var imageEnd = ".png\"\n" - + " alt=\"Available in Android Market\" />\n</a>"; + + " <img alt=\""; + // leaves opening for the alt text value +var imageSrc = "\"\n src=\"" + imagePath; + // leaves opening for the image file name +var imageEnd = ".png\" />\n</a>"; // variables for creating code snippet -var linkStartCode = "<a href=\"http://market.android.com/"; +var linkStartCode = "<a href=\"http://play.google.com/store/"; var imageStartCode = "\">\n" - + " <img src=\"" + imagePath; -var imageEndCode = ".png\"\n" - + " alt=\"Available in Android Market\" />\n</a>"; + + " <img alt=\""; + // leaves opening for the alt text value +var imageSrcCode = "\"\n src=\"" + imagePath; + // leaves opening for the image file name +var imageEndCode = ".png\" />\n</a>"; /** Generate the HTML snippet and demo based on form values */ function buildButton(form) { - if (form["package"].value != "com.android.example") { + var selectedValue = $('form input[type=radio]:checked').val(); + var altText = selectedValue.indexOf("get_it") != -1 ? "Get it on Google Play" : "Android app on Google Play"; + + if (form["package"].value != "com.example.android") { $("#preview").show(); - $("#snippet").show().html(linkStartCode + "details?id=" + form["package"].value - + imageStartCode + $('form input[type=radio]:checked').val() + imageEndCode); - $("#button-preview").html(linkStart + "details?id=" + form["package"].value - + imageStart + $('form input[type=radio]:checked').val() + imageEnd); + $("#snippet").show().html(linkStartCode + "apps/details?id=" + form["package"].value + + imageStartCode + altText + imageSrcCode + + selectedValue + imageEndCode); + $("#button-preview").html(linkStart + "apps/details?id=" + form["package"].value + + imageStart + altText + imageSrc + + selectedValue + imageEnd); } else if (form["publisher"].value != "Example, Inc.") { $("#preview").show(); $("#snippet").show().html(linkStartCode + "search?q=pub:" + form["publisher"].value - + imageStartCode + $('form input[type=radio]:checked').val() + imageEndCode); - $("#button-preview").html(linkStart + "search?q=pub:" + form["publisher"].value + imageStart + - $('form input[type=radio]:checked').val() + imageEnd); + + imageStartCode + altText + imageSrcCode + + selectedValue + imageEndCode); + $("#button-preview").html(linkStart + "search?q=pub:" + form["publisher"].value + + imageStart + altText + imageSrc + + selectedValue + imageEnd); } else { alert("Please enter your package name or publisher name"); } @@ -597,13 +611,13 @@ $(document).ready(function() { <form class="button-form"> <label class="block" for="package">Package name:</label> <input class="text" type="text" id="package" name="package" - value="com.android.example" - default="com.android.example" - onfocus="onInputFocus(this, 'com.android.example')" - onblur="onInputBlur(this, 'com.android.example')" + value="com.example.android" + default="com.example.android" + onfocus="onInputFocus(this, 'com.example.android')" + onblur="onInputBlur(this, 'com.example.android')" onkeyup="return onTextEntered(event, this.parentNode, this)"/> <a id="package-clear" style="display:none" href="#" - onclick="return clearLabel('package','com.android.example');">clear</a> + onclick="return clearLabel('package','com.example.android');">clear</a> <p style="clear:both;margin:0"> <em>or</em></p> <label class="block" style="margin-top:5px" for="publisher">Publisher name:</label> <input class="text" type="text" id="publisher" name="publisher" @@ -617,23 +631,23 @@ $(document).ready(function() { <br/><br/> <div class="button-row"> - <input type="radio" name="buttonStyle" value="45_avail_market_logo1" id="ns" checked="checked" /> - <label for="ns"><img src="http://www.android.com/images/brand/45_avail_market_logo1.png" -alt="narrow and small logo" /></label> + <input type="radio" name="buttonStyle" value="get_it_on_play_logo_small" id="ns" checked="checked" /> + <label for="ns"><img src="http://www.android.com/images/brand/get_it_on_play_logo_small.png" +alt="Get it on Google Play (small)" /></label> - <input type="radio" name="buttonStyle" value="60_avail_market_logo1" id="nm" /> - <label for="nm"><img src="http://www.android.com/images/brand/60_avail_market_logo1.png" -alt="narrow and large logo" /></label> + <input type="radio" name="buttonStyle" value="get_it_on_play_logo_large" id="nm" /> + <label for="nm"><img src="http://www.android.com/images/brand/get_it_on_play_logo_large.png" +alt="Get it on Google Play (large)" /></label> </div> <div class="button-row"> - <input type="radio" name="buttonStyle" value="45_avail_market_logo2" id="ws" /> - <label for="ws"><img src="http://www.android.com/images/brand/45_avail_market_logo2.png" -alt="wide and small logo" /></label> + <input type="radio" name="buttonStyle" value="android_app_on_play_logo_small" id="ws" /> + <label for="ws"><img src="http://www.android.com/images/brand/android_app_on_play_logo_small.png" +alt="Android app on Google Play (small)" /></label> - <input type="radio" name="buttonStyle" value="60_avail_market_logo2" id="wm" /> - <label for="wm"><img src="http://www.android.com/images/brand/60_avail_market_logo2.png" -alt="wide and large logo" /></label> + <input type="radio" name="buttonStyle" value="android_app_on_play_logo_large" id="wm" /> + <label for="wm"><img src="http://www.android.com/images/brand/android_app_on_play_logo_large.png" +alt="Android app on Google Play (large)" /></label> </div> <input type="button" onclick="return buildButton(this.parentNode)" value="Build my button" @@ -643,7 +657,7 @@ style="padding:5px" /> <div id="preview" style="display:none"> <p>Copy and paste this HTML into your web site:</p> - <textarea id="snippet" cols="80" rows="4" onclick="this.select()" + <textarea id="snippet" cols="100" rows="5" onclick="this.select()" style="font-family:monospace;background-color:#efefef;padding:5px;display:none;margin-bottom:1em"> </textarea > @@ -658,7 +672,7 @@ style="font-family:monospace;background-color:#efefef;padding:5px;display:none;m <h3 id="UriSummary">Summary of URI formats</h3> -<p>The table below provides a summary of the URIs currently supported by the Android Market (both on +<p>The table below provides a summary of the URIs currently supported by the Google Play (both on the web and in the Android application), as discussed in the previous sections.</p> <table> @@ -670,19 +684,19 @@ the web and in the Android application), as discussed in the previous sections.< <tr> <td>Display the details screen for a specific application</td> -<td><code>http://market.android.com/details?id=<package_name></code> +<td><code>http://play.google.com/store/apps/details?id=<package_name></code> <td><code>market://details?id=<package_name></code></td> </tr> <tr> <td>Search for applications using a general string query.</td> -<td><code>http://market.android.com/search?q=<query></code></td> +<td><code>http://play.google.com/store/search?q=<query></code></td> <td><code>market://search?q=<query></code></td> </tr> <tr> <td>Search for applications by publisher name</td> -<td><nobr><code>http://market.android.com/search?q=pub:<publisher_name></code></nobr></td> +<td><nobr><code>http://play.google.com/store/search?q=pub:<publisher_name></code></nobr></td> <td><nobr><code>market://search?q=pub:<publisher_name></code></nobr></td> </tr> diff --git a/docs/html/guide/publishing/publishing_overview.jd b/docs/html/guide/publishing/publishing_overview.jd index 79199c5..6fb77e1 100755 --- a/docs/html/guide/publishing/publishing_overview.jd +++ b/docs/html/guide/publishing/publishing_overview.jd @@ -14,7 +14,7 @@ page.title=Publishing Overview <li><a href="#publishing-prepare">Preparing Your Application for Release</a></li> <li><a href="#publishing-release">Releasing Your Application to Users</a> <ol> - <li><a href="#publishing-market">Releasing on Android Market</a></li> + <li><a href="#publishing-market">Releasing on Google Play</a></li> <li><a href="#publishing-website">Releasing on your own website</a></li> <li><a href="#publishing-email">Releasing through email</a></li> </ol> @@ -23,7 +23,7 @@ page.title=Publishing Overview <ol> <li><a href="{@docRoot}guide/publishing/preparing.html">Preparing for Release</a></li> - <li><a href="{@docRoot}guide/publishing/publishing.html">Publishing on Android Market</a></li> + <li><a href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play</a></li> </ol> </div> </div> @@ -42,7 +42,7 @@ publish an Android application you perform two main tasks:</p> </li> </ul> -<p>Usually, you release your application through an application marketplace, such as Android Market. +<p>Usually, you release your application through an application marketplace, such as Google Play. However, you can also release applications by sending them directly to users or by letting users download them from your own website.</p> @@ -73,7 +73,7 @@ tasks:</p> <code>android:versionCode</code> and <code>android:versionName</code> attributes, which are located in the <a href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a> - element. You may also have to configure several other settings to meet Android Market + element. You may also have to configure several other settings to meet Google Play requirements or accomodate whatever method you're using to release your application.</p> </li> <li>Building and signing a release version of your application. @@ -114,27 +114,27 @@ application.</p> <h2 id="publishing-release">Releasing Your Application to Users</h2> <p>You can release your Android applications several ways. Usually, you release applications -through an application marketplace, such as Android Market, but you can also release applications -on your own website or by sending an application directly to a user. Android Market is the +through an application marketplace, such as Google Play, but you can also release applications +on your own website or by sending an application directly to a user. Google Play is the recommended marketplace for Android applications and is particularly useful if you want to distribute your applications to a large global audience. The other two release methods—server distribution and email distribution—are useful if you are releasing an application to a small group of users (for example, a work group in an enterprise environment), or if you do not want to make your application available to the general public.</p> -<h3 id="publishing-market">Releasing Your Applications on Android Market</h3> +<h3 id="publishing-market">Releasing Your Applications on Google Play</h3> -<p>Android Market is a robust publishing platform that helps you publicize, sell, and distribute +<p>Google Play is a robust publishing platform that helps you publicize, sell, and distribute your Android applications to users around the world. When you release your applications through -Android Market you have access to a suite of developer tools that let you analyze your sales, +Google Play you have access to a suite of developer tools that let you analyze your sales, identify market trends, and control who your applications are being distributed to. You also have access to several revenue-enhancing features that are not available anywhere else, such as <a href="{@docRoot}guide/market/billing/index.html">in-app billing</a> and <a -href="{@docRoot}guide/publishing/licensing.html">application licensing</a>. This rich array of tools -and features, coupled with numerous end-user community features, makes Android Market the premier +href="{@docRoot}guide/market/licensing.html">application licensing</a>. This rich array of tools +and features, coupled with numerous end-user community features, makes Google Play the premier marketplace for selling and buying Android applications.</p> -<p>Releasing your application on Android Market is a simple process that involves three basic +<p>Releasing your application on Google Play is a simple process that involves three basic steps:</p> <div class="figure" style="width:275px"> @@ -143,19 +143,19 @@ marketplace for selling and buying Android applications.</p> to be installed" /> <p class="img-caption"> <strong>Figure 2.</strong> The <strong>Unknown sources</strong> setting lets you install - applications that are not published on Android Market . + applications that are not published on Google Play . </p> </div> <ul> <li>Preparing promotional materials. - <p>To fully leverage the marketing and publicity capabilities of Android Market, you need to + <p>To fully leverage the marketing and publicity capabilities of Google Play, you need to create promotional materials for your application, such as screenshots, videos, graphics, and promotional text.</p> </li> <li>Configuring options and uploading assets. - <p>Android Market lets you target your application to a worldwide pool of users and devices. - By configuring various Android Market settings, you can choose the countries you want to + <p>Google Play lets you target your application to a worldwide pool of users and devices. + By configuring various Google Play settings, you can choose the countries you want to reach, the listing languages you want to use, and the price you want to charge in each country. You can also configure listing details such as the application type, category, and content rating. When you are done configuring options you can upload your promotional materials @@ -169,21 +169,21 @@ marketplace for selling and buying Android applications.</p> </li> </ul> -<p>For information about Android Market, see <a -href="{@docRoot}guide/publishing/publishing.html#market">Publishing on Android Market</a>. This -topic provides an introduction to Android Market features and provides a step-by-step guide for -distributing your applications on Android Market.</p> +<p>For information about Google Play, see <a +href="{@docRoot}guide/publishing/publishing.html#market">Publishing on Google Play</a>. This +topic provides an introduction to Google Play features and provides a step-by-step guide for +distributing your applications on Google Play.</p> <h3 id="publishing-website">Releasing your application on your own website</h3> -<p>If you do not want to release your application on an application marketplace like Android Market, +<p>If you do not want to release your application on an application marketplace like Google Play, you can release your application by making it available for download on your own website or server. To do this, you must first prepare your application for release (that is, you must build it for release and sign it). Then all you need to do is host the release-ready application on your website and provide a download link for the application. When users browse to your website with their Android-powered devices and download your application, the Android system will automatically start installing the application on the device. However, the installation process will start automatically -only if the user has configured their device to allow the installation of non-Android Market +only if the user has configured their device to allow the installation of non-Google Play applications.</p> <div class="figure" style="width:275px"> @@ -197,7 +197,7 @@ applications.</p> </div> <p>By default, Android-powered devices allow users to install applications only if the applications -have been downloaded from Android Market. To allow the installation of applications from other +have been downloaded from Google Play. To allow the installation of applications from other sources, users need to enable the <strong>Unknown sources</strong> setting on their devices, and they need to make this configuration change before they download your application to their device (see figure 2).</p> @@ -208,7 +208,7 @@ applications from unknown sources.</p> <p>Although it is relatively easy to release your application on your own website, it can be inefficient and cumbersome. For example, if you want to monetize your application you will have to process and track all financial transactions yourself and you will not be able to use -Android Market's in-app billing feature to sell in-app products. In addition, you will not be +Google Play's in-app billing feature to sell in-app products. In addition, you will not be able to use the licensing feature to help prevent unauthorized installation and use of your application.</p> @@ -222,7 +222,7 @@ button in the email message (see figure 3). Users can install your application b button.</p> <p class="note"><strong>Note:</strong> The <strong>Install Now</strong> button appears only if a -user has configured their device to allow the installation of non-Android Market applications and +user has configured their device to allow the installation of non-Google Play applications and they open your email with the native Gmail application.</p> <p>Releasing applications through email is convenient if you are sending your application to diff --git a/docs/html/guide/publishing/versioning.jd b/docs/html/guide/publishing/versioning.jd index 79ebf96..da57e3e 100644 --- a/docs/html/guide/publishing/versioning.jd +++ b/docs/html/guide/publishing/versioning.jd @@ -25,7 +25,7 @@ page.title=Versioning Your Applications <ol> <li><a href="{@docRoot}guide/publishing/preparing.html">Preparing to Publish Your Application</a></li> -<li><a href="{@docRoot}guide/publishing/publishing.html#market">Publishing On Android Market</a></li> +<li><a href="{@docRoot}guide/publishing/publishing.html#market">Publishing On Google Play</a></li> <li><a href="{@docRoot}guide/topics/manifest/manifest-intro.html">The AndroidManifest.xml File</a></li> </ol> diff --git a/docs/html/guide/topics/admin/device-admin.jd b/docs/html/guide/topics/admin/device-admin.jd index 820c3c0..4a325db 100644 --- a/docs/html/guide/topics/admin/device-admin.jd +++ b/docs/html/guide/topics/admin/device-admin.jd @@ -75,8 +75,8 @@ server. </li> not currently have an automated provisioning solution. Some of the ways a sysadmin might distribute the application to users are as follows: <ul> -<li>Android Market.</li> -<li>Enabling non-market installation.</li> +<li>Google Play.</li> +<li>Enabling installation from another store.</li> <li>Distributing the application through other means, such as email or websites.</li> </ul> diff --git a/docs/html/guide/topics/data/backup.jd b/docs/html/guide/topics/data/backup.jd index 79dfd88..d91e422 100644 --- a/docs/html/guide/topics/data/backup.jd +++ b/docs/html/guide/topics/data/backup.jd @@ -892,8 +892,8 @@ href="{@docRoot}guide/developing/tools/bmgr.html">{@code bmgr}</a>.</p> <li>Install your application on a suitable Android system image <ul> <li>If using the emulator, create and use an AVD with Android 2.2 (API Level 8).</li> - <li>If using a device, the device must be running Android 2.2 or greater and have Android -Market built in.</li> + <li>If using a device, the device must be running Android 2.2 or greater and have Google +Play built in.</li> </ul> </li> <li>Ensure that backup is enabled diff --git a/docs/html/guide/topics/fundamentals.jd b/docs/html/guide/topics/fundamentals.jd index d1a3786..a86d905 100644 --- a/docs/html/guide/topics/fundamentals.jd +++ b/docs/html/guide/topics/fundamentals.jd @@ -392,13 +392,13 @@ same features and capabilities. In order to prevent your application from being that lack features needed by your application, it's important that you clearly define a profile for the types of devices your application supports by declaring device and software requirements in your manifest file. Most of these declarations are informational only and the system does not read -them, but external services such as Android Market do read them in order to provide filtering +them, but external services such as Google Play do read them in order to provide filtering for users when they search for applications from their device.</p> <p>For example, if your application requires a camera and uses APIs introduced in Android 2.1 (<a href="{@docRoot}guide/appendix/api-levels.html">API Level</a> 7), you should declare these as requirements in your manifest file. That way, devices that do <em>not</em> have a camera and have an -Android version <em>lower</em> than 2.1 cannot install your application from Android Market.</p> +Android version <em>lower</em> than 2.1 cannot install your application from Google Play.</p> <p>However, you can also declare that your application uses the camera, but does not <em>require</em> it. In that case, your application must perform a check at runtime to determine @@ -458,12 +458,12 @@ element.</dd> </dl> <p>It's important that you declare all such requirements for your application, because, when you -distribute your application on Android Market, Market uses these declarations to filter which +distribute your application on Google Play, the store uses these declarations to filter which applications are available on each device. As such, your application should be available only to devices that meet all your application requirements.</p> -<p>For more information about how Android Market filters applications based on these (and other) -requirements, see the <a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a> +<p>For more information about how Google Play filters applications based on these (and other) +requirements, see the <a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> document.</p> diff --git a/docs/html/guide/topics/fundamentals/activities.jd b/docs/html/guide/topics/fundamentals/activities.jd index 8736aa8..b79136c 100644 --- a/docs/html/guide/topics/fundamentals/activities.jd +++ b/docs/html/guide/topics/fundamentals/activities.jd @@ -62,7 +62,7 @@ is presented to the user when launching the application for the first time. Each activity can then start another activity in order to perform different actions. Each time a new activity starts, the previous activity is stopped, but the system preserves the activity in a stack (the "back stack"). When a new activity starts, it is pushed onto the back stack and -takes user focus. The back stack abides to the basic "last in, first out" queue mechanism, +takes user focus. The back stack abides to the basic "last in, first out" stack mechanism, so, when the user is done with the current activity and presses the <em>Back</em> button, it is popped from the stack (and destroyed) and the previous activity resumes. (The back stack is discussed more in the <a href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks diff --git a/docs/html/guide/topics/fundamentals/fragments.jd b/docs/html/guide/topics/fundamentals/fragments.jd index 281cb9d..2a22394 100644 --- a/docs/html/guide/topics/fundamentals/fragments.jd +++ b/docs/html/guide/topics/fundamentals/fragments.jd @@ -129,7 +129,7 @@ handset design.</p> <p>For example—to continue with the news application example—the application can embed two fragments in <em>Activity A</em>, when running on a tablet-sized device. However, on a -handset-sized screen, there's not be enough room for both fragments, so <em>Activity A</em> includes +handset-sized screen, there's not enough room for both fragments, so <em>Activity A</em> includes only the fragment for the list of articles, and when the user selects an article, it starts <em>Activity B</em>, which includes the second fragment to read the article. Thus, the application supports both tablets and handsets by reusing fragments in different combinations, as illustrated in diff --git a/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd b/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd index 465cf54..0880614 100644 --- a/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd +++ b/docs/html/guide/topics/fundamentals/tasks-and-back-stack.jd @@ -154,7 +154,7 @@ See the following section about <a href="#ActivityState">Activity state</a>.</p> <p>Because the activities in the back stack are never rearranged, if your application allows users to start a particular activity from more than one activity, a new instance of -that activity is created and popped onto the stack (rather than bringing any previous instance of +that activity is created and pushed onto the stack (rather than bringing any previous instance of the activity to the top). As such, one activity in your application might be instantiated multiple times (even from different tasks), as shown in figure 3. As such, if the user navigates backward using the <em>Back</em> button, each instance of the activity is revealed in the order they were @@ -291,7 +291,7 @@ B should associate with current task. If both activities define how Activity B should associate with a task, then Activity A's request (as defined in the intent) is honored over Activity B's request (as defined in its manifest).</p> -<p class="note"><strong>Note:</strong> Some the launch modes available in the manifest +<p class="note"><strong>Note:</strong> Some launch modes available for the manifest file are not available as flags for an intent and, likewise, some launch modes available as flags for an intent cannot be defined in the manifest.</p> diff --git a/docs/html/guide/topics/graphics/hardware-accel.jd b/docs/html/guide/topics/graphics/hardware-accel.jd index 39ccbf4..04fb564 100644 --- a/docs/html/guide/topics/graphics/hardware-accel.jd +++ b/docs/html/guide/topics/graphics/hardware-accel.jd @@ -42,19 +42,20 @@ parent.link=index.html <li><a href="{@docRoot}guide/topics/graphics/opengl.html">OpenGL with the Framework APIs</a></li> - <li><a href="{@docRoot}guide/topics/renderscript/index.html">RenderScript</a></li> + <li><a href="{@docRoot}guide/topics/renderscript/index.html">Renderscript</a></li> </ol> </div> </div> <p>Beginning in Android 3.0 (API level 11), the Android 2D rendering pipeline is designed to better support hardware acceleration. Hardware acceleration carries out all drawing operations - that are performed on a {@link android.view.View}'s canvas using the GPU.</p> + that are performed on a {@link android.view.View}'s canvas using the GPU. Because of the + increased resources required to enable hardware acceleration, your app will consume more RAM.</p> <p>The easiest way to enable hardware acceleration is to turn it on globally for your entire application. If your application uses only standard views and {@link android.graphics.drawable.Drawable}s, turning it on globally should not cause any adverse - effects. However, because hardware acceleration is not supported for all of the 2D drawing + drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your applications that use custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels. To remedy this, Android gives you the option to enable or disable hardware diff --git a/docs/html/guide/topics/graphics/opengl.jd b/docs/html/guide/topics/graphics/opengl.jd index 6a2a20f..a786d42 100644 --- a/docs/html/guide/topics/graphics/opengl.jd +++ b/docs/html/guide/topics/graphics/opengl.jd @@ -189,7 +189,7 @@ shown below. <uses-feature android:glEsVersion="0x00020000" android:required="true" /> </pre> - <p>Adding this declaration causes the Android Market to restrict your application from being + <p>Adding this declaration causes Google Play to restrict your application from being installed on devices that do not support OpenGL ES 2.0.</p> </li> <li><strong>Texture compression requirements</strong> - If your application uses texture @@ -200,9 +200,9 @@ formats, see <a href="#textures">Texture compression support</a>. <p>Declaring texture compression requirements in your manifest hides your application from users with devices that do not support at least one of your declared compression types. For more -information on how Android Market filtering works for texture compressions, see the <a +information on how Google Play filtering works for texture compressions, see the <a href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html#market-texture-filtering"> -Android Market and texture compression filtering</a> section of the {@code +Google Play and texture compression filtering</a> section of the {@code <supports-gl-texture>} documentation.</p> </li> </ul> @@ -470,7 +470,7 @@ the next section. <p class="note"><strong>Note:</strong> Once you decide which texture compression formats your application will support, make sure you declare them in your manifest using <a href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html"><supports-gl-texture> -</a>. Using this declaration enables filtering by external services such as Android Market, so that +</a>. Using this declaration enables filtering by external services such as Google Play, so that your app is installed only on devices that support the formats your app requires. For details, see <a href="{@docRoot}guide/topics/graphics/opengl.html#manifest">OpenGL manifest declarations</a>.</p> diff --git a/docs/html/guide/topics/location/index.jd b/docs/html/guide/topics/location/index.jd index 5f98902..8a2e9cd 100644 --- a/docs/html/guide/topics/location/index.jd +++ b/docs/html/guide/topics/location/index.jd @@ -98,7 +98,7 @@ Google APIs add-on, visit</p> href="http://code.google.com/android/add-ons/google-apis">http://code.google.com/android/add-ons/google-apis</a></p> <p>For your convenience, the Google APIs add-on is also available as a downloadable component from -the Android SDK and AVD Manager (see <a href="{@docRoot}sdk/adding-components.html">Adding SDK +the Android SDK Manager (see <a href="{@docRoot}sdk/adding-components.html">Adding SDK Components</a>).</p> <p class="note"><strong>Note:</strong> In order to display Google Maps data in a diff --git a/docs/html/guide/topics/manifest/activity-element.jd b/docs/html/guide/topics/manifest/activity-element.jd index f44901b..9dc124b 100644 --- a/docs/html/guide/topics/manifest/activity-element.jd +++ b/docs/html/guide/topics/manifest/activity-element.jd @@ -307,7 +307,7 @@ attribute). <dd>Whether or not an existing instance of the activity should be shut down (finished) whenever the user again launches its task (chooses the task on the home screen) — "{@code true}" if it should be shut down, and "{@code false}" -if not. The default value is "{@code false}". +if not. The default value is "{@code false}". <p> If this attribute and @@ -321,13 +321,15 @@ activity is ignored. The activity is not re-parented, but destroyed. Activity — "{@code true}" if it should be enabled, and "{@code false}" if not. The default value is "{@code false}". + <p>Starting from Android 3.0, a hardware-accelerated OpenGL renderer is available to applications, to improve performance for many common 2D graphics operations. When the hardware-accelerated renderer is enabled, most operations in Canvas, Paint, Xfermode, ColorFilter, Shader, and Camera are accelerated. This results in smoother animations, smoother scrolling, and improved responsiveness overall, even for applications that do not explicitly make use -the framework's OpenGL libraries. </p> +the framework's OpenGL libraries. Because of the increased resources required to +enable hardware acceleration, your app will consume more RAM.</p> <p>Note that not all of the OpenGL 2D operations are accelerated. If you enable the hardware-accelerated renderer, test your application to ensure that it can @@ -587,9 +589,9 @@ Permissions</a>. </p></dd> <dt><a name="proc"></a>{@code android:process}</dt> -<dd>The name of the process in which the activity should run. Normally, +<dd>The name of the process in which the activity should run. Normally, all components of an application run in the default process created for the -application. It has the same name as the application package. The <code><a href="{@docRoot}guide/topics/manifest/application-element.html"><application></a></code> element's +application. It has the same name as the application package. The <code><a href="{@docRoot}guide/topics/manifest/application-element.html"><application></a></code> element's <code><a href="{@docRoot}guide/topics/manifest/application-element.html#proc">process</a></code> attribute can set a different default for all components. But each component can override the default, allowing you to spread your application across @@ -670,7 +672,7 @@ unspecified}" setting.</td> <p class="note"><strong>Note:</strong> When you declare one of the landscape or portrait values, it is considered a hard requirement for the orientation in which the activity runs. As such, -the value you declare enables filtering by services such as Android Market so your application is +the value you declare enables filtering by services such as Google Play so your application is available only to devices that support the orientation required by your activities. For example, if you declare either {@code "landscape"}, {@code "reverseLandscape"}, or {@code "sensorLandscape"}, then your application will be available only to devices that support @@ -679,7 +681,7 @@ your application requires either portrait or landscape orientation with the <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code <uses-feature>}</a> element. For example, <code><uses-feature android:name="android.hardware.screen.portrait"/></code>. This is purely a filtering behavior -provided by Android Market (and other services that support it) and the platform itself does not +provided by Google Play (and other services that support it) and the platform itself does not control whether your app can be installed when a device supports only certain orientations.</p> </dd> @@ -706,7 +708,7 @@ activity started for the first time. A "{@code true}" setting ensures that the activity can be restarted in the absence of retained state. For example, the activity that displays the home screen uses this setting to make sure that it does not get removed if it -crashes for some reason. +crashes for some reason. </p></dd> <dt><a name="aff"></a>{@code android:taskAffinity}</dt> diff --git a/docs/html/guide/topics/manifest/compatible-screens-element.jd b/docs/html/guide/topics/manifest/compatible-screens-element.jd index 5c89869..a27c316 100644 --- a/docs/html/guide/topics/manifest/compatible-screens-element.jd +++ b/docs/html/guide/topics/manifest/compatible-screens-element.jd @@ -27,10 +27,10 @@ specifies a specific screen size-density combination with which the application <p>The Android system <em>does not</em> read the {@code <compatible-screens>} manifest element (neither at install-time nor at runtime). This element is informational only and may be used -by external services (such as Android Market) to better understand the application's compatibility +by external services (such as Google Play) to better understand the application's compatibility with specific screen configurations and enable filtering for users. Any screen configuration that is <em>not</em> declared in this element is a screen with which the application is <em>not</em> -compatible. Thus, external services (such as Android Market) should not provide the application to +compatible. Thus, external services (such as Google Play) should not provide the application to devices with such screens.</p> <p class="caution"><strong>Caution:</strong> Normally, <strong>you should not use this manifest @@ -48,14 +48,14 @@ should use the <a href="{@docRoot}guide/topics/manifest/supports-screens-element only for <em>large</em> and <em>xlarge</em> screen devices, the <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>}</a> element allows you to declare that your application does not -support <em>small</em> and <em>normal</em> screen sizes. External services (such as Android -Market) will filter your application accordingly. You can also use the <a +support <em>small</em> and <em>normal</em> screen sizes. External services (such as Google +Play) will filter your application accordingly. You can also use the <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>}</a> element to declare whether the system should resize your application for different screen sizes.</p> - <p>Also see the <a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a> -document for more information about how Android Market filters applications using this and + <p>Also see the <a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> +document for more information about how Google Play filters applications using this and other manifest elements.</p> </dd> @@ -138,5 +138,5 @@ entry looks like if your application is compatible with only small and normal sc <dt>see also:</dt> <dd><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></dd> -<dd><a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a></dd> +<dd><a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a></dd> </dl> diff --git a/docs/html/guide/topics/manifest/manifest-element.jd b/docs/html/guide/topics/manifest/manifest-element.jd index d737a67..98968d7 100644 --- a/docs/html/guide/topics/manifest/manifest-element.jd +++ b/docs/html/guide/topics/manifest/manifest-element.jd @@ -37,7 +37,7 @@ parent.link=manifest-intro.html <dt>description:</dt> <dd>The root element of the AndroidManifest.xml file. It must contain an <code><a href="{@docRoot}guide/topics/manifest/application-element.html"><application></a></code> element -and specify {@code xlmns:android} and {@code package} attributes.</dd> +and specify {@code xmlns:android} and {@code package} attributes.</dd> <dt>attributes:</dt> <dd> @@ -150,9 +150,9 @@ either internal or external storage through the system settings.</td> </tr> </table> -<p class="caution"><strong>Caution:</strong> If your application uses the Android Market's Copy - Protection feature, it cannot be installed to a device's SD card. However, if you use Android - Market's <a href="{@docRoot}guide/publishing/licensing.html">Application Licensing</a> instead, +<p class="caution"><strong>Caution:</strong> If your application uses Google Play's Copy + Protection feature, it cannot be installed to a device's SD card. However, if you use Google + Play's <a href="{@docRoot}guide/market/licensing.html">Application Licensing</a> instead, your application <em>can</em> be installed to internal or external storage, including SD cards.</p> <p class="note"><strong>Note:</strong> By default, your application will be installed on the diff --git a/docs/html/guide/topics/manifest/supports-gl-texture-element.jd b/docs/html/guide/topics/manifest/supports-gl-texture-element.jd index 6c4a05a..ebdd0b1 100644 --- a/docs/html/guide/topics/manifest/supports-gl-texture-element.jd +++ b/docs/html/guide/topics/manifest/supports-gl-texture-element.jd @@ -18,20 +18,20 @@ parent.link=manifest-intro.html <div class="sidebox-wrapper"> <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> <div id="qv-sub-rule"> - <img src="{@docRoot}assets/images/icon_market.jpg" + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> - <p style="color:#669999;">Android Market and <code + <p style="color:#669999;padding-top:1em;">Google Play and <code style="color:#669999;"><supports-gl-texture></code> elements</p> - <p style="margin-top:1em;">Android Market filters applications according + <p style="margin-top:1em;">Google Play filters applications according to the texture compression formats that they support, to ensure that they can be installed only on devices that can handle their textures properly. Developers can use texture compression filtering as a way of targeting specific device types, based on GPU platform.</p> <p style="margin-top:1em;" class="caution">For important information about how - Android Market uses <code><supports-gl-texture></code> elements as - the basis for filtering, please read <a href="#market-texture-filtering">Android - Market and texture compression filtering</a>, below.</p> + Google Play uses <code><supports-gl-texture></code> elements as + the basis for filtering, please read <a href="#market-texture-filtering">Google + Play and texture compression filtering</a>, below.</p> </div> </div> @@ -57,7 +57,7 @@ texture compression formats, you can declare multiple <p>Declared <code><supports-gl-texture></code> elements are informational, meaning that the Android system itself does not examine the elements at install time to ensure matching support on the device. However, other services -(such as Android Market) or applications can check your application's +(such as Google Play) or applications can check your application's <code><supports-gl-texture></code> declarations as part of handling or interacting with your application. For this reason, it's very important that you declare all of the texture compression formats (from the list below) that @@ -141,20 +141,20 @@ and others.</td> <dt>see also:</dt> <dd> <ul> - <li><a href="{@docRoot}guide/appendix/market-filters.html">Android Market Filters</a></li> + <li><a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a></li> </ul> </dd> -<h2 id="market-texture-filtering">Android Market and texture compression filtering</h2> +<h2 id="market-texture-filtering">Google Play and texture compression filtering</h2> -<p>Android Market filters the applications that are visible to users, so that +<p>Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with -their devices. One of the ways Market filters applications is by texture +their devices. One of the ways it filters applications is by texture compression compatibility, giving you control over the availability of your application to various devices, based on the capabilities of their GPUs.</p> <p>To determine an application's texture compression compatibility with a given -user's device, Android Market compares:</p> +user's device, Google Play compares:</p> <ul> <li>Texture compression formats that are supported by the application — @@ -164,26 +164,26 @@ an application declares its supported texture compression formats in a device reports the formats it supports as read-only system properties.</li> </ul> -<p>Each time you upload an application to the Android Market Publisher Site, -Android Market scans the application's manifest file and looks for any +<p>Each time you upload an application to the Google Play publisher site, +Google Play scans the application's manifest file and looks for any <code><supports-gl-texture></code> elements. It extracts the format descriptors from the elements and stores them internally as metadata associated with the application <code>.apk</code> and the application version. </p> -<p>When a user searches or browses for applications on Android Market, +<p>When a user searches or browses for applications on Google Play, the service compares the texture compression formats supported by the application with those supported by the user's device. The comparison is based on the format descriptor strings and a match must be exact.</p> <p>If <em>any</em> of an application's supported texture compression formats is -also supported by the device, Android Market allows the user to see the +also supported by the device, Google Play allows the user to see the application and potentially download it. Otherwise, if none of the application's -formats is supported by the device, Android Market filters the application so +formats is supported by the device, Google Play filters the application so that it is not available for download. </p> <p>If an application does not declare any <code><supports-gl-texture></code> elements, -Android Market does not apply any filtering based on GL texture compression format.</p> +Google Play does not apply any filtering based on GL texture compression format.</p> </dl> diff --git a/docs/html/guide/topics/manifest/supports-screens-element.jd b/docs/html/guide/topics/manifest/supports-screens-element.jd index 81d6e27..ae14121 100644 --- a/docs/html/guide/topics/manifest/supports-screens-element.jd +++ b/docs/html/guide/topics/manifest/supports-screens-element.jd @@ -80,7 +80,7 @@ should not use it.</p> 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 + small screen devices from external services (such as Google Play), 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> @@ -156,8 +156,8 @@ smallest screen width qualifier</a> ({@code sw<N>dp}).</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 +to enable filtering for your application on services such as Google Play. However, +<strong>Google Play 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> diff --git a/docs/html/guide/topics/manifest/uses-feature-element.jd b/docs/html/guide/topics/manifest/uses-feature-element.jd index 9f80638..5f0a501 100644 --- a/docs/html/guide/topics/manifest/uses-feature-element.jd +++ b/docs/html/guide/topics/manifest/uses-feature-element.jd @@ -9,7 +9,7 @@ parent.link=manifest-intro.html <h2>In this document</h2> <ol> - <li><a href="#market-feature-filtering">Android Market and Feature-Based Filtering</a> + <li><a href="#market-feature-filtering">Google Play and Feature-Based Filtering</a> <ol> <li><a href="#declared">Filtering based on explicitly declared features</a></li> <li><a href="#implicit">Filtering based on implicit features</a></li> @@ -45,26 +45,26 @@ href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a <div class="sidebox-wrapper"> <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;">Android Market and <code style="color:#669999;"><uses-feature></code> elements</p> - <p style="margin-top:1em;">Android Market filters the applications that are visible to users, so + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> + <p style="color:#669999;padding-top:1em;">Google Play and <code style="color:#669999;"><uses-feature></code> elements</p> + <p style="margin-top:1em;">Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with their -devices. One of the ways Market filters applications is by feature compatibility.</p> +devices. One of the ways it filters applications is by feature compatibility.</p> -<p style="margin-top:1em;">To do this, Market checks the +<p style="margin-top:1em;">To do this, Google Play checks the <code><uses-feature></code> elements in each application's manifest, to -establish the app's feature needs. Market then shows or hides the application to +establish the app's feature needs. Google Play then shows or hides the application to each user, based on a comparison with the features available on the user's device. </p> <p style="margin-top:1em;">By specifying the features that your application requires, -you enable Android Market to present your application only to users whose +you enable Google Play to present your application only to users whose devices meet the application's feature requirements, rather than presenting it to all users. </p> <p style="margin-top:1em;" class="caution">For important information about how -Android Market uses features as the basis for filtering, please read <a -href="#market-feature-filtering">Android Market and Feature-Based Filtering</a>, +Google Play uses features as the basis for filtering, please read <a +href="#market-feature-filtering">Google Play and Feature-Based Filtering</a>, below.</p> </div> </div> @@ -106,7 +106,7 @@ application requires.</p> <p>Declared <code><uses-feature></code> elements are informational only, meaning that the Android system itself does not check for matching feature support on the device before installing an application. However, other services -(such as Android Market) or applications may check your application's +(such as Google Play) or applications may check your application's <code><uses-feature></code> declarations as part of handling or interacting with your application. For this reason, it's very important that you declare all of the features (from the list below) that your application uses. </p> @@ -207,22 +207,22 @@ can check at run-time whether a higher level of OpenGL ES is available.)</p> <li>{@link android.content.pm.FeatureInfo}</li> <li>{@link android.content.pm.ConfigurationInfo}</li> <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><code><uses-permission></code></a></li> - <li><a href="{@docRoot}guide/appendix/market-filters.html">Android Market Filters</a></li> + <li><a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a></li> </ul> </dd> </dl> -<h2 id="market-feature-filtering">Android Market and Feature-Based Filtering</h2> +<h2 id="market-feature-filtering">Google Play and Feature-Based Filtering</h2> -<p>Android Market filters the applications that are visible to users, so that +<p>Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with -their devices. One of the ways Market filters applications is by feature +their devices. One of the ways it filters applications is by feature compatibility.</p> <p>To determine an application's feature compatibility with a given user's -device, the Android Market service compares:</p> +device, Google Play compares:</p> <ul> <li>Features required by the application — an application declares features in @@ -238,14 +238,14 @@ are listed in the <a href="#features-reference">Features Reference</a> tables at the bottom of this document, and in the class documentation for {@link android.content.pm.PackageManager}.</p> -<p>When the user launches the Market application, the application queries the +<p>When the user launches Google Play, the application queries the Package Manager for the list of features available on the device by calling {@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The -Market application then passes the features list up to the Android Market -service when establishing the session for the user.</p> +Store application then passes the features list up to Google Play +when establishing the session for the user.</p> -<p>Each time you upload an application to the Android Market Publisher Site, -Android Market scans the application's manifest file. It looks for +<p>Each time you upload an application to the Google Play publisher site, +Google Play scans the application's manifest file. It looks for <code><uses-feature></code> elements and evaluates them in combination with other elements, in some cases, such as <code><uses-sdk></code> and <code><uses-permission></code> elements. After establishing the @@ -253,17 +253,17 @@ application's set of required features, it stores that list internally as metadata associated with the application <code>.apk</code> and the application version. </p> -<p>When a user searches or browses for applications using the Android Market +<p>When a user searches or browses for applications using the Google Play application, the service compares the features needed by each application with the features available on the user's device. If all of an application's required -features are present on the device, Android Market allows the user to see the +features are present on the device, Google Play allows the user to see the application and potentially download it. If any required feature is not -supported by the device, Android Market filters the application so that it is +supported by the device, Google Play filters the application so that it is not visible to the user and not available for download. </p> <p>Because the features you declare in <code><uses-feature></code> -elements directly affect how Android Market filters your application, it's -important to understand how Android Market evaluates the application's manifest +elements directly affect how Google Play filters your application, it's +important to understand how Google Play evaluates the application's manifest and establishes the set of required features. The sections below provide more information. </p> @@ -277,35 +277,35 @@ application absolutely requires the feature and cannot function properly without it (<code>"true"</code>), or whether the application prefers to use the feature if available, but is designed to run without it (<code>"false"</code>).</p> -<p>Android Market handles explicitly declared features in this way: </p> +<p>Google Play handles explicitly declared features in this way: </p> <ul> -<li>If a feature is explicitly declared as being required, Android Market adds +<li>If a feature is explicitly declared as being required, Google Play adds the feature to the list of required features for the application. It then filters the application from users on devices that do not provide that feature. For example: <pre><uses-feature android:name="android.hardware.camera" android:required="true" /></pre></li> -<li>If a feature is explicitly declared as <em>not</em> being required, Android -Market <em>does not</em> add the feature to the list of required features. For +<li>If a feature is explicitly declared as <em>not</em> being required, Google +Play <em>does not</em> add the feature to the list of required features. For that reason, an explicitly declared non-required feature is never considered when filtering the application. Even if the device does not provide the declared -feature, Android Market will still consider the application compatible with the +feature, Google Play will still consider the application compatible with the device and will show it to the user, unless other filtering rules apply. For example: <pre><uses-feature android:name="android.hardware.camera" android:required="false" /></pre></li> <li>If a feature is explicitly declared, but without an -<code>android:required</code> attribute, Android Market assumes that the feature +<code>android:required</code> attribute, Google Play assumes that the feature is required and sets up filtering on it. </li> </ul> <p>In general, if your application is designed to run on Android 1.6 and earlier versions, the <code>android:required</code> attribute is not available in the -API and Android Market assumes that any and all +API and Google Play assumes that any and all <code><uses-feature></code> declarations are required. </p> <p class="note"><strong>Note:</strong> By declaring a feature explicitly and including an <code>android:required="false"</code> attribute, you can -effectively disable all filtering on Android Market for the specified feature. +effectively disable all filtering on Google Play for the specified feature. </p> @@ -317,7 +317,7 @@ function properly, but which is <em>not</em> declared in a speaking, every application should <em>always</em> declare all features that it uses or requires, so the absence of a declaration for a feature used by an application should be considered an error. However, as a safeguard for users and -developers, Android Market looks for implicit features in each application and +developers, Google Play looks for implicit features in each application and sets up filters for those features, just as it would do for an explicitly declared feature. </p> @@ -337,25 +337,25 @@ element name or an unrecognized string value for the </li> </ul> -<p>To account for the cases above, Android Market attempts to discover an +<p>To account for the cases above, Google Play attempts to discover an application's implied feature requirements by examining <em>other elements</em> declared in the manifest file, specifically, <code><uses-permission></code> elements.</p> -<p>If an application requests hardware-related permissions, Android Market +<p>If an application requests hardware-related permissions, Google Play <em>assumes that the application uses the underlying hardware features and therefore requires those features</em>, even though there might be no corresponding to <code><uses-feature></code> declarations. For such -permissions, Android Market adds the underlying hardware features to the +permissions, Google Play adds the underlying hardware features to the metadata that it stores for the application and sets up filters for them.</p> <p>For example, if an application requests the <code>CAMERA</code> permission but does not declare a <code><uses-feature></code> element for -<code>android.hardware.camera</code>, Android Market considers that the +<code>android.hardware.camera</code>, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.</p> -<p>If you don't want Android Market to filter based on a specific implied +<p>If you don't want Google Play to filter based on a specific implied feature, you can disable that behavior. To do so, declare the feature explicitly in a <code><uses-feature></code> element and include an <code>android:required="false"</code> attribute. For example, to disable @@ -366,30 +366,30 @@ the feature as shown below.</p> <p class="caution">It's important to understand that the permissions that you request in <code><uses-permission></code> elements can directly affect how -Android Market filters your application. The reference section <a +Google Play filters your application. The reference section <a href="#permissions">Permissions that Imply Feature Requirements</a>, below, lists the full set of permissions that imply feature requirements and therefore trigger filtering.</p> <h3 id="bt-permission-handling">Special handling for Bluetooth feature</h3> -<p>Android Market applies slightly different rules than described above, when +<p>Google Play applies slightly different rules than described above, when determining filtering for Bluetooth.</p> <p>If an application declares a Bluetooth permission in a <code><uses-permission></code> element, but does not explicitly declare -the Bluetooth feature in a <code><uses-feature></code> element, Android -Market checks the version(s) of the Android platform on which the application is +the Bluetooth feature in a <code><uses-feature></code> element, Google +Play checks the version(s) of the Android platform on which the application is designed to run, as specified in the <code><uses-sdk></code> element. </p> -<p>As shown in the table below, Android Market enables filtering for the +<p>As shown in the table below, Google Play enables filtering for the Bluetooth feature only if the application declares its lowest or targeted -platform as Android 2.0 (API level 5) or higher. However, note that Android -market applies the normal rules for filtering when the application explicitly +platform as Android 2.0 (API level 5) or higher. However, note that Google +Play applies the normal rules for filtering when the application explicitly declares the Bluetooth feature in a <code><uses-feature></code> element. </p> -<p class="caption"><strong>Table 1.</strong> How Android Market determines the +<p class="caption"><strong>Table 1.</strong> How Google Play determines the Bluetooth feature requirement for an application that requests a Bluetooth permission but does not declare the Bluetooth feature in a <code><uses-feature></code> element.</p> @@ -403,14 +403,14 @@ permission but does not declare the Bluetooth feature in a <tr> <td><nobr><=4 (or uses-sdk is not declared)</nobr></td> <td><=4</td> -<td>Android Market <em>will not</em> filter the application from any devices +<td>Google Play <em>will not</em> filter the application from any devices based on their reported support for the <code>android.hardware.bluetooth</code> feature.</td> </tr> <tr> <td><=4</td> <td>>=5</td> -<td rowspan="2">Android Market filters the application from any devices that +<td rowspan="2">Google Play filters the application from any devices that do not support the <code>android.hardware.bluetooth</code> feature (including older releases).</td> </tr> @@ -421,13 +421,13 @@ older releases).</td> </table> <p>The examples below illustrate the different filtering effects, based on how -Android Market handles the Bluetooth feature. </p> +Google Play handles the Bluetooth feature. </p> <dl> <dt>In first example, an application that is designed to run on older API levels declares a Bluetooth permission, but does not declare the Bluetooth feature in a <code><uses-feature></code> element.</dt> -<dd><em>Result:</em> Android Market does not filter the application from any device.</dd> +<dd><em>Result:</em> Google Play does not filter the application from any device.</dd> </dl> <pre><manifest ...> @@ -439,7 +439,7 @@ declares a Bluetooth permission, but does not declare the Bluetooth feature in a <dl> <dt>In the second example, below, the same application also declares a target API level of "5". </dt> -<dd><em>Result:</em> Android Market now assumes that the feature is required and +<dd><em>Result:</em> Google Play now assumes that the feature is required and will filter the application from all devices that do not report Bluetooth support, including devices running older versions of the platform. </dd> </dl> @@ -465,7 +465,7 @@ including devices running older versions of the platform. </dd> <dl> <dt>Finally, in the case below, the same application adds an <code>android:required="false"</code> attribute.</dt> -<dd><em>Result:</em> Android Market disables filtering based on Bluetooth +<dd><em>Result:</em> Google Play disables filtering based on Bluetooth feature support, for all devices.</dd> </dl> @@ -481,10 +481,10 @@ feature support, for all devices.</dd> <h3 id="testing">Testing the features required by your application</h3> <p>You can use the <code>aapt</code> tool, included in the Android SDK, to -determine how Android Market will filter your application, based on its declared +determine how Google Play will filter your application, based on its declared features and permissions. To do so, run <code>aapt</code> with the <code>dump badging</code> command. This causes <code>aapt</code> to parse your -application's manifest and apply the same rules as used by Android Market to +application's manifest and apply the same rules as used by Google Play to determine the features that your application requires. </p> <p>To use the tool, follow these steps: </p> @@ -501,7 +501,7 @@ If you are using SDK Tools r8 or higher, you can find <code>aapt</code> in the <p class="note"><strong>Note:</strong> You must use the version of <code>aapt</code> that is provided for the latest Platform-Tools component available. If you do not have the latest Platform-Tools component, download it using the <a -href="{@docRoot}sdk/adding-components.html">Android SDK and AVD Manager</a>. +href="{@docRoot}sdk/adding-components.html">Android SDK Manager</a>. </p></li> <li>Run <code>aapt</code> using this syntax: </li> </ol> @@ -529,7 +529,7 @@ densities: '160' <h2 id=features-reference>Features Reference</h2> <p>The tables below provide reference information about hardware and software -features and the permissions that can imply them on Android Market. </p> +features and the permissions that can imply them on Google Play. </p> <h3 id="hw-features">Hardware features</h3> @@ -873,12 +873,12 @@ level 5). Because of this, some apps were able to use the API before they had the ability to declare that they require the API via the <code><uses-feature></code> system. </p> -<p>To prevent those apps from being made available unintentionally, Android -Market assumes that certain hardware-related permissions indicate that the +<p>To prevent those apps from being made available unintentionally, Google +Play assumes that certain hardware-related permissions indicate that the underlying hardware features are required by default. For instance, applications that use Bluetooth must request the <code>BLUETOOTH</code> permission in a -<code><uses-permission></code> element — for legacy apps, Android -Market assumes that the permission declaration means that the underlying +<code><uses-permission></code> element — for legacy apps, Google +Play assumes that the permission declaration means that the underlying <code>android.hardware.bluetooth</code> feature is required by the application and sets up filtering based on that feature. </p> diff --git a/docs/html/guide/topics/manifest/uses-library-element.jd b/docs/html/guide/topics/manifest/uses-library-element.jd index d94ad9f..2f8eb50 100644 --- a/docs/html/guide/topics/manifest/uses-library-element.jd +++ b/docs/html/guide/topics/manifest/uses-library-element.jd @@ -33,7 +33,7 @@ parent.link=manifest-intro.html </p> <p> This element also affects the installation of the application on a particular device and - the availability of the application in Android Market: + the availability of the application on Google Play: </p> <dl> <dt><em>Installation</em></dt> @@ -42,11 +42,11 @@ parent.link=manifest-intro.html {@code true}, the {@link android.content.pm.PackageManager} framework won't let the user install the application unless the library is present on the user's device. </dd> - <dt><em>Market</em></dt> + <dt><em>Google Play</em></dt> <dd> - Android Market filters applications based on the libraries installed on the + Google Play filters applications based on the libraries installed on the user's device. For more information about filtering, see the topic - <a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a>. + <a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a>. </dd> </dl> <p> diff --git a/docs/html/guide/topics/manifest/uses-permission-element.jd b/docs/html/guide/topics/manifest/uses-permission-element.jd index 967fc5a..6c71fb4 100644 --- a/docs/html/guide/topics/manifest/uses-permission-element.jd +++ b/docs/html/guide/topics/manifest/uses-permission-element.jd @@ -8,21 +8,21 @@ parent.link=manifest-intro.html <div class="sidebox-wrapper"> <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;"><code style="color:#669999;"><uses-permission></code> and filtering on Android Market. </p> + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> + <p style="color:#669999;padding-top:1em;"><code style="color:#669999;"><uses-permission></code> and filtering on Google Play. </p> <p style="margin-top:1em;">In some cases, the permissions that you request through <code><uses-permission></code> can affect how -your application is filtered by Android Market.</p> +your application is filtered by Google Play.</p> <p style="margin-top:1em;">If you request a hardware-related permission — -<code>CAMERA</code>, for example — Android Market assumes that your +<code>CAMERA</code>, for example — Google Play assumes that your application requires the underlying hardware feature and filters the application from devices that do not offer it.</p> <p style="margin-top:1em;">To control filtering, always explicitly declare hardware features in <code><uses-feature></code> elements, rather than -relying on Android Market to "discover" the requirements in +relying on Google Play to "discover" the requirements in <code><uses-permission></code> elements. Then, if you want to disable filtering for a particular feature, you can add a <code>android:required="false"</code> attribute to the diff --git a/docs/html/guide/topics/manifest/uses-sdk-element.jd b/docs/html/guide/topics/manifest/uses-sdk-element.jd index 99c91f6..8fa39d1 100644 --- a/docs/html/guide/topics/manifest/uses-sdk-element.jd +++ b/docs/html/guide/topics/manifest/uses-sdk-element.jd @@ -33,16 +33,16 @@ major version or the sum of the major and minor versions).</p> <div class="sidebox-wrapper" xstyle="margin-bottom:2em;margin-top:.5em;width:90%;"> <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;">Android Market and <uses-sdk> attributes</p> - <p>Android Market filters the applications that are visible to users, so + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> + <p style="color:#669999;padding-top:1em;">Google Play and <uses-sdk> attributes</p> + <p style="padding-top:1em;">Google Play filters the applications that are visible to users, so that users can only see and download applications that are compatible with their -devices. One of the ways Market filters applications is by Android -version-compatibility. To do this, Market checks the <code><uses-sdk></code> +devices. One of the ways it filters applications is by Android +version-compatibility. To do this, Google Play checks the <code><uses-sdk></code> attributes in each application's manifest to establish its version-compatibility range, then shows or hides the application based on a comparison with the API Level of the user's Android system version. For more information, see <a -href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a>.</p> +href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a>.</p> </div> </div> @@ -114,7 +114,7 @@ the corresponding platform version.</p> updates, consider the following example: </p> <p>An application declaring <code>maxSdkVersion="5"</code> in its - manifest is published on Android Market. A user whose device is running Android + manifest is published on Google Play. A user whose device is running Android 1.6 (API Level 4) downloads and installs the app. After a few weeks, the user receives an over-the-air system update to Android 2.0 (API Level 5). After the update is installed, the system checks the application's @@ -143,7 +143,7 @@ the corresponding platform version.</p> <div class="special">Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the <code>maxSdkVersion</code> attribute during -installation or re-validation. Android Market will continue to use the attribute +installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download. </div> </dd> diff --git a/docs/html/guide/topics/media/camera.jd b/docs/html/guide/topics/media/camera.jd index 4e928b3..7d72491 100644 --- a/docs/html/guide/topics/media/camera.jd +++ b/docs/html/guide/topics/media/camera.jd @@ -131,11 +131,11 @@ for example: <p>For a list of camera features, see the manifest <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#hw-features">Features Reference</a>.</p> - <p>Adding camera features to your manifest causes Android Market to prevent your application from + <p>Adding camera features to your manifest causes Google Play to prevent your application from being installed to devices that do not include a camera or do not support the camera features you -specify. For more information about using feature-based filtering with Android Market, see <a -href="{@docRoot}guide/topics/manifest/uses-feature-element.html#market-feature-filtering">Android -Market and Feature-Based Filtering</a>.</p> +specify. For more information about using feature-based filtering with Google Play, see <a +href="{@docRoot}guide/topics/manifest/uses-feature-element.html#market-feature-filtering">Google +Play and Feature-Based Filtering</a>.</p> <p>If your application <em>can use</em> a camera or camera feature for proper operation, but does not <em>require</em> it, you should specify this in the manifest by including the {@code android:required} attribute, and setting it to {@code false}:</p> @@ -442,7 +442,7 @@ use or does not exist will cause your application to be shut down by the system. the first, back-facing camera on a device with more than one camera.</p> <h3 id="check-camera-features">Checking camera features</h3> -<p>Once you obtain access to a camera, you can get further information about its capabilties using +<p>Once you obtain access to a camera, you can get further information about its capabilities using the {@link android.hardware.Camera#getParameters() Camera.getParameters()} method and checking the returned {@link android.hardware.Camera.Parameters} object for supported capabilities. When using API Level 9 or higher, use the {@link android.hardware.Camera#getCameraInfo(int, @@ -677,8 +677,8 @@ button {@link android.view.View.OnClickListener}.</p> <pre> // Add a listener to the Capture button Button captureButton = (Button) findViewById(id.button_capture); - captureButton.setOnClickListener( - new View.OnClickListener() { +captureButton.setOnClickListener( + new View.OnClickListener() { @Override public void onClick(View v) { // get an image from the camera @@ -1260,7 +1260,7 @@ supported.</p> <p>If your application requires certain camera features in order to function properly, you can require them through additions to your application manifest. When you declare the use of specific -camera features, such as flash and auto-focus, the Android Market restricts your application from +camera features, such as flash and auto-focus, Google Play restricts your application from being installed on devices which do not support these features. For a list of camera features that can be declared in your app manifest, see the manifest <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#hw-features"> Features diff --git a/docs/html/guide/topics/network/sip.jd b/docs/html/guide/topics/network/sip.jd index 276adb6..600da78 100644 --- a/docs/html/guide/topics/network/sip.jd +++ b/docs/html/guide/topics/network/sip.jd @@ -147,7 +147,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk></a </ul> <p>To control how your application is filtered from devices that do not support -SIP (for example, in Android Market), add the following to your application's +SIP (for example, on Google Play), add the following to your application's manifest:</p> <ul> diff --git a/docs/html/guide/topics/nfc/nfc.jd b/docs/html/guide/topics/nfc/nfc.jd index 83873c3..834656a 100644 --- a/docs/html/guide/topics/nfc/nfc.jd +++ b/docs/html/guide/topics/nfc/nfc.jd @@ -318,8 +318,8 @@ other two intents, giving the user a better experience.</p> </pre> </li> - <li>The <code>uses-feature</code> element so that your application shows up in the Android -Market only for devices that have NFC hardware: + <li>The <code>uses-feature</code> element so that your application shows up in Google +Play only for devices that have NFC hardware: <pre> <uses-feature android:name="android.hardware.nfc" android:required="true" /> </pre> @@ -660,7 +660,7 @@ certainty that your application is started when an NFC tag is scanned. An AAR ha of an application embedded inside an NDEF record. You can add an AAR to any NDEF record of your NDEF message, because Android searches the entire NDEF message for AARs. If it finds an AAR, it starts the application based on the package name inside the AAR. If the application is not present on the device, -Android Market is launched to download the application.</p> +Google Play is launched to download the application.</p> <p>AARs are useful if you want to prevent other applications from filtering for the same intent and potentially handling specific tags that you have deployed. AARs are only supported at the @@ -678,7 +678,7 @@ the intent also matches the AAR, start the Activity.</li> <li>If the Activity that filters for the intent does not match the AAR, if multiple Activities can handle the intent, or if no Activity handles the intent, start the application specified by the AAR.</li> - <li>If no application can start with the AAR, go to the Android Market to download the + <li>If no application can start with the AAR, go to Google Play to download the application based on the AAR.</li> </ol> @@ -897,7 +897,7 @@ public class Beam extends Activity implements CreateNdefMessageCallback { <p>Note that this code comments out an AAR, which you can remove. If you enable the AAR, the application specified in the AAR always receives the Android Beam message. If the application is not -present, the Android Market is started to download the application. Therefore, the following intent +present, Google Play launches to download the application. Therefore, the following intent filter is not technically necessary for Android 4.0 devices or later if the AAR is used: </p> diff --git a/docs/html/guide/topics/providers/content-provider-basics.jd b/docs/html/guide/topics/providers/content-provider-basics.jd index 40b5c3f..de89568 100644 --- a/docs/html/guide/topics/providers/content-provider-basics.jd +++ b/docs/html/guide/topics/providers/content-provider-basics.jd @@ -123,7 +123,7 @@ page.title=Content Provider Basics <!-- Intro paragraphs --> <p> - A content provider manages access to a central repository of data. The provider and + A content provider manages access to a central repository of data. A provider is part of an Android application, which often provides its own UI for working with the data. However, content providers are primarily intended to be used by other applications, which access the provider using a provider client object. Together, providers @@ -569,7 +569,7 @@ selectionArgs[0] = mUserInput; </pre> <p> A selection clause that uses <code>?</code> as a replaceable parameter and an array of - selection arguments array are preferred way to specify a selection, even the provider isn't + selection arguments array are preferred way to specify a selection, even if the provider isn't based on an SQL database. </p> <!-- Displaying the results --> diff --git a/docs/html/guide/topics/renderscript/graphics.jd b/docs/html/guide/topics/renderscript/graphics.jd index 1c6d0de..462a990 100644 --- a/docs/html/guide/topics/renderscript/graphics.jd +++ b/docs/html/guide/topics/renderscript/graphics.jd @@ -142,7 +142,7 @@ href="{@docRoot}resources/samples/RenderScript/MiscSamples/index.html">Misc Samp <p class="note"><strong>Note:</strong> The Renderscript runtime makes its best effort to refresh the frame at the specified rate. For example, if you are creating a live wallpaper - and set the return value to 20, the Renderscript runtime renders the wallpaper at 20fps if it has just + and set the return value to 20, the Renderscript runtime renders the wallpaper at 50fps if it has just enough or more resources to do so. It renders as fast as it can if not enough resources are available.</p> @@ -570,7 +570,7 @@ point if this is your first time using Renderscript.</p> vertex 0, 1, and 2 (the vertices are drawn counter-clockwise).</p> <pre> int float2VtxSize = 2; -Mesh.TriangleMeshBuilder triangle = new Mesh.TriangleMeshBuilder(renderscriptGL, +Mesh.TriangleMeshBuilder triangles = new Mesh.TriangleMeshBuilder(renderscriptGL, float2VtxSize, Mesh.TriangleMeshBuilder.COLOR); triangles.addVertex(300.f, 300.f); triangles.addVertex(150.f, 450.f); diff --git a/docs/html/guide/topics/renderscript/index.jd b/docs/html/guide/topics/renderscript/index.jd index a0e8876..24b9750 100644 --- a/docs/html/guide/topics/renderscript/index.jd +++ b/docs/html/guide/topics/renderscript/index.jd @@ -231,7 +231,8 @@ would block until the value was returned.</p> <p> If you want the Renderscript code to send a value back to the Android framework, use the -<code>rsSendToClient()</code> function. +<a href="{@docRoot}reference/renderscript/rs__core_8rsh.html"><code>rsSendToClient()</code></a> +function. </p> <h3 id="var">Variables</h3> @@ -256,53 +257,6 @@ public long get_unsignedInteger(){ } </pre> - <h3 id="pointer">Pointers</h3> - <p>Pointers are reflected into the script class itself, located in -<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. You -can declare pointers to a <code>struct</code> or any of the supported Renderscript types, but a -<code>struct</code> cannot contain pointers or nested arrays. For example, if you declare the -following pointers to a <code>struct</code> and <code>int32_t</code></p> - -<pre> -typedef struct Point { - float2 point; -} Point_t; - -Point_t *touchPoints; -int32_t *intPointer; -</pre> - <p>then the following code is generated in:</p> - - <pre> -private ScriptField_Point mExportVar_touchPoints; -public void bind_touchPoints(ScriptField_Point v) { - mExportVar_touchPoints = v; - if (v == null) bindAllocation(null, mExportVarIdx_touchPoints); - else bindAllocation(v.getAllocation(), mExportVarIdx_touchPoints); - } - - public ScriptField_Point get_touchPoints() { - return mExportVar_touchPoints; - } - - private Allocation mExportVar_intPointer; - public void bind_intPointer(Allocation v) { - mExportVar_intPointer = v; - if (v == null) bindAllocation(null, mExportVarIdx_intPointer); - else bindAllocation(v, mExportVarIdx_intPointer); - } - - public Allocation get_intPointer() { - return mExportVar_intPointer; - } - </pre> - -<p>A <code>get</code> method and a special method named <code>bind_<em>pointer_name</em></code> -(instead of a <code>set()</code> method) is generated. This method allows you to bind the memory -that is allocated in the Android VM to the Renderscript runtime (you cannot allocate -memory in your <code>.rs</code> file). For more information, see <a href="#memory">Working -with Allocated Memory</a>. -</p> <h3 id="struct">Structs</h3> <p>Structs are reflected into their own classes, located in @@ -311,7 +265,8 @@ with Allocated Memory</a>. specified number of <code>struct</code>s. For example, if you declare the following struct:</p> <pre> typedef struct Point { -float2 point; + float2 position; + float size; } Point_t; </pre> @@ -478,7 +433,8 @@ in memory. Each <code>struct</code>'s class defines the following methods and co </pre> <p>If you modify the memory in one memory space and want to push the updates to the rest of - the memory spaces, call <code>rsgAllocationSyncAll()</code> in your Renderscript code to + the memory spaces, call <a href="{@docRoot}reference/renderscript/rs__graphics_8rsh.html"> + <code>rsgAllocationSyncAll()</code></a> in your Renderscript code to synchronize the memory.</p> </li> @@ -511,6 +467,56 @@ Renderscript runtime. When you call a set accessor method on a member, there is properties that are not yet synchronized.</li> </ul> + <h3 id="pointer">Pointers</h3> + <p>Pointers are reflected into the script class itself, located in +<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. You +can declare pointers to a <code>struct</code> or any of the supported Renderscript types, but a +<code>struct</code> cannot contain pointers or nested arrays. For example, if you declare the +following pointers to a <code>struct</code> and <code>int32_t</code></p> + +<pre> +typedef struct Point { + float2 position; + float size; +} Point_t; + +Point_t *touchPoints; +int32_t *intPointer; +</pre> + <p>then the following code is generated in:</p> + +<pre> +private ScriptField_Point mExportVar_touchPoints; +public void bind_touchPoints(ScriptField_Point v) { + mExportVar_touchPoints = v; + if (v == null) bindAllocation(null, mExportVarIdx_touchPoints); + else bindAllocation(v.getAllocation(), mExportVarIdx_touchPoints); +} + +public ScriptField_Point get_touchPoints() { + return mExportVar_touchPoints; +} + +private Allocation mExportVar_intPointer; +public void bind_intPointer(Allocation v) { + mExportVar_intPointer = v; + if (v == null) bindAllocation(null, mExportVarIdx_intPointer); + else bindAllocation(v, mExportVarIdx_intPointer); +} + +public Allocation get_intPointer() { + return mExportVar_intPointer; +} + </pre> + +<p>A <code>get</code> method and a special method named <code>bind_<em>pointer_name</em></code> +(instead of a <code>set()</code> method) is generated. This method allows you to bind the memory +that is allocated in the Android VM to the Renderscript runtime (you cannot allocate +memory in your <code>.rs</code> file). For more information, see <a href="#memory">Working +with Allocated Memory</a>. +</p> + + <h2 id="mem-allocation">Memory Allocation APIs</h2> <p>Applications that use Renderscript still run in the Android VM. The actual Renderscript code, however, runs natively and @@ -693,7 +699,8 @@ communicated back to the Android framework layer for efficiency purposes. The la that is set from the Android framework is always returned during a call to a <code>get</code> method. However, when Android framework code modifies a variable, that change can be communicated to the Renderscript runtime automatically or synchronized at a later time. If you need to send data -from the Renderscript runtime to the Android framework layer, you can use the <code>rsSendToClient()</code> function +from the Renderscript runtime to the Android framework layer, you can use the +<a href="{@docRoot}reference/renderscript/rs__core_8rsh.html"><code>rsSendToClient()</code></a> function to overcome this limitation. </p> <p>When working with dynamically allocated memory, any changes at the Renderscript runtime layer are propagated diff --git a/docs/html/guide/topics/resources/localization.jd b/docs/html/guide/topics/resources/localization.jd index 9affb15..c2b668d 100755 --- a/docs/html/guide/topics/resources/localization.jd +++ b/docs/html/guide/topics/resources/localization.jd @@ -186,7 +186,7 @@ speak. </p> and can include other types of resources such as animations.
<br>
<code> res/drawable/</code>(required directory holding at least
- one graphic file, for the application's icon in the Market)<br>
+ one graphic file, for the application's icon on Google Play)<br>
<code> res/layout/</code> (required directory holding an XML
file that defines the default layout)<br>
<code> res/anim/</code> (required if you have any
@@ -507,7 +507,7 @@ the new locale. </p> <h2 id="publishing">Publishing Localized Applications</h2>
-<p>The Android Market is
+<p>The Google Play is
the main application distribution system for Android devices. To publish a
localized application, you need to sign your application, version it, and go
through all the other steps described in <a
@@ -521,7 +521,7 @@ different locale, follow these guidelines:</p> href="{@docRoot}guide/publishing/app-signing.html#strategies">Signing
Strategies</a>. </li>
<li>Give each .apk file a different application name. Currently it is
-impossible to put two applications into the Android Market that have exactly the
+impossible to publish two applications on Google Play that have exactly the
same name.</li>
<li>Include a complete set of default resources in each .apk file.</li>
</ul>
@@ -638,7 +638,7 @@ border="0"></td> <tr>
<td valign="top" align="center"><img src="../../../images/resources/arrow.png" alt="arrow" width="26"
border="0"></td>
- <td>Upload your .apk file or files to Market, selecting the appropriate
+ <td>Upload your .apk file or files to Google Play, selecting the appropriate
languages as
you upload. (For more details, see <a
href="{@docRoot}guide/publishing/publishing.html">Publishing Your
diff --git a/docs/html/guide/topics/resources/providing-resources.jd b/docs/html/guide/topics/resources/providing-resources.jd index 380791a..b33a097 100644 --- a/docs/html/guide/topics/resources/providing-resources.jd +++ b/docs/html/guide/topics/resources/providing-resources.jd @@ -287,9 +287,8 @@ names.</p> from the SIM card in the device. For example, <code>mcc310</code> is U.S. on any carrier, <code>mcc310-mnc004</code> is U.S. on Verizon, and <code>mcc208-mnc00</code> is France on Orange.</p> - <p>If the device uses a radio connection (GSM phone), the MCC comes - from the SIM, and the MNC comes from the network to which the - device is connected.</p> + <p>If the device uses a radio connection (GSM phone), the MCC and MNC values come + from the SIM card.</p> <p>You can also use the MCC alone (for example, to include country-specific legal resources in your application). If you need to specify based on the language only, then use the <em>language and region</em> qualifier instead (discussed next). If you decide to use the MCC and diff --git a/docs/html/guide/topics/resources/string-resource.jd b/docs/html/guide/topics/resources/string-resource.jd index ecd2d48..5f5484e 100644 --- a/docs/html/guide/topics/resources/string-resource.jd +++ b/docs/html/guide/topics/resources/string-resource.jd @@ -358,11 +358,14 @@ values, with non-exhaustive examples in parentheses: <pre> 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, count); +String songsFound = res.<a +href="{@docRoot}reference/android/content/res/Resources.html#getQuantityString(int, int, java.lang.Object...)" +>getQuantityString</a>(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 + +<p>When using the <a +href="{@docRoot}reference/android/content/res/Resources.html#getQuantityString(int, int, java.lang.Object...)">{@code +getQuantityString()}</a> 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 diff --git a/docs/html/guide/topics/sensors/index.jd b/docs/html/guide/topics/sensors/index.jd index 75a1716..43903dc 100644 --- a/docs/html/guide/topics/sensors/index.jd +++ b/docs/html/guide/topics/sensors/index.jd @@ -43,7 +43,7 @@ device's temperature sensor and humidity sensor to calculate and report the dewp application might use the geomagnetic field sensor and accelerometer to report a compass bearing.</p> -<p>The Android platform supports four broad categories of sensors:</p> +<p>The Android platform supports three broad categories of sensors:</p> <ul> <li>Motion sensors diff --git a/docs/html/guide/topics/sensors/sensors_overview.jd b/docs/html/guide/topics/sensors/sensors_overview.jd index 3c5e94c..543872c 100644 --- a/docs/html/guide/topics/sensors/sensors_overview.jd +++ b/docs/html/guide/topics/sensors/sensors_overview.jd @@ -606,7 +606,7 @@ sensor is present on a device so your app can run successfully. You have two opt that a given sensor is present on a device:</p> <ul> <li>Detect sensors at runtime and enable or disable application features as appropriate.</li> - <li>Use Android Market filters to target devices with specific sensor configurations.</li> + <li>Use Google Play filters to target devices with specific sensor configurations.</li> </ul> <p>Each option is discussed in the following sections.</p> @@ -633,9 +633,9 @@ whether there's a pressure sensor on a device:</p> } </pre> -<h4>Using Android Market filters to target specific sensor configurations</h4> +<h4>Using Google Play filters to target specific sensor configurations</h4> -<p>If you are publishing your application on Android Market you can use the +<p>If you are publishing your application on Google Play you can use the <a href="{@docRoot}guide//topics/manifest/uses-feature-element.html"><code><uses-feature> </code></a> element in your manifest file to filter your application from devices that do not have the appropriate sensor configuration for your application. The @@ -650,7 +650,7 @@ following is an example manifest entry that filters apps that do not have an acc </pre> <p>If you add this element and descriptor to your application's manifest, users will see your -application on Android Market only if their device has an accelerometer.</p> +application on Google Play only if their device has an accelerometer.</p> <p>You should set the descriptor to <code>android:required="true"</code> only if your application relies entirely on a specific sensor. If your application uses a sensor for some functionality, but diff --git a/docs/html/guide/topics/ui/accessibility/apps.jd b/docs/html/guide/topics/ui/accessibility/apps.jd new file mode 100644 index 0000000..dc91638 --- /dev/null +++ b/docs/html/guide/topics/ui/accessibility/apps.jd @@ -0,0 +1,574 @@ +page.title=Making Applications Accessible +parent.title=Accessibility +parent.link=index.html +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>In this document</h2> + <ol> + <li><a href="#label-ui">Labeling User Interface Elements</a></li> + <li><a href="#focus-nav">Enabling Focus Navigation</a> + <ol> + <li><a href="#focus-enable">Enabling view focus</a></li> + <li><a href="#focus-order">Controlling focus order</a></li> + </ol> + </li> + <li><a href="#custom-views">Building Accessible Custom Views</a> + <ol> + <li><a href="#directional-control">Handling directional controller clicks</a></li> + <li><a href="#accessibility-methods">Implementing accessibility API methods</a></li> + <li><a href="#send-events">Sending accessibility events</a></li> + <li><a href="#populate-events">Populating accessibility events</a></li> + </ol> + </li> + <li><a href="#test">Testing Accessibility</a> + <ol> + <li><a href="#test-audibles">Testing audible feedback</a></li> + <li><a href="#test-navigation">Testing focus navigation</a></li> + </ol> + </li> + </ol> + + <h2>Key classes</h2> + <ol> + <li>{@link android.view.accessibility.AccessibilityEvent}</li> + <li>{@link android.view.accessibility.AccessibilityNodeInfo}</li> + <li>{@link android.support.v4.view.accessibility.AccessibilityNodeInfoCompat}</li> + <li>{@link android.view.View.AccessibilityDelegate}</li> + <li>{@link android.support.v4.view.AccessibilityDelegateCompat}</li> + </ol> + + <h2>See also</h2> + <ol> + <li><a href="{@docRoot}training/accessibility/index.html">Implementing Accessibility</a></li> + <li><a href="{@docRoot}training/design-navigation/index.html">Designing Effective Navigation</a> + </li> + <li><a href="{@docRoot}design/index.html">Android Design</a></li> + </ol> + +</div> +</div> + +<p>Applications built for Android are accessible to users with visual, physical or age-related +disabilities when they activate accessibility features and services on a device. By default, +these services make your application more accessible. However, there are further steps you should +take to optimize the accessibility of your application and ensure a pleasant experience for all your +users.</p> + +<p>Making sure your application is accessible to all users is relatively easy, particularly when you +use framework-provided user interface components. If you only use these standard components for your +application, there are just a few steps required to ensure your application is accessible:</p> + +<ol> + <li>Label your {@link android.widget.ImageButton}, {@link android.widget.ImageView}, {@link +android.widget.EditText}, {@link android.widget.CheckBox} and other user interface controls using +the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription"> + {@code android:contentDescription}</a> attribute.</li> + <li>Make all of your user interface elements accessible with a directional controller, + such as a trackball or D-pad.</li> + <li>Test your application by turning on accessibility services like TalkBack and Explore by + Touch, and try using your application using only directional controls.</li> +</ol> + +<p>Developers who create custom controls that extend from the {@link android.view.View} class have +some additional responsibilities for making sure their components are accessible for users. This +document also discusses how to make custom view controls compatible with accessibility services.</p> + + +<h2 id="label-ui">Labeling User Interface Elements</h2> + +<p>Many user interface controls rely on visual cues to inform users of their meaning. For +example, a note-taking application might use an {@link android.widget.ImageButton} with a +picture of a plus sign to indicate that the user can add a new note. Or, an {@link +android.widget.EditText} component may have a label near it that indicates its purpose. When a user +with impaired vision accesses your application, these visual cues are often useless.</p> + +<p>To provide textual information about interface controls (as an alternative to the visual cues), +use the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription"> +{@code android:contentDescription}</a> attribute. The text you provide in this attribute is not +visible on the screen, but if a user has enabled accessibility services that provide audible +prompts, then the description in this attribute is read aloud to the user.</p> + +<p>Set the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription"> +{@code android:contentDescription}</a> attribute for every {@link android.widget.ImageButton}, +{@link android.widget.ImageView}, {@link android.widget.EditText}, {@link android.widget.CheckBox} +in your application's user interface, and on any other input controls that might require additional +information for users who are not able to see it.</p> + +<p>For example, the following {@link android.widget.ImageButton} sets the content description for +the plus button to the {@code add_note} string resource, which could be defined as “Add note" for an +English language interface:</p> + +<pre> +<ImageButton + android:id=”@+id/add_note_button” + android:src=”@drawable/add_note” + android:contentDescription=”@string/add_note”/> +</pre> + +<p>By including the description, speech-based accessibility services can announce "Add note" when a +user moves focus to this button or hovers over it.</p> + +<p class="note"><strong>Note:</strong> For {@link android.widget.EditText} fields, provide an +<a href="{@docRoot}reference/android/widget/TextView.html#attr_android:hint">android:hint</a> +attribute to help users understand what content is expected.</p> + +<h2 id="focus-nav">Enabling Focus Navigation</h2> + +<p>Focus navigation allows users with disabilities to step through user interface controls using a +directional controller. Directional controllers can be physical, such as a clickable trackball, +directional pad (D-pad) or arrow keys, tab key navigation with an attached keyboard or a software +application, such as the +<a href="https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.inputmethod.latin"> +Eyes-Free Keyboard</a>, that provides an on-screen directional control.</p> + +<p>A directional controller is a primary means of navigation for many users. +Verify that all user interface (UI) controls in your application are accessible +without using the touchscreen and that clicking with the center button (or OK button) of a +directional controller has the same effect as touching the controls on the touchscreen. For +information on testing directional controls, see <a href="#test-navigation">Testing focus +navigation</a>.</p> + +<h3 id="focus-enable">Enabling view focus</h3> + +<p>A user interface element is accessible using directional controls when its +<a href="{@docRoot}reference/android/view/View.html#attr_android:focusable"> +{@code android:focusable}</a> attribute is set to {@code true}. This setting allows users to focus +on the element using the directional controls and then interact with it. The user interface controls +provided by the Android framework are focusable by default and visually indicate focus by changing +the control’s appearance.</p> + +<p>Android provides several APIs that let you control whether a user interface control is focusable +and even request that a control be given focus:</p> + +<ul> + <li>{@link android.view.View#setFocusable setFocusable()}</li> + <li>{@link android.view.View#isFocusable isFocusable()}</li> + <li>{@link android.view.View#requestFocus requestFocus()}</li> +</ul> + +<p>When working with a view that is not focusable by default, you can make it focusable from the XML +layout file by setting the +<a href="{@docRoot}reference/android/view/View.html#attr_android:focusable"> +{@code android:focusable}</a> attribute to {@code true} or by using the {@link +android.view.View#setFocusable setFocusable()} method.</p> + +<h3 id="focus-order">Controlling focus order</h3> + +<p>When users navigate in any direction using directional controls, focus is passed from one +user interface element (View) to another, as determined by the focus ordering. The ordering of the +focus movement is based on an algorithm that finds the nearest neighbor in a given direction. In +rare cases, the default algorithm may not match the order that you intended for your UI. In these +situations, you can provide explicit overrides to the ordering using the following XML attributes in +the layout file:</p> + +<dl> + <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown" +>{@code android:nextFocusDown}</a></dt> + <dd>Defines the next view to receive focus when the user navigates down.</dd> + <a><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusLeft" +>{@code android:nextFocusLeft}</a></dt> + <dd>Defines the next view to receive focus when the user navigates left.</dd> + <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusRight" +>{@code android:nextFocusRight}</a></dt> + <dd>Defines the next view to receive focus when the user navigates right.</dd> + <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp" +>{@code android:nextFocusUp}</a></dt> + <dd>Defines the next view to receive focus when the user navigates up.</dd> +</dl> + +<p>The following example XML layout shows two focusable user interface elements where the <a +href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown" +>{@code android:nextFocusDown}</a> and <a +href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp" +>{@code android:nextFocusUp}</a> attributes have been explicitly set. The {@link android.widget.TextView} is +located to the right of the {@link android.widget.EditText}. However, since these properties have +been set, the {@link android.widget.TextView} element can now be reached by pressing the down arrow +when focus is on the {@link android.widget.EditText} element: </p> + +<pre> +<LinearLayout android:orientation="horizontal" + ... > + <EditText android:id="@+id/edit" + android:nextFocusDown=”@+id/text” + ... /> + <TextView android:id="@+id/text" + android:focusable=”true” + android:text="Hello, I am a focusable TextView" + android:nextFocusUp=”@id/edit” + ... /> +</LinearLayout> +</pre> + +<p>When modifying focus order, be sure that the navigation works as expected in all directions from +each user interface control and when navigating in reverse (to get back to where you came from).</p> + +<p class="note"><strong>Note:</strong> You can modify the focus order of user interface components +at runtime, using methods such as {@link android.view.View#setNextFocusDownId setNextFocusDownId()} +and {@link android.view.View#setNextFocusRightId setNextFocusRightId()}.</p> + + +<h2 id="custom-views">Building Accessible Custom Views</h2> + +<p>If your application requires a <a href="{@docRoot}guide/topics/ui/custom-components.html">custom +view component</a>, you must do some additional work to ensure that your custom view is accessible. +These are the main tasks for ensuring the accessibility of your view:</p> + +<ul> + <li>Handle directional controller clicks</li> + <li>Implement Accessibility API methods</li> + <li>Send {@link android.view.accessibility.AccessibilityEvent} objects specific to your custom view</li> + <li>Populate {@link android.view.accessibility.AccessibilityEvent} and {@link + android.view.accessibility.AccessibilityNodeInfo} for your view</li> +</ul> + + +<h3 id="directional-control">Handling directional controller clicks</h3> + +<p>On most devices, clicking a view using a directional controller sends a {@link +android.view.KeyEvent} with {@link android.view.KeyEvent#KEYCODE_DPAD_CENTER} to the view currently +in focus. All standard Android views already handle {@link +android.view.KeyEvent#KEYCODE_DPAD_CENTER} appropriately. When building a custom {@link +android.view.View} control, make sure this event has the same effect as touching the view on the +touchscreen. </p> + +<p>Your custom control should also treat the {@link android.view.KeyEvent#KEYCODE_ENTER} event the +same as {@link android.view.KeyEvent#KEYCODE_DPAD_CENTER}. This approach makes interaction from a +full keyboard much easier for users.</p> + + +<h3 id="accessibility-methods">Implementing accessibility API methods</h3> + +<p>Accessibility events are messages about users interaction with visual interface components in +your application. These messages are handled by <a href="services.html">Accessibility Services</a>, +which use the information in these events to produce supplemental feedback and prompts when users +have enabled accessibility services. As of Android 4.0 (API Level 14) and higher, the methods for +generating accessibility events have been expanded to provide more detailed information beyond the +{@link android.view.accessibility.AccessibilityEventSource} interface introduced in Android 1.6 (API +Level 4). The expanded accessibility methods are part of the {@link android.view.View} class as well +as the {@link android.view.View.AccessibilityDelegate} class. The methods are as follows:</p> + +<dl> + <dt>{@link android.view.View#sendAccessibilityEvent sendAccessibilityEvent()}</dt> + <dd>(API Level 4) This method is called when a user takes action on a view. The event is +classified with a user action type such as {@link +android.view.accessibility.AccessibilityEvent#TYPE_VIEW_CLICKED TYPE_VIEW_CLICKED}. You typically do +not need to implement this method unless you are creating a custom view.</dd> + + <dt>{@link android.view.View#sendAccessibilityEventUnchecked +sendAccessibilityEventUnchecked()}</dt> + <dd>(API Level 4) This method is used when the calling code needs to directly control the check +for accessibility being enabled on the device ({@link +android.view.accessibility.AccessibilityManager#isEnabled AccessibilityManager.isEnabled()}). If +you do implement this method, you must assume that the calling method has already checked that +accessibility is enabled and the result is {@code true}. You typically do not need to implement this +method for a custom view.</dd> + + <dt>{@link android.view.View#dispatchPopulateAccessibilityEvent +dispatchPopulateAccessibilityEvent()} </dt> + <dd>(API Level 4) The system calls this method when your custom view generates an +accessibility event. As of API Level 14, the default implementation of this method calls {@link +android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} for this view and +then the {@link android.view.View#dispatchPopulateAccessibilityEvent +dispatchPopulateAccessibilityEvent()} method for each child of this view. In order to support +accessibility services on revisions of Android <em>prior</em> to 4.0 (API Level 14) you +<em>must</em> override this method and populate {@link +android.view.accessibility.AccessibilityEvent#getText} with descriptive text for your custom +view.</dd> + + <dt>{@link android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()}</dt> + <dd>(API Level 14) This method sets the text output of an {@link +android.view.accessibility.AccessibilityEvent} for your view. This method is also called if the +view is a child of a view which generates an accessibility event. + + <p class="note"><strong>Note:</strong> Modifying additional attributes beyond the text within +this method potentially overwrites properties set by other methods. So, while you are able modify +attributes of the accessibility event with this method, you should limit these changes +to text content only and use the {@link android.view.View#onInitializeAccessibilityEvent +onInitializeAccessibilityEvent()} method to modify other properties of the event.</p> + + <p class="note"><strong>Note:</strong> If your implementation of this event calls for completely +overiding the output text without allowing other parts of your layout to modify its content, then +do not call the super implementation of this method in your code.</p> + </dd> + + <dt>{@link android.view.View#onInitializeAccessibilityEvent onInitializeAccessibilityEvent()}</dt> + <dd>(API Level 14) The system calls this method to obtain additional information about the +state of the view, beyond text content. If your custom view provides interactive control beyond a +simple {@link android.widget.TextView} or {@link android.widget.Button}, you should override this +method and set the additional information about your view into the event using this method, such as +password field type, checkbox type or states that provide user interaction or feedback. If you +do override this method, you must call its super implementation and then only modify properties +that have not been set by the super class.</dd> + + <dt>{@link android.view.View#onInitializeAccessibilityNodeInfo +onInitializeAccessibilityNodeInfo()}</dt> + <dd>(API Level 14) This method provides accessibility services with information about the state of +the view. The default {@link android.view.View} implementation sets a standard set of view +properties, but if your custom view provides interactive control beyond a simple {@link +android.widget.TextView} or {@link android.widget.Button}, you should override this method and set +the additional information about your view into the {@link +android.view.accessibility.AccessibilityNodeInfo} object handled by this method.</dd> + + <dt>{@link android.view.ViewGroup#onRequestSendAccessibilityEvent +onRequestSendAccessibilityEvent()}</dt> + <dd>(API Level 14) The system calls this method when a child of your view has generated an +{@link android.view.accessibility.AccessibilityEvent}. This step allows the the parent view to amend +the accessibility event with additional information. You should implement this method only if your +custom view can have child views and if the parent view can provide context information to the +accessibility event that would be useful to accessibility services.</dd> +</dl> + +<p>In order to support these accessibility methods for a custom view, you should take one of the +following approaches:</p> + +<ul> + <li>If your application targets Android 4.0 (API level 14) and higher, override and implement the +accessibility methods listed above directly in your custom view class.</li> + <li>If your custom view is intended to be compatible with Android 1.6 (API Level 4) and above, add +the Android <a href="{@docRoot}sdk/compatibility-library.html">Support Library</a>, revision 5 or +higher, to your project. Then, within your custom view class, call the +{@link android.support.v4.view.ViewCompat#setAccessibilityDelegate +ViewCompat.setAccessibilityDelegate()} method to implement the accessibility methods +above. For an example of this approach, see the Android Support Library (revision 5 or higher) +sample {@code AccessibilityDelegateSupportActivity} in +({@code <sdk>/extras/android/support/v4/samples/Support4Demos/}) + </li> +</ul> + +<p>In either case, you should implement the following accessibility methods for your custom view +class:</p> + +<ul> + <li>{@link android.view.View#dispatchPopulateAccessibilityEvent + dispatchPopulateAccessibilityEvent()}</li> + <li>{@link android.view.View#onPopulateAccessibilityEvent + onPopulateAccessibilityEvent()}</li> + <li>{@link android.view.View#onInitializeAccessibilityEvent + onInitializeAccessibilityEvent()}</li> + <li>{@link android.view.View#onInitializeAccessibilityNodeInfo + onInitializeAccessibilityNodeInfo()}</li> +</ul> + +<p>For more information about implementing these methods, see <a href="#populate-events">Populating +Accessibility Events</a>.</p> + + +<h3 id="send-events">Sending accessibility events</h3> + +<p>Depending on the specifics of your custom view, it may need to send {@link +android.view.accessibility.AccessibilityEvent} objects at a different times or for events not +handled by the default implementation. The {@link android.view.View} class provides a default +implementation for these event types:</p> + +<ul> + <li>Starting with API Level 4: + <ul> + <li>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_CLICKED}</li> + + <li>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_LONG_CLICKED}</li> + + <li>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_FOCUSED}</li> + </ul> + </li> + <li>Starting with API Level 14: + <ul> + <li>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_SCROLLED}</li> + + <li>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_HOVER_ENTER}</li> + + <li>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_HOVER_EXIT}</li> + </ul> + </li> +</ul> + +<p class="note"><strong>Note:</strong> Hover events are associated with the Explore by +Touch feature, which uses these events as triggers for providing audible prompts for user interface +elements.</p> + +<p>In general, you should send an {@link android.view.accessibility.AccessibilityEvent} whenever the +content of your custom view changes. For example, if you are implementing a custom slider bar that +allows a user to select a numeric value by pressing the left or right arrows, your custom view +should emit an event of type {@link +android.view.accessibility.AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED} whenever the slider +value changes. The following sample code demonstrates the use of the {@link +android.view.accessibility.AccessibilityEventSource#sendAccessibilityEvent +sendAccessibilityEvent()} method to report this event.</p> + +<pre> +@Override +public boolean onKeyUp (int keyCode, KeyEvent event) { + if (keyCode == KeyEvent.KEYCODE_DPAD_LEFT) { + mCurrentValue--; + sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED); + return true; + } + ... +} +</pre> + + +<h3 id="populate-events">Populating accessibility events</h3> + +<p>Each {@link android.view.accessibility.AccessibilityEvent} has a set of required properties that +describe the current state of the view. These properties include things such as the view’s class +name, content description and checked state. The specific properties required for each event type +are described in the {@link android.view.accessibility.AccessibilityEvent} reference documentation. +The {@link android.view.View} implementation provides default values for these properties. Many of +these values, including the class name and event timestamp, are provided automatically. If you are +creating a custom view component, you must provide some information about the content and +characteristics of the view. This information may be as simple as a button label, but may also +include additional state information that you want to add to the event.</p> + +<p>The minimum requirement for providing information to accessibility services with a custom +view is to implement {@link android.view.View#dispatchPopulateAccessibilityEvent +dispatchPopulateAccessibilityEvent()}. This method is called by the system to request +information for an {@link android.view.accessibility.AccessibilityEvent} and makes your custom +view compatible with accessibility services on Android 1.6 (API Level 4) and higher. The +following example code demonstrates a basic implementation of this method.</p> + +<pre> +@Override +public void dispatchPopulateAccessibilityEvent(AccessibilityEvent event) { + super.dispatchPopulateAccessibilityEvent(event); + // Call the super implementation to populate its text to the event, which + // calls onPopulateAccessibilityEvent() on API Level 14 and up. + + // In case this is running on a API revision earlier that 14, check + // the text content of the event and add an appropriate text + // description for this custom view: + CharSequence text = getText(); + if (!TextUtils.isEmpty(text)) { + event.getText().add(text); + } +} +</pre> + +<p>On Android 4.0 (API Level 14) and higher, the {@link +android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} and +{@link android.view.View#onInitializeAccessibilityEvent onInitializeAccessibilityEvent()} +methods are the recommended way to populate or modify the information in an {@link +android.view.accessibility.AccessibilityEvent}. Use the +{@link android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} method +specifically for adding or modifying the text content of the event, which is turned into audible +prompts by accessibility services such as TalkBack. Use the +{@link android.view.View#onInitializeAccessibilityEvent onInitializeAccessibilityEvent()} method for +populating additional information about the event, such as the selection state of the view.</p> + +<p>In addition, you should also implement the +{@link android.view.View#onInitializeAccessibilityNodeInfo onInitializeAccessibilityNodeInfo()} +method. {@link android.view.accessibility.AccessibilityNodeInfo} objects populated by this method +are used by accessibility services to investigate the view hierarchy that generated an accessibility +event after receiving that event, to obtain a more detailed context information and provide +appropriate feedback to users.</p> + +<p>The example code below shows how override these three methods by using +{@link android.support.v4.view.ViewCompat#setAccessibilityDelegate +ViewCompat.setAccessibilityDelegate()}. Note that this sample code requires that the Android +<a href="{@docRoot}sdk/compatibility-library.html">Support Library</a> for API Level 4 (revision 5 +or higher) is added to your project.</p> + +<pre> +ViewCompat.setAccessibilityDelegate(new AccessibilityDelegateCompat() { + @Override + public void onPopulateAccessibilityEvent(View host, AccessibilityEvent event) { + super.onPopulateAccessibilityEvent(host, event); + // We call the super implementation to populate its text for the + // event. Then we add our text not present in a super class. + // Very often you only need to add the text for the custom view. + CharSequence text = getText(); + if (!TextUtils.isEmpty(text)) { + event.getText().add(text); + } + } + @Override + public void onInitializeAccessibilityEvent(View host, AccessibilityEvent event) { + super.onInitializeAccessibilityEvent(host, event); + // We call the super implementation to let super classes + // set appropriate event properties. Then we add the new property + // (checked) which is not supported by a super class. + event.setChecked(isChecked()); + } + @Override + public void onInitializeAccessibilityNodeInfo(View host, + AccessibilityNodeInfoCompat info) { + super.onInitializeAccessibilityNodeInfo(host, info); + // We call the super implementation to let super classes set + // appropriate info properties. Then we add our properties + // (checkable and checked) which are not supported by a super class. + info.setCheckable(true); + info.setChecked(isChecked()); + // Quite often you only need to add the text for the custom view. + CharSequence text = getText(); + if (!TextUtils.isEmpty(text)) { + info.setText(text); + } + } +} +</pre> + +<p>On applications targeting Android 4.0 (API Level 14) and higher, these methods can be implemented +directly in your custom view class. For another example of this approach, see the Android +<a href="{@docRoot}sdk/compatibility-library.html">Support Library</a> (revision 5 or higher) sample +{@code AccessibilityDelegateSupportActivity} in +({@code <sdk>/extras/android/support/v4/samples/Support4Demos/}).</p> + +<p class="note"><strong>Note:</strong> You may find information on implementing accessibility for +custom views written prior to Android 4.0 that describes the use of the +{@link android.view.View#dispatchPopulateAccessibilityEvent dispatchPopulateAccessibilityEvent()} +method for populating AccessibilityEvents. As of the Android 4.0 release, however, the recommended +approach is to use the +{@link android.view.View#onPopulateAccessibilityEvent onPopulateAccessibilityEvent()} and +{@link android.view.View#onInitializeAccessibilityEvent onInitializeAccessibilityEvent()} +methods.</p> + + +<h2 id="test">Testing Accessibility</h2> + +<p>Testing the accessibility of your application is an important part of ensuring your users have a +great experience. You can test the most important parts of accessibility by testing your application +with audible feedback enabled and testing navigation within your application using directional +controls.</p> + +<h3 id="test-audibles">Testing audible feedback</h3> +<p>You can simulate the experience for many users by enabling an accessibility service that speaks +as you move around the screen. The Explore by Touch accessibility service, which is available on +devices with Android 4.0 and later. The <a +href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">TalkBack</a> +accessibility service, by the <a href="http://code.google.com/p/eyes-free/">Eyes-Free +Project</a> comes preinstalled on many Android devices.</p> + +<p>To enable TalkBack on revisions of Android prior to Android 4.0:</p> +<ol> + <li>Launch the Settings application.</li> + <li>Navigate to the <strong>Accessibility</strong> category and select it.</li> + <li>Select <strong>Accessibility</strong> to enable it.</li> + <li>Select <strong>TalkBack</strong> to enable it.</li> +</ol> + +<p class="note"><strong>Note:</strong> If the TalkBack accessibility service is not available, you +can install it for free from <a href="http://play.google.com">Google Play</a>.</p> + +<p>To enable Explore by Touch on Android 4.0 and later:</p> +<ol> + <li>Launch the Settings application.</li> + <li>Navigate to the <strong>Accessibility</strong> category and select it.</li> + <li>Select the <strong>TalkBack</strong> to enable it.</li> + <li>Return to the <strong>Accessibility</strong> category and select <strong>Explore by +Touch</strong> to enable it. + <p class="note"><strong>Note:</strong> You must turn on TalkBack <em>first</em>, otherwise this +option is not available.</p> + </li> +</ol> + +<h3 id="test-navigation">Testing focus navigation</h3> + +<p>As part of your accessibility testing, you can test navigation of your application using focus, +even if your test devices does not have a directional controller. The <a +href="{@docRoot}guide/developing/tools/emulator.html">Android Emulator</a> provides a +simulated directional controller that you can easily use to test navigation. You can also use a +software-based directional controller, such as the one provided by the +<a href="https://play.google.com/store/apps/details?id=com.googlecode.eyesfree.inputmethod.latin"> +Eyes-Free Keyboard</a> to simulate use of a D-pad.</p> diff --git a/docs/html/guide/topics/ui/accessibility/index.jd b/docs/html/guide/topics/ui/accessibility/index.jd new file mode 100644 index 0000000..414d5f3 --- /dev/null +++ b/docs/html/guide/topics/ui/accessibility/index.jd @@ -0,0 +1,55 @@ +page.title=Accessibility +parent.title=User Interface +parent.link=../index.html +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>Topics</h2> + <ol> + <li><a href="{@docRoot}guide/topics/ui/accessibility/apps.html">Making Applications Accessible</a> + </li> + <li><a href="{@docRoot}guide/topics/ui/accessibility/services.html">Building Accessibility + Services</a></li> + </ol> + + <h2>Key classes</h2> + <ol> + <li>{@link android.view.accessibility.AccessibilityEvent}</li> + <li>{@link android.accessibilityservice.AccessibilityService}</li> + </ol> + + <h2>See also</h2> + <ol> + <li><a href="{@docRoot}training/accessibility/index.html">Implementing Accessibility</a></li> + </ol> + +</div> +</div> + +<p>Many Android users have disabilities that require them to interact with their Android devices in +different ways. These include users who have visual, physical or age-related disabilities that +prevent them from fully seeing or using a touchscreen.</p> + +<p>Android provides accessibility features and services for helping these users navigate their +devices more easily, including text-to-speech, haptic feedback, trackball and D-pad navigation that +augment their experience. Android application developers can take advantage of these services to +make their applications more accessible and also build their own accessibility services.</p> + +<p>The following topics show you how to use the Android framework to make applications more +accessible.</p> + +<dl> + <dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/apps.html">Making Applications +Accessible</a></strong> + </dt> + <dd>Development practices and API features to ensure your application is accessible to users with +disabilities.</dd> + + <dt><strong><a href="{@docRoot}guide/topics/ui/accessibility/service.html">Building Accessibility +Services</a></strong> + </dt> + <dd>How to use API features to build services that make other applications more accessible for +users.</dd> +</dl>
\ No newline at end of file diff --git a/docs/html/guide/topics/ui/accessibility/services.jd b/docs/html/guide/topics/ui/accessibility/services.jd new file mode 100644 index 0000000..0dad4ec --- /dev/null +++ b/docs/html/guide/topics/ui/accessibility/services.jd @@ -0,0 +1,290 @@ +page.title=Building Accessibility Services +parent.title=Accessibility +parent.link=index.html +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + + <h2>Topics</h2> + <ol> + <li><a href="#manifest">Manifest Declarations and Permissions</a> + <ol> + <li><a href="service-declaration">Accessibility service declaration</a></li> + <li><a href="#service-config">Accessibility service configuration</a></li> + </ol> + </li> + <li><a href="#methods">AccessibilityService Methods</a></li> + <li><a href="#event-details">Getting Event Details</a></li> + <li><a href="#examples">Example Code</a></li> + </ol> + + <h2>Key classes</h2> + <ol> + <li>{@link android.accessibilityservice.AccessibilityService}</li> + <li>{@link android.accessibilityservice.AccessibilityServiceInfo}</li> + <li>{@link android.view.accessibility.AccessibilityEvent}</li> + <li>{@link android.view.accessibility.AccessibilityRecord}</li> + <li>{@link android.view.accessibility.AccessibilityNodeInfo}</li> + </ol> + + <h2>See also</h2> + <ol> + <li><a href="{@docRoot}training/accessibility/index.html">Implementing Accessibility</a></li> + </ol> + +</div> +</div> + +<p>An accessibility service is an application that provides user interface enhancements to +assist users with disabilities, or who may temporarily be unable to fully interact with a device. +For example, users who are driving, taking care of a young child or attending a very loud party +might need additional or alternative interface feedback.</p> + +<p>Android provides standard accessibility services, including TalkBack, and developers can +create and distribute their own services. This document explains the basics of building an +accessibility service.</p> + +<p>The ability for you to build and deploy accessibility services was introduced with Android +1.6 (API Level 4) and received significant improvements with Android 4.0 (API Level 14). The Android +Support Library was also updated with the release of Android 4.0 to provide support for these +enhanced accessibility features back to Android 1.6. Developers aiming for widely compatible +accessibility services are encouraged to use the +<a href="{@docRoot}sdk/compatibility-library.html">Support Library</a> and develop for the more +advanced accessibility features introduced in Android 4.0.</p> + + +<h2 id="manifest">Manifest Declarations and Permissions</h2> + +<p>Applications that provide accessibility services must include specific declarations in their + application manifests in order to be treated as an accessibility service by an Android system. + This section explains the required and optional settings for accessibility services.</p> + + +<h3 id="service-declaration">Accessibility service declaration</h3> + +<p>In order to be treated as an accessibility service, your application must include the +{@code service} element (rather than the {@code activity} element) within the {@code application} +element in its manifest. In addition, within the {@code service} element, you must also include an +accessibility service intent filter, as shown in the following sample:</p> + +<pre> +<application> + <service android:name=".MyAccessibilityService" + android:label="@string/accessibility_service_label"> + <intent-filter> + <action android:name="android.accessibilityservice.AccessibilityService" /> + </intent-filter> + </service> +</application> +</pre> + +<p>These declarations are required for all accessibility services deployed on Android 1.6 (API Level + 4) or higher.</p> + + +<h3 id="service-config">Accessibility service configuration</h3> + +<p>Accessibility services must also provide a configuration which specifies the types of +accessibility events that the service handles and additional information about the service. The +configuration of an accessibility service is contained in the {@link +android.accessibilityservice.AccessibilityServiceInfo} class. Your service can build and set a +configuration using an instance of this class and {@link +android.accessibilityservice.AccessibilityService#setServiceInfo setServiceInfo()} at runtime. +However, not all configuration options are available using this method.</p> + +<p>Beginning with Android 4.0, you can include a {@code <meta-data>} element in your manifest +with a reference to a configuration file, which allows you to set the full range of options for +your accessibility service, as shown in the following example:</p> + +<pre> +<service android:name=".MyAccessibilityService"> + ... + <meta-data + android:name="android.accessibilityservice" + android:resource="@xml/accessibility_service_config" /> +</service> +</pre> + +<p>This meta-data element refers to an XML file that you create in your application’s resource +directory ({@code <project_dir>/res/xml/accessibility_service_config.xml}). The following code +shows example contents for the service configuration file:</p> + +<pre> +<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android" + android:description="@string/accessibility_service_description" + android:packageNames="com.example.android.apis" + android:accessibilityEventTypes="typeAllMask" + android:accessibilityFlags="flagDefault" + android:accessibilityFeedbackType="feedbackSpoken" + android:notificationTimeout="100" + android:canRetrieveWindowContent="true" + android:settingsActivity="com.example.android.accessibility.ServiceSettingsActivity" +/> +</pre> + +<p>One of the most important functions of the accessibility service configuration parameters is to +allow you to specify what types of accessibility events your service can handle. Being able to +specify this information enables accessibility services to cooperate with each other, and allows you +as a developer the flexibility to handle only specific events types from specific applications. The +event filtering can include the following criteria:</p> + +<ul> + <li><strong>Package Names</strong> - Specify the package names of applications whose accessibility +events you want your service to handle. If this parameter is omitted, your accessibility service is +considered available to service accessibility events for any application. This parameter can be set +in the accessibility service configuration files with the {@code android:packageNames} attribute as +a comma-separated list, or set using the {@link +android.accessibilityservice.AccessibilityServiceInfo#packageNames +AccessibilityServiceInfo.packageNames} member.</li> + <li><strong>Event Types</strong> - Specify the types of accessibility events you want your service +to handle. This parameter can be set in the accessibility service configuration files with the +{@code android:accessibilityEventTypes} attribute as a comma-separated list, or set using the +{@link android.accessibilityservice.AccessibilityServiceInfo#eventTypes +AccessibilityServiceInfo.eventTypes} member. </li> +</ul> + +<p>For more information about the XML attributes which can be used in the accessibility service + configuration file, follow these links to the reference documentation:</p> + +<ul> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_description">{@code android:description}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_packageNames">{@code android:packageNames}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_accessibilityEventTypes">{@code android:accessibilityEventTypes}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_accessibilityFlags">{@code android:accessibilityFlags}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_accessibilityFeedbackType">{@code android:accessibilityFeedbackType}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_notificationTimeout">{@code android:notificationTimeout}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_canRetrieveWindowContent">{@code android:canRetrieveWindowContent}</a></li> + <li><a href="{@docRoot}reference/android/R.styleable.html#AccessibilityService_settingsActivity">{@code android:settingsActivity}</a></li> +</ul> + +<p>For more information about which configuration settings can be dynamically set at runtime, see +the {@link android.accessibilityservice.AccessibilityServiceInfo} reference documentation.</p> + + +<h2 id="methods">AccessibilityService Methods</h2> + +<p>An application that provides accessibility service must extend the {@link +android.accessibilityservice.AccessibilityService} class and override the following methods from +that class. These methods are presented in the order in which they are called by the Android system, +from when the service is started +({@link android.accessibilityservice.AccessibilityService#onServiceConnected onServiceConnected()}), +while it is running ({@link android.accessibilityservice.AccessibilityService#onAccessibilityEvent +onAccessibilityEvent()}, +{@link android.accessibilityservice.AccessibilityService#onInterrupt onInterrupt()}) to when it is +shut down ({@link android.accessibilityservice.AccessibilityService#onUnbind onUnbind()}).</p> + +<ul> + <li>{@link android.accessibilityservice.AccessibilityService#onServiceConnected +onServiceConnected()} - (optional) This system calls this method when it successfully connects to +your accessibility service. Use this method to do any one-time setup steps for your service, +including connecting to user feedback system services, such as the audio manager or device vibrator. +If you want to set the configuration of your service at runtime or make one-time adjustments, this +is a convenient location from which to call {@link +android.accessibilityservice.AccessibilityService#setServiceInfo setServiceInfo()}.</li> + + <li>{@link android.accessibilityservice.AccessibilityService#onAccessibilityEvent +onAccessibilityEvent()} - (required) This method is called back by the system when it detects an +{@link android.view.accessibility.AccessibilityEvent} that matches the event filtering parameters +specified by your accessibility service. For example, when the user clicks a button or focuses on a +user interface control in an application for which your accessibility service is providing feedback. +When this happens, the system calls this method of your service with the associated {@link +android.view.accessibility.AccessibilityEvent}, which you can then interpret and provide feedback to +the user. This method may be called many times over the lifecycle of your service.</li> + + <li>{@link android.accessibilityservice.AccessibilityService#onInterrupt onInterrupt()} - +(required) This method is called when the system wants to interrupt the feedback your service is +providing, usually in response to a user taking action, such as moving focus to a different user +interface control than the one for which you are currently providing feedback. This method may be +called many times over the lifecycle of your service.</li> + + <li>{@link android.accessibilityservice.AccessibilityService#onUnbind onUnbind()} - (optional) +This method is called when the system is about to shutdown the accessibility service. Use this +method to do any one-time shutdown procedures, including de-allocating user feedback system +services, such as the audio manager or device vibrator.</li> +</ul> + +<p>These callback methods provide the basic structure for your accessibility service. It is up to +you to decide on how to process data provided by the Android system in the form of {@link +android.view.accessibility.AccessibilityEvent} objects and provide feedback to the user.</p> + + +<h2 id="event-details">Getting Event Details</h2> + +<p>The Android system provides information to accessibility services about the user interface +interaction through {@link android.view.accessibility.AccessibilityEvent} objects. Prior to Android +4.0, the information available in an accessibility event, while providing a significant amount of +detail about a user interface control selected by the user, typically provided limited contextual +information. In many cases, this missing context information might be critical to understanding the +meaning of the selected control.</p> + +<p>A typical example of an interface where context is of critical importance is a calendar or day +planner. If a user selects a 4:00 PM time slot in a Monday to Friday day list and the accessibility +service announces “4 PM”, but fails to indicate this is a Friday a Monday, the month or day, this is +hardly ideal feedback for the user. In this case, the context of a user interface control is of +critical importance to a user who wants to schedule a meeting.</p> + +<p>Android 4.0 significantly extends the amount of information that an accessibility service can +obtain about an user interface interaction by composing accessibility events based on the view +hierarchy. A view hierarchy is the set of user interface components that contain the component (its +parents) and the user interface elements that may be contained by that component (its children). In +this way, the Android system can provide much richer detail about accessibility events, allowing +accessibility services to provide more useful feedback to users.</p> + +<p>An accessibility service gets information about an user interface event through an {@link +android.view.accessibility.AccessibilityEvent} passed by the system to the service’s +{@link android.accessibilityservice.AccessibilityService#onAccessibilityEvent +onAccessibilityEvent()} callback method. This object provides details about the event, including the +type of object being acted upon, its descriptive text and other details. Starting in Android 4.0 +(and supported in previous releases through the {@link +android.support.v4.view.accessibility.AccessibilityEventCompat} object in the Support Library), you +can obtain additional information about the event using these calls:</p> + +<ul> + <li>{@link android.view.accessibility.AccessibilityEvent#getRecordCount +AccessibilityEvent.getRecordCount()} and {@link +android.view.accessibility.AccessibilityEvent#getRecord getRecord(int)} - These methods allow you to +retrieve the set of {@link android.view.accessibility.AccessibilityRecord} objects which contributed +to the {@link android.view.accessibility.AccessibilityEvent} passed to you by the system, which can +provide more context for your accessibility service.</li> + + <li>{@link android.view.accessibility.AccessibilityEvent#getSource +AccessibilityEvent.getSource()} - This method returns an {@link +android.view.accessibility.AccessibilityNodeInfo} object. This object allows you to request the +parents and children of the component that originated the accessibility event and investigate their +contents and state in order to provide + + <p class="caution"><strong>Important:</strong> The ability to investigate the full view +hierarchy from an {@link android.view.accessibility.AccessibilityEvent} potentially exposes private +user information to your accessibility service. For this reason, your service must request this +level of access through the accessibility <a href="#service-config">service configuration XML</a> +file, by including the {@code canRetrieveWindowContent} attribute and setting it to {@code true}. If +you do not include this setting in your service configuration xml file, calls to {@link +android.view.accessibility.AccessibilityEvent#getSource getSource()} fail.</p> + </li> +</ul> + + +<h2 id="examples">Example Code</h2> + +<p>The API Demo project contains two samples which can be used as a starting point for generating +accessibility services +({@code <sdk>/samples/<platform>/ApiDemos/src/com/example/android/apis/accessibility}): +</p> + +<ul> + <li><a href="{@docRoot}resources/samples/ApiDemos/src/com/example/android/apis/accessibility/ClockBackService.html">ClockBackService</a> + - This service is based on the original implementation of {@link +android.accessibilityservice.AccessibilityService} and can be used as a base for developing basic +accessibility services that are compatible with Android 1.6 (API Level 4) and higher.</li> + <li><a href="{@docRoot}resources/samples/ApiDemos/src/com/example/android/apis/accessibility/TaskBackService.html">TaskBackService</a> + - This service is based on the enhanced accessibility APIs introduced in Android 4.0 (API Level +14). However, you can use the Android <a href="{@docRoot}sdk/compatibility-library.html">Support +Libary</a> to substitute classes introduced in later API levels (e.g., +{@link android.view.accessibility.AccessibilityRecord}, +{@link android.view.accessibility.AccessibilityNodeInfo} +) with equivalent support package classes (e.g., +{@link android.support.v4.view.accessibility.AccessibilityRecordCompat}, +{@link android.support.v4.view.accessibility.AccessibilityNodeInfoCompat} +) to make this example work with API versions back to Android 1.6 (API Level 4).</li> +</ul> diff --git a/docs/html/guide/topics/ui/actionbar.jd b/docs/html/guide/topics/ui/actionbar.jd index e59fa0f..bf7369a 100644 --- a/docs/html/guide/topics/ui/actionbar.jd +++ b/docs/html/guide/topics/ui/actionbar.jd @@ -349,7 +349,7 @@ of the following:</p> <li><strong>Frequently used</strong>: It's an action that your users need seven out of ten visits or they use it several times in a row. <p>Example frequent actions: "New message" in the Messaging app and -"Search" in Android Market.</p> +"Search" on Google Play.</p> </li> <li><strong>Important</strong>: It's an action that you need users to easily discover or, if it's diff --git a/docs/html/guide/topics/ui/layout-objects.jd b/docs/html/guide/topics/ui/layout-objects.jd index 8b2792d..e251fe9 100644 --- a/docs/html/guide/topics/ui/layout-objects.jd +++ b/docs/html/guide/topics/ui/layout-objects.jd @@ -163,7 +163,7 @@ refer to the ID using the syntax of a relative resource <td> <pre> <?xml version="1.0" encoding="utf-8"?> -<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android +<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="wrap_content" android:background="@drawable/blue" diff --git a/docs/html/guide/topics/usb/adk.jd b/docs/html/guide/topics/usb/adk.jd index 4d5fbfa..c8949a3 100644 --- a/docs/html/guide/topics/usb/adk.jd +++ b/docs/html/guide/topics/usb/adk.jd @@ -97,6 +97,9 @@ page.title=Android Open Accessory Development Kit <li><a href="http://www.sparkfun.com/products/10748"> SparkFun</a></li> + <li><a href="http://troido.de/de/shoplsmallgbuy-android-stufflsmallg"> + Troido</a></li> + </ol> </div> </div> diff --git a/docs/html/guide/topics/wireless/bluetooth.jd b/docs/html/guide/topics/wireless/bluetooth.jd index 76da08e..0567799 100644 --- a/docs/html/guide/topics/wireless/bluetooth.jd +++ b/docs/html/guide/topics/wireless/bluetooth.jd @@ -249,12 +249,20 @@ if (!mBluetoothAdapter.isEnabled()) { <p>A dialog will appear requesting user permission to enable Bluetooth, as shown in Figure 1. If the user responds "Yes," the system will begin to enable Bluetooth and focus will return to your application once the process completes (or fails).</p> -<p>If enabling Bluetooth succeeds, your Activity will receive the {@link + +<p>The {@code REQUEST_ENABLE_BT} constant passed to {@link +android.app.Activity#startActivityForResult(Intent,int) startActivityForResult()} is a locally +defined integer (which must be greater than 0), that the system passes back to you in your +{@link +android.app.Activity#onActivityResult(int,int,Intent) onActivityResult()} implementation as the +<code>requestCode</code> parameter.</p> + +<p>If enabling Bluetooth succeeds, your activity receives the {@link android.app.Activity#RESULT_OK} result code in the {@link android.app.Activity#onActivityResult(int,int,Intent) onActivityResult()} callback. If Bluetooth was not enabled -due to an error (or the user responded "No") then the result code will be {@link -android.app.Activity#RESULT_CANCELED}.</p> +due to an error (or the user responded "No") then the result code is {@link +android.app.Activity#RESULT_CANCELED}.</p> </li> </ol> @@ -431,11 +439,11 @@ startActivity(discoverableIntent); <p>A dialog will be displayed, requesting user permission to make the device discoverable, as shown in Figure 2. If the user responds "Yes," then the device -will become discoverable for the specified amount of time. Your Activity will +will become discoverable for the specified amount of time. Your activity will then receive a call to the {@link android.app.Activity#onActivityResult(int,int,Intent) onActivityResult())} callback, with the result code equal to the duration that the device is discoverable. If the user responded "No" or if an error occurred, the result code will -be Activity.RESULT_CANCELLED.</p> +be {@link android.app.Activity#RESULT_CANCELED}.</p> <p class="note"><strong>Note:</strong> If Bluetooth has not been enabled on the device, then enabling device discoverability will automatically enable Bluetooth.</p> @@ -568,7 +576,7 @@ socket.</p> </ol> <p>The {@link android.bluetooth.BluetoothServerSocket#accept()} call should not -be executed in the main Activity UI thread because it is a blocking call and +be executed in the main activity UI thread because it is a blocking call and will prevent any other interaction with the application. It usually makes sense to do all work with a {@link android.bluetooth.BluetoothServerSocket} or {@link android.bluetooth.BluetoothSocket} in a new @@ -696,7 +704,7 @@ android.bluetooth.BluetoothSocket#connect()} method times out (after about 12 seconds), then it will throw an exception.</p> <p>Because {@link android.bluetooth.BluetoothSocket#connect()} is a blocking call, this connection -procedure should always be performed in a thread separate from the main Activity +procedure should always be performed in a thread separate from the main activity thread.</p> <p class="note">Note: You should always ensure that the device is not performing device discovery when you call {@link @@ -838,7 +846,7 @@ private class ConnectedThread extends Thread { try { // Read from the InputStream bytes = mmInStream.read(buffer); - // Send the obtained bytes to the UI Activity + // Send the obtained bytes to the UI activity mHandler.obtainMessage(MESSAGE_READ, bytes, -1, buffer) .sendToTarget(); } catch (IOException e) { @@ -847,14 +855,14 @@ private class ConnectedThread extends Thread { } } - /* Call this from the main Activity to send data to the remote device */ + /* Call this from the main activity to send data to the remote device */ public void write(byte[] bytes) { try { mmOutStream.write(bytes); } catch (IOException e) { } } - /* Call this from the main Activity to shutdown the connection */ + /* Call this from the main activity to shutdown the connection */ public void cancel() { try { mmSocket.close(); @@ -866,12 +874,12 @@ private class ConnectedThread extends Thread { <p>The constructor acquires the necessary streams and once executed, the thread will wait for data to come through the InputStream. When {@link java.io.InputStream#read(byte[])} returns with -bytes from the stream, the data is sent to the main Activity using a member +bytes from the stream, the data is sent to the main activity using a member Handler from the parent class. Then it goes back and waits for more bytes from the stream.</p> <p>Sending outgoing data is as simple as calling the thread's -<code>write()</code> method from the main Activity and passing in the bytes to +<code>write()</code> method from the main activity and passing in the bytes to be sent. This method then simply calls {@link java.io.OutputStream#write(byte[])} to send the data to the remote device.</p> diff --git a/docs/html/guide/topics/wireless/wifip2p.jd b/docs/html/guide/topics/wireless/wifip2p.jd index 4dd3d26..ec8e71e 100644 --- a/docs/html/guide/topics/wireless/wifip2p.jd +++ b/docs/html/guide/topics/wireless/wifip2p.jd @@ -333,7 +333,7 @@ protected void onCreate(Bundle savedInstanceState){ ... mManager = (WifiP2pManager) getSystemService(Context.WIFI_P2P_SERVICE); mChannel = mManager.initialize(this, getMainLooper(), null); - Receiver = new WiFiDirectBroadcastReceiver(manager, channel, this); + mReceiver = new WiFiDirectBroadcastReceiver(manager, channel, this); ... } </pre> @@ -364,13 +364,13 @@ protected void onCreate(Bundle savedInstanceState){ @Override protected void onResume() { super.onResume(); - registerReceiver(receiver, intentFilter); + registerReceiver(mReceiver, mIntentFilter); } /* unregister the broadcast receiver */ @Override protected void onPause() { super.onPause(); - unregisterReceiver(receiver); + unregisterReceiver(mReceiver); } </pre> diff --git a/docs/html/guide/tutorials/views/hello-mapview.jd b/docs/html/guide/tutorials/views/hello-mapview.jd index 458db4f..5217b6b 100644 --- a/docs/html/guide/tutorials/views/hello-mapview.jd +++ b/docs/html/guide/tutorials/views/hello-mapview.jd @@ -14,8 +14,8 @@ location:</p> href="http://code.google.com/android/add-ons/google-apis">http://code.google.com/android/add-ons/google-apis</a></p> <p>The Google APIs add-on requires Android 1.5 SDK or later release. After -installing the add-on in your SDK, set your project properties to use the build -target called "Google APIs Add-on". See the instructions for setting a build +installing the add-on in your SDK, set your project properties to use a <strong>Google +APIs</strong> build target. See the instructions for setting a build target in <a href="{@docRoot}guide/developing/eclipse-adt.html">Developing in Eclipse with ADT</a> or <a href="{@docRoot}guide/developing/other-ide.html">Developing in Other IDEs</a>, |