Doc change: String changes for Android Market

Change-Id: I823812a4fd24021bec906ad856479c92a8d2a759

14 files changed, 459 insertions, 459 deletions

diff --git a/docs/html/guide/market/billing/billing_admin.jd b/docs/html/guide/market/billing/billing_admin.jd
index a84eb4e..0f869ab 100755
--- a/docs/html/guide/market/billing/billing_admin.jd
+++ b/docs/html/guide/market/billing/billing_admin.jd
@@ -38,19 +38,19 @@ parent.link=index.html
 few administrative tasks, including setting up and maintaining your product list on the publisher
 site, registering test accounts, and handling refunds when necessary.</p>
 
-<p>You must have an Android Market publisher account to register test accounts. And you must have a
+<p>You must have a Google Play publisher account to register test accounts. And you must have a
 Google Checkout merchant account to create a product list and issue refunds to your users. If you
-already have a publisher account on Android Market, you can use your existing account. You do not
+already have a publisher account on Google Play, you can use your existing account. You do not
 need to register for a new account to support in-app billing. If you do not have a publisher
-account, you can register as an Android Market developer and set up a publisher account at the
-Android Market <a href="http://market.android.com/publish">publisher site</a>. If you do not have a
+account, you can register as a Google Play developer and set up a publisher account at the
+Google Play <a href="http://play.google.com/apps/publish">publisher site</a>. If you do not have a
 Google Checkout merchant account, you can register for one at the <a
 href="http://checkout.google.com">Google Checkout site</a>.</p>
 
 <h2 id="billing-list-setup">Creating a Product List</h2>
 
-<p>The Android Market publisher site provides a product list for each of your published
-applications. You can sell an item using Android Market's in-app billing feature only if the item is
+<p>The Google Play publisher site provides a product list for each of your published
+applications. You can sell an item using Google Play's in-app billing feature only if the item is
 listed on an application's product list. Each application has its own product list; you cannot sell
 items that are listed in another application's product list.</p>
 
@@ -77,7 +77,7 @@ storing and delivering the digital content that you sell in your applications.</
 </p>
 
 <p>You can create a product list for any published application or any draft application that's been
-uploaded and saved to the Android Market site. However, you must have a Google Checkout merchant
+uploaded and saved to the Google Play site. However, you must have a Google Checkout merchant
 account and the application's manifest must include the <code>com.android.vending.BILLING</code>
 permission. If an application's manifest does not include this permission, you will be able to edit
 existing items in the product list but you will not be able to add new items to the list. For more
@@ -104,8 +104,8 @@ number of in-app items.</p>
 <p>To add an item to a product list using the In-app Products UI, follow these steps:</p>
 
 <ol>
-  <li><a href="http://market.android.com/publish">Log in</a> to your publisher account.</li>
-  <li>In the <strong>All Android Market listings</strong> panel, under the application name, click
+  <li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li>
+  <li>In the <strong>All Google Play listings</strong> panel, under the application name, click
   <strong>In-app Products</strong>.</li>
   <li>On the In-app Products List page, click <strong>Add in-app product</strong>.</li>
   <li>On the Create New In-app Product page (see figure 3), provide details about the item you are
@@ -137,7 +137,7 @@ number of in-app items.</p>
   <li><strong>Publishing State</strong>
     <p>An item's publishing state can be <strong>Published</strong> or <strong>Unpublished
     </strong>. To be visible to a user during checkout, an item's publishing state must be set to
-    <strong>Published</strong> and the item's application must be published on Android Market.</p>
+    <strong>Published</strong> and the item's application must be published on Google Play.</p>
     <p class="note"><strong>Note:</strong> This is not true for test accounts. An item is visible to
     a test account if the application is not published and the item is published. See <a
     href="{@docRoot}guide/market/billing/billing_testing.html#billing-testing-real">Testing In-app
@@ -167,9 +167,9 @@ number of in-app items.</p>
     <p>You must provide a default price in your home currency. You can also provide prices in other
     currencies, but you can do this only if a currency's corresponding country is listed as a
     target country for your application. You can specify target countries on the Edit Application
-    page in the Android Market developer console.</p>
+    page in the Google Play developer console.</p>
     <p>To specify prices in other currencies, you can manually enter the price for each
-    currency or you can click <strong>Auto Fill</strong> and let Android Market do a one-time
+    currency or you can click <strong>Auto Fill</strong> and let Google Play do a one-time
     conversion from your home currency to the currencies you are targeting (see figure 4).</p>
   </li>
 </ul>
@@ -357,8 +357,8 @@ with the <em>locale</em> field.</p>
 <p>To import the items that are specified in your CSV file, do the following:</p>
 
 <ol>
-  <li><a href="http://market.android.com/publish">Log in</a> to your publisher account.</li>
-  <li>In the <strong>All Android Market listings</strong> panel, under the application name, click
+  <li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li>
+  <li>In the <strong>All Google Play listings</strong> panel, under the application name, click
   <strong>In-app Products</strong>.</li>
   <li>On the In-app Products List page, click <strong>Choose File</strong> and select your CSV
 file.
@@ -381,17 +381,17 @@ a product list and you want to start managing the product list through a CSV fil
 
 <h3 id="billing-purchase-type">Choosing a Purchase Type</h3>
 
-<p>An item's purchase type controls how Android Market manages the purchase of the item. There are
+<p>An item's purchase type controls how Google Play manages the purchase of the item. There are
 two purchase types: "managed per user account" and "unmanaged."</p>
 
 <p>Items that are managed per user account can be purchased only once per user account. When an item
-is managed per user account, Android Market permanently stores the transaction information for each
-item on a per-user basis. This enables you to query Android Market with the
+is managed per user account, Google Play permanently stores the transaction information for each
+item on a per-user basis. This enables you to query Google Play with the
 <code>RESTORE_TRANSACTIONS</code> request and restore the state of the items a specific user has
 purchased.</p>
 
-<p>If a user attempts to purchase a managed item that has already been purchased, Android Market
-displays an "Item already purchased" error. This occurs during checkout, when Android Market
+<p>If a user attempts to purchase a managed item that has already been purchased, Google Play
+displays an "Item already purchased" error. This occurs during checkout, when Google Play
 displays the price and description information on the checkout page. When the user dismisses the
 error message, the checkout page disappears and the user returns to your user interface. As a best
 practice, your application should prevent the user from seeing this error. The sample application
@@ -404,10 +404,10 @@ or application features. These items are not transient and usually need to be re
 user reinstalls your application, wipes the data on their device, or installs your application on a
 new device.</p>
 
-<p>Items that are unmanaged do not have their transaction information stored on Android Market,
-which means you cannot query Android Market to retrieve transaction information for items whose
+<p>Items that are unmanaged do not have their transaction information stored on Google Play,
+which means you cannot query Google Play to retrieve transaction information for items whose
 purchase type is listed as unmanaged. You are responsible for managing the transaction information
-of unmanaged items. Also, unmanaged items can be purchased multiple times as far as Android Market
+of unmanaged items. Also, unmanaged items can be purchased multiple times as far as Google Play
 is concerned, so it's also up to you to control how many times an unmanaged item can be
 purchased.</p>
 
@@ -417,10 +417,10 @@ times.</p>
 
 <h2 id="billing-refunds">Handling Refunds</h2>
 
-<p>In-app billing does not allow users to send a refund request to Android Market. Refunds for
+<p>In-app billing does not allow users to send a refund request to Google Play. Refunds for
 in-app purchases must be directed to you (the application developer). You can then process the
-refund through your Google Checkout merchant account. When you do this, Android Market receives a
-refund notification from Google Checkout, and Android Market sends a refund message to your
+refund through your Google Checkout merchant account. When you do this, Google Play receives a
+refund notification from Google Checkout, and Google Play sends a refund message to your
 application. For more information, see <a
 href="{@docRoot}guide/market/billing/billing_overview.html#billing-action-notify">Handling
 IN_APP_NOTIFY messages</a> and <a
@@ -434,9 +434,9 @@ information.</p>
 
 <h2 id="billing-testing-setup">Setting Up Test Accounts</h2>
 
-<p>The Android Market publisher site lets you set up one or more test accounts. A test account is a
+<p>The Google Play publisher site lets you set up one or more test accounts. A test account is a
 regular Google account that you register on the publisher site as a test account. Test accounts are
-authorized to make in-app purchases from applications that you have uploaded to the Android Market
+authorized to make in-app purchases from applications that you have uploaded to the Google Play
 site but have not yet published.</p>
 
 <p>You can use any Google account as a test account. Test accounts are useful if you want to let
@@ -458,7 +458,7 @@ accounts yourself and distribute the credentials to your developers or testers.<
 <p>To add test accounts to your publisher account, follow these steps:</p>
 
 <ol>
-  <li><a href="http://market.android.com/publish">Log in</a> to your publisher account.</li>
+  <li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li>
   <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li>
   <li>On the Edit Profile page, scroll down to the Licensing &amp; In-app Billing panel (see figure
   5).</li>
@@ -480,7 +480,7 @@ support resources listed in the following table (see table 2). By directing your
 correct forum, you can get the support you need more quickly.</p>
 
 <p class="table-caption" id="support-table"><strong>Table 2.</strong> Developer support resources
-for Android Market in-app billing.</p>
+for Google Play in-app billing.</p>
 
 <table>
 
@@ -502,8 +502,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co
 android</a></td>
 </tr>
 <tr>
-<td>Market billing issue tracker</td>
-<td><a href="http://code.google.com/p/marketbilling/issues/">Market billing
+<td>Billing issue tracker</td>
+<td><a href="http://code.google.com/p/marketbilling/issues/">Billing
 project issue tracker</a></td>
 <td>Bug and issue reports related specifically to in-app billing sample code.</td>
 </tr>
diff --git a/docs/html/guide/market/billing/billing_best_practices.jd b/docs/html/guide/market/billing/billing_best_practices.jd
index d9776af..e100ce5 100755
--- a/docs/html/guide/market/billing/billing_best_practices.jd
+++ b/docs/html/guide/market/billing/billing_best_practices.jd
@@ -32,7 +32,7 @@ parent.link=index.html
 
 <p>As you design your in-app billing implementation, be sure to follow the security and design
 guidelines that are discussed in this document. These guidelines are recommended best practices for
-anyone who is using Android Market's in-app billing service.</p>
+anyone who is using Google Play's in-app billing service.</p>
 
 <h2>Security Best Practices</h2>
 
@@ -92,7 +92,7 @@ replay attacks.</p>
 nonces on the server.</p>
 
 <h4>Take action against trademark and copyright infringement</h4>
-<p>If you see your content being redistributed on Android Market, act quickly and decisively. File a
+<p>If you see your content being redistributed on Google Play, act quickly and decisively. File a
 <a href="http://market.android.com/support/bin/answer.py?hl=en&amp;answer=141511">trademark notice
 of infringement</a> or a <a href="http://www.google.com/android_dmca.html">copyright notice of
 infringement</a>.</p>
@@ -102,7 +102,7 @@ infringement</a>.</p>
 purchase state of the unlocked content whenever a user accesses the content. This allows you to
 revoke use when necessary and minimize piracy.</p>
 
-<h4>Protect your Android Market public key</h4>
+<h4>Protect your Google Play public key</h4>
 <p>To keep your public key safe from malicious users and hackers, do not embed it in any code as a
 literal string. Instead, construct the string at runtime from pieces or use bit manipulation (for
 example, XOR with some other string) to hide the actual key. The key itself is not secret
diff --git a/docs/html/guide/market/billing/billing_integrate.jd b/docs/html/guide/market/billing/billing_integrate.jd
index 6017583..57f685b 100755
--- a/docs/html/guide/market/billing/billing_integrate.jd
+++ b/docs/html/guide/market/billing/billing_integrate.jd
@@ -35,8 +35,8 @@ parent.link=index.html
 </div>
 </div>
 
-<p>Android Market In-app Billing provides a straightforward, simple interface for sending in-app
-billing requests and managing in-app billing transactions using Android Market. This document helps
+<p>In-app Billing on Google Play provides a straightforward, simple interface for sending in-app
+billing requests and managing in-app billing transactions using Google Play. This document helps
 you implement in-app billing by stepping through the primary implementation tasks, using the in-app
 billing sample application as an example.</p>
 
@@ -53,23 +53,23 @@ billing.</p>
   <li><a href="#billing-permission">Update your AndroidManifest.xml file</a>.</li>
   <li><a href="#billing-service">Create a Service</a> and bind it to the
   <code>MarketBillingService</code> so your application can send billing requests and receive
-  billing responses from the Android Market application.</li>
+  billing responses from Google Play.</li>
   <li><a href="#billing-broadcast-receiver">Create a BroadcastReceiver</a> to handle broadcast
