Merge "resolved conflicts for merge of 532679a5 to master"
diff --git a/core/java/android/app/ApplicationErrorReport.java b/core/java/android/app/ApplicationErrorReport.java
index 588125d..ebf42619 100644
--- a/core/java/android/app/ApplicationErrorReport.java
+++ b/core/java/android/app/ApplicationErrorReport.java
@@ -98,7 +98,7 @@
/**
* Package name of the application which installed the application this
* report pertains to.
- * This identifies which Market the application came from.
+ * This identifies which market the application came from.
*/
public String installerPackageName;
diff --git a/core/java/android/content/Intent.java b/core/java/android/content/Intent.java
index ab62c44..b1b09d5 100644
--- a/core/java/android/content/Intent.java
+++ b/core/java/android/content/Intent.java
@@ -1137,7 +1137,7 @@
/**
* Activity Action: The user pressed the "Report" button in the crash/ANR dialog.
* This intent is delivered to the package which installed the application, usually
- * the Market.
+ * Google Play.
* <p>Input: No data is specified. The bug report is passed in using
* an {@link #EXTRA_BUG_REPORT} field.
* <p>Output: Nothing.
diff --git a/core/java/android/os/StrictMode.java b/core/java/android/os/StrictMode.java
index a0ad9c0..759be91 100644
--- a/core/java/android/os/StrictMode.java
+++ b/core/java/android/os/StrictMode.java
@@ -109,7 +109,7 @@
* effort mechanism. Notably, disk or network access from JNI calls
* won't necessarily trigger it. Future versions of Android may catch
* more (or fewer) operations, so you should never leave StrictMode
- * enabled in shipping applications on the Android Market.
+ * enabled in applications distributed on Google Play.
*/
public final class StrictMode {
private static final String TAG = "StrictMode";
diff --git a/core/java/android/provider/Settings.java b/core/java/android/provider/Settings.java
index b42417a..bc6594b 100644
--- a/core/java/android/provider/Settings.java
+++ b/core/java/android/provider/Settings.java
@@ -2644,10 +2644,10 @@
/**
* Whether the package installer should allow installation of apps downloaded from
- * sources other than the Android Market (vending machine).
+ * sources other than Google Play.
*
* 1 = allow installing from other sources
- * 0 = only allow installing from the Android Market
+ * 0 = only allow installing from Google Play
*/
public static final String INSTALL_NON_MARKET_APPS = "install_non_market_apps";
diff --git a/docs/html/design/building-blocks/progress.html b/docs/html/design/building-blocks/progress.html
index 32183bc..500ccb1 100644
--- a/docs/html/design/building-blocks/progress.html
+++ b/docs/html/design/building-blocks/progress.html
@@ -147,7 +147,7 @@
<li class="value-1"><h4>Activity bar (shown with the Holo Dark theme)</h4>
<p>
-An indeterminate activity bar is used at the start of an application download because Market hasn't
+An indeterminate activity bar is used at the start of an application download because Google Play hasn't
been able to contact the server yet, and it's not possible to determine how long it will take for
the download to begin.
diff --git a/docs/html/design/building-blocks/tabs.html b/docs/html/design/building-blocks/tabs.html
index d4b0e52..029e484 100644
--- a/docs/html/design/building-blocks/tabs.html
+++ b/docs/html/design/building-blocks/tabs.html
@@ -130,7 +130,7 @@
<source src="../static/content/tabs_scrolly.ogv" type="video/ogg">
</video>
<div class="figure-caption">
- Scrolling tabs in Android Market.
+ Scrolling tabs on Google Play.
<div class="video-instructions"> </div>
</div>
diff --git a/docs/html/design/patterns/actionbar.html b/docs/html/design/patterns/actionbar.html
index 1566d04..e93498e 100644
--- a/docs/html/design/patterns/actionbar.html
+++ b/docs/html/design/patterns/actionbar.html
@@ -281,7 +281,7 @@
<source src="../static/content/tabs_scrolly.ogv" type="video/ogg">
</video>
<div class="figure-caption">
- Scrolling tabs in Android Market.
+ Scrolling tabs on Google Play.
<div class="video-instructions"> </div>
</div>
diff --git a/docs/html/design/patterns/app-structure.html b/docs/html/design/patterns/app-structure.html
index 1b48280..6780594 100644
--- a/docs/html/design/patterns/app-structure.html
+++ b/docs/html/design/patterns/app-structure.html
@@ -112,7 +112,7 @@
single screen</li>
<li>Apps such as Phone whose main purpose is to switch between different activities without deeper
navigation</li>
-<li>Apps such as Gmail or Market that combine a broad set of data views with deep navigation</li>
+<li>Apps such as Gmail and Google Play that combine a broad set of data views with deep navigation</li>
</ul>
<p>Your app's structure depends largely on the content and tasks you want to surface for your users.</p>
<h2 id="general-structure">General Structure</h2>
@@ -165,7 +165,7 @@
<img src="../static/content/app_structure_market.png">
<div class="figure-caption">
- Market's start screen primarily allows navigation into the stores for Apps, Music, Books,
+ The Google Play app's start screen primarily allows navigation into the stores for Apps, Music, Books,
Movies and Games. It is also enriched with tailored recommendations and promotions that
surface content of interest to the user. Search is readily available from the action bar.
</div>
@@ -250,7 +250,7 @@
<img src="../static/content/app_structure_scrolltabs.png">
<div class="figure-caption">
- Market uses tabs to simultaneously show category choice and content. To navigate between
+ Google Play uses tabs to simultaneously show category choice and content. To navigate between
categories, users can swipe left/right on the content.
</div>
diff --git a/docs/html/design/patterns/navigation.html b/docs/html/design/patterns/navigation.html
index 6287b5e..5d1568e 100644
--- a/docs/html/design/patterns/navigation.html
+++ b/docs/html/design/patterns/navigation.html
@@ -167,7 +167,7 @@
<img src="../static/content/navigation_between_siblings_gmail.png">
<p>However, a notable exception to this occurs when browsing between "related" detail views not tied
-together by the referring list—for example, when browsing in the Market between apps from
+together by the referring list—for example, when browsing on Google Play between apps from
the same developer, or albums by the same artist. In these cases, following each link does create
history, causing the Back button to step through each screen of related content which has been
viewed. Up should continue to bypass these related screens and navigate to the most recently viewed
@@ -176,7 +176,7 @@
<img src="../static/content/navigation_between_siblings_market1.png">
<p>You have the ability to make the Up behavior even smarter based on your knowledge of detail
-view. If we extend our Market sample from above, imagine the user has navigated from the last Book
+view. If we extend our Google Play sample from above, imagine the user has navigated from the last Book
viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies)
which the user had not previously navigated through.</p>
@@ -200,10 +200,10 @@
- If the destination screen is typically reached from one particular screen within your app, Up
should navigate to that screen.
- Otherwise, Up should navigate to the topmost ("Home") screen of your app.</p>
-<p>For example, after choosing to share a book being viewed in Market, the user navigates directly to
+<p>For example, after choosing to share a book being viewed on Google Play, the user navigates directly to
Gmail's compose screen. From there, Up returns to the Inbox (which happens to be both the
typical referrer to compose, as well as the topmost screen of the app), while Back returns to
-Market.</p>
+Google Play.</p>
<img src="../static/content/navigation_from_outside_up.png">
diff --git a/docs/html/design/style/iconography.html b/docs/html/design/style/iconography.html
index 96954de..0b2852e 100644
--- a/docs/html/design/style/iconography.html
+++ b/docs/html/design/style/iconography.html
@@ -146,7 +146,7 @@
<li class="no-bullet with-icon tablet">
<p>Launcher icons on a mobile device must be <strong>48x48 <acronym title="Density-independent pixels. One dp is one pixel on a 160 dpi screen.">dp</acronym></strong>.</p></li>
<li class="no-bullet with-icon web">
- <p>Launcher icons for display in Market must be <strong>512x512 pixels</strong>.</p></li>
+ <p>Launcher icons for display on Google Play must be <strong>512x512 pixels</strong>.</p></li>
</ul>
</div>
diff --git a/docs/html/guide/appendix/install-location.jd b/docs/html/guide/appendix/install-location.jd
index e5ed226..63a3817 100644
--- a/docs/html/guide/appendix/install-location.jd
+++ b/docs/html/guide/appendix/install-location.jd
@@ -172,9 +172,9 @@
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/market/licensing/index.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 @@
<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 @@
<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 @@
</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 @@
<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 @@
<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 @@
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 @@
<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 @@
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 @@
</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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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 @@
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 @@
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 @@
</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 @@
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/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 @@
<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/guide_toc.cs b/docs/html/guide/guide_toc.cs
index fd2ec93..9d5064e 100644
--- a/docs/html/guide/guide_toc.cs
+++ b/docs/html/guide/guide_toc.cs
@@ -444,12 +444,12 @@
</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 class="toggle-list">
<div><a href="<?cs var:toroot ?>guide/market/licensing/index.html">
@@ -496,7 +496,7 @@
</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>
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 @@
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 @@
</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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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 @@
<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 @@
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 @@
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 @@
<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 @@
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 @@
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..57f685b 100755
--- a/docs/html/guide/market/billing/billing_integrate.jd
+++ b/docs/html/guide/market/billing/billing_integrate.jd
@@ -35,8 +35,8 @@
</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 @@
<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>
@@ -109,12 +109,12 @@
<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 @@
<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>
@@ -171,7 +171,7 @@
<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 @@
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 @@
</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 @@
<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 @@
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 @@
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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
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 @@
<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 @@
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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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 @@
<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 @@
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 @@
}
</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 @@
<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 @@
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 @@
<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 @@
</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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
</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 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 @@
<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 @@
<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 @@
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 @@
<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 @@
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 @@
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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
</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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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.</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 @@
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 @@
<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 @@
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 @@
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 @@
</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 @@
<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 @@
<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
index fad30e9..26e63ec 100644
--- a/docs/html/guide/market/expansion-files.jd
+++ b/docs/html/guide/market/expansion-files.jd
@@ -8,7 +8,7 @@
<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>Android Market hosts and serves the expansion files at no charge</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>
@@ -61,28 +61,28 @@
-<p>Android Market currently requires that your APK file be no more than 50MB. For most
+<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, Android Market allows you to attach two large expansion files that supplement your
+for users, Google Play allows you to attach two large expansion files that supplement your
APK.</p>
-<p>Android Market hosts the expansion files for your application and serves them to the device at
+<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, Android Market downloads the expansion file(s) at the same time it
+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 Android Market
+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 Android Market Developer Console, you have the option to
+<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>
@@ -102,7 +102,7 @@
<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 Android Market
+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
@@ -115,7 +115,7 @@
<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, Android Market considers them opaque binary blobs and renames the files
+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">
@@ -133,7 +133,7 @@
<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 Android Market Developer Console allows you to
+ <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>
@@ -147,9 +147,9 @@
<h3 id="StorageLocation">Storage location</h3>
-<p>When Android Market downloads your expansion files to a device, it saves them to the system's
+<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 Android Market
+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>
@@ -194,27 +194,27 @@
<h3 id="DownloadProcess">Download process</h3>
-<p>Most of the time, Android Market downloads and saves your expansion files at the same time it
-downloads the APK to the device. However, in some cases Android Market
+<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 Android Market.</p>
+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 Android Market.</li>
- <li>If Android Market is able to download the expansion files (which is the case for most
+ <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 Android Market is unable to download the expansion files, it downloads the
+ <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 Android Market. Your app
-must send a request to the Android Market client using the Android Market's <a
+ <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>
@@ -223,7 +223,7 @@
</ol>
<p class="caution"><strong>Caution:</strong> It is critical that you include the necessary code to
-download the expansion files from Android Market in the event that the files are not already on the
+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
@@ -258,7 +258,7 @@
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 Android Market's <a
+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
@@ -280,15 +280,15 @@
<h2 id="Rules">Rules and Limitations</h2>
<p>Adding APK expansion files is a feature available when you upload your application using the
-Android Market Developer Console. When uploading your application for the first time or updating an
+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 Android Market, <strong>the user must have
-acquired your application from Android Market</strong>. Android Market will not
+ <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 Android Market
+ <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
@@ -313,7 +313,7 @@
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 Android Market (or your app itself) to repeatedly
+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>
@@ -328,11 +328,11 @@
<h2 id="Downloading">Downloading the Expansion Files</h2>
-<p>In most cases, Android Market downloads and saves your expansion files to the device at the same
+<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 Android Market's <a
+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>
@@ -345,15 +345,15 @@
<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 Android Market's <a
+ <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 Android Market to download the expansion files and save
+ <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 Android Market's response.
- <p class="note"><strong>Note:</strong> The URL that Android Market provides for your
+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>
@@ -368,16 +368,16 @@
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 Android Market). In order to facilitate the
+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 Android Market. So, even if your application is free for users, you need to include the Android
-Market License Verification Library (LVL) to use APK expansion files. Of course, if your application
+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, Android Market
-returns the expansion file URLs only if the user acquired your application from Android Market.</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.
@@ -464,7 +464,7 @@
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 "Android Market License Library" and "Market
+ <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>
@@ -495,7 +495,7 @@
<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
-Android Market. The format that you choose for the expansion files and how you read them
+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>
@@ -518,10 +518,10 @@
<pre>
<manifest ...>
- <!-- Required to access Android Market Licensing -->
+ <!-- Required to access Google Play Licensing -->
<uses-permission android:name="com.android.vending.CHECK_LICENSE" />
- <!-- Required to download files from Android Market -->
+ <!-- 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) -->
@@ -570,7 +570,7 @@
<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 Android Market Developer Console (see <a
+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
@@ -589,7 +589,7 @@
<pre>
public class SampleDownloaderService extends DownloaderService {
// You must use the public key belonging to your publisher account
- public static final String BASE64_PUBLIC_KEY = "YourAndroidMarketLVLKey";
+ 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
@@ -613,8 +613,8 @@
</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 Android
-Market Developer Console under your profile information. This is necessary even when testing
+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>
@@ -899,11 +899,11 @@
<h2 id="ExpansionPolicy">Using APKExpansionPolicy</h2>
-<p>If you decide to build your own downloader service instead of using the Android Market
+<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
-Android Market License Verification Library) but includes additional handling for the APK expansion
+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
@@ -1144,21 +1144,21 @@
<h3 id="TestingReading">Testing file reads</h3>
-<p>Before you upload your application to Android Market, you
+<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 Android
-Market will save your files.
+ <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 Android Market will use.
+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>
@@ -1166,7 +1166,7 @@
<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
-Android Market.
+Google Play.
</ul>
</li>
<li>Now that the expansion file(s) are on the device, you can install and run your application to
@@ -1176,7 +1176,7 @@
<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 Android Market (or your app itself) to
+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
@@ -1192,16 +1192,16 @@
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 Android Market as a "draft" to make your expansion files available for
+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 Android Market Developer
+ <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 Android Market users,
+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>
@@ -1216,14 +1216,14 @@
<h2 id="Updating">Updating Your Application</h2>
-<p>One of the great benefits to using expansion files on Android Market is the ability to
-update your application without re-downloading all of the original assets. Because Android Market
+<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 Android Market perform actual patching between your main and patch expansion
+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
@@ -1232,13 +1232,13 @@
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 Android Market to perform an update.
+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 Android Market Developer Console, users who previously installed your application will not
+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>
@@ -1246,7 +1246,7 @@
<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, Android Market deletes the
+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.
diff --git a/docs/html/guide/market/licensing/adding-licensing.jd b/docs/html/guide/market/licensing/adding-licensing.jd
index d1fe839..d4dd008 100644
--- a/docs/html/guide/market/licensing/adding-licensing.jd
+++ b/docs/html/guide/market/licensing/adding-licensing.jd
@@ -82,7 +82,7 @@
<h2 id="manifest-permission">Adding the Licensing Permission</h2>
-<p>To use the Android Market application for sending a license check to the
+<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,
@@ -101,7 +101,7 @@
<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. -->
+ <!-- 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" />
@@ -123,7 +123,7 @@
<h2>ServerManagedPolicy</h2>
<p>The LVL includes a complete {@code Policy} implementation called ServerManagedPolicy
-that makes use of license-management settings provided by the Android Market
+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
@@ -133,7 +133,7 @@
</div>
</div>
-<p>Android Market licensing service does not itself determine whether a
+<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>
@@ -227,7 +227,7 @@
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 Android Market client automatically retries failed
+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
@@ -286,7 +286,7 @@
<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
+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
@@ -298,7 +298,7 @@
Extras</a>.</p>
<p>For convenience, best performance, and the benefit of using license settings
-from the Android Market server, <strong>using ServerManagedPolicy as your
+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
@@ -446,7 +446,7 @@
<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 Android Market
+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>
@@ -647,11 +647,11 @@
<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 Market, from which the
+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">Using Intents to
-Launch the Market Application on a Device</a>. </li>
+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>
@@ -688,7 +688,7 @@
// 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 Android Market to purchase the app.
+ // take them to Google Play to purchase the app.
showDialog(DIALOG_GOTOMARKET);
}
}
@@ -707,16 +707,16 @@
<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 Android Market
+<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 Android Market application
+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 Android Market application, including the call that sends the request and
+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>
@@ -858,14 +858,14 @@
<h3 id="account-key">Embed your public key for licensing</h3>
-<p>For each publisher account, the Android Market service automatically
+<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 Android Market publisher site exposes the public key for licensing to any
+<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
@@ -878,8 +878,8 @@
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.
+<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>
@@ -907,7 +907,7 @@
{@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 Android Market
+{@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>
@@ -992,13 +992,13 @@
<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>
+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 Android Market. Follow the normal steps to <a
+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>.
@@ -1021,7 +1021,7 @@
support you need more quickly. </p>
<p class="table-caption"><strong>Table 2.</strong> Developer support resources
-for Android Market Licensing Service.</p>
+for Google Play Licensing Service.</p>
<table>
@@ -1045,8 +1045,8 @@
</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><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>
diff --git a/docs/html/guide/market/licensing/index.jd b/docs/html/guide/market/licensing/index.jd
index f08176d..b9a7154 100644
--- a/docs/html/guide/market/licensing/index.jd
+++ b/docs/html/guide/market/licensing/index.jd
@@ -2,9 +2,9 @@
@jd:body
-<p>Android Market offers a licensing service that lets you enforce licensing policies for
-applications that you publish on Android Market. With Android Market Licensing, your application can
-query Android Market at run time to obtain the licensing status for the current user, then allow or
+<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
@@ -15,26 +15,26 @@
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 Android Market server signs the licensing status
+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 Android Market can use the Android Market Licensing
+<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 Android Market Licensing service is primarily intended
+<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 Android Market. However, any application (including free apps) may use the licensing service
+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 Android Market's application licensing service and start integrating it into
+<p>To learn more about Google Play's application licensing service and start integrating it into
your applications, read the following documents:</p>
<dl>
@@ -44,7 +44,7 @@
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 Android Market account, development environment, and
+ <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>
diff --git a/docs/html/guide/market/licensing/licensing-reference.jd b/docs/html/guide/market/licensing/licensing-reference.jd
index ac5d596..0a7e033 100644
--- a/docs/html/guide/market/licensing/licensing-reference.jd
+++ b/docs/html/guide/market/licensing/licensing-reference.jd
@@ -117,7 +117,7 @@
<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>
+Google Play client.</td>
</tr>
<tr>
<td><em>ILicenseResultListener</em></td>
@@ -137,7 +137,7 @@
necessary handling of these response codes for you. </p>
<p class="table-caption"><strong>Table 2.</strong> Summary of response codes
-returned by the Android Market server in a license response.</p>
+returned by the Google Play server in a license response.</p>
<table>
@@ -178,7 +178,7 @@
</tr>
<tr>
<td>{@code ERROR_CONTACTING_SERVER}</td>
-<td>Local error — the Android Market application was not able to reach the
+<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>
@@ -217,12 +217,12 @@
<tr>
<td>{@code ERROR_NOT_MARKET_MANAGED}</td>
<td>Server error — the application (package name) was not recognized by
-Android Market. </td>
+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 Android Market or that there is an development error in the licensing
+through Google Play or that there is an development error in the licensing
implementation.</p>
</td>
</tr>
@@ -233,7 +233,7 @@
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
-Android Market publisher site.
+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
@@ -263,7 +263,7 @@
settings. </p>
<p class="table-caption"><strong>Table 3.</strong> Summary of
-license-management settings supplied by the Android Market server in a license
+license-management settings supplied by the Google Play server in a license
response.</p>
<table>
@@ -329,7 +329,7 @@
<h4 id="VT">License validity period</h4>
-<p>The Android Market licensing server sets a license validity period for all
+<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
@@ -351,7 +351,7 @@
<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
+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>
@@ -381,15 +381,15 @@
<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
+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 Android
-Market client notifies the application by returning a {@code RETRY} response code to
+<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 Android Market's
+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>
@@ -397,7 +397,7 @@
<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 Android Market server helps an application to manage licensing under
+<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>
diff --git a/docs/html/guide/market/licensing/overview.jd b/docs/html/guide/market/licensing/overview.jd
index 3576e26..05a3a40 100644
--- a/docs/html/guide/market/licensing/overview.jd
+++ b/docs/html/guide/market/licensing/overview.jd
@@ -9,9 +9,9 @@
<h2>Quickview</h2>
<ul>
- <li>Licensing allows you to verify your app was purchased from Android Market</li>
+ <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 Android Market</li>
+ <li>The service is free for all developers who publish on Google Play</li>
</ul>
<h2>In this document</h2>
@@ -26,19 +26,19 @@
</div>
-<p>Android Market Licensing is a network-based service that lets an application query a trusted
-Android Market licensing server to determine whether the application is licensed to the current
-device user. The licensing service is based on the capability of the Android Market licensing server
-to determine whether a given user is licensed to use a given application. Android Market considers a
+<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 Android Market client application. The Android Market application then sends a request to
-the licensing server and receives the result. The Android Market application sends
+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 Android Market but
+<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
@@ -48,39 +48,39 @@
<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 Android Market
-client, which handles communication with the Market server.</p>
+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 Android Market client work
-together to assemble the information and the Android Market client passes it to the server. </p>
+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 Billing
+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 Android Market licensing service. With
+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 Android Market client over remote IPC to
+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 Android Market client collects the necessary information about the user and the device,
+<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 Android Market server evaluates the request using all available information, attempting
+<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 Android Market client returns to your
+returns a license response, which the Google Play client returns to your
application over the IPC callback.</li>
</ul>
@@ -97,7 +97,7 @@
<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 Android Market
+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
@@ -120,7 +120,7 @@
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 Android Market client to initiate a license request and
+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>
@@ -179,17 +179,17 @@
<h2 id="Reqs">Requirements and Limitations</h2>
-<p>Android Market Licensing is designed to let you apply license controls to
-applications that you publish through Android Market. The service is not
+<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 Android Market or that are run on devices that do not offer the Android
-Market client. </p>
+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 Android Market client is
+<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
@@ -202,7 +202,7 @@
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 Android Market.</li>
+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>
@@ -212,20 +212,20 @@
<h2 id="CopyProtection">Replacement for Copy Protection</h2>
-<p>Android Market Licensing is a flexible, secure mechanism for controlling
+<p>Google Play 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
+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 Android Market is
+<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 Market to a device that provides root
+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 Android Market licensing, you can move to a license-based model in
+<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 Android Market and the licensing policy that you define.
+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>
diff --git a/docs/html/guide/market/licensing/setting-up.jd b/docs/html/guide/market/licensing/setting-up.jd
index c79f90b..15214d1 100644
--- a/docs/html/guide/market/licensing/setting-up.jd
+++ b/docs/html/guide/market/licensing/setting-up.jd
@@ -31,27 +31,27 @@
</div>
</div>
-<p>Before you start adding license verification to your application, you need to set up your Android
-Market publishing account, your development environment, and test accounts required to verify
+<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 Android Market, you need to register for one
-using your Google account and agree to the terms of service on the Android Market publisher site:</p>
+<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://market.android.com/publish">http://market.android.com/publish</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 Android Market</a>.</p>
+href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play</a>.</p>
-<p>If you already have a publisher account on Android Market, use your existing
+<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 Android Market, you can:</p>
+<p>Using your publisher account on Google Play, you can:</p>
<ul>
<li>Obtain a public key for licensing</li>
@@ -63,7 +63,7 @@
<h4>Administrative settings for licensing</h4>
<p>You can manage several
-administrative controls for Android Market licensing on the publisher site. The controls are available
+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>
@@ -114,17 +114,17 @@
<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
+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 Android Market service, so that your application is able
+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 Android Market application, or</li>
+<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>
@@ -137,12 +137,12 @@
<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 Android Market client application
+<li>Run a system image on which the Google Play 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>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
@@ -154,16 +154,16 @@
licensing.</p>
<p>Because the Android platforms provided in the Android SDK <em>do
-not</em> include Android Market, you need to download the Google APIs Add-On
+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 Android Market client.
+<p>The Google APIs Add-On does not include the full Google Play client.
However, it does provide: </p>
<ul>
-<li>An Android Market background service that implements the
+<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
@@ -174,8 +174,8 @@
</ul>
<p>Several versions of the add-on are available through the SDK Manager, but only
-<strong>Google APIs Add-On, API 8 (release 2) or higher</strong> includes the necessary Android
-Market services.</p>
+<strong>Google APIs Add-On, API 8 (release 2) or higher</strong> includes the necessary Google
+Play services.</p>
<img src="{@docRoot}images/licensing_gapis_8.png" alt=""/>
@@ -256,11 +256,11 @@
<p>To download the LVL component into your development environment, use the
Android SDK Manager. Launch the Android SDK Manager and then
-select the "Market Licensing" component, as shown in figure 3.
+select the "Google Market Licensing" component, as shown in figure 3.
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 3.</strong> The Market Licensing package contains the LVL and
+<p class="img-caption"><strong>Figure 3.</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
@@ -297,7 +297,7 @@
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
+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>
@@ -438,7 +438,7 @@
<h2 id="test-env">Setting Up the Testing Environment</h2>
-<p>The Android Market publisher site provides configuration tools that let you
+<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
@@ -454,7 +454,7 @@
<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
+<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>
@@ -472,7 +472,7 @@
<h3 id="test-response">Setting test responses for license checks</h3>
-<p>Android Market provides a configuration setting in your publisher account
+<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
@@ -522,7 +522,7 @@
<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
+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>
@@ -632,11 +632,11 @@
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
+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 Android Market application terminates 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
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 @@
<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 @@
</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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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 @@
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 @@
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 @@
</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 @@
<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 @@
<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 @@
</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 @@
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 @@
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 @@
<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 @@
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 @@
<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 @@
<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 @@
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 @@
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 @@
<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 @@
<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 @@
<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 @@
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 @@
<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 @@
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.jd b/docs/html/guide/practices/design/accessibility.jd
index a66a974..72da04e 100644
--- a/docs/html/guide/practices/design/accessibility.jd
+++ b/docs/html/guide/practices/design/accessibility.jd
@@ -332,11 +332,10 @@
<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
+href="https://play.google.com/store/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>
+Android-powered devices, but is also available for free from the <a
+href="https://play.google.com/store/details?id=com.google.android.marvin.talkback">Google Play</a> store.</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
diff --git a/docs/html/guide/practices/optimizing-for-3.0.jd b/docs/html/guide/practices/optimizing-for-3.0.jd
index 39662f1..140c50c 100644
--- a/docs/html/guide/practices/optimizing-for-3.0.jd
+++ b/docs/html/guide/practices/optimizing-for-3.0.jd
@@ -481,7 +481,7 @@
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 @@
</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 @@
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 @@
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 @@
<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 @@
<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 @@
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 @@
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 @@
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 @@
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 @@
<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 @@
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..29dff26 100644
--- a/docs/html/guide/practices/screens_support.jd
+++ b/docs/html/guide/practices/screens_support.jd
@@ -882,8 +882,8 @@
<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>
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..f8ca3f8 100644
--- a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd
+++ b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd
@@ -886,7 +886,7 @@
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 @@
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 @@
<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 @@
</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 @@
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 @@
-<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 @@
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/publishing/app-signing.jd b/docs/html/guide/publishing/app-signing.jd
index 9abcdf7..e86ec30 100644
--- a/docs/html/guide/publishing/app-signing.jd
+++ b/docs/html/guide/publishing/app-signing.jd
@@ -82,7 +82,7 @@
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 @@
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>
@@ -292,7 +292,7 @@
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>
diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd
index c355479..fe56352 100644
--- a/docs/html/guide/publishing/preparing.jd
+++ b/docs/html/guide/publishing/preparing.jd
@@ -22,7 +22,7 @@
<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 @@
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 @@
<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 @@
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 @@
<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 @@
</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,16 +283,15 @@
<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/market/licensing/index.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>
@@ -353,7 +352,7 @@
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 27a87f9..952e602 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 @@
<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 @@
<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 @@
</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/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 @@
<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 @@
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 @@
<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 @@
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 @@
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/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,53 +282,53 @@
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/...} 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>
@@ -344,14 +344,14 @@
<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);
@@ -359,7 +359,7 @@
startActivity(intent);
</pre>
-<p>This will open the Android Market application on the device to view the {@code
+<p>This will open the Google Play application on the device to view the {@code
com.android.example} application.</p>
@@ -369,32 +369,32 @@
format:</p>
<p style="margin-left:2em">
- <code>http://market.android.com/details?id=<package_name></code>
+ <code>http://play.google.com/store/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/details?id=com.android.example">App Link</a>
</pre>
-<p>When clicked from a desktop web browser, this opens the Android Market web site to view the
+<p>When clicked from a desktop web browser, this opens the Google Play 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
+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 +410,14 @@
<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,43 +426,43 @@
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
+<p>Use the following form to generate an "Available on Google Play" 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>
+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
+<p>This form offers four versions of the official "Available on Google Play" 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>
@@ -507,18 +507,18 @@
// 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>";
+ + " alt=\"Available on Google Play\" />\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>";
+ + " alt=\"Available on Google Play\" />\n</a>";
/** Generate the HTML snippet and demo based on form values */
function buildButton(form) {
@@ -658,7 +658,7 @@
<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 +670,19 @@
<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/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 c94d201..6fb77e1 100755
--- a/docs/html/guide/publishing/publishing_overview.jd
+++ b/docs/html/guide/publishing/publishing_overview.jd
@@ -14,7 +14,7 @@
<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 @@
<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 @@
</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 @@
<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,28 +114,27 @@
<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/market/licensing/index.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">
@@ -144,19 +143,19 @@
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
@@ -170,21 +169,21 @@
</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">
@@ -198,7 +197,7 @@
</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>
@@ -209,7 +208,7 @@
<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>
@@ -223,7 +222,7 @@
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 @@
<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 @@
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 @@
<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 @@
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 @@
</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/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 @@
<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 @@
<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 @@
<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/manifest/activity-element.jd b/docs/html/guide/topics/manifest/activity-element.jd
index 8b131c8..9dc124b 100644
--- a/docs/html/guide/topics/manifest/activity-element.jd
+++ b/docs/html/guide/topics/manifest/activity-element.jd
@@ -672,7 +672,7 @@
<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
@@ -681,7 +681,7 @@
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>
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 @@
<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 @@
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 @@
<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 c970c72..9788945 100644
--- a/docs/html/guide/topics/manifest/manifest-element.jd
+++ b/docs/html/guide/topics/manifest/manifest-element.jd
@@ -150,9 +150,9 @@
</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/market/licensing/index.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 @@
<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 @@
<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 @@
<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 @@
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 @@
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 @@
<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..9175566 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 @@
<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 @@
<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 @@
<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 @@
<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 @@
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 @@
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 @@
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 @@
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 @@
</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 @@
<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 @@
<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 @@
</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 @@
<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 @@
<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 @@
<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>
@@ -529,7 +529,7 @@
<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 @@
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 @@
</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 @@
{@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 @@
<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 @@
<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 @@
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 @@
<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..a76c3c7 100644
--- a/docs/html/guide/topics/media/camera.jd
+++ b/docs/html/guide/topics/media/camera.jd
@@ -131,11 +131,11 @@
<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>
@@ -1260,7 +1260,7 @@
<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 @@
</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 @@
</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 @@
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 @@
<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 @@
<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/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 @@
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 @@
<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 @@
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 @@
<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/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 @@
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 @@
}
</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 @@
</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/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 @@
<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/index.jd b/docs/html/index.jd
index 431a7d2..60cd8b7 100644
--- a/docs/html/index.jd
+++ b/docs/html/index.jd
@@ -59,11 +59,11 @@
<td colspan="2"><div class="seperator"> </div></td>
</tr>
<tr>
- <td class="imageCell"><a href="http://market.android.com/publish"><img src="{@docRoot}assets/images/icon_market.jpg" style="padding:0" /></a></td>
+ <td class="imageCell"><a href="http://play.google.com/apps/publish"><img src="{@docRoot}assets/images/icon_play.png" style="padding:0" /></a></td>
<td>
<h2 class="green">Publish</h2>
- <p>Android Market is an open service that lets you distribute your apps to handsets.</p>
- <p><a href="http://market.android.com/publish">Learn more »</a></p>
+ <p>Google Play is an open service that lets you distribute your apps to devices.</p>
+ <p><a href="http://play.google.com/apps/publish">Learn more »</a></p>
</td>
</tr>
<tr>
@@ -182,8 +182,8 @@
'desc': "<p>Run and debug your Android applications directly on one of these "
+ "devices. Modify and rebuild the Android operating system, and flash it onto "
+ "the phone. The Android Dev Phones are carrier-independent, and available for "
- + "purchase by developers through their Android Market publisher accounts.</p><p> "
- + "<a href='http://market.android.com/publish'>Visit Android Market "
+ + "purchase by developers through their Google Play publisher accounts.</p><p> "
+ + "<a href='http://play.google.com/apps/publish'>Visit Google Play "
+ "to learn more »</a></p>"
},
*/
diff --git a/docs/html/intl/ja/community/index.jd b/docs/html/intl/ja/community/index.jd
index 490b23f..9739f0d 100644
--- a/docs/html/intl/ja/community/index.jd
+++ b/docs/html/intl/ja/community/index.jd
@@ -85,7 +85,7 @@
<li><b>Android マーケット ヘルプフォーラム</b> - Android マーケットに関する質問や問題の報告をするための、ウェブベースのディスカッション フォーラムです。
<ul>
-<li>URL: <a href="http://www.google.com/support/forum/p/Android+Market?hl=ja">http://www.google.com/support/forum/p/Android+Market?hl=ja</a></li>
+<li>URL: <a href="http://support.google.com/googleplay?hl=ja">http://support.google.com/googleplay?hl=ja</a></li>
</ul>
</li>
diff --git a/docs/html/intl/ja/index.jd b/docs/html/intl/ja/index.jd
index 8096247..fbbd88f 100644
--- a/docs/html/intl/ja/index.jd
+++ b/docs/html/intl/ja/index.jd
@@ -52,11 +52,11 @@
<td colspan="2"><div class="seperator"> </div></td>
</tr>
<tr>
- <td class="imageCell"><a href="http://www.android.com/market.html"><img src="{@docRoot}assets/images/icon_market.jpg" style="padding:0" /></a></td>
+ <td class="imageCell"><a href="http://play.google.com/apps/publish"><img src="{@docRoot}assets/images/icon_play.png" style="padding:0" /></a></td>
<td>
<h2 class="green">公開</h2>
<p>Android マーケットは、アプリケーションを携帯端末に配信するためのオープン サービスです。</p>
- <p><a href="http://market.android.com/publish/Home">詳細 »</a></p>
+ <p><a href="http://play.google.com/apps/publish">詳細 »</a></p>
</td>
</tr>
<tr>
@@ -148,7 +148,7 @@
'name':"Dev Phone 1",
'img':"devphone-large.png",
'title':"Android Dev Phone 1",
- 'desc': "<p>この携帯電話を使用することで、開発した Android アプリケーションの実行とデバッグを行うことができます。Android オペレーティングシステムを変更してからリビルドし、携帯電話に書き込むことができます。Android Dev Phone 1 は携帯通信会社に依存しておらず、<a href='http://market.android.com/publish'>Android マーケット</a>に登録済みのデベロッパーなら誰でも購入可能です。</p><p><a href='/guide/developing/device.html#dev-phone-1'>Android Dev Phone 1 の詳細»</a></p>"
+ 'desc': "<p>この携帯電話を使用することで、開発した Android アプリケーションの実行とデバッグを行うことができます。Android オペレーティングシステムを変更してからリビルドし、携帯電話に書き込むことができます。Android Dev Phone 1 は携帯通信会社に依存しておらず、<a href='http://play.google.com/apps/publish'>Android マーケット</a>に登録済みのデベロッパーなら誰でも購入可能です。</p><p><a href='/guide/developing/device.html#dev-phone-1'>Android Dev Phone 1 の詳細»</a></p>"
}
}
diff --git a/docs/html/intl/ja/resources/community-groups.jd b/docs/html/intl/ja/resources/community-groups.jd
index ecedde1..3fd6601 100644
--- a/docs/html/intl/ja/resources/community-groups.jd
+++ b/docs/html/intl/ja/resources/community-groups.jd
@@ -85,7 +85,7 @@
<li><b>Android マーケット ヘルプフォーラム</b> - Android マーケットに関する質問や問題の報告をするための、ウェブベースのディスカッション フォーラムです。
<ul>
-<li>URL: <a href="http://www.google.com/support/forum/p/Android+Market?hl=ja">http://www.google.com/support/forum/p/Android+Market?hl=ja</a></li>
+<li>URL: <a href="http://support.google.com/googleplay?hl=ja">http://support.google.com/googleplay?hl=ja</a></li>
</ul>
</li>
diff --git a/docs/html/resources/articles/can-i-use-this-intent.jd b/docs/html/resources/articles/can-i-use-this-intent.jd
index c527331..7787d31e 100644
--- a/docs/html/resources/articles/can-i-use-this-intent.jd
+++ b/docs/html/resources/articles/can-i-use-this-intent.jd
@@ -68,4 +68,4 @@
UI accordingly to prevent the user from doing something that won't work. The
technique described here can also be used at startup time to ask the user
whether he'd like to install the missing package, you can then simply redirect
-him to the Android Market by using the appropriate URI.</p>
\ No newline at end of file
+him to Google Play by using the appropriate URI.</p>
\ No newline at end of file
diff --git a/docs/html/resources/articles/contacts.jd b/docs/html/resources/articles/contacts.jd
index 8365d29..374587b 100644
--- a/docs/html/resources/articles/contacts.jd
+++ b/docs/html/resources/articles/contacts.jd
@@ -298,10 +298,10 @@
<li>At launch time, check the version of the SDK. The version of the SDK
is available as {@link android.os.Build.VERSION#SDK android.os.Build.VERSION.SDK}.</li>
<li>If the SDK version is greater or equal to 5 (Android 2.0), show a dialog
-suggesting to the user that it's time to go to Market and find a new version of
-the app. You can even provide a link to the new app on Market (see <a
+suggesting to the user that it's time to go to Google Play and find a new version of
+the app. You can even provide a link to the new app on Google Play (see <a
href="{@docRoot}guide/publishing/publishing.html#marketintent">Using Intents
-to Launch Market</a>). </li>
+to Launch Google Play</a>). </li>
</ul>
<li>Change the new application:</li>
<ul>
@@ -311,14 +311,14 @@
<li>Modify that application's AndroidManifest.xml file: </li>
<ul>
<li>Give the application a new name and a new package name. Currently
-Android Market does not allow you to have two applications with the same
+Google Play does not allow you to have two applications with the same
name/package.</li>
<li>Update (or add) the <code>android:minSdkVersion</code> attribute
to the <code><uses-sdk></code> element. To use the new Contacts API,
you should set the value of the attribute to "5" (or higher, as appropriate).</li>
</ul>
</ul>
- <li>Publish both apps on Market, the old app one as an upgrade and the
+ <li>Publish both apps on Google Play, the old app one as an upgrade and the
other as new. Make sure to explain the difference between the apps in their
descriptions.</li>
</ul>
diff --git a/docs/html/resources/articles/live-wallpapers.jd b/docs/html/resources/articles/live-wallpapers.jd
index bfbbb34..0692a62 100644
--- a/docs/html/resources/articles/live-wallpapers.jd
+++ b/docs/html/resources/articles/live-wallpapers.jd
@@ -76,19 +76,19 @@
supported only on Android 2.1 (API level 7) and higher versions of the platform.
To ensure that your application can only be installed on devices that support
live wallpapers, remember to add the following to the application's manifest
-before publishing to Android Market:</p>
+before publishing to Google Play:</p>
<ul>
<li><code><uses-sdk android:minSdkVersion="7" /></code>, which indicates
-to Android Market and the platform that your application requires Android 2.1 or
+to Google Play and the platform that your application requires Android 2.1 or
higher. For more information, see the <a href="{@docRoot}guide/appendix/api-levels.html">API
Levels</a> and the documentation for the
<a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><code><uses-sdk></code></a>
element.</li>
<li><code><uses-feature android:name="android.software.live_wallpaper" /></code>,
-which tells Android Market that your application includes a live wallpaper
-Android Market uses this feature as a filter, when presenting users lists of
-available applications. When you declaring this feature, Android Market
+which tells Google Play that your application includes a live wallpaper
+Google Play uses this feature as a filter, when presenting users lists of
+available applications. When you declaring this feature, Google Play
displays your application only to users whose devices support live wallpapers,
while hiding it from other devices on which it would not be able to run. For
more information, see the documentation for the
@@ -98,5 +98,5 @@
element.</li>
</ul>
-<p>Many great live wallpapers are already available on Android Market and
+<p>Many great live wallpapers are already available on Google Play and
we can't wait to see more!</p>
diff --git a/docs/html/resources/articles/speech-input.jd b/docs/html/resources/articles/speech-input.jd
index 0867ff2..2f9cd69 100644
--- a/docs/html/resources/articles/speech-input.jd
+++ b/docs/html/resources/articles/speech-input.jd
@@ -9,7 +9,7 @@
<p>Speech input adds another dimension to staying in touch.
Google's Voice Search application, which is pre-installed on many Android devices
-and available in Android Market, provides powerful features like "search by voice"
+and available on Google Play, provides powerful features like "search by voice"
and Voice Actions like "Navigate to." Further
enhancing the voice experience, Android 2.1 introduces a <a
href="http://www.youtube.com/watch?v=laOlkD8LmZw">
@@ -21,7 +21,7 @@
<p> We believe speech can
fundamentally change the mobile experience. We would like to invite every
Android application developer to consider integrating speech input capabilities
-via the Android SDK. One of our favorite apps in the Market that integrates
+via the Android SDK. One of our favorite apps on Google Play that integrates
speech input is <a href="http://www.handcent.com/">Handcent SMS</a>,
because you can dictate a reply to any SMS with a
quick tap on the SMS popup window. Here is Speech input integrated into
diff --git a/docs/html/resources/articles/tts.jd b/docs/html/resources/articles/tts.jd
index 7d07a89..929d084 100644
--- a/docs/html/resources/articles/tts.jd
+++ b/docs/html/resources/articles/tts.jd
@@ -43,7 +43,7 @@
know to install the data that's required for the device to become a
multi-lingual talking machine! Downloading and installing the data is
accomplished by firing off the ACTION_INSTALL_TTS_DATA intent, which will take
-the user to Android Market, and will let her/him initiate the download.
+the user to Google Play, and will let her/him initiate the download.
Installation of the data will happen automatically once the download completes.
Here is an example of what your implementation of
<code>onActivityResult()</code> would look like:</p>
diff --git a/docs/html/resources/articles/ui-1.6.jd b/docs/html/resources/articles/ui-1.6.jd
index 09108dd..b3238e3 100644
--- a/docs/html/resources/articles/ui-1.6.jd
+++ b/docs/html/resources/articles/ui-1.6.jd
@@ -129,4 +129,4 @@
<p>The Android team is committed to helping you write applications in the
easiest and most efficient way possible. We hope you find these improvements
-useful and we're excited to see your applications on Android Market.</p>
+useful and we're excited to see your applications on Google Play.</p>
diff --git a/docs/html/resources/community-groups.jd b/docs/html/resources/community-groups.jd
index 599c4ae..6bd347c 100644
--- a/docs/html/resources/community-groups.jd
+++ b/docs/html/resources/community-groups.jd
@@ -14,7 +14,7 @@
<li><a href="#UsingEmail">Using email with the mailing lists</a></li>
<li><a href="#ApplicationDeveloperLists">Application developer mailing lists</a></li>
</ol></li>
- <li><a href="#MarketHelp">Android Market Help Forum</a></li>
+ <li><a href="#PlayHelp">Google Play Help Forum</a></li>
</ol>
</div>
@@ -113,8 +113,8 @@
</ul>
-<h2 id="MarketHelp">Android Market Help Forum</h2>
+<h2 id="PlayHelp">Google Play Help Forum</h2>
-<p>The <a href="http://www.google.com/support/forum/p/Android+Market">Android Market Help Forum</a> is a web-based discussion forum where you can ask questions or report issues relating to Android Market.</p>
+<p>The <a href="http://support.google.com/googleplay">Google Play Help Forum</a> is a web-based discussion forum where you can ask questions or report issues relating to Google Play.</p>
-<p style="margin-left: 2em"><a href="http://www.google.com/support/forum/p/Android+Market">http://www.google.com/support/forum/p/Android+Market</a></p>
+<p style="margin-left: 2em"><a href="http://support.google.com/googleplay">http://support.google.com/googleplay</a></p>
diff --git a/docs/html/resources/dashboard/opengl.jd b/docs/html/resources/dashboard/opengl.jd
index 6978d62..b1c3234 100644
--- a/docs/html/resources/dashboard/opengl.jd
+++ b/docs/html/resources/dashboard/opengl.jd
@@ -50,7 +50,7 @@
uses.</p>
<p class="note"><strong>Note:</strong> This data is based on the number
-of Android devices that have accessed Android Market within a 7-day period
+of Android devices that have accessed Google Play within a 7-day period
ending on the data collection date noted below.</p>
diff --git a/docs/html/resources/dashboard/platform-versions.jd b/docs/html/resources/dashboard/platform-versions.jd
index acb8472..65a5575 100644
--- a/docs/html/resources/dashboard/platform-versions.jd
+++ b/docs/html/resources/dashboard/platform-versions.jd
@@ -47,7 +47,7 @@
<h3 id="Current">Current Distribution</h3>
<p>The following pie chart and table is based on the number of Android devices that have accessed
-Android Market within a 14-day period ending on the data collection date noted below.</p>
+Google Play within a 14-day period ending on the data collection date noted below.</p>
<div class="dashboard-panel">
@@ -103,7 +103,7 @@
line for that version meets the y-axis on the right.</p>
<p>Each dataset in the timeline is based on the number of Android devices that accessed
-Android Market within a 14-day period ending on the date indicated on the x-axis.</p>
+Google Play within a 14-day period ending on the date indicated on the x-axis.</p>
<div class="dashboard-panel">
diff --git a/docs/html/resources/dashboard/screens.jd b/docs/html/resources/dashboard/screens.jd
index 6c04f7e..e9c738e 100644
--- a/docs/html/resources/dashboard/screens.jd
+++ b/docs/html/resources/dashboard/screens.jd
@@ -53,7 +53,7 @@
Screens</a>.</p>
<p class="note"><strong>Note:</strong> This data is based on the number
-of Android devices that have accessed Android Market within a 7-day period
+of Android devices that have accessed Google Play within a 7-day period
ending on the data collection date noted below.</p>
diff --git a/docs/html/sdk/android-1.6-highlights.jd b/docs/html/sdk/android-1.6-highlights.jd
index 84766d6..f0a50fb 100644
--- a/docs/html/sdk/android-1.6-highlights.jd
+++ b/docs/html/sdk/android-1.6-highlights.jd
@@ -38,7 +38,7 @@
<ul>
<li><a href="#UserFeatures">New User Features</a></li>
- <li><a href="#AndroidMarketUpdates">Android Market Updates</a></li>
+ <li><a href="#GooglePlayUpdates">Google Play Updates</a></li>
<li><a href="#PlatformTechnologies">New Platform Technologies</a></li>
</ul>
@@ -118,14 +118,14 @@
-<h2 id="AndroidMarketUpdates" style="clear:right">Android Market Updates</h2>
+<h2 id="GooglePlayUpdates" style="clear:right">Google Play Updates</h2>
<div class="screenshot" style="margin-top:-35px">
<img src="images/market.png" class="screenshot" alt="" /><br/>
-New Android Market UI
+New Google Play UI
</div>
-<p>For devices with Android Market, the latest version improves the overall user experience and makes
+<p>For devices with Google Play, the latest version improves the overall user experience and makes
it easier for users to discover great apps and games from developers.</p>
<ul>
@@ -157,7 +157,7 @@
It allows any Android application to "speak" a string of text with an accent that matches the language.
The engine supports the following languages: English (American and British accents), French,
Italian, German and Spanish. If you're using a T-Mobile G1 or Dream device, you'll need to download the
-SpeechSynthesis Data Installer from Android Market, which includes the "voices" needed by the
+SpeechSynthesis Data Installer from Google Play, which includes the "voices" needed by the
text-to-speech engine.</p>
diff --git a/docs/html/sdk/android-2.1.jd b/docs/html/sdk/android-2.1.jd
index 3f28551..1ee833c 100644
--- a/docs/html/sdk/android-2.1.jd
+++ b/docs/html/sdk/android-2.1.jd
@@ -191,7 +191,7 @@
<uses-feature android:name="android.software.live_wallpaper" />
</pre>
-<p>When you've published your application, Android Market checks for the
+<p>When you've published your application, Google Play checks for the
presence of this element and uses it as a filter, ensuring that your application
is not made available to users whose devices do not support Live Wallpapers.
</p>
diff --git a/docs/html/sdk/android-2.2-highlights.jd b/docs/html/sdk/android-2.2-highlights.jd
index 8bed675..37a20d5 100644
--- a/docs/html/sdk/android-2.2-highlights.jd
+++ b/docs/html/sdk/android-2.2-highlights.jd
@@ -231,7 +231,7 @@
<h3>Android Application Error Reports</h3>
-<p>New bug reporting feature for Android Market apps enables developers to receive crash and freeze
+<p>New bug reporting feature for Google Play apps enables developers to receive crash and freeze
reports from their users. The reports will be available when they log into their publisher
account.</p>
diff --git a/docs/html/sdk/android-2.3.3.jd b/docs/html/sdk/android-2.3.3.jd
index 023e2e4..405c063 100644
--- a/docs/html/sdk/android-2.3.3.jd
+++ b/docs/html/sdk/android-2.3.3.jd
@@ -192,7 +192,7 @@
declaring <code><uses-permission
android:name="android.permission.NFC"></code> in their manifest files.</p>
-<p>Additionally, developers can request filtering on Android Market, such that
+<p>Additionally, developers can request filtering on Google Play, such that
their applications are not discoverable to users whose devices do not support
NFC. To request filtering, add
<code><uses-feature android:name="android.hardware.nfc"
diff --git a/docs/html/sdk/android-2.3.4.jd b/docs/html/sdk/android-2.3.4.jd
index eeaa69a..4bfdabd 100644
--- a/docs/html/sdk/android-2.3.4.jd
+++ b/docs/html/sdk/android-2.3.4.jd
@@ -197,7 +197,7 @@
accessories, please see the related <a
href="{@docRoot}guide/topics/usb/index.html">developer documentation</a>.</p>
-<p>Additionally, developers can request filtering on Android Market, such that
+<p>Additionally, developers can request filtering on Google Play, such that
their applications are not available to users whose devices do not provide the
appropriate accessory support. To request filtering, add the element below
to the application manifest:</p>
diff --git a/docs/html/sdk/android-2.3.jd b/docs/html/sdk/android-2.3.jd
index fc4f5aa..b466913 100644
--- a/docs/html/sdk/android-2.3.jd
+++ b/docs/html/sdk/android-2.3.jd
@@ -150,7 +150,7 @@
android:name="android.permission.INTERNET"></code> and <code><uses-permission
android:name="android.permission.USE_SIP"></code> in their manifest files.</p>
-<p>Additionally, developers can request filtering on Android Market, such that
+<p>Additionally, developers can request filtering on Google Play, such that
their applications are not discoverable to users whose devices do not include
the platform’s SIP stack and services. To request filtering, add <code><uses-feature
android:name="android.software.sip"
@@ -197,7 +197,7 @@
declaring <code><uses-permission
android:name="android.permission.NFC"></code> in their manifest files.</p>
-<p>Additionally, developers can request filtering on Android Market, such that
+<p>Additionally, developers can request filtering on Google Play, such that
their applications are not discoverable to users whose devices do not support
NFC. To request filtering, add
<code><uses-feature android:name="android.hardware.nfc"
@@ -219,7 +219,7 @@
<p>Note that the specific set of hardware sensors available on any given device
varies at the discretion of the device manufacturer. </p>
-<p>Developers can request filtering in Android Market, such that their
+<p>Developers can request filtering on Google Play, such that their
applications are not discoverable to users whose devices do not offer a
gyroscope sensor. To do so, add <code><uses-feature
android:name="android.hardware.sensor.gyroscope"
@@ -726,7 +726,7 @@
<p>The platform adds several new hardware features that developers can declare
in their application manifests as being required by their applications. This
lets developers control how their application is filtered, when published on
-Android Market. </p>
+Google Play. </p>
<ul>
<li>{@link android.content.pm.PackageManager#FEATURE_AUDIO_LOW_LATENCY
diff --git a/docs/html/sdk/android-3.0.jd b/docs/html/sdk/android-3.0.jd
index 49fefee..39a234f 100644
--- a/docs/html/sdk/android-3.0.jd
+++ b/docs/html/sdk/android-3.0.jd
@@ -922,7 +922,7 @@
<p>The <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code <uses-feature>}</a>
-manfest element should be used to inform external entities (such as Android Market) of the set of
+manfest element should be used to inform external entities (such as Google Play) of the set of
hardware and software features on which your application depends. In this release, Android adds the
following new constants that applications can declare with this element:</p>
diff --git a/docs/html/sdk/android-3.1.jd b/docs/html/sdk/android-3.1.jd
index b9cf969..7ec7e33 100644
--- a/docs/html/sdk/android-3.1.jd
+++ b/docs/html/sdk/android-3.1.jd
@@ -214,7 +214,7 @@
their manufacturers. In particular, host mode relies on appropriate USB
controller hardware in the Android-powered device. </p>
-<p>Additionally, developers can request filtering on Android Market, such that
+<p>Additionally, developers can request filtering on Google Play, such that
their applications are not availabe to users whose devices do not provide the
appropriate USB support. To request filtering, add one or both of the elements
below to the application manifest, as appropriate: </p>
@@ -908,8 +908,8 @@
<h3 id="features">New feature constants</h3>
<p>The platform adds new hardware feature constants that developers can declare
-in their application manifests, to inform external entities such as Android
-Market of the application's requirement for new hardware capabilities supported
+in their application manifests, to inform external entities such as Google
+Play of the application's requirement for new hardware capabilities supported
in this version of the platform. Developers declare these and other feature
constants in <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code
@@ -926,11 +926,11 @@
devices.</li>
</ul>
-<p>Android Market filters applications based on features declared in <a
+<p>Google Play filters applications based on features declared in <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code
<uses-feature>}</a> manifest elements. For more information about
declaring features in an application manifest, read <a
-href="{@docRoot}guide/appendix/market-filters.html">Android Market
+href="{@docRoot}guide/appendix/market-filters.html">Google Play
Filters</a>.</p>
diff --git a/docs/html/sdk/android-3.2.jd b/docs/html/sdk/android-3.2.jd
index aeaf9c8..27df22c 100644
--- a/docs/html/sdk/android-3.2.jd
+++ b/docs/html/sdk/android-3.2.jd
@@ -320,7 +320,7 @@
from being installed and run.</li>
</ul>
-<p class="note"><strong>Note:</strong> Android Market does not currently filter
+<p class="note"><strong>Note:</strong> Google Play does not currently filter
apps based on any of the attributes above. Support for filtering will be
added in a later platform release. Applications that require
filtering based on screen size can use the existing <code><supports-screens></code>
@@ -526,13 +526,13 @@
<h3 id="features">New feature constants</h3>
<p>The platform adds new hardware feature constants that you can declare
-in their application manifests, to inform external entities such as Android
-Market of required hardware and software capabilities. You declare these
+in their application manifests, to inform external entities such as Google
+Play of required hardware and software capabilities. You declare these
and other feature constants in <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code
<uses-feature>}</a> manifest elements.
-<p>Android Market filters applications based on their <code><uses-feature></code> attributes, to ensure that they are available only to devices on which their requirements are met. </p>
+<p>Google Play filters applications based on their <code><uses-feature></code> attributes, to ensure that they are available only to devices on which their requirements are met. </p>
<ul>
<li>Feature constants for landscape or portrait requirements
diff --git a/docs/html/sdk/android-4.0-highlights.jd b/docs/html/sdk/android-4.0-highlights.jd
index 922bb08..50e9a14 100644
--- a/docs/html/sdk/android-4.0-highlights.jd
+++ b/docs/html/sdk/android-4.0-highlights.jd
@@ -529,7 +529,7 @@
Just touch one Android-powered phone to another, then tap to send.</p>
<p>For sharing apps, Android Beam pushes a link to the app's details page in
-Android Market. On the other device, the Market app launches and loads the
+Google Play. On the other device, the Google Play client app launches and loads the
details page, for easy downloading of the app. Individual apps can build on
Android Beam to add other types of interactions, such as passing game scores,
initiating a multiplayer game or chat, and more.</p>
@@ -715,7 +715,7 @@
<p>Even if developers do not add custom interactions based on Android Beam they
can still benefit from it being deeply integrated into Android. By default the
-system shares the app’s Android Market URL, so it’s easy for the user to
+system shares the app’s Google Play URL, so it’s easy for the user to
download or purchase the app right away.</p>
diff --git a/docs/html/sdk/android-4.0.jd b/docs/html/sdk/android-4.0.jd
index 2cad86b..e3b13c8 100644
--- a/docs/html/sdk/android-4.0.jd
+++ b/docs/html/sdk/android-4.0.jd
@@ -660,14 +660,14 @@
application record and multiple applications contain activities that handle the specified intent,
the system always delivers the message to the activity in your application (based on the matching
application record). If the target device does not currently have your application installed, the
-system uses the Android application record to launch Android Market and take the user to the
+system uses the Android application record to launch Google Play and take the user to the
application in order to install it.</p>
<p>If your application doesn’t use NFC APIs to perform NDEF Push messaging, then Android provides a
default behavior: When your application is in the foreground on one device and Android Beam is
invoked with another Android-powered device, then the other device receives an NDEF message with an
Android application record that identifies your application. If the receiving device has the
-application installed, the system launches it; if it’s not installed, Android Market opens and takes
+application installed, the system launches it; if it’s not installed, Google Play opens and takes
the user to your application in order to install it.</p>
<p>You can read more about Android Beam and other NFC features in the <a
diff --git a/docs/html/sdk/ndk/index.jd b/docs/html/sdk/ndk/index.jd
index 29f0749..a1c59e3 100644
--- a/docs/html/sdk/ndk/index.jd
+++ b/docs/html/sdk/ndk/index.jd
@@ -756,7 +756,7 @@
<li>Includes improvements to the <code>cpufeatures</code> helper library that improves reporting
of the CPU type (some devices previously reported ARMv7 CPU when the device really was an ARMv6). We
recommend developers that use this library to rebuild their applications then
- upload to Market to benefit from the improvements.</li>
+ upload to Google Play to benefit from the improvements.</li>
<li>Adds an EGL library that lets you create and manage OpenGL ES textures and
services.</li>
@@ -832,7 +832,7 @@
<code>.apk</code>.</li>
<li>To ensure that your applications are available to users only if their devices are
- capable of running them, Android Market now filters applications based on the
+ capable of running them, Google Play now filters applications based on the
instruction set information included in your application — no action is needed on
your part to enable the filtering. Additionally, the Android system itself also checks
your application at install time and allows the installation to continue only if the
diff --git a/docs/html/sdk/ndk/overview.jd b/docs/html/sdk/ndk/overview.jd
index e969f5d..c98e600 100644
--- a/docs/html/sdk/ndk/overview.jd
+++ b/docs/html/sdk/ndk/overview.jd
@@ -535,7 +535,7 @@
<li>Additionally, an application using the OpenGL ES APIs should declare a
<code><uses-feature></code> element in its manifest, with an
<code>android:glEsVersion</code> attribute that specifies the minimum OpenGl ES version
- required by the application. This ensures that Android Market will show your application only
+ required by the application. This ensures that Google Play will show your application only
to users whose devices are capable of supporting your application. For example:
<pre style="margin:1em;">
<manifest>
diff --git a/docs/html/sdk/oem-usb.jd b/docs/html/sdk/oem-usb.jd
index f98257d..addcc5e 100644
--- a/docs/html/sdk/oem-usb.jd
+++ b/docs/html/sdk/oem-usb.jd
@@ -211,7 +211,7 @@
<h2 id="Drivers">OEM Drivers</h2>
<p class="note"><strong>Note:</strong> If your device is one of the Android Developer Phones
-(purchased from the Android Market publisher site), a Nexus One, or a Nexus S, then you need
+(purchased from the Google Play publisher site), a Nexus One, or a Nexus S, then you need
the <a href="{@docRoot}sdk/win-usb.html">Google USB Driver</a>, instead of an OEM driver. The Galaxy
Nexus driver, however, is distributed by <a
href="http://www.samsung.com/us/support/downloads/verizon-wireless/SCH-I515MSAVZW">Samsung</a>
diff --git a/docs/html/training/camera/photobasics.jd b/docs/html/training/camera/photobasics.jd
index e6ab43e..3420918 100644
--- a/docs/html/training/camera/photobasics.jd
+++ b/docs/html/training/camera/photobasics.jd
@@ -55,7 +55,7 @@
<h2 id="TaskManifest">Request Camera Permission</h2>
<p>If an essential function of your application is taking pictures, then restrict
-its visibility in Android Market to devices that have a camera. To advertise
+its visibility on Google Play to devices that have a camera. To advertise
that your application depends on having a camera, put a <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html"> {@code
<uses-feature>}</a> tag in your manifest file:</p>
@@ -68,7 +68,7 @@
</pre>
<p>If your application uses, but does not require a camera in order to function, add {@code
-android:required="false"} to the tag. In doing so, Android Market will allow devices without a
+android:required="false"} to the tag. In doing so, Google Play will allow devices without a
camera to download your application. It's then your responsibility to check for the availability
of the camera at runtime by calling {@link
android.content.pm.PackageManager#hasSystemFeature hasSystemFeature(PackageManager.FEATURE_CAMERA)}.
diff --git a/docs/html/training/camera/videobasics.jd b/docs/html/training/camera/videobasics.jd
index a3512b0..f8ce03c 100644
--- a/docs/html/training/camera/videobasics.jd
+++ b/docs/html/training/camera/videobasics.jd
@@ -62,7 +62,7 @@
</pre>
<p>If your application uses, but does not require a camera in order to function, add {@code
-android:required="false"} to the tag. In doing so, Android Market will allow devices without a
+android:required="false"} to the tag. In doing so, Google Play will allow devices without a
camera to download your application. It's then your responsibility to check for the availability
of the camera at runtime by calling {@link
android.content.pm.PackageManager#hasSystemFeature hasSystemFeature(PackageManager.FEATURE_CAMERA)}.
diff --git a/docs/html/training/id-auth/custom_auth.jd b/docs/html/training/id-auth/custom_auth.jd
index e2bd778..0509c6e 100644
--- a/docs/html/training/id-auth/custom_auth.jd
+++ b/docs/html/training/id-auth/custom_auth.jd
@@ -181,6 +181,6 @@
<p>One solution is to place the service in one small, special-purpose APK. When
an app wishes to use your custom account type, it can check the device to see if
your custom account service is available. If not, it can direct the user to
-Android Market to download the service. This may seem like a great deal of
+Google Play to download the service. This may seem like a great deal of
trouble at first, but compared with the alternative of re-entering credentials
for every app that uses your custom account, it's refreshingly easy.</p>
diff --git a/docs/html/training/multiple-apks/api.jd b/docs/html/training/multiple-apks/api.jd
index d8588d4..8b731bd 100644
--- a/docs/html/training/multiple-apks/api.jd
+++ b/docs/html/training/multiple-apks/api.jd
@@ -44,7 +44,7 @@
</div>
-<p>When developing your Android application to take advantage of multiple APKs on Android Market,
+<p>When developing your Android application to take advantage of multiple APKs on Google Play,
it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches
further into the development process. This lesson shows you how to create multiple APKs of your
app, each covering a slightly different range of API levels. You will also gain some tools
@@ -198,7 +198,7 @@
<h2 id="AdjustManifests">Adjust the Manifests</h2>
-<p>When a user downloads an application which uses multiple APKs through Android Market, the correct
+<p>When a user downloads an application which uses multiple APKs through Google Play, the correct
APK to use is chosen using two simple rules:</p>
<ul>
<li>The manifest has to show that particular APK is eligible</li>
@@ -278,19 +278,20 @@
</table>
<p>
-Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The
-Market Filters page of the Android Developer guide has a whole list of possible culprits. For the
+Now, let’s further assume that the Red APK has some requirement on it that the other two don’t.
+<a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> page of
+the Android Developer guide has a whole list of possible culprits. For the
sake of example, let’s assume that red requires a front-facing camera. In fact, the entire point of
the red APK is to combine the front-facing camera with sweet new functionality that was added in API
11. But, it turns out, not all devices that support API 11 even HAVE front-facing cameras! The
horror!</p>
-<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the
+<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the
manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having
determined that Red and that device are not a match made in digital heaven. It will then see that
Green is not only forward-compatible with devices with API 11 (since no maxSdkVersion was defined),
but also doesn’t care whether or not there’s a front-facing camera! The app can still be downloaded
-from Android Market by the user, because despite the whole front-camera mishap, there was still an
+from Google Play by the user, because despite the whole front-camera mishap, there was still an
APK that supported that particular API level.</p>
<p> In order to keep all your APKs on separate "tracks", it’s important to have a good version code
@@ -330,7 +331,7 @@
</pre>
<h2 id="PreLaunch">Go Over Pre-launch Checklist</h2>
-<p> Before uploading to Android Market, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Android Market.</p>
+<p> Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Google Play.</p>
<ul>
<li>All APKs must have the same package name</li>
@@ -342,7 +343,7 @@
</ul>
<p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t
-any surprises that could hide your application in Market. This is actually quite simple using the
+any surprises that could hide your application on Google Play. This is actually quite simple using the
"aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and
packaging your Android applications, and is also a very handy tool for inspecting them. </p>
@@ -370,10 +371,10 @@
supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values
that were added as a result of permissions you set in the manifest. In the example above, the APK
won’t be visible to very many devices.</p>
-<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Market will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware.
+<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Google Play will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware.
</p>
<p>Fortunately this is easily fixed by adding the following to your manifest:</p>
<pre>
<uses-feature android:name="android.hardware.telephony" android:required="false" />
</pre>
-<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
+<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
diff --git a/docs/html/training/multiple-apks/index.jd b/docs/html/training/multiple-apks/index.jd
index f9b2b43..d92c106 100644
--- a/docs/html/training/multiple-apks/index.jd
+++ b/docs/html/training/multiple-apks/index.jd
@@ -16,7 +16,7 @@
<ul>
<li>Android 1.0 and higher</li>
- <li>You must have an <a href="http://market.android.com/publish">Android Market</a> publisher
+ <li>You must have an <a href="http://play.google.com/apps/publish">Google Play</a> publisher
account</li>
</ul>
@@ -30,7 +30,7 @@
</div>
</div>
-<p>Multiple APK support is a feature in Android Market that allows you to publish multiple APKs
+<p>Multiple APK support is a feature of Google Play that allows you to publish multiple APKs
under the same application listing. Each APK is a complete instance of your application, optimized
to target specific device configurations. Each APK can target a specific set of GL
textures, API levels, screen sizes, or some combination thereof.</p>
@@ -39,7 +39,7 @@
configuration variables. Each lesson covers basics about how to organize your codebase and target
the right devices, as well as the smart way to avoid pitfalls such as unnecessary redundancy across
your codebase, and making mistakes in your manifest that could render an APK invisible to all
-devices in Android Market. By going through any of these lessons, you'll know how to develop
+devices on Google Play. By going through any of these lessons, you'll know how to develop
multiple APKs the smart way, make sure they're targeting the devices you want them to,
and know how to catch mistakes <em>before</em> your app goes live.</p>
diff --git a/docs/html/training/multiple-apks/multiple.jd b/docs/html/training/multiple-apks/multiple.jd
index 26a3a93..0c49705 100644
--- a/docs/html/training/multiple-apks/multiple.jd
+++ b/docs/html/training/multiple-apks/multiple.jd
@@ -40,7 +40,7 @@
</div>
</div>
-<p>When developing your Android application to take advantage of multiple APKs on Android Market,
+<p>When developing your Android application to take advantage of multiple APKs on Google Play,
it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches
further into the development process. This lesson shows you how to create multiple APKs of your
app, each covering a different class of screen size. You will also gain some tools necessary to
@@ -227,7 +227,7 @@
<h2 id="AdjustManifests">Adjust the Manifests</h2>
-<p>When a user downloads an application which uses multiple APKs through Android Market, the correct
+<p>When a user downloads an application which uses multiple APKs through Google Play, the correct
APK to use is chosen using two simple rules:
<ul>
@@ -329,17 +329,17 @@
Purple ≥ Red ≥ Green ≥ Blue
</p><p>
Why allow all the overlap? Let’s pretend that the Purple APK has some requirement on it that the
-other two don’t. The <a href="{@docRoot}guide/appendix/market-filters.html">Market Filters page</a>
+other two don’t. The <a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> page
of the Android Developer guide has a whole list of possible culprits. For the sake of example,
let’s assume that Purple requires a front-facing camera. In fact, the entire point of Purple is to
use entertaining things with the front-facing camera! But, it turns out, not all API 11+ devices
even HAVE front-facing cameras! The horror!</p>
-<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the
+<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the
manifest, see that Purple lists the front-facing camera as a requirement, and quietly ignore it,
having determined that Purple and that device are not a match made in digital heaven. It will then
see that Red is not only compatible with xlarge devices, but also doesn’t care whether or not
-there’s a front-facing camera! The app can still be downloaded from Android Market by the user,
+there’s a front-facing camera! The app can still be downloaded from Google Play by the user,
because despite the whole front-camera mishap, there was still an APK that supported that particular
API level.</p>
@@ -420,9 +420,9 @@
</p>
<h2 id="PreLaunch">Go Over Pre-launch Checklist</h2>
-<p> Before uploading to Android Market, double-check the following items. Remember that these are
+<p> Before uploading to Google Play, double-check the following items. Remember that these are
specifically relevant to multiple APKs, and in no way represent a complete checklist for all
-applications being uploaded to Android Market.</p>
+applications being uploaded to Google Play.</p>
<ul>
<li>All APKs must have the same package name.</li>
<li>All APKs must be signed with the same certificate.</li>
@@ -439,7 +439,7 @@
</ul>
<p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t
-any surprises that could hide your application in Market. This is actually quite simple using the
+any surprises that could hide your application on Google Play. This is actually quite simple using the
"aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and
packaging your Android applications, and is also a very handy tool for inspecting them. </p>
@@ -467,11 +467,11 @@
supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values
that were added as a result of permissions you set in the manifest. In the example above, the APK
will be invisible to most, if not all devices.</p>
-<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.
+<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.
</p>
<p>Fortunately this is easily fixed by adding the following to your manifest:<p>
<pre>
<uses-feature android:name="android.hardware.telephony" android:required="false" />
</pre>
-<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
+<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
diff --git a/docs/html/training/multiple-apks/screensize.jd b/docs/html/training/multiple-apks/screensize.jd
index 0ed972a..cbf17c5 100644
--- a/docs/html/training/multiple-apks/screensize.jd
+++ b/docs/html/training/multiple-apks/screensize.jd
@@ -43,7 +43,7 @@
</div>
-<p>When developing your Android application to take advantage of multiple APKs on Android Market,
+<p>When developing your Android application to take advantage of multiple APKs on Google Play,
it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches
further into the development process. This lesson shows you how to create multiple APKs of your
app, each covering a different class of screen size. You will also gain some tools necessary to
@@ -178,7 +178,7 @@
<h2 id="AdjustManifests">Adjust the Manifests</h2>
-<p>When a user downloads an application which uses multiple APKs through Android Market, the correct
+<p>When a user downloads an application which uses multiple APKs through Google Play, the correct
APK to use is chosen using two simple rules:</p>
<ul>
<li>The manifest has to show that particular APK is eligible</li>
@@ -227,17 +227,17 @@
</table>
<p>
Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The
-<a href="{@docRoot}guide/appendix/market-filters.html">Market Filters page</a> of the Android
+<a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> page of the Android
Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that
red requires a front-facing camera. In fact, the entire point of the red APK is to use the extra
available screen space to do entertaining things with that front-facing camera. But, it turns out,
not all xlarge devices even HAVE front-facing cameras! The horror!</p>
-<p>Fortunately, if a user is browsing Market from one such device, Android Market will look at the
+<p>Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the
manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having
determined that Red and that device are not a match made in digital heaven. It will then see that
Green is not only compatible with xlarge devices, but also doesn’t care whether or not there’s a
-front-facing camera! The app can still be downloaded from Android Market by the user, because
+front-facing camera! The app can still be downloaded from Google Play by the user, because
despite the whole front-camera mishap, there was still an APK that supported that particular screen
size.</p>
@@ -300,9 +300,9 @@
</p>
<h2 id="PreLaunch">Go Over Pre-launch Checklist</h2>
-<p> Before uploading to Android Market, double-check the following items. Remember that these are
+<p> Before uploading to Google Play, double-check the following items. Remember that these are
specifically relevant to multiple APKs, and in no way represent a complete checklist for all
-applications being uploaded to Android Market.</p>
+applications being uploaded to Google Play.</p>
<ul>
<li>All APKs must have the same package name</li>
<li>All APKs must be signed with the same certificate</li>
@@ -317,7 +317,7 @@
</ul>
<p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t
-any surprises that could hide your application in Market. This is actually quite simple using the
+any surprises that could hide your application on Google Play. This is actually quite simple using the
"aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and
packaging your Android applications, and is also a very handy tool for inspecting them. </p>
@@ -345,11 +345,11 @@
supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values
that were added as a result of permissions you set in the manifest. In the example above, the APK
will be invisible to most, if not all devices.</p>
-<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.
+<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.
</p>
<p>Fortunately this is easily fixed by adding the following to your
manifest:</p>
<pre>
<uses-feature android:name="android.hardware.telephony" android:required="false" />
</pre>
-<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
+<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
diff --git a/docs/html/training/multiple-apks/texture.jd b/docs/html/training/multiple-apks/texture.jd
index 2bbe511..0dbee61 100644
--- a/docs/html/training/multiple-apks/texture.jd
+++ b/docs/html/training/multiple-apks/texture.jd
@@ -40,7 +40,7 @@
</div>
</div>
-<p>When developing your Android application to take advantage of multiple APKs on Android Market, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.</p>
+<p>When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.</p>
<h2 id="Confirm">Confirm You Need Multiple APKs</h2>
@@ -158,7 +158,7 @@
<h2 id="AdjustManifests">Adjust the Manifests</h2>
-<p>When a user downloads an application which uses multiple APKs through Android Market, the correct
+<p>When a user downloads an application which uses multiple APKs through Google Play, the correct
APK to use is chosen using some simple rules:</p>
<ul>
@@ -246,9 +246,9 @@
</pre>
<h2 id="PreLaunch">Go Over Pre-launch Checklist</h2>
-<p>Before uploading to Android Market, double-check the following items. Remember that these are
+<p>Before uploading to Google Play, double-check the following items. Remember that these are
specifically relevant to multiple APKs, and in no way represent a complete checklist for all
-applications being uploaded to Android Market.</p>
+applications being uploaded to Google Play.</p>
<ul>
<li>All APKs must have the same package name</li>
@@ -262,7 +262,7 @@
</ul>
<p>It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t
-any surprises that could hide your application in Market. This is actually quite simple using the
+any surprises that could hide your application on Google Play. This is actually quite simple using the
"aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and
packaging your Android applications, and is also a very handy tool for inspecting them. </p>
@@ -290,10 +290,10 @@
supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values
that were added as a result of permissions you set in the manifest. In the example above, the APK
will be invisible to most, if not all devices.</p>
-<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.
+<p>Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.
</p>
<p>Fortunately this is easily fixed by adding the following to your manifest:</p>
<pre>
<uses-feature android:name="android.hardware.telephony" android:required="false" />
</pre>
-<p>Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
+<p>Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!</p>
diff --git a/docs/html/training/sharing/receive.jd b/docs/html/training/sharing/receive.jd
index cc55967..a0a5bc8 100644
--- a/docs/html/training/sharing/receive.jd
+++ b/docs/html/training/sharing/receive.jd
@@ -34,7 +34,7 @@
from applications. Think about how users interact with your application, and what data types you
want to receive from other applications. For example, a social networking application would likely
be interested in receiving text content, like an interesting web URL, from another app. The
-<a href="https://market.android.com/details?id=com.google.android.apps.plus">Google+ Android
+<a href="https://play.google.com/store/details?id=com.google.android.apps.plus">Google+ Android
application</a>
accepts both text <em>and</em> single or multiple images. With this app, a user can easily start a
new Google+ post with photos from the Android Gallery app.</p>
diff --git a/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp b/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp
index 74fe478..b3c350f 100644
--- a/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp
+++ b/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp
@@ -1041,7 +1041,7 @@
/* Marker Bit */
if (!BitstreamRead1Bits(stream))
{
- mp4dec_log("DecodeShortHeader(): Market bit wrong.\n");
+ mp4dec_log("DecodeShortHeader(): Marker bit wrong.\n");
status = PV_FAIL;
goto return_point;
}