-  intents from the Android Market application.</li>
+  intents from Google Play.</li>
   <li><a href="#billing-signatures">Create a security processing component</a> to verify the
-  integrity of the transaction messages that are sent by Android Market .</li>
+  integrity of the transaction messages that are sent by Google Play.</li>
   <li><a href="#billing-implement">Modify your application code</a> to support in-app billing.</li>
 </ol>
 
 <h2 id="billing-download">Downloading the Sample Application</h2>
 
 <p>The in-app billing sample application shows you how to perform several tasks that are common to
-all Android Market in-app billing implementations, including:</p>
+all in-app billing implementations, including:</p>
 
 <ul>
-  <li>Sending in-app billing requests to the Android Market application.</li>
-  <li>Handling synchronous responses from the Android Market application.</li>
-  <li>Handling broadcast intents (asynchronous responses) from the Android Market application.</li>
+  <li>Sending in-app billing requests to Google Play.</li>
+  <li>Handling synchronous responses from Google Play.</li>
+  <li>Handling broadcast intents (asynchronous responses) from Google Play.</li>
   <li>Using in-app billing security mechanisms to verify the integrity of billing responses.</li>
   <li>Creating a user interface that lets users select items for purchase.</li>
 </ul>
@@ -109,12 +109,12 @@ history.</td>
 <tr>
   <td>BillingReceiver.java</td>
   <td>A {@link android.content.BroadcastReceiver} that receives asynchronous response messages
-  (broadcast intents) from Android Market. Forwards all messages to the
+  (broadcast intents) from Google Play. Forwards all messages to the
   <code>BillingService</code>.</td>
 </tr>
 <tr>
   <td>BillingService.java</td>
-  <td>A {@link android.app.Service} that sends messages to Android Market on behalf of the
+  <td>A {@link android.app.Service} that sends messages to Google Play on behalf of the
   application by connecting (binding) to the <code>MarketBillingService</code>.</td>
 </tr>
 
@@ -136,8 +136,8 @@ history.</td>
 
 <tr>
 <td>Consts.java</td>
-<td>Defines various Android Market constants and sample application constants. All constants that
-are defined by Android Market must be defined the same way in your application.</td>
+<td>Defines various Google Play constants and sample application constants. All constants that
+are defined by Google Play must be defined the same way in your application.</td>
 </tr>
 
 <tr>
@@ -171,7 +171,7 @@ running the sample application involves three tasks:</p>
 
 <ul>
   <li>Configuring and building the sample application.</li>
-  <li>Uploading the sample application to Android Market.</li>
+  <li>Uploading the sample application to Google Play.</li>
   <li>Setting up test accounts and running the sample application.</li>
 </ul>
 
@@ -186,12 +186,12 @@ your project</a>.</p>
 following:</p>
 
 <ol>
-  <li><strong>Add your Android Market public key to the sample application code.</strong>
+  <li><strong>Add your Google Play public key to the sample application code.</strong>
     <p>This enables the application to verify the signature of the transaction information that is
-    returned from Android Market. To add your public key to the sample application code, do the
+    returned from Google Play. To add your public key to the sample application code, do the
     following:</p>
     <ol>
-      <li>Log in to your Android Market <a href="http://market.android.com/publish">publisher
+      <li>Log in to your Google Play <a href="http://play.google.com/apps/publish">publisher
       account</a>.</li>
       <li>On the upper left part of the page, under your name, click <strong>Edit
       Profile</strong>.</li>
@@ -208,7 +208,7 @@ following:</p>
     </ol>
   </li>
   <li><strong>Change the package name of the sample application.</strong>
-    <p>The current package name is <code>com.example.dungeons</code>. Android Market does not let
+    <p>The current package name is <code>com.example.dungeons</code>. Google Play does not let
     you upload applications with package names that contain <code>com.example</code>, so you must
     change the package name to something else.</p>
   </li>
@@ -221,14 +221,14 @@ following:</p>
 <h3>Uploading the sample application</h3>
 
 <p>After you build a release version of the sample application and sign it, you need to upload it as
-a draft to the Android Market publisher site. You also need to create a product list for the in-app
+a draft to the Google Play publisher site. You also need to create a product list for the in-app
 items that are available for purchase in the sample application. The following instructions show you
 how to do this.</p>
 <ol>
-  <li><strong>Upload the release version of the sample application to Android Market.</strong>
+  <li><strong>Upload the release version of the sample application to Google Play.</strong>
     <p>Do not publish the sample application; leave it as an unpublished draft application. The
     sample application is for demonstration purposes only and should not be made publicly available
-    on Android Market. To learn how to upload an application to Android Market, see <a
+    on Google Play. To learn how to upload an application to Google Play, see <a
     href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading
     applications</a>.</p>
   </li>
@@ -253,7 +253,7 @@ how to do this.</p>
 onto a device to run it. To run the sample application, do the following:</p>
 
 <ol>
-  <li><strong>Make sure you have at least one test account registered under your Android Market
+  <li><strong>Make sure you have at least one test account registered under your Google Play
   publisher account.</strong>
     <p>You cannot purchase items from yourself (Google Checkout prohibits this), so you need to
     create at least one test account that you can use to purchase items in the sample application.
@@ -261,18 +261,18 @@ onto a device to run it. To run the sample application, do the following:</p>
     href="{@docRoot}guide/market/billing/billing_testing.html#billing-testing-setup">Setting up Test
     Accounts</a>.</p>
   </li>
-  <li><strong>Verify that your device is running a supported version of the Android Market
+  <li><strong>Verify that your device is running a supported version of the Google Play
   application or the MyApps application.</strong>
     <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, in-app billing
-    requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the
-    version of the Android Market application, see <a
-    href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android
-    Market</a>.</p>
+    requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+    version of the Google Play application, see <a
+    href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
+    Play</a>.</p>
   </li>
   <li><strong>Install the application onto your device.</strong>
-    <p>Even though you uploaded the application to Android Market, the application is not published,
-    so you cannot download it from Android Market to a device. Instead, you must install the
+    <p>Even though you uploaded the application to Google Play, the application is not published,
+    so you cannot download it from Google Play to a device. Instead, you must install the
     application onto your device. To learn how to install an application onto a device, see <a
     href="{@docRoot}guide/developing/building/building-cmdline.html#RunningOnDevice">Running on a
     device</a>.</p>
@@ -280,7 +280,7 @@ onto a device to run it. To run the sample application, do the following:</p>
  <li><strong>Make one of your test accounts the primary account on your device.</strong>
     <p>The primary account on your device must be one of the <a
     href="{@docRoot}guide/market/billing/billing_admin.html#billing-testing-setup">test accounts</a>
-    that you registered on the Android Market site. If the primary account on your device is not a
+    that you registered on the Google Play publisher site. If the primary account on your device is not a
     test account, you must do a factory reset of the device and then sign in with one of your test
     accounts. To perform a factory reset, do the following:</p>
     <ol>
@@ -306,7 +306,7 @@ to <code>true</code> in the <code>Consts.java</code> file.</p>
 <h2 id="billing-add-aidl">Adding the AIDL file to your project</h2>
 
 <p>The sample application contains an Android Interface Definition Language (AIDL) file,  which
-defines the interface to Android Market's in-app billing service
+defines the interface to Google Play's in-app billing service
 (<code>MarketBillingService</code>). When you add this file to your project, the Android build
 environment creates an interface file (<code>IMarketBillingService.java</code>). You can then use
 this interface to make billing requests by invoking IPC method calls.</p>
@@ -333,29 +333,29 @@ the <code>gen</code> folder of your project.</p>
 
 <h2 id="billing-permission">Updating Your Application's Manifest</h2>
 
-<p>In-app billing relies on the Android Market application, which handles all communication between
-your application and the Android Market server. To use the Android Market application, your
+<p>In-app billing relies on the Google Play application, which handles all communication between
+your application and the Google Play server. To use the Google Play application, your
 application must request the proper permission. You can do this by adding the
 <code>com.android.vending.BILLING</code> permission to your AndroidManifest.xml file. If your
 application does not declare the in-app billing permission, but attempts to send billing requests,
-Android Market will refuse the requests and respond with a <code>RESULT_DEVELOPER_ERROR</code>
+Google Play will refuse the requests and respond with a <code>RESULT_DEVELOPER_ERROR</code>
 response code.</p>
 
 <p>In addition to the billing permission, you need to declare the {@link
 android.content.BroadcastReceiver} that you will use to receive asynchronous response messages
-(broadcast intents) from Android Market, and you need to declare the {@link android.app.Service}
-that you will use to bind with the <code>IMarketBillingService</code> and send messages to Android
-Market. You must also declare <a
+(broadcast intents) from Google Play, and you need to declare the {@link android.app.Service}
+that you will use to bind with the <code>IMarketBillingService</code> and send messages to Google
+Play. You must also declare <a
 href="{@docRoot}guide/topics/manifest/intent-filter-element.html">intent filters</a> for the {@link
 android.content.BroadcastReceiver} so that the Android system knows how to handle the broadcast
-intents that are sent from the Android Market application.</p>
+intents that are sent from the Google Play application.</p>
 
 <p>For example, here is how the in-app billing sample application declares the billing permission,
 the {@link android.content.BroadcastReceiver}, the {@link android.app.Service}, and the intent
 filters. In the sample application, <code>BillingReceiver</code> is the {@link
-android.content.BroadcastReceiver} that handles broadcast intents from the Android Market
+android.content.BroadcastReceiver} that handles broadcast intents from the Google Play
 application and <code>BillingService</code> is the {@link android.app.Service} that sends requests
-to the Android Market application.</p>
+to the Google Play application.</p>
 
 <pre>
 &lt;?xml version="1.0" encoding="utf-8"?&gt;
@@ -391,11 +391,11 @@ to the Android Market application.</p>
 <h2 id="billing-service">Creating a Local Service</h2>
 
 <p>Your application must have a local {@link android.app.Service} to facilitate messaging between
-your application and Android Market. At a minimum, this service must do the following:</p>
+your application and Google Play. At a minimum, this service must do the following:</p>
 
 <ul>
   <li>Bind to the <code>MarketBillingService</code>.
-  <li>Send billing requests (as IPC method calls) to the Android Market application. The five types
+  <li>Send billing requests (as IPC method calls) to the Google Play application. The five types
   of billing requests include:
     <ul>
       <li><code>CHECK_BILLING_SUPPORTED</code> requests</li>
@@ -474,7 +474,7 @@ The five request types are specified using the <code>BILLING_REQUEST</code> Bund
 key can have the following five values:</p>
 
 <ul>
-  <li><code>CHECK_BILLING_SUPPORTED</code>&mdash;verifies that the Android Market application
+  <li><code>CHECK_BILLING_SUPPORTED</code>&mdash;verifies that the Google Play application
   supports in-app billing.</li>
   <li><code>REQUEST_PURCHASE</code>&mdash;sends a purchase request for an in-app item.</li>
   <li><code>GET_PURCHASE_INFORMATION</code>&mdash;retrieves transaction information for a purchase
@@ -510,7 +510,7 @@ application's main thread.</p>
 
 <h4>Verifying that in-app billing is supported (CHECK_BILLING_SUPPPORTED)</h4>
 
-<p>The following code sample shows how to verify whether the Android Market application supports
+<p>The following code sample shows how to verify whether the Google Play application supports
 in-app billing. In the sample, <code>mService</code> is an instance of the
 <code>MarketBillingService</code> interface.</p>
 
@@ -533,7 +533,7 @@ android.os.Bundle} response, which contains only a single key: <code>RESPONSE_CO
   <li><code>RESULT_BILLING_UNAVAILABLE</code>&mdash;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>&mdash;there was an error connecting with the Android Market
+  <li><code>RESULT_ERROR</code>&mdash;there was an error connecting with the Google Play
   application.</li>
   <li><code>RESULT_DEVELOPER_ERROR</code>&mdash;the application is trying to make an in-app billing
   request but the application has not declared the <code>com.android.vending.BILLING</code>
@@ -546,10 +546,10 @@ android.os.Bundle} response, which contains only a single key: <code>RESPONSE_CO
 
 <p>We recommend that you invoke the <code>CHECK_BILLING_SUPPORTED</code> request within a
 <code>RemoteException</code> block. When your code throws a <code>RemoteException</code> it
-indicates that the remote method call failed, which means that the Android Market application is out
+indicates that the remote method call failed, which means that the Google Play application is out
 of date and needs to be updated. In this case, you can provide users with an error message that
 contains a link to the <a
-href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android Market</a>
+href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google Play</a>
 Help topic.</p>
 
 <p>The sample application demonstrates how you can handle this error condition (see
@@ -561,16 +561,16 @@ Help topic.</p>
 
 <ul>
   <li>Send the <code>REQUEST_PURCHASE</code> request.</li>
-  <li>Launch the {@link android.app.PendingIntent} that is returned from the Android Market
+  <li>Launch the {@link android.app.PendingIntent} that is returned from the Google Play
   application.</li>
-  <li>Handle the broadcast intents that are sent by the Android Market application.</li>
+  <li>Handle the broadcast intents that are sent by the Google Play application.</li>
 </ul>
 
 <h5>Making the request</h5>
 
 <p>You must specify four keys in the request {@link android.os.Bundle}. The following code sample
 shows how to set these keys and make a purchase request for a single in-app item. In the sample,
-<code>mProductId</code> is the Android Market product ID of an in-app item (which is listed in the
+<code>mProductId</code> is the Google Play product ID of an in-app item (which is listed in the
 application's <a href="{@docRoot}guide/market/billing/billing_admin.html#billing-list-setup">product
 list</a>), and <code>mService</code> is an instance of the <code>MarketBillingService</code>
 interface.</p>
@@ -644,25 +644,25 @@ void startBuyPageActivity(PendingIntent pendingIntent, Intent intent) {
 context and not an application context. Also, you cannot use the <code>singleTop</code> <a
 href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">launch mode</a> to launch the
 pending intent. If you do either of these, the Android system will not attach the pending intent to
-your application process. Instead, it will bring Android Market to the foreground, disrupting your
+your application process. Instead, it will bring Google Play to the foreground, disrupting your
 application.</p>
 
 <h5>Handling broadcast intents</h5>
 
 <p>A <code>REQUEST_PURCHASE</code> request also triggers two asynchronous responses (broadcast
-intents). First, the Android Market application sends a <code>RESPONSE_CODE</code> broadcast intent,
+intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent,
 which provides error information about the request. If the request does not generate an
 error, the <code>RESPONSE_CODE</code> broadcast intent returns <code>RESULT_OK</code>, which
 indicates that the request was successfully sent. (To be clear, a <code>RESULT_OK</code> response
 does not indicate that the requested purchase was successful; it indicates that the request was sent
-successfully to Android Market.)</p>
+successfully to Google Play.)</p>
 
 <p>Next, when the requested transaction changes state (for example, the purchase is successfully
-charged to a credit card or the user cancels the purchase), the Android Market application sends an
+charged to a credit card or the user cancels the purchase), the Google Play application sends an
 <code>IN_APP_NOTIFY</code> broadcast intent. This message contains a notification ID, which you can
 use to retrieve the transaction details for the <code>REQUEST_PURCHASE</code> request.</p>
 
-<p class="note"><strong>Note:</strong> The Android Market application also sends
+<p class="note"><strong>Note:</strong> The Google Play application also sends
 an <code>IN_APP_NOTIFY</code> for refunds. For more information, see <a
 href="{@docRoot}guide/market/billing/billing_overview.html#billing-action-notify">Handling
 IN_APP_NOTIFY messages</a>.</p>
@@ -670,7 +670,7 @@ IN_APP_NOTIFY messages</a>.</p>
 <p>Because the purchase process is not instantaneous and can take several seconds (or more), you
 must assume that a purchase request is pending from the time you receive a <code>RESULT_OK</code>
 message until you receive an <code>IN_APP_NOTIFY</code> message for the transaction. While the
-transaction is pending, the Android Market checkout UI displays an "Authorizing purchase..."
+transaction is pending, the Google Play checkout UI displays an "Authorizing purchase..."
 notification; however, this notification is dismissed after 60 seconds and you should not rely on
 this notification as your primary means of conveying transaction status to users. Instead, we
 recommend that you do the following:</p>
@@ -693,12 +693,12 @@ status of pending and completed in-app purchases.</p>
 be sure that your pending status UI does not block your application. For example, you should avoid
 using a hovering progress wheel to convey the status of a pending transaction because a pending
 transaction could last a long time, particularly if a device loses network connectivity and cannot
-receive transaction updates from Android Market.</p>
+receive transaction updates from Google Play.</p>
 
 <p class="caution"><strong>Important:</strong> If a user purchases a managed item, you must prevent
 the user from purchasing the item again while the original transaction is pending. If a user
-attempts to purchase a managed item twice, and the first transaction is still pending, Android
-Market will display an error to the user; however, Android Market will not send an error to your
+attempts to purchase a managed item twice, and the first transaction is still pending, Google
+Play will display an error to the user; however, Google Play will not send an error to your
 application notifying you that the second purchase request was canceled. This might cause your
 application to get stuck in a pending state while it waits for an <code>IN_APP_NOTIFY</code> message
 for the second purchase request.</p>
@@ -730,7 +730,7 @@ three keys that are required for all requests: <code>BILLING_REQUEST</code>,
 <code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional keys are then added to the
 bundle prior to invoking the <code>sendBillingRequest()</code> method. The
 <code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you
-must generate. The Android Market application returns this nonce with the
+must generate. The Google Play application returns this nonce with the
 <code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the integrity of the
 transaction information. The <code>NOTIFY_IDS</code> key contains an array of notification IDs,
 which you received in the <code>IN_APP_NOTIFY</code> broadcast intent.</p>
@@ -741,9 +741,9 @@ you with the status of the request and the <code>REQUEST_ID</code> key provides
 request identifier for the request.</p>
 
 <p>A <code>GET_PURCHASE_INFORMATION</code> request also triggers two asynchronous responses
-(broadcast intents). First, the Android Market application sends a <code>RESPONSE_CODE</code>
+(broadcast intents). First, the Google Play application sends a <code>RESPONSE_CODE</code>
 broadcast intent, which provides status and error information about the request. Next, if the
-request was successful, the Android Market application sends a <code>PURCHASE_STATE_CHANGED</code>
+request was successful, the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code>
 broadcast intent. This message contains detailed transaction information. The transaction
 information is contained in a signed JSON string (unencrypted). The message includes the signature
 so you can verify the integrity of the signed string.</p>
@@ -783,8 +783,8 @@ request identifier for the request.</p>
 <code>RESPONSE_CODE</code> broadcast intent. This broadcast intent provides status and error
 information about the request.</p>
 
-<p>You must send a confirmation when you receive transaction information from Android Market. If you
-don't send a confirmation message, Android Market will continue sending
+<p>You must send a confirmation when you receive transaction information from Google Play. If you
+don't send a confirmation message, Google Play will continue sending
 <code>IN_APP_NOTIFY</code> messages for the transactions you have not confirmed. Also,
 your application must be able to handle <code>IN_APP_NOTIFY</code> messages that contain multiple
 orders.</p>
@@ -792,7 +792,7 @@ orders.</p>
 <p>In addition, as a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request
 for a purchased item until you have delivered the item to the user. This way, if your application
 crashes or something else prevents your application from delivering the product, your application
-will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Android Market indicating
+will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating
 that you need to deliver the product.</p>
 
 <h4>Restoring transaction information (RESTORE_TRANSACTIONS)</h4>
@@ -817,7 +817,7 @@ three keys that are required for all requests: <code>BILLING_REQUEST</code>,
 <code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional <code>REQUEST_NONCE</code>
 key is then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The
 <code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you
-must generate. The Android Market application returns this nonce with the transactions information
+must generate. The Google Play application returns this nonce with the transactions information
 contained in the <code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the
 integrity of the transaction information.</p>
 
@@ -827,9 +827,9 @@ you with the status of the request and the <code>REQUEST_ID</code> key provides
 request identifier for the request.</p>
 
 <p>A <code>RESTORE_TRANSACTIONS</code> request also triggers two asynchronous responses (broadcast
-intents). First, the Android Market application sends a <code>RESPONSE_CODE</code> broadcast intent,
+intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent,
 which provides status and error information about the request. Next, if the request was successful,
-the Android Market application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This
+the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This
 message contains the detailed transaction information. The transaction information is contained in a
 signed JSON string (unencrypted). The message includes the signature so you can verify the integrity
 of the signed string.</p>
@@ -842,7 +842,7 @@ application has been removed from a device and reinstalled.</p>
 
 <p>You may also want your {@link android.app.Service} to receive intent messages from your {@link
 android.content.BroadcastReceiver}. You can use these intent messages to convey the information that
-was sent asynchronously from the Android Market application to your {@link
+was sent asynchronously from the Google Play application to your {@link
 android.content.BroadcastReceiver}. To see an example of how you can send and receive these intent
 messages, see the <code>BillingReceiver.java</code> and <code>BillingService.java</code> files in
 the sample application. You can use these samples as a basis for your own implementation. However,
@@ -851,16 +851,16 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D
 
 <h2 id="billing-broadcast-receiver">Creating a BroadcastReceiver</h2>
 
-<p>The Android Market application uses broadcast intents to send asynchronous billing responses to
+<p>The Google Play application uses broadcast intents to send asynchronous billing responses to
 your application. To receive these intent messages, you need to create a {@link
 android.content.BroadcastReceiver} that can handle the following intents:</p>
 
 <ul>
   <li>com.android.vending.billing.RESPONSE_CODE
-  <p>This broadcast intent contains an Android Market response code, and is sent after you make an
+  <p>This broadcast intent contains a Google Play response code, and is sent after you make an
   in-app billing request. For more information about the response codes that are sent with this
   response, see <a
-  href="{@docRoot}guide/market/billing/billing_reference.html#billing-codes">Android Market Response
+  href="{@docRoot}guide/market/billing/billing_reference.html#billing-codes">Google Play Response
   Codes for In-app Billing</a>.</p>
   </li>
   <li>com.android.vending.billing.IN_APP_NOTIFY
@@ -895,18 +895,18 @@ sent in response to billing requests.</p>
   <td><code>com.android.vending.billing.RESPONSE_CODE</code></td>
   <td><code>request_id</code></td>
   <td>A <code>long</code> representing a request ID. A request ID identifies a specific billing
-  request and is returned by Android Market at the time a request is made.</td>
+  request and is returned by Google Play at the time a request is made.</td>
 </tr>
 <tr>
   <td><code>com.android.vending.billing.RESPONSE_CODE</code></td>
   <td><code>response_code</code></td>
-  <td>An <code>int</code> representing the actual Android Market server response code.</td>
+  <td>An <code>int</code> representing the actual Google Play server response code.</td>
 </tr>
 <tr>
   <td><code>com.android.vending.billing.IN_APP_NOTIFY</code></td>
   <td><code>notification_id</code></td>
   <td>A <code>String</code> representing the notification ID for a given purchase state change.
-  Android Market notifies you when there is a purchase state change and the notification includes a
+  Google Play notifies you when there is a purchase state change and the notification includes a
   unique notification ID. To get the details of the purchase state change, you send the notification
   ID with the <code>GET_PURCHASE_INFORMATION</code> request.</td>
 </tr>
@@ -933,16 +933,16 @@ public class BillingReceiver extends BroadcastReceiver {
 
   private static final String TAG = "BillingReceiver";
 
-  // Intent actions that we receive in the BillingReceiver from Android Market.
-  // These are defined by Android Market and cannot be changed.
+  // Intent actions that we receive in the BillingReceiver from Google Play.
+  // These are defined by Google Play and cannot be changed.
   // The sample application defines these in the Consts.java file.
   public static final String ACTION_NOTIFY = "com.android.vending.billing.IN_APP_NOTIFY";
   public static final String ACTION_RESPONSE_CODE = "com.android.vending.billing.RESPONSE_CODE";
   public static final String ACTION_PURCHASE_STATE_CHANGED =
     "com.android.vending.billing.PURCHASE_STATE_CHANGED";
 
-  // The intent extras that are passed in an intent from Android Market.
-  // These are defined by Android Market and cannot be changed.
+  // The intent extras that are passed in an intent from Google Play.
+  // These are defined by Google Play and cannot be changed.
   // The sample application defines these in the Consts.java file.
   public static final String NOTIFICATION_ID = "notification_id";
   public static final String INAPP_SIGNED_DATA = "inapp_signed_data";
@@ -974,7 +974,7 @@ public class BillingReceiver extends BroadcastReceiver {
 }
 </pre>
 
-<p>In addition to receiving broadcast intents from the Android Market application, your {@link
+<p>In addition to receiving broadcast intents from the Google Play application, your {@link
 android.content.BroadcastReceiver} must handle the information it received in the broadcast intents.
 Usually, your {@link android.content.BroadcastReceiver} does this by sending the information to a
 local service (discussed in the next section). The <code>BillingReceiver.java</code> file in the
@@ -985,8 +985,8 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D
 
 <h2 id="billing-signatures">Verifying Signatures and Nonces</h2>
 
-<p>Android Market's in-app billing service uses two mechanisms to help verify the integrity of the
-transaction information you receive from Android Market: nonces and signatures. A nonce (number used
+<p>Google Play's in-app billing service uses two mechanisms to help verify the integrity of the
+transaction information you receive from Google Play: nonces and signatures. A nonce (number used
 once) is a cryptographically secure number that your application generates and sends with every
 <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is
 returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, enabling you to verify that
@@ -1023,12 +1023,12 @@ implementation, be sure to follow the guidelines in <a
 href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and Design</a> and
 obfuscate your code.</p>
 
-<p>You will need to use your Android Market public key to perform the signature verification. The
-following procedure shows you how to retrieve Base64-encoded public key from the Android Market
+<p>You will need to use your Google Play public key to perform the signature verification. The
+following procedure shows you how to retrieve Base64-encoded public key from the Google Play
 publisher site.</p>
 
 <ol>
-  <li>Log in to your <a href="http://market.android.com/publish">publisher account</a>.</li>
+  <li>Log in to your <a href="http://play.google.com/apps/publish">publisher account</a>.</li>
   <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li>
   <li>On the Edit Profile page, scroll down to the Licensing &amp; In-app Billing panel (see figure
   2).</li>
@@ -1080,8 +1080,8 @@ unmanaged items is important because unmanaged items cannot be restored by using
 
 <h3>Creating a user interface for selecting items</h3>
 
-<p>You must provide users with a means for selecting items that they want to purchase. Android
-Market provides the checkout user interface (which is where the user provides a form of payment and
+<p>You must provide users with a means for selecting items that they want to purchase. Google
+Play provides the checkout user interface (which is where the user provides a form of payment and
 approves the purchase), but your application must provide a control (widget) that invokes the
 <code>sendBillingRequest()</code> method when a user selects an item for purchase.</p>
 
diff --git a/docs/html/guide/market/billing/billing_overview.jd b/docs/html/guide/market/billing/billing_overview.jd
index 8f9fd4c..b593811 100755
--- a/docs/html/guide/market/billing/billing_overview.jd
+++ b/docs/html/guide/market/billing/billing_overview.jd
@@ -38,24 +38,24 @@ parent.link=index.html
 </div>
 </div>
 
-<p>Android Market In-app Billing is an Android Market service that provides checkout processing for
+<p>In-app Billing is a Google Play service that provides checkout processing for
 in-app purchases. To use the service, your application sends a billing request for a specific in-app
 product. The service then handles all of the checkout details for the transaction, including
 requesting and validating the form of payment and processing the financial transaction. When the
 checkout process is complete, the service sends your application the purchase details, such as the
 order number, the order date and time, and the price paid. At no point does your application have to
-handle any financial transactions; that role is provided by Android Market's in-app billing
+handle any financial transactions; that role is provided by Google Play's in-app billing
 service.</p>
 
 <h2 id="billing-arch">In-app Billing Architecture</h2>
 
 <p>In-app billing uses an asynchronous message loop to convey billing requests and billing responses
-between your application and the Android Market server. In practice, your application never directly
-communicates with the Android Market server (see figure 1). Instead, your application sends billing
-requests to the Android Market application over interprocess communication (IPC) and receives
-purchase responses from the Android Market application in the form of asynchronous broadcast
-intents. Your application does not manage any network connections between itself and the Android
-Market server or use any special APIs from the Android platform.</p>
+between your application and the Google Play server. In practice, your application never directly
+communicates with the Google Play server (see figure 1). Instead, your application sends billing
+requests to the Google Play application over interprocess communication (IPC) and receives
+purchase responses from the Google Play application in the form of asynchronous broadcast
+intents. Your application does not manage any network connections between itself and the Google
+Play server or use any special APIs from the Android platform.</p>
 
 <p>Some in-app billing implementations may also use a private remote server to deliver content or
 validate transactions, but a remote server is not required to implement in-app billing. A remote
@@ -70,16 +70,16 @@ to security attacks.</p>
 <img src="{@docRoot}images/billing_arch.png" alt="" height="582" />
 <p class="img-caption">
   <strong>Figure 1.</strong> Your application sends and receives billing messages through the
-  Android Market application, which handles all communication with the Android Market server.</p>
+  Google Play application, which handles all communication with the Google Play server.</p>
 </div>
 
 <p>A typical in-app billing implementation relies on three components:</p>
 <ul>
   <li>A {@link android.app.Service} (named <code>BillingService</code> in the sample application),
-  which processes purchase messages from the application and sends billing requests to Android
-  Market's in-app billing service.</li>
+  which processes purchase messages from the application and sends billing requests to the Google
+  Play in-app billing service.</li>
   <li>A {@link android.content.BroadcastReceiver} (named <code>BillingReceiver</code> in the sample
-  application), which receives all asynchronous billing responses from the Android Market
+  application), which receives all asynchronous billing responses from the Google Play
   application.</li>
   <li>A security component (named <code>Security</code> in the sample application), which performs
   security-related tasks, such as signature verification and nonce generation. For more information
@@ -99,19 +99,19 @@ to security attacks.</p>
 
 <p>In addition to these components, your application must provide a way to store information about
 users' purchases and some sort of user interface that lets users select items to purchase. You do
-not need to provide a checkout user interface. When a user initiates an in-app purchase, the Android
-Market application presents the checkout user interface to your user. When the user completes the
+not need to provide a checkout user interface. When a user initiates an in-app purchase, the Google
+Play application presents the checkout user interface to your user. When the user completes the
 checkout process, your application resumes.</p>
 
 <h2 id="billing-msgs">In-app Billing Messages</h2>
 
-<p>When the user initiates a purchase, your application sends billing messages to Android Market's
+<p>When the user initiates a purchase, your application sends billing messages to Google Play's
 in-app billing service (named <code>MarketBillingService</code>) using simple IPC method calls. The
-Android Market application responds to all billing requests synchronously, providing your
-application with status notifications and other information. The Android Market application also
+Google Play application responds to all billing requests synchronously, providing your
+application with status notifications and other information. The Google Play application also
 responds to some billing requests asynchronously, providing your application with error messages and
 detailed transaction information. The following section describes the basic request-response
-messaging that takes place between your application and the Android Market application.</p>
+messaging that takes place between your application and the Google Play application.</p>
 
 <h3 id="billing-request">In-app billing requests</h3>
 
@@ -133,31 +133,31 @@ Service Interface</a>.
 
 <p>One of the most important keys that every request Bundle must have is the
 <code>BILLING_REQUEST</code> key. This key lets you specify the type of billing request you are
-making. Android Market's in-app billing service supports the following five types of billing
+making. Google Play's in-app billing service supports the following five types of billing
 requests:</p>
 
 <ul>
   <li><code>CHECK_BILLING_SUPPORTED</code>
-    <p>This request verifies that the Android Market application supports in-app billing. You
+    <p>This request verifies that the Google Play application supports in-app billing. You
     usually send this request when your application first starts up. This request is useful if you
     want to enable or disable certain UI features that are relevant only to in-app billing.</p>
   </li>
   <li><code>REQUEST_PURCHASE</code>
-    <p>This request sends a purchase message to the Android Market application and is the foundation
+    <p>This request sends a purchase message to the Google Play application and is the foundation
     of in-app billing. You send this request when a user indicates that he or she wants to purchase
-    an item in your application. Android Market then handles the financial transaction by displaying
+    an item in your application. Google Play then handles the financial transaction by displaying
     the checkout user interface.</p>
   </li>
   <li><code>GET_PURCHASE_INFORMATION</code>
     <p>This request retrieves the details of a purchase state change. A purchase changes state when
     a requested purchase is billed successfully or when a user cancels a transaction during
-    checkout. It can also occur when a previous purchase is refunded. Android Market notifies your
+    checkout. It can also occur when a previous purchase is refunded. Google Play notifies your
     application when a purchase changes state, so you only need to send this request when there is
     transaction information to retrieve.</p>
   </li>
   <li><code>CONFIRM_NOTIFICATIONS</code>
     <p>This request acknowledges that your application received the details of a purchase state
-    change. Android Market sends purchase state change notifications to your application until you
+    change. Google Play sends purchase state change notifications to your application until you
     confirm that you received them.</p>
   </li>
   <li><code>RESTORE_TRANSACTIONS</code>
@@ -171,7 +171,7 @@ requests:</p>
 
 <h3 id="billing-response">In-app Billing Responses</h3>
 
-<p>The Android Market application responds to in-app billing requests with both synchronous and
+<p>The Google Play application responds to in-app billing requests with both synchronous and
 asynchronous responses. The synchronous response is a {@link android.os.Bundle} with the following
 three keys:</p>
 
@@ -196,9 +196,9 @@ include the following:</p>
 
 <ul>
     <li><code>com.android.vending.billing.RESPONSE_CODE</code>
-    <p>This response contains an Android Market server response code, and is sent after you make an
+    <p>This response contains a Google Play server response code, and is sent after you make an
     in-app billing request. A server response code can indicate that a billing request was
-    successfully sent to Android Market or it can indicate that some error occurred during a billing
+    successfully sent to Google Play or it can indicate that some error occurred during a billing
     request. This response is <em>not</em> used to report any purchase state changes (such as refund
     or purchase information). For more information about the response codes that are sent with this
     response, see <a
@@ -253,7 +253,7 @@ broadcast intents that are sent for every request.</p>
 <ol>
   <li>Your application sends a purchase request (<code>REQUEST_PURCHASE</code> type), specifying a
   product ID and other parameters.</li>
-  <li>The Android Market application sends your application a Bundle with the following keys:
+  <li>The Google Play application sends your application a Bundle with the following keys:
   <code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and <code>REQUEST_ID</code>. The
   <code>PURCHASE_INTENT</code> key provides a {@link android.app.PendingIntent}, which your
   application uses to start the checkout UI for the given product ID.</li>
@@ -262,20 +262,20 @@ broadcast intents that are sent for every request.</p>
     context and not an application context.</p>
   </li>
   <li>When the checkout flow finishes (that is, the user successfully purchases the item or cancels
-  the purchase), Android Market sends your application a notification message (an
+  the purchase), Google Play sends your application a notification message (an
   <code>IN_APP_NOTIFY</code> broadcast intent). The notification message includes a notification ID,
   which references the transaction.</li>
   <li>Your application requests the transaction information by sending a
   <code>GET_PURCHASE_STATE_CHANGED</code> request, specifying the notification ID for the
   transaction.</li>
-  <li>The Android Market application sends a Bundle with a <code>RESPONSE_CODE</code> key and a 
+  <li>The Google Play application sends a Bundle with a <code>RESPONSE_CODE</code> key and a 
   <code>REQUEST_ID</code> key.
-  <li>Android Market sends the transaction information to your application in a
+  <li>Google Play sends the transaction information to your application in a
   <code>PURCHASE_STATE_CHANGED</code> broadcast intent.</li>
   <li>Your application confirms that you received the transaction information for the given
   notification ID by sending a confirmation message (<code>CONFIRM_NOTIFICATIONS</code> type),
   specifying the notification ID for which you received transaction information.</li>
-  <li>The Android Market application sends your application a Bundle with a
+  <li>The Google Play application sends your application a Bundle with a
   <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key.</li>
 </ol>
 
@@ -284,13 +284,13 @@ broadcast intents that are sent for every request.</p>
   <strong>Figure 2.</strong> Message sequence for a purchase request.
 </p>
 
-<p>Keep in mind, you must send a confirmation when you receive transaction information from Android
-Market (step 8 in figure 2). If you don't send a confirmation message, Android Market will
+<p>Keep in mind, you must send a confirmation when you receive transaction information from Google
+Play (step 8 in figure 2). If you don't send a confirmation message, Google Play will
 continue sending <code>IN_APP_NOTIFY</code> messages for the transactions you have not
 confirmed. As a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request for
 a purchased item until you have delivered the item to the user. This way, if your application
 crashes or something else prevents your application from delivering the product, your application
-will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Android Market indicating
+will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating
 that you need to deliver the product. Also, as a best practice, your application must be able to
 handle <code>IN_APP_NOTIFY</code> messages that contain multiple orders.</p>
 
@@ -307,7 +307,7 @@ broadcast intents that are sent for every request.</p>
 </div>
 
 <p>The request triggers three responses. The first is a {@link android.os.Bundle} with a
-<code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. Next, the Android Market
+<code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. Next, the Google Play
 application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides status information
 or error information about the request. As always, the <code>RESPONSE_CODE</code> message references
 a specific request ID, so you can determine which request a <code>RESPONSE_CODE</code> message
@@ -338,18 +338,18 @@ is supported; a <code>RESULT_BILLING_UNAVAILABLE</code> response code indicates
 is unavailable because the API version you specified is unrecognized or the user is not eligible to
 make in-app purchases (for example, the user resides in a country that does not allow in-app
 billing). A <code>SERVER_ERROR</code> can also be returned, indicating that there was a problem with
-the Android Market server.</p>
+the Google Play server.</p>
 
 <h3 id="billing-action-notify">Handling IN_APP_NOTIFY messages</h3>
 
-<p>Usually, your application receives an <code>IN_APP_NOTIFY</code> broadcast intent from Android
-Market in response to a <code>REQUEST_PURCHASE</code> message (see figure 2). The
+<p>Usually, your application receives an <code>IN_APP_NOTIFY</code> broadcast intent from Google
+Play in response to a <code>REQUEST_PURCHASE</code> message (see figure 2). The
 <code>IN_APP_NOTIFY</code> broadcast intent informs your application that the state of a requested
 purchase has changed. To retrieve the details of that purchase, your application sends a
-<code>GET_PURCHASE_INFORMATION</code> request. Android Market responds with a
+<code>GET_PURCHASE_INFORMATION</code> request. Google Play responds with a
 <code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the details of the purchase
 state change. Your application then sends a <code>CONFIRM_NOTIFICATIONS</code> message, informing
-Android Market that you have received the purchase state change information.</p>
+Google Play that you have received the purchase state change information.</p>
 
 <p>In some special cases, you may receive multiple <code>IN_APP_NOTIFY</code> messages even though
 you have confirmed receipt of the purchase information, or you may receive
@@ -358,13 +358,13 @@ purchase. Your application must handle both of these special cases.</p>
 
 <h4>Handling multiple IN_APP_NOTIFY messages</h4>
 
-<p>When Android Market receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given
+<p>When Google Play receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given
 <code>PURCHASE_STATE_CHANGED</code> message, it usually stops sending <code>IN_APP_NOTIFY</code>
-intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Android
-Market may send repeated <code>IN_APP_NOTIFY</code> intents for a
+intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Google
+Play may send repeated <code>IN_APP_NOTIFY</code> intents for a
 <code>PURCHASE_STATE_CHANGED</code> message even though your application has sent a
 <code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a device loses network connectivity
-while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Android Market
+while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Google Play
 might not receive your <code>CONFIRM_NOTIFICATIONS</code> message and it could send multiple
 <code>IN_APP_NOTIFY</code> messages until it receives acknowledgement that you received the
 transaction message. Therefore, your application must be able to recognize that the subsequent
@@ -390,7 +390,7 @@ IN_APP_NOTIFY messages.</p>
 
 <p>In the first case, your application may receive an <code>IN_APP_NOTIFY</code> broadcast intent
 when a user has your application installed on two (or more) devices and the user makes an in-app
-purchase from one of the devices. In this case, Android Market sends an <code>IN_APP_NOTIFY</code>
+purchase from one of the devices. In this case, Google Play sends an <code>IN_APP_NOTIFY</code>
 message to the second device, informing the application that there is a purchase state change. Your
 application can handle this message the same way it handles the response from an
 application-initiated <code>REQUEST_PURCHASE</code> message, so that ultimately your application
@@ -400,8 +400,8 @@ href="{@docRoot}guide/market/billing/billing_admin.html#billing-purchase-type">p
 to "managed per user account."</p>
 
 <p>In the second case, your application can receive an <code>IN_APP_NOTIFY</code> broadcast intent
-when Android Market receives a refund notification from Google Checkout. In this case, Android
-Market sends an <code>IN_APP_NOTIFY</code> message to your application. Your application can handle
+when Google Play receives a refund notification from Google Checkout. In this case, Google
+Play sends an <code>IN_APP_NOTIFY</code> message to your application. Your application can handle
 this message the same way it handles responses from an application-initiated
 <code>REQUEST_PURCHASE</code> message so that ultimately your application receives a
 <code>PURCHASE_STATE_CHANGED</code> message that includes information about the item that has been
@@ -417,13 +417,13 @@ information.</p>
 <h2 id="billing-security">Security Controls</h2>
 
 <p>To help ensure the integrity of the transaction information that is sent to your application,
-Android Market signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code>
-broadcast intent. Android Market uses the private key that is associated with your publisher account
+Google Play signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code>
+broadcast intent. Google Play uses the private key that is associated with your publisher account
 to create this signature. The publisher site generates an RSA key pair for each publisher account.
 You can find the public key portion of this key pair on your account's profile page. It is the same
-public key that is used with Android Market licensing.</p>
+public key that is used with Google Play licensing.</p>
 
-<p>When Android Market signs a billing response, it includes the signed JSON string (unencrypted)
+<p>When Google Play signs a billing response, it includes the signed JSON string (unencrypted)
 and the signature. When your application receives this signed response you can use the public key
 portion of your RSA key pair to verify the signature. By performing signature verification you can
 help detect responses that have been tampered with or that have been spoofed. You can perform this
@@ -431,9 +431,9 @@ signature verification step in your application; however, if your application co
 remote server then we recommend that you perform the signature verification on that server.</p>
 
 <p>In-app billing also uses nonces (a random number used once) to help verify the integrity of the
-purchase information that's returned from Android Market. Your application must generate a nonce and
+purchase information that's returned from Google Play. Your application must generate a nonce and
 send it with a <code>GET_PURCHASE_INFORMATION</code> request and a <code>RESTORE_TRANSACTIONS</code>
-request. When Android Market receives the request, it adds the nonce to the JSON string that
+request. When Google Play receives the request, it adds the nonce to the JSON string that
 contains the transaction information. The JSON string is then signed and returned to your
 application. When your application receives the JSON string, you need to verify the nonce as well as
 the signature of the JSON string.</p>
@@ -447,20 +447,20 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D
 limitations.</p>
 
 <ul>
-  <li>In-app billing can be implemented only in applications that you publish through Android
-  Market.</li>
-  <li>You must have a Google Checkout Merchant account to use Android Market In-app Billing.</li>
+  <li>In-app billing can be implemented only in applications that you publish through Google
+  Play.</li>
+  <li>You must have a Google Checkout Merchant account to use Google Play In-app Billing.</li>
   <li>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
   the MyApps application. If your device is running any other version of Android, in-app billing
-  requires version 2.3.4 (or higher) of the Android Market application.</li>
+  requires version 2.3.4 (or higher) of the Google Play application.</li>
   <li>An application can use in-app billing only if the device is running Android 1.6 (API level 4)
   or higher.</li>
   <li>You can use in-app billing to sell only digital content. You cannot use in-app billing to sell
   physical goods, personal services, or anything that requires physical delivery.</li>
-  <li>Android Market does not provide any form of content delivery. You are responsible for
+  <li>Google Play does not provide any form of content delivery. You are responsible for
   delivering the digital content that you sell in your applications.</li>
   <li>You cannot implement in-app billing on a device that never connects to the network. To
-  complete in-app purchase requests, a device must be able to access the Android Market server over
+  complete in-app purchase requests, a device must be able to access the Google Play server over
   the network. </li>
 </ul>
 
diff --git a/docs/html/guide/market/billing/billing_reference.jd b/docs/html/guide/market/billing/billing_reference.jd
index 5a7ba56..e8cf2ee 100755
--- a/docs/html/guide/market/billing/billing_reference.jd
+++ b/docs/html/guide/market/billing/billing_reference.jd
@@ -36,20 +36,20 @@ parent.link=index.html
 <p>The following document provides technical reference information for the following:</p>
 
 <ul>
-  <li><a href="#billing-codes">Android Market Server Response Codes for In-app Billing</a></li>
+  <li><a href="#billing-codes">Google Play Server Response Codes for In-app Billing</a></li>
   <li><a href="#billing-interface">In-app Billing Interface Parameters</a></li>
   <li><a href="#billing-intents">In-app Billing Broadcast Intents</a></li>
 </ul>
 
-<h2 id="billing-codes">Android Market Server Response Codes for In-app Billing</h2>
+<h2 id="billing-codes">Google Play Server Response Codes for In-app Billing</h2>
 
-<p>The following table lists all of the server response codes that are sent from Android Market to
-your application. Android Market sends these response codes asynchronously as
+<p>The following table lists all of the server response codes that are sent from Google Play to
+your application. Google Play sends these response codes asynchronously as
 <code>response_code</code> extras in the <code>com.android.vending.billing.RESPONSE_CODE</code>
 broadcast intent. Your application must handle all of these response codes.</p>
 
 <p class="table-caption" id="response-codes-table"><strong>Table 1.</strong> Summary of response
-codes returned by Android Market.</p>
+codes returned by Google Play.</p>
 
 <table>
 
@@ -80,13 +80,13 @@ codes returned by Android Market.</p>
   <td><code>RESULT_BILLING_UNAVAILABLE</code></td>
   <td>3</td>
   <td>Indicates that in-app billing is not available because the <code>API_VERSION</code> that you
-  specified is not recognized by the Android Market application or the user is ineligible for in-app
+  specified is not recognized by the Google Play application or the user is ineligible for in-app
   billing (for example, the user resides in a country that prohibits in-app purchases).</td>
 </tr>
 <tr>
   <td><code>RESULT_ITEM_UNAVAILABLE</code></td>
   <td>4</td>
-  <td>Indicates that Android Market cannot find the requested item in the application's product
+  <td>Indicates that Google Play cannot find the requested item in the application's product
   list. This can happen if the product ID is misspelled in your <code>REQUEST_PURCHASE</code>
   request or if an item is unpublished in the application's product list.</td>
 </tr>
@@ -108,7 +108,7 @@ purchase an item from yourself, which is not allowed by Google Checkout.</td>
 
 <h2 id="billing-interface">In-app Billing Service Interface</h2>
 
-<p>The following section describes the interface for Android Market's in-app billing service. The
+<p>The following section describes the interface for Google Play's in-app billing service. The
 interface is defined in the <code>IMarketBillingService.aidl</code> file, which is included with the
 in-app billing <a
 href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample
@@ -144,7 +144,7 @@ pairs, which are summarized in table 2.</p>
   <td><code>int</code></td>
   <td>1</td>
   <td>Yes</td>
-  <td>The version of Android Market's in-app billing service you are using. The current version is
+  <td>The version of Google Play's in-app billing service you are using. The current version is
   1.</td>
 </tr>
 <tr>
@@ -160,8 +160,8 @@ pairs, which are summarized in table 2.</p>
   <td>Any valid product identifier.</td>
   <td>Required for <code>REQUEST_PURCHASE</code> requests.</td>
   <td>The product ID of the item you are making a billing request for. Every in-app item that you
-  sell using Android Market's in-app billing service must have a unique product ID, which you
-  specify on the Android Market publisher site.</td>
+  sell using Google Play's in-app billing service must have a unique product ID, which you
+  specify on the Google Play publisher site.</td>
 </tr>
 <tr>
   <td><code>NONCE</code></td>
@@ -172,7 +172,7 @@ pairs, which are summarized in table 2.</p>
   <td>A number used once. Your application must generate and send a nonce with each
   <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is
   returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, so you can use this value
-  to verify the integrity of transaction responses form Android Market.</td>
+  to verify the integrity of transaction responses form Google Play.</td>
 </tr>
 <tr>
   <td><code>NOTIFY_IDS</code></td>
@@ -202,20 +202,20 @@ pairs, which are summarized in table 2.</p>
 
 <ul>
   <li><code>CHECK_BILLING_SUPPORTED</code>
-    <p>This request verifies that the Android Market application supports in-app billing. You
+    <p>This request verifies that the Google Play application supports in-app billing. You
     usually send this request when your application first starts up. This request is useful if you
     want to enable or disable certain UI features that are relevant only to in-app billing.</p>
   </li>
   <li><code>REQUEST_PURCHASE</code>
-    <p>This request sends a purchase message to the Android Market application and is the foundation
+    <p>This request sends a purchase message to the Google Play application and is the foundation
     of in-app billing. You send this request when a user indicates that he or she wants to purchase
-    an item in your application. Android Market then handles the financial transaction by displaying
+    an item in your application. Google Play then handles the financial transaction by displaying
     the checkout user interface.</p>
   </li>
   <li><code>GET_PURCHASE_INFORMATION</code>
     <p>This request retrieves the details of a purchase state change. A purchase state change can
     occur when a purchase request is billed successfully or when a user cancels a transaction during
-    checkout. It can also occur when a previous purchase is refunded. Android Market notifies your
+    checkout. It can also occur when a previous purchase is refunded. Google Play notifies your
     application when a purchase changes state, so you only need to send this request when there is
     transaction information to retrieve.</p>
   </li>
@@ -294,8 +294,8 @@ each in-app billing request type.</p>
 
 <h2 id="billing-intents">In-app Billing Broadcast Intents</h2>
 
-<p>The following section describes the in-app billing broadcast intents that are sent by the Android
-Market application. These broadcast intents inform your application about in-app billing actions
+<p>The following section describes the in-app billing broadcast intents that are sent by the Google
+Play application. These broadcast intents inform your application about in-app billing actions
 that have occurred. Your application must implement a {@link android.content.BroadcastReceiver} to
 receive these broadcast intents, such as the <code>BillingReceiver</code> that's shown in the in-app
 billing <a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample
@@ -303,21 +303,21 @@ application</a>.</p>
 
 <h4>com.android.vending.billing.RESPONSE_CODE</h4>
 
-<p>This broadcast intent contains an Android Market response code, and is sent after you make an
+<p>This broadcast intent contains a Google Play response code, and is sent after you make an
 in-app billing request. A server response code can indicate that a billing request was successfully
-sent to Android Market or it can indicate that some error occurred during a billing request. This
+sent to Google Play or it can indicate that some error occurred during a billing request. This
 intent is not used to report any purchase state changes (such as refund or purchase information).
 For more information about the response codes that are sent with this response, see <a
-href="#billing-codes">Android Market Response Codes for In-app Billing</a>. The sample application
+href="#billing-codes">Google Play Response Codes for In-app Billing</a>. The sample application
 assigns this broadcast intent to a constant named <code>ACTION_RESPONSE_CODE</code>.</p>
 
 <h5>Extras</h5>
 
 <ul type="none">
   <li><code>request_id</code>&mdash;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>&mdash;an <code>int</code> representing the Android Market server
+  <li><code>response_code</code>&mdash;an <code>int</code> representing the Google Play server
   response code.</li>
 </ul>
 
@@ -335,7 +335,7 @@ message details. The sample application assigns this broadcast intent to a const
 
 <ul type="none">
   <li><code>notification_id</code>&mdash;a <code>String</code> representing the notification ID for
-  a given purchase state change. Android Market notifies you when there is a purchase state change
+  a given purchase state change. Google Play notifies you when there is a purchase state change
   and the notification includes a unique notification ID. To get the details of the purchase state
   change, you send the notification ID with the <code>GET_PURCHASE_INFORMATION</code> request.</li>
 </ul>
@@ -375,15 +375,15 @@ a <code>PURCHASE_STATE_CHANGED</code> intent.</p>
 <tr>
   <td>nonce</td>
   <td>A number used once. Your application generates the nonce and sends it with the
-  <code>GET_PURCHASE_INFORMATION</code> request. Android Market sends the nonce back as part of the
+  <code>GET_PURCHASE_INFORMATION</code> request. Google Play sends the nonce back as part of the
   JSON string so you can verify the integrity of the message.</td>
 </tr>
 <tr>
   <td>notificationId</td>
   <td>A unique identifier that is sent with an <code>IN_APP_NOTIFY</code> broadcast intent. Each
   <code>notificationId</code> corresponds to a specify message that is waiting to be retrieved on
-  the Android Market server. Your application sends back the <code>notificationId</code> with the
-  <code>GET_PURCHASE_INFORMATION</code> message so Android Market can determine which messages you
+  the Google Play server. Your application sends back the <code>notificationId</code> with the
+  <code>GET_PURCHASE_INFORMATION</code> message so Google Play can determine which messages you
   are retrieving.</td>
 </tr>
 <tr>
@@ -398,7 +398,7 @@ a <code>PURCHASE_STATE_CHANGED</code> intent.</p>
 <tr>
   <td>productId</td>
   <td>The item's product identifier. Every item has a product ID, which you must specify in the
-  application's product list on the Android Market publisher site.</td>
+  application's product list on the Google Play publisher site.</td>
 </tr>
 <tr>
   <td>purchaseTime</td>
diff --git a/docs/html/guide/market/billing/billing_testing.jd b/docs/html/guide/market/billing/billing_testing.jd
index 5453047..77aa3ed 100755
--- a/docs/html/guide/market/billing/billing_testing.jd
+++ b/docs/html/guide/market/billing/billing_testing.jd
@@ -32,16 +32,16 @@ parent.link=index.html
 </div>
 </div>
 
-<p>The Android Market publisher site provides several tools that help you test your in-app billing
+<p>The Google Play publisher site provides several tools that help you test your in-app billing
 implementation before it is published. You can use these tools to create test accounts and purchase
 special reserved items that send static billing responses to your application.</p>
 
 <p>To test in-app billing in an application you must install the application on an Android-powered
 device. You cannot use the Android emulator to test in-app billing.  The device you use for testing
 must run a standard version of the Android 1.6 or later platform (API level 4 or higher), and have
-the most current version of the Android Market application installed. If a device is not running the
-most current Android Market application, your application won't be able to send in-app billing
-requests to Android Market. For general information about how to set up a device for use in
+the most current version of the Google Play application installed. If a device is not running the
+most current Google Play application, your application won't be able to send in-app billing
+requests to Google Play. For general information about how to set up a device for use in
 developing Android applications, see <a href="{@docRoot}guide/developing/device.html">Using Hardware
 Devices</a>.</p>
 
@@ -50,12 +50,12 @@ Devices</a>.</p>
 <h2 id="billing-testing-static">Testing in-app purchases with static responses</h2>
 
 <p>We recommend that you first test your in-app billing implementation using static responses from
-Android Market. This enables you to verify that your application is handling the primary Android
-Market responses correctly and that your application is able to verify signatures correctly.</p>
+Google Play. This enables you to verify that your application is handling the primary Google
+Play responses correctly and that your application is able to verify signatures correctly.</p>
 
 <p>To test your implementation with static responses, you make an in-app billing request using a
 special item that has a reserved product ID. Each reserved product ID returns a specific static
-response from Android Market. No money is transferred when you make in-app billing requests with the
+response from Google Play. No money is transferred when you make in-app billing requests with the
 reserved product IDs. Also, you cannot specify the form of payment when you make a billing request
 with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the
 product ID android.test.purchased.</p>
@@ -65,7 +65,7 @@ product ID android.test.purchased.</p>
   <strong>Figure 1.</strong> Checkout flow for the special reserved item android.test.purchased.
 </p>
 
-<p>You do not need to list the reserved products in your application's product list. Android Market
+<p>You do not need to list the reserved products in your application's product list. Google Play
 already knows about the reserved product IDs. Also, you do not need to upload your application to
 the publisher site to perform static response tests with the reserved product IDs. You can simply
 install your application on a device, log into the device, and make billing requests using the
@@ -75,24 +75,24 @@ reserved product IDs.</p>
 
 <ul>
   <li><strong>android.test.purchased</strong>
-    <p>When you make an in-app billing request with this product ID, Android Market responds as
+    <p>When you make an in-app billing request with this product ID, Google Play responds as
     though you successfully purchased an item. The response includes a JSON string, which contains
     fake purchase information (for example, a fake order ID). In some cases, the JSON string is
     signed and the response includes the signature so you can test your signature verification
     implementation using these responses.</p>
   </li>
   <li><strong>android.test.canceled</strong>
-    <p>When you make an in-app billing request with this product ID Android Market responds as
+    <p>When you make an in-app billing request with this product ID Google Play responds as
     though the purchase was canceled. This can occur when an error is encountered in the order
     process, such as an invalid credit card, or when you cancel a user's order before it is
     charged.</p>
   </li>
   <li><strong>android.test.refunded</strong>
-    <p>When you make an in-app billing request with this product ID, Android Market responds as
-    though the purchase was refunded. Refunds cannot be initiated through Android Market's in-app
+    <p>When you make an in-app billing request with this product ID, Google Play responds as
+    though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app
     billing service. Refunds must be initiated by you (the merchant). After you process a refund
     request through your Google Checkout account, a refund message is sent to your application by
-    Android Market. This occurs only when Android Market gets notification from Google Checkout that
+    Google Play. This occurs only when Google Play gets notification from Google Checkout that
     a refund has been made. For more information about refunds, see <a
     href="{@docRoot}guide/market/billing/billing_overview.html#billing-action-notify">Handling
     IN_APP_NOTIFY messages</a> and <a
@@ -100,7 +100,7 @@ reserved product IDs.</p>
     Pricing</a>.</p>
   </li>
   <li><strong>android.test.item_unavailable</strong>
-    <p>When you make an in-app billing request with this product ID, Android Market responds as
+    <p>When you make an in-app billing request with this product ID, Google Play responds as
     though the item being purchased was not listed in your application's product list.</p>
   </li>
 </ul>
@@ -185,20 +185,20 @@ application's product list you use one of the reserved product IDs.</p>
     <p>You do not need to use a test account if you are testing only with the reserved product
     IDs.</p>
   </li>
-  <li><strong>Verify that your device is running a supported version of the Android Market
+  <li><strong>Verify that your device is running a supported version of the Google Play
   application or the MyApps application.</strong>
     <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, in-app billing
-    requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the
-    version of the Android Market application, see <a
-    href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android
-    Market</a>.</p>
+    requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+    version of the Google Play application, see <a
+    href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
+    Play</a>.</p>
   </li>
   <li><strong>Run your application and purchase the reserved product IDs.</strong></li>
 </ol>
 
 <p class="note"><strong>Note</strong>: Making in-app billing requests with the reserved product IDs
-overrides the usual Android Market production system. When you send an in-app billing request for a
+overrides the usual Google Play production system. When you send an in-app billing request for a
 reserved product ID, the quality of service will not be comparable to the production
 environment.</p>
 
@@ -207,7 +207,7 @@ environment.</p>
 <p>After you finish your static response testing, and you verify that signature verification is
 working in your application, you can test your in-app billing implementation by making actual in-app
 purchases. Testing real in-app purchases enables you to test the end-to-end in-app billing
-experience, including the actual responses from Android Market and the actual checkout flow that
+experience, including the actual responses from Google Play and the actual checkout flow that
 users will experience in your application.</p>
 
 <p class="note"><strong>Note</strong>: You do not need to publish your application to do end-to-end
@@ -215,7 +215,7 @@ testing. You only need to upload your application as a draft application to perf
 testing.</p>
 
 <p>To test your in-app billing implementation with actual in-app purchases, you will need to
-register at least one test account on the Android Market publisher site. You cannot use your
+register at least one test account on the Google Play publisher site. You cannot use your
 developer account to test the complete in-app purchase process because Google Checkout does not let
 you buy items from yourself. If you have not set up test accounts before, see <a
 href="{@docRoot}guide/market/billing/billing_admin.html#billing-testing-setup">Setting up test
@@ -237,7 +237,7 @@ actual payouts to your merchant account.</p>
     IDs; you only need to upload your application as a draft application. However, you must sign
     your application with your release key before you upload it as a draft application. Also, the
     version number of the uploaded application must match the version number of the application you
-    load to your device for testing. To learn how to upload an application to Android Market, see
+    load to your device for testing. To learn how to upload an application to Google Play, see
     <a href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading
     applications</a>.</p>
   </li>
@@ -257,7 +257,7 @@ actual payouts to your merchant account.</p>
     <p>To perform end-to-end testing of in-app billing, the primary account on your device must be
     one of the <a
     href="{@docRoot}guide/market/billing/billing_admin.html#billing-testing-setup">test accounts</a>
-    that you registered on the Android Market site. If the primary account on your device is not a
+    that you registered on the Google Play site. If the primary account on your device is not a
     test account, you must do a factory reset of the device and then sign in with one of your test
     accounts. To perform a factory reset, do the following:</p>
     <ol>
@@ -269,14 +269,14 @@ actual payouts to your merchant account.</p>
       device setup process.</li>
     </ol>
   </li>
-  <li><strong>Verify that your device is running a supported version of the Android Market
+  <li><strong>Verify that your device is running a supported version of the Google Play
   application or the MyApps application.</strong>
     <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, in-app billing
-    requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the
-    version of the Android Market application, see <a
-    href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Android
-    Market</a>.</p>
+    requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+    version of the Google Play application, see <a
+    href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
+    Play</a>.</p>
   </li>
   <li><strong>Make in-app purchases in your application.</strong></li>
 </ol>
@@ -285,7 +285,7 @@ actual payouts to your merchant account.</p>
 do a factory reset, making sure you log on with your primary account first.</p>
 
 <p>When you are finished testing your in-app billing implementation, you are ready to
-publish your application on Android Market. You can follow the normal steps for <a
+publish your application on Google Play. You can follow the normal steps for <a
 href="{@docRoot}guide/publishing/preparing.html">preparing</a>, <a
 href="{@docRoot}guide/publishing/app-signing.html">signing</a>, and <a
 href="{@docRoot}guide/publishing/publishing.html">publishing your application</a>.
diff --git a/docs/html/guide/market/billing/index.jd b/docs/html/guide/market/billing/index.jd
index fdfa6fa..036761f 100755
--- a/docs/html/guide/market/billing/index.jd
+++ b/docs/html/guide/market/billing/index.jd
@@ -30,18 +30,18 @@ page.title=In-app Billing
 </div>
 </div>
 
-<p>Android Market In-app Billing is an Android Market service that lets you sell digital content in
+<p>Google Play In-app Billing is a Google Play service that lets you sell digital content in
 your applications. You can use the service to sell a wide range of content, including downloadable
 content such as media files or photos, and virtual content such as game levels or potions.</p>
 
-<p>When you use Android Market's in-app billing service to sell an item, Android Market handles all
+<p>When you use Google Play's in-app billing service to sell an item, Google Play handles all
 checkout details so your application never has to directly process any financial transactions.
-Android Market uses the same checkout service that is used for application purchases, so your users
+Google Play uses the same checkout service that is used for application purchases, so your users
 experience a consistent and familiar purchase flow (see figure 1). Also, the transaction fee for
 in-app purchases is the same as the transaction fee for application purchases (30%).</p>
 
-<p>Any application that you publish through Android Market can implement in-app billing. No special
-account or registration is required other than an Android Market publisher account and a Google
+<p>Any application that you publish through Google Play can implement in-app billing. No special
+account or registration is required other than a Google Play app publisher account and a Google
 Checkout Merchant account. Also, because the service uses no dedicated framework APIs, you can add
 in-app billing to any application that uses a minimum API level of 4 or higher.</p>
 
@@ -59,11 +59,11 @@ obfuscate the sample code before you use it in a production application. For mor
 <img src="{@docRoot}images/billing_checkout_flow.png" height="382" id="figure1" />
 <p class="img-caption">
   <strong>Figure 1.</strong> Applications initiate in-app billing requests through their own UI
-  (first screen). Android Market responds to the request by providing the checkout user interface
+  (first screen). Google Play responds to the request by providing the checkout user interface
   (middle screen). When checkout is complete, the application resumes.
 </p>
 
-<p>To learn more about Android Market's in-app billing service and start integrating it into your
+<p>To learn more about Google Play's in-app billing service and start integrating it into your
 applications, read the following documents:</p>
 
 <dl>
@@ -88,7 +88,7 @@ applications, read the following documents:</p>
     <dd>Learn how to set up your product list, register test accounts, and handle refunds.</dd>
   <dt><strong><a href="{@docRoot}guide/market/billing/billing_reference.html">In-app Billing
   Reference</a></strong></dt>
-    <dd>Get detailed information about Android Market response codes and the in-app billing
+    <dd>Get detailed information about Google Play response codes and the in-app billing
     interface.</dd>
 </dl>
 
diff --git a/docs/html/guide/market/expansion-files.jd b/docs/html/guide/market/expansion-files.jd
index fad30e9..26e63ec 100644
--- a/docs/html/guide/market/expansion-files.jd
+++ b/docs/html/guide/market/expansion-files.jd
@@ -8,7 +8,7 @@ page.title=APK Expansion Files
 <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 @@ APK Support</a></li>
 
 
 
-<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 @@ release or as necessary.</p>
 <p>However, even if your application update requires only a new patch expansion file, you still must
 upload a new APK with an updated <a
 href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code
-versionCode}</a> in the manifest. (The 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 @@ yourself or be able to distinguish between the two files.</p>
 <h3 id="Filename">File name format</h3>
 
 <p>Each expansion file you upload can be any format you choose (ZIP, PDF, MP4, etc.). Regardless of
-the file type, 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 @@ only one main file and one patch file for each APK.</dd>
 <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&mdash;it
 retains the version applied to it when you first uploaded the file.</p></dd>
   <dt>{@code &lt;package-name&gt;}</dt> 
@@ -147,9 +147,9 @@ upload a main expansion file, the file is renamed to:</p>
 
 <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 @@ compressed: <br/>
 
 <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 @@ download the files and save them to the proper <a href="#StorageLocation">storag
 </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 @@ your expansion files, then read them using the <a href="#ZipLib">APK Expansion Z
 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 @@ Your Expansion Files</a>.</p>
 <h2 id="Rules">Rules and Limitations</h2>
 
 <p>Adding APK expansion files is a feature available when you upload your application using the
-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 @@ versionName}</a>).</p></li>
 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 @@ download the expansion file.</li>
 
 <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 @@ href="#StorageLocation">shared storage location</a> (in the
       <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/&lt;package-name&gt;/</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 @@ your application.</p>
 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&mdash;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 @@ Library. For each library:
 source</strong> and choose the library from the {@code &lt;sdk&gt;/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 @@ android update project --path ~/Android/MyApp \
 
 <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 @@ are:</p>
 
 <pre>
 &lt;manifest ...>
-    &lt;!-- Required to access Android Market Licensing -->
+    &lt;!-- Required to access Google Play Licensing -->
     &lt;uses-permission android:name="com.android.vending.CHECK_LICENSE" />
 
-    &lt;!-- Required to download files from Android Market -->
+    &lt;!-- Required to download files from Google Play -->
     &lt;uses-permission android:name="android.permission.INTERNET" />
 
     &lt;!-- Required to keep CPU alive while downloading files (NOT to keep screen awake) -->
@@ -570,7 +570,7 @@ DownloaderService} class and override three methods to provide specific applicat
 <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 @@ restarted (which might happen if the downloader service unexpectedly stops).</dd
 <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 @@ public class SampleDownloaderService extends DownloaderService {
 </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 @@ mRemoteService.setDownloadFlags(IDownloaderService.FLAGS_DOWNLOAD_OVER_CELLULAR)
 
 <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 @@ expansion files and downloading the files.</p>
 
 <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 @@ The version code can be whatever value you want. Just remember:</p>
     <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 @@ test your expansion file(s).</li>
 <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 @@ opens, it's important that you test this process to be sure your application can
 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 @@ files as soon as the main activity starts.</p>
 
 <h2 id="Updating">Updating Your Application</h2>
 
-<p>One of the great benefits to using expansion files on 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 @@ your
 patch file with the main expansion file.</p>
 
 <p class="note"><strong>Note:</strong> Even if you only need to make changes to the patch
-expansion file, you must still update the APK in order for 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 @@ expansion file (retaining the previous main expansion file).</p>
 
 <ul>
   <li>There can be only two expansion files for your application at a time. One main expansion
-file and one patch expansion file. During an update to a file, 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 @@ and Interfaces</a>.</p>
 
 <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 @@ android:name="com.android.vending.CHECK_LICENSE"&gt;</code></p>
 <pre>&lt;?xml version="1.0" encoding="utf-8"?&gt;
 
 &lt;manifest xmlns:android="http://schemas.android.com/apk/res/android" ..."&gt;
-    &lt;!-- Devices &gt;= 3 have version of Android Market that supports licensing. --&gt;
+    &lt;!-- Devices &gt;= 3 have version of Google Play that supports licensing. --&gt;
     &lt;uses-sdk android:minSdkVersion="3" /&gt;
     &lt;!-- Required permission to check licensing. --&gt;
     &lt;uses-permission android:name="com.android.vending.CHECK_LICENSE" /&gt;
@@ -123,7 +123,7 @@ application's manifest. </p>
 <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 @@ href="#ServerManagedPolicy">ServerManagedPolicy</a> section, below.</p>
 </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 @@ extra is highly recommended. See <a
 href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server Response Extras</a>
 for more information.</li>
 <li>Uses an exponential backoff period, if retrying any requests the result in
-errors. Note that the 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 @@ responses.</p>
 <p>Importantly, a key feature of ServerMangedPolicy is its use of
 server-provided settings as the basis for managing licensing across an
 application's refund period and through varying network and error conditions.
-When an application contacts the Android Market server for a license check, the
+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 @@ href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server R
 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 @@ the device IMEI or related data, the application will also need to request the
 
 <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>&lt;uses-feature&gt;</code>).</p>
 
@@ -647,11 +647,11 @@ have determined the exact behaviors you want, you can add more complex handling.
 <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 @@ private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
             // 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 @@ method should log the error code and call <code>dontAllow()</code>.</p>
 <h3 id="thread-handler">Create a Handler for posting from LicenseCheckerCallback
 to the UI thread</h3>
 
-<p>During a license check, the LVL passes the request to the 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 @@ sample application calls <code>checkAccess()</code> from a
 
 <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 @@ public key for licensing and copy it into your application. Here's how to find
 your account's public key for licensing:</p>
 
 <ol>
-<li>Go to the Android Market <a
-href="http://market.android.com/publish">publisher site</a> and sign in.
+<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 @@ to close IPC connections</h3>
 {@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 @@ and then recompile it.</p>
 <p>Several obfuscator programs are available for Android applications, including
 <a href="http://proguard.sourceforge.net/">ProGuard</a>, which also offers
 code-optimization features. The use of ProGuard or a similar program to obfuscate
-your code is <em>strongly recommended</em> for all applications that use Android
-Market Licensing. </p>
+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 @@ table below. By directing your queries to the correct forum, you can get the
 support you need more quickly. </p>
 
 <p class="table-caption"><strong>Table 2.</strong> Developer support resources
-for Android Market Licensing Service.</p>
+for Google Play Licensing Service.</p>
 
 <table>
 
@@ -1045,8 +1045,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co
 </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 @@ page.title=Application Licensing
 @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 @@ that allow the user to run it unlicensed for a specific validity period. An appl
 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 @@ Overview</a></strong></dt>
 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 @@ managed by an Obfuscator.</td>
 <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 @@ codes. By default, the LicenseValidator class in the LVL provides all of the
 necessary handling of these response codes for you. </p>
 
 <p class="table-caption"><strong>Table 2.</strong> Summary of response codes
-returned by the Android Market server in a license response.</p>
+returned by the Google Play server in a license response.</p>
 
 <table>
 
@@ -178,7 +178,7 @@ until upgrade.</p>
 </tr>
 <tr>
 <td>{@code ERROR_CONTACTING_SERVER}</td>
-<td>Local error &mdash; the Android Market application was not able to reach the
+<td>Local error &mdash; 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 @@ application. </td>
 <tr>
 <td>{@code ERROR_NOT_MARKET_MANAGED}</td>
 <td>Server error &mdash; 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 @@ implementation.</p>
 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 @@ implementation and an illustration of how to obtain, store, and use the
 settings. </p>
 
 <p class="table-caption"><strong>Table 3.</strong> Summary of
-license-management settings supplied by the 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 @@ storage location before downloading.</td>
 
 <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 @@ status instead of sending a new license check to the server.</p>
 
 <p>The licensing server manages the validity period as a means of helping the
 application properly enforce licensing across the refund period offered by
-Android Market for paid applications. It sets the validity period based on
+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 @@ the application. </p>
 
 <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&mdash;such as when on an airplane&mdash;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 @@ Policy <code>processServerResonse()</code> method with a {@code RETRY} response
 <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 @@ parent.link=index.html
   
   <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 @@ parent.link=index.html
 </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 @@ implementation.</p>
 <div class="figure" style="width:469px">
 <img src="{@docRoot}images/licensing_arch.png" alt=""/>
 <p class="img-caption"><strong>Figure 1.</strong> Your application initiates a
-license check through the License Verification Library and the 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&mdash;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&mdash;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 @@ network connections or use any licensing related APIs in the Android platform.</
 <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 @@ tampered with or that are spoofed.</p>
 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 @@ physical device.</p>
 
 <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 @@ handling of the license are factors are up to you. By following the best
 practices in the following documents, you can help ensure that your implementation will be
 secure.</li>
 <li>Adding licensing to an application does not affect the way the application
-functions when run on a device that does not offer 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 @@ href="{@docRoot}guide/market/expansion-files.html">APK expansion files</a>.</li>
 
 <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 @@ environment</a></li>
 </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 @@ publishing the application</li>
 <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 @@ checking and enforcement. </p>
 
 <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 @@ debugging and testing licensing, the device must:</p>
 <ul>
 <li>Run a compatible version of Android 1.5 or later (API level
 3 or higher) platform, <em>and</em> </li>
-<li>Run a system image on which the 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 @@ href="{@docRoot}guide/developing/device.html">Using Hardware Devices</a>.</p>
 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 @@ href="#acct-signin">Signing in to an authorized account</a>, below.</p></li>
 </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 @@ classes to check and enforce licensing.</li>
 
 <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 @@ system, add and track the sources that are in the working location rather
 than those in default location in the SDK. </p>
 
 <p>Moving the library sources is important is because, when you later update the
-Market licensing package, the SDK installs the new files to the same location as
+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 @@ Setting up a Library Project</a>.</p>
 
 <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 @@ signed in to the publisher account or a test account.</li>
 <li>An optional set of test accounts that will receive the static test
 response when they check the license of an application that you have uploaded
 (regardless whether the application is published or not).</li>
-<li>A runtime environment for the application that includes the Android Market
+<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 @@ publisher account or one of the test accounts.</li>
 
 <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 @@ test responses available and their meanings. </p>
 <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> &mdash; accounts that are
 authorized to query the licensing server and receive static test responses from
 your publisher account.</p>
@@ -632,11 +632,11 @@ directly. </p>
 environment</h3>
 
 <p>The licensing service is designed to determine whether a given user is
-licensed to use a given application &mdash; 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 &mdash; 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 @@ support all desired devices with a single APK</li>
 
   <h2>See also</h2>
 <ol>
-  <li><a href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a></li>
+  <li><a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a></li>
   <li><a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li>
   <li><a href="{@docRoot}sdk/compatibility-library.html">Compatibility
 Package</a></li>
@@ -55,10 +55,10 @@ Package</a></li>
 </div>
 </div>
 
-<p>Multiple APK support is a feature in Android Market that allows you to publish different APKs
+<p>Multiple APK support is a feature on Google Play that allows you to publish different APKs
 for your application that are each targeted to different device configurations. Each APK is a
 complete and independent version of your application, but they share the same application listing on
-Android Market and must share the same package name and be signed with the same release key. This
+Google Play and must share the same package name and be signed with the same release key. This
 feature is useful for cases in which your application cannot reach all desired devices with a single
 APK.</p>
 
@@ -73,8 +73,8 @@ prevent a single APK from working on all devices.</p>
 
 <p>Although <strong>we encourage you to develop and publish a single APK</strong> that supports as
 many device configurations as possible, doing so is sometimes not possible. To help
-you publish your application for as many devices as possible, Android Market allows you to
-publish multiple APKs under the same application listing. Android Market then supplies each APK to
+you publish your application for as many devices as possible, Google Play allows you to
+publish multiple APKs under the same application listing. Google Play then supplies each APK to
 the appropriate devices based on configuration support you've declared in the manifest file of each
 APK.</p>
 
@@ -86,7 +86,7 @@ APK.</p>
   <li>Support different platform versions with each APK.</li>
 </ul>
 
-<p>Currently, these are the only device characteristics that Android Market supports for publishing
+<p>Currently, these are the only device characteristics that Google Play supports for publishing
 multiple APKs as the same application.</p>
 
 <p class="note"><strong>Note:</strong> You should generally use multiple APKs to support
@@ -100,8 +100,8 @@ consider your options before publishing multiple APKs.</p>
 
 <h2 id="Concepts">Publishing Concepts</h2>
 
-<p>Before you start publishing multiple APKs on Android Market, you must understand a few
-concepts regarding how the Android Market publisher site works.</p>
+<p>Before you start publishing multiple APKs on Google Play, you must understand a few
+concepts regarding how the Google Play publisher site works.</p>
 
 <h3 id="Active">Active APKs</h3>
 
@@ -111,20 +111,20 @@ concepts regarding how the Android Market publisher site works.</p>
   <p>When editing your application, there are two buttons on the top-right side of the page. The
 first button is either <strong>Publish</strong> or <strong>Unpublish</strong> and the second
 button is always <strong>Save</strong> (but its behavior changes).</p>
-  <p>When your application is new or you have unpublished it from Market, the first
+  <p>When your application is new or you have unpublished it from Google Play, the first
 button says <strong>Publish</strong>. Clicking it will publish any APKs listed as
-Active, making them available on Android Market. Also while your application is new
+Active, making them available on Google Play. Also while your application is new
 or unpublished, clicking <strong>Save</strong> will save any changes you've made, such
 as information added to the Product details and APKs you've uploaded, but nothing is made visible on
-Android Market&mdash;this allows you to save your changes and sign out of the publisher site before
+Google Play&mdash;this allows you to save your changes and sign out of the publisher site before
 deciding to publish.</p>
  <p>Once you've published your application, the first button changes to
 <strong>Unpublish</strong>. Clicking it in this state unpublishes your application so that none
-of the APKs are available on Android Market. Also while published, the behavior of the
+of the APKs are available on Google Play. Also while published, the behavior of the
 <strong>Save</strong> button is different. In this state, clicking <strong>Save</strong> not
-only saves all your changes, but also publishes them to Android Market. For example, if you've
+only saves all your changes, but also publishes them to Google Play. For example, if you've
 already published your application and then make changes to your product details or activate new
-APKs, clicking <strong>Save</strong> makes all those changes live on Android Market.</p>
+APKs, clicking <strong>Save</strong> makes all those changes live on Google Play.</p>
 </div>
 </div>
 
@@ -135,14 +135,14 @@ moves into the list of <em>Active</em> APKs. This list allows you to preview whi
 you're about to publish.</p>
 
 <p>If there are no errors, any "active" APK will be published to
-Android Market when you click the <strong>Publish</strong> button (if the application is
+Google Play when you click the <strong>Publish</strong> button (if the application is
 unpublished) or when you click the <strong>Save</strong> button (if the application is
 already published).</p>
 
 
 <h3 id="SimpleAndAdvanced">Simple mode and advanced mode</h3>
 
-<p>The Android Market publisher site provides two modes for managing the APKs associated with
+<p>The Google Play publisher site provides two modes for managing the APKs associated with
 your application: <em>simple mode</em> and <em>advanced mode</em>. You can switch between these by
 clicking the
 link at the top-right corner of the <strong>APK files</strong> tab.</p>
@@ -164,21 +164,21 @@ below.</p>
 
 <h2 id="HowItWorks">How Multiple APKs Work</h2>
 
-<p>The concept for using multiple APKs on Android Market is that you have just one entry in
-Android Market for your application, but different devices might download a different APK. This
+<p>The concept for using multiple APKs on Google Play is that you have just one entry in
+Google Play for your application, but different devices might download a different APK. This
 means that:</p>
 
 <ul>
   <li>You maintain only one set of product details (app description, icons, screenshots, etc.).
 This also means you <em>cannot</em> charge a different price for different APKs.</li>
-  <li>All users see only one version of your application on Android Market, so they are not
+  <li>All users see only one version of your application on Google Play, so they are not
 confused by different versions you may have published that are "for tablets" or
 "for phones."</li>
   <li>All user reviews are applied to the same application listing, even though users on different
 devices may have different APKs.</li>
   <li>If you publish different APKs for different versions of Android (for different API levels),
 then when a user's device receives a system update that qualifies them for a different APK you've
-published, Android Market updates the user's application to the APK designed for the higher version
+published, Google Play updates the user's application to the APK designed for the higher version
 of Android. Any system data associated with the application is retained (the same as with normal
 application updates when using a single APK).</li>
 </ul>
@@ -192,8 +192,8 @@ following sections describe more about how it works.</p>
 <h3 id="SupportedFilters">Supported filters</h3>
 
 <p>Which devices receive each APK is determined by <a
-href="{@docRoot}guide/appendix/market-filters.html">Android Market filters</a> that are specified by
-elements in the manifest file of each APK. However, Android Market allows you to publish multiple
+href="{@docRoot}guide/appendix/market-filters.html">Google Play filters</a> that are specified by
+elements in the manifest file of each APK. However, Google Play allows you to publish multiple
 APKs only when each APK uses filters to support a variation of the following
 device characteristics:</p>
 
@@ -229,7 +229,7 @@ with a single APK.</p>
 href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
 &lt;supports-screens&gt;}</a> element are "true" if you do not declare them otherwise. However,
 because the {@code android:xlargeScreens} attribute was added in Android 2.3 (API level
-9), Android Market will assume that it is "false" if your application does not set either <a
+9), Google Play will assume that it is "false" if your application does not set either <a
 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code
 android:minSdkVersion}</a> or <a
 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code
@@ -266,7 +266,7 @@ with a higher <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min
 android:minSdkVersion}</a> value must have a higher <a
 href="{@docRoot}guide/topics/manifest/manifest-element.html#vcode">{@code android:versionCode}</a>
 value. This is also true if two APKs overlap their device support based on a different supported
-filter. This ensures that when a device receives a system update, Android Market can offer the user
+filter. This ensures that when a device receives a system update, Google Play can offer the user
 an update for your application (because updates are based on an increase in the app version code).
 This requirement is described further in the section below about <a href="#Rules">Rules for
 multiple APKs</a>.</li>
@@ -286,8 +286,8 @@ higher, as per the previous note).</li>
 </ul>
 
 <p>Other manifest elements that enable <a
-href="{@docRoot}guide/appendix/market-filters.html">Android Market filters</a>&mdash;but are not
-listed above&mdash;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>&mdash;but are not
+listed above&mdash;are still applied for each APK as usual. However, Google Play does not allow
 you to publish multiple APKs based on variations of them. Thus, you cannot publish
 multiple APKs if the above listed filters are the same for each APK (but the APKs differ based on
 other characteristics in the manifest file). For
@@ -312,7 +312,7 @@ android:versionCode}</a> attribute.</li>
 
   <li>Each APK <strong>must not exactly match the configuration support of another APK</strong>.
     <p>That is, each APK must declare slightly different support for at least one of
-the <a href="#MarketFiltersSupported">supported Market filters</a> (listed above).</p>
+the <a href="#SupportedFilters">supported Google Play filters</a> (listed above).</p>
     <p>Usually, you will differentiate your APKs based on a specific characteristic (such as the
 supported texture compression formats), and thus, each APK will declare support for different
 devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two
@@ -330,11 +330,11 @@ application.</li>
   <li>An APK that requires a <strong>higher API level</strong> must have a <strong>higher
 version code</strong>.
     <p>This is true only when either: the APKs differ based <em>only</em> on the
-supported API levels (no other <a href="#SupportedMarketFilters">supported market filters</a>
+supported API levels (no other <a href="#SupportedFilters">supported filters</a>
 distinguish the APKs from each other) <em>or</em> when the APKs do use another supported filter, but
 there is an overlap between the APKs within that filter.</p>
     <p>This is important because a user's device receives an application update from
-Android Market only if the version code for the APK on Android Market is higher than the version
+Google Play only if the version code for the APK on Google Play is higher than the version
 code of the APK currently on the device. This ensures that if a device receives a system update that
 then qualifies it to install the APK for higher API levels, the device receives an application
 update because the version code increases.</p>
@@ -365,7 +365,7 @@ increase from the lower API level to the higher API level.</li>
 
 </ul>
 
-<p>Failure to abide by the above rules results in an error on the Android Market publisher site
+<p>Failure to abide by the above rules results in an error on the Google Play publisher site
 when you activate your APKs&mdash;you will be unable to publish your application until you
 resolve the error.</p>
 
@@ -377,7 +377,7 @@ in warnings rather than errors. Warnings can be caused by the following:</p>
 APKs support the devices that then fall outside the supported range. For example, if an APK
 currently supports small and normal size screens and you change it to support only small screens,
 then you have shrunk the pool of supported devices and some devices will no longer see your
-application in Android Market. You can resolve this by adding another APK that supports normal size
+application on Google Play. You can resolve this by adding another APK that supports normal size
 screens so that all previously-supported devices are still supported.</li>
 
   <li>When there are "overlaps" between two or more APKs. For example, if an APK supports screen
@@ -467,8 +467,8 @@ user visible version assigned to <a
 href="{@docRoot}guide/topics/manifest/manifest-element.html#vname">{@code android:versionName}</a>),
 so that it's easy for you to associate the version code and version name.</p>
 
-<p class="note"><strong>Note:</strong> When you increase the version code for an APK, Android
-Market will prompt users of the previous version to update the application. Thus, to avoid
+<p class="note"><strong>Note:</strong> When you increase the version code for an APK, Google
+Play will prompt users of the previous version to update the application. Thus, to avoid
 unnecessary updates, you should not increase the version code for APKs that do not actually
 include changes.</p>
 
@@ -507,7 +507,7 @@ configuration support for one or several of the APKs.</p>
 <h2 id="SingleAPK">Using a Single APK Instead</h2>
 
 <p><strong>Creating multiple APKs for your application is not the normal procedure</strong> for
-publishing an application on Android Market. In most cases, you should be able to publish your
+publishing an application on Google Play. In most cases, you should be able to publish your
 application to most users with a single APK and we encourage that you do so. When you encounter
 a situation in which using a single APK becomes difficult, you should carefully consider all your
 options before deciding to publish multiple APKs.</p>
@@ -542,7 +542,7 @@ setup, the user receives your application and it runs using the resources optimi
 For example, on a new tablet, the user receives your application and it runs with your
 tablet-optimized resources. This restore
 process does not work across different APKs, because each APK can potentially have different
-permissions that the user has not agreed to, so Android Market may not restore the application at
+permissions that the user has not agreed to, so Google Play may not restore the application at
 all. (If you use multiple APKs, the user receives either the exact same APK if it's compatible or
 nothing at all and must manually download your application to get the APK designed for the new
 device.)</p></li>
@@ -586,7 +586,7 @@ public void onSurfaceChanged(GL10 gl, int w, int h) {
 
 <h3 id="ScreenOptions">Supporting multiple screens</h3>
 
-<p>Unless your APK file exceeds the Android Market size limit of 50MB, supporting multiple screens
+<p>Unless your APK file exceeds the Google Play size limit of 50MB, supporting multiple screens
 should always be done with a single APK. Since Android 1.6, the Android system manages most of the
 work required for your application to run successfully on a variety of screen sizes and
 densities.</p>