From 4d7bc65538c7cd9fbb1fbbcf22d1da47fcee1219 Mon Sep 17 00:00:00 2001 From: Dirk Dougherty Date: Fri, 27 Jan 2012 17:56:49 -0800 Subject: Doc change: String changes for Android Market Change-Id: I823812a4fd24021bec906ad856479c92a8d2a759 --- docs/html/guide/appendix/install-location.jd | 6 +- docs/html/guide/appendix/market-filters.jd | 148 ++++++------ docs/html/guide/developing/building/index.jd | 4 +- docs/html/guide/guide_toc.cs | 10 +- docs/html/guide/market/billing/billing_admin.jd | 62 ++--- .../guide/market/billing/billing_best_practices.jd | 6 +- .../html/guide/market/billing/billing_integrate.jd | 174 +++++++------- docs/html/guide/market/billing/billing_overview.jd | 120 +++++----- .../html/guide/market/billing/billing_reference.jd | 56 ++--- docs/html/guide/market/billing/billing_testing.jd | 60 ++--- docs/html/guide/market/billing/index.jd | 16 +- docs/html/guide/market/expansion-files.jd | 126 +++++----- .../guide/market/licensing/adding-licensing.jd | 52 ++--- docs/html/guide/market/licensing/index.jd | 18 +- .../guide/market/licensing/licensing-reference.jd | 28 +-- docs/html/guide/market/licensing/overview.jd | 66 +++--- docs/html/guide/market/licensing/setting-up.jd | 62 ++--- docs/html/guide/market/publishing/multiple-apks.jd | 72 +++--- docs/html/guide/practices/compatibility.jd | 42 ++-- docs/html/guide/practices/design/accessibility.jd | 7 +- docs/html/guide/practices/optimizing-for-3.0.jd | 14 +- docs/html/guide/practices/screens-distribution.jd | 14 +- docs/html/guide/practices/screens_support.jd | 4 +- .../ui_guidelines/activity_task_design.jd | 2 +- .../ui_guidelines/icon_design_launcher.jd | 30 +-- .../ui_guidelines/icon_design_launcher_archive.jd | 12 +- docs/html/guide/publishing/app-signing.jd | 10 +- docs/html/guide/publishing/preparing.jd | 45 ++-- docs/html/guide/publishing/publishing.jd | 256 ++++++++++----------- docs/html/guide/publishing/publishing_overview.jd | 51 ++-- docs/html/guide/publishing/versioning.jd | 2 +- docs/html/guide/topics/admin/device-admin.jd | 4 +- docs/html/guide/topics/data/backup.jd | 4 +- docs/html/guide/topics/fundamentals.jd | 10 +- docs/html/guide/topics/graphics/opengl.jd | 8 +- .../html/guide/topics/manifest/activity-element.jd | 4 +- .../topics/manifest/compatible-screens-element.jd | 14 +- .../html/guide/topics/manifest/manifest-element.jd | 6 +- .../topics/manifest/supports-gl-texture-element.jd | 36 +-- .../topics/manifest/supports-screens-element.jd | 6 +- .../guide/topics/manifest/uses-feature-element.jd | 122 +++++----- .../guide/topics/manifest/uses-library-element.jd | 8 +- .../topics/manifest/uses-permission-element.jd | 10 +- .../html/guide/topics/manifest/uses-sdk-element.jd | 16 +- docs/html/guide/topics/media/camera.jd | 10 +- docs/html/guide/topics/network/sip.jd | 2 +- docs/html/guide/topics/nfc/nfc.jd | 10 +- docs/html/guide/topics/resources/localization.jd | 8 +- docs/html/guide/topics/sensors/sensors_overview.jd | 8 +- docs/html/guide/topics/ui/actionbar.jd | 2 +- 50 files changed, 930 insertions(+), 933 deletions(-) (limited to 'docs/html/guide') diff --git a/docs/html/guide/appendix/install-location.jd b/docs/html/guide/appendix/install-location.jd index e5ed226..63a3817 100644 --- a/docs/html/guide/appendix/install-location.jd +++ b/docs/html/guide/appendix/install-location.jd @@ -172,9 +172,9 @@ persist after external storage is remounted. before the external storage is mounted to the device. If your application is installed on the external storage, it can never receive this broadcast.
Copy Protection
-
Your application cannot be installed to a device's SD card if it uses Android Market's - Copy Protection feature. However, if you use Android Market's - Application Licensing instead, your +
Your application cannot be installed to a device's SD card if it uses Google Play's + Copy Protection feature. However, if you use Google Play's + Application Licensing instead, your application can be installed to internal or external storage, including SD cards.
diff --git a/docs/html/guide/appendix/market-filters.jd b/docs/html/guide/appendix/market-filters.jd index d9b2155..3e502d7 100644 --- a/docs/html/guide/appendix/market-filters.jd +++ b/docs/html/guide/appendix/market-filters.jd @@ -1,4 +1,4 @@ -page.title=Market Filters +page.title=Filters on Google Play @jd:body
@@ -6,15 +6,15 @@ page.title=Market Filters

Quickview

In this document

    -
  1. How Filters Work in Android Market
    2. +
  2. How Filters Work on Google Play
  3. Filtering based on Manifest Elements
    1. Advanced manifest filters
      2. @@ -47,10 +47,10 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk>
      - -

      Interested in publishing your app on Android Market?

      + +

      Interested in publishing your app on Google Play?

      Go to Android Market to create a publisher +href="http://play.google.com/apps/publish">Go to Google Play to create a publisher account and upload your app.

@@ -58,44 +58,44 @@ account and upload your app.

-

When a user searches or browses in Android Market on an Android device, the results are filtered +

When a user searches or browses on Google Play on an Android device, the results are filtered based on which applications are compatible with that device. For example, if an application -requires a camera (as specified in the application manifest file), then Android Market will not show +requires a camera (as specified in the application manifest file), then Google Play will not show the app on any device that does not have a camera.

Declarations in the manifest file that are compared to the device's configuration is not the only part of how applications are filtered. Filtering might also occur due to the user's country and carrier, the presence or absence of a SIM card, and other factors.

-

Changes to the Android Market filters are independent of changes to the Android platform itself. -This document is updated periodically to reflect any changes that affect the way Android Market +

Changes to the Google Play filters are independent of changes to the Android platform itself. +This document is updated periodically to reflect any changes that affect the way Google Play filters applications.

-

How Filters Work in Android Market

+

How Filters Work on Google Play

-

Android Market uses the filter restrictions described below to determine +

Google Play uses the filter restrictions described below to determine whether to show your application to a user who is browsing or searching for -applications from the Android Market app. When determining whether to display your app, -Market checks the device's hardware and software configuration, as well as it's +applications from the Google Play app. When determining whether to display your app, +Google Play checks the device's hardware and software configuration, as well as it's carrier, location, and other characteristics. It then compares those against the restrictions and dependencies expressed by the application's manifest file and publishing details. If the application is -compatible with the device according to the filter rules, Market displays the -application to the user. Otherwise, Market hides your application from search +compatible with the device according to the filter rules, Google Play displays the +application to the user. Otherwise, Google Play hides your application from search results and category browsing, even if a user specifically requests -the app by clicking a deep link that points directly to the app's ID within Market..

+the app by clicking a deep link that points directly to the app's ID within Google Play..

Note: When users browse the Android Market web site, they can see all published -applications. The Android Market web site compares the application requirements to each of the +href="http://play.google.com/apps">Google Play web site, they can see all published +applications. The Google Play web site compares the application requirements to each of the user's registered devices for compatibility, though, and only allows them to install the application if it's compatible with their device.

You can use any combination of the available filters for your app. For example, you can set a minSdkVersion requirement of "4" and set smallScreens="false" -in the app, then when uploading the app to Market you could target European countries (carriers) -only. Android Market's filters will thus prevent the application from being available on any device +in the app, then when uploading the app to Google Play you could target European countries (carriers) +only. Google Play's filters will thus prevent the application from being available on any device that does not match all three of these requirements.

All filtering restrictions are associated with an application's version and can @@ -106,15 +106,15 @@ available.

Filtering based on Manifest Elements

-

Most Market filters are triggered by elements within an application's +

Most filters are triggered by elements within an application's manifest file, AndroidManifest.xml (although not everything in the manifest file can trigger filtering). -Table 1 lists the manifest elements that you should use to trigger Android -Market filtering, and explains how the filtering for each element works.

+Table 1 lists the manifest elements that you should use to trigger +filtering, and explains how the filtering for each element works.

Table 1. Manifest elements that -trigger filtering on Market.

+trigger filtering on Google Play.

@@ -129,19 +129,19 @@ trigger filtering on Market.

An application indicates the screen sizes that it is capable of supporting by setting attributes of the <supports-screens> element. When -the application is published, Market uses those attributes to determine whether +the application is published, Google Play uses those attributes to determine whether to show the application to users, based on the screen sizes of their devices.

-

As a general rule, Market assumes that the platform on the device can adapt +

As a general rule, Google Play assumes that the platform on the device can adapt smaller layouts to larger screens, but cannot adapt larger layouts to smaller screens. Thus, if an application declares support for "normal" screen size only, -Market makes the application available to both normal- and large-screen devices, +Google Play makes the application available to both normal- and large-screen devices, but filters the application so that it is not available to small-screen devices.

If an application does not declare attributes for -<supports-screens>, Market uses the default values for those +<supports-screens>, Google Play uses the default values for those attributes, which vary by API Level. Specifically:

@@ -218,16 +218,16 @@ Level 5).

The manifest includes <uses-feature android:name="android.hardware.sensor.light" />, and a user is searching for apps on a device that does not have a light sensor. -Result: Android Market will not show the app to the user.

+Result: Google Play will not show the app to the user.

Example 2
The manifest does not include a <uses-feature> -element. Result: Android Market will show the app to all users, +element. Result: Google Play will show the app to all users, unless other filters apply.

For complete information, see <uses-feature> .

-

Filtering based on implied features: In some cases, Android -Market interprets permissions requested through +

Filtering based on implied features: In some cases, Google +Play interprets permissions requested through <uses-permission> elements as feature requirements equivalent to those declared in <uses-feature> elements. See <uses-permission>, @@ -245,19 +245,19 @@ below.

Example 1
An app requests multiple OpenGL-ES versions by specifying openGlEsVersion multiple times in the - manifest. Result: Market assumes that the app requires the highest of the indicated versions.

+ manifest. Result: Google Play assumes that the app requires the highest of the indicated versions.

Example 2
An app - requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. Result: Android Market will show the app to the user, unless other filters apply. If a - device reports that it supports OpenGL-ES version X, Market assumes that it + requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. Result: Google Play will show the app to the user, unless other filters apply. If a + device reports that it supports OpenGL-ES version X, Google Play assumes that it also supports any version earlier than X.

Example 3
A user is searching for apps on a device that does not - report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). Result: Android Market assumes that the device - supports only OpenGL-ES 1.0. Market will only show the user apps that do not specify openGlEsVersion, or apps that do not specify an OpenGL-ES version higher than 1.0.

+ report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). Result: Google Play assumes that the device + supports only OpenGL-ES 1.0. Google Play will only show the user apps that do not specify openGlEsVersion, or apps that do not specify an OpenGL-ES version higher than 1.0.

Example 4
- The manifest does not specify openGlEsVersion. Result: Android Market will show the app to all users, unless other filters apply.

+ The manifest does not specify openGlEsVersion. Result: Google Play will show the app to all users, unless other filters apply.

For more details, see <uses-feature>.

@@ -268,28 +268,28 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses- - @@ -316,7 +316,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android:m @@ -327,7 +327,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max">android:m

Advanced manifest filters

-

In addition to the manifest elements in table 1, Android Market can also +

In addition to the manifest elements in table 1, Google Play can also filter applications based on the advanced manifest elements in table 2.

These manifest elements and the filtering they trigger are for exceptional use-cases @@ -336,14 +336,14 @@ require strict controls on application distribution. Most applications s these filters.

Table 2. Advanced manifest elements for -Android Market filtering.

+Google Play filtering.

Manifest Element

An application can - request certain hardware features, and Android Market will show the app only on devices that have the required hardware.

+ request certain hardware features, and Google Play will show the app only on devices that have the required hardware.

Example 1
- The manifest includes <uses-configuration android:reqFiveWayNav="true" />, and a user is searching for apps on a device that does not have a five-way navigational control. Result: Android Market will not show the app to the user.

+ The manifest includes <uses-configuration android:reqFiveWayNav="true" />, and a user is searching for apps on a device that does not have a five-way navigational control. Result: Google Play will not show the app to the user.

Example 2
- The manifest does not include a <uses-configuration> element. Result: Android Market will show the app to all users, unless other filters apply.

+ The manifest does not include a <uses-configuration> element. Result: Google Play will show the app to all users, unless other filters apply.

For more details, see <uses-configuration>.

An application can require specific shared libraries to be present on the device.

Example 1
- An app requires the com.google.android.maps library, and a user is searching for apps on a device that does not have the com.google.android.maps library. Result: Android Market will not show the app to the user.

+ An app requires the com.google.android.maps library, and a user is searching for apps on a device that does not have the com.google.android.maps library. Result: Google Play will not show the app to the user.

Example 2
- The manifest does not include a <uses-library> element. Result: Android Market will show the app to all users, unless other filters apply.

+ The manifest does not include a <uses-library> element. Result: Google Play will show the app to all users, unless other filters apply.

For more details, see <uses-library>.
<uses-permission>  Strictly, Android Market does not filter based on + Strictly, Google Play does not filter based on <uses-permission> elements. However, it does read the elements to determine whether the application has hardware feature requirements that may not have been properly declared in <uses-feature> elements. For example, if an application requests the CAMERA permission but does not declare a <uses-feature> element for -android.hardware.camera, Android Market considers that the +android.hardware.camera, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.

In general, if an application requests hardware-related permissions, -Android Market assumes that the application requires the underlying hardware +Google Play assumes that the application requires the underlying hardware features, even though there might be no corresponding to -<uses-feature> declarations. Android Market then sets up +<uses-feature> declarations. Google Play then sets up filtering based on the features implied by the <uses-feature> declarations.

For a list of permissions that imply hardware features, see @@ -305,9 +305,9 @@ element.

An application can require a minimum API level.

Example 1
The manifest includes <uses-sdk - android:minSdkVersion="3">, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Android Market will not show the app to the user.

+ android:minSdkVersion="3">, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Google Play will not show the app to the user.

Example 2
- The manifest does not include minSdkVersion, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Android Market assumes that minSdkVersion is "1" and that the app is compatible with all versions of Android. Market shows the app to the user and allows the user to download the app. The app crashes at runtime.

+ The manifest does not include minSdkVersion, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Google Play assumes that minSdkVersion is "1" and that the app is compatible with all versions of Android. Google Play shows the app to the user and allows the user to download the app. The app crashes at runtime.

Because you want to avoid this second scenario, we recommend that you always declare a minSdkVersion. For details, see android:minSdkVersion.

Deprecated. Android 2.1 and later do not check or enforce the maxSdkVersion attribute, and the SDK will not compile if maxSdkVersion is set in an app's manifest. For devices already - compiled with maxSdkVersion, Market will respect it and use it for + compiled with maxSdkVersion, Google Play will respect it and use it for filtering.

Declaring maxSdkVersion is not recommended. For details, see android:maxSdkVersion.

@@ -370,16 +370,16 @@ formats supported by the application are also supported by the device.

Other Filters

-

Android Market uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below.

+

Google Play uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below.

Table 3. Application and publishing -characteristics that affect filtering on Market.

+characteristics that affect filtering on Google Play.

Manifest ElementSummary
{@code <compatible-screens>} -

Android Market filters the application if the device screen size and density does not match +

Google Play filters the application if the device screen size and density does not match any of the screen configurations (declared by a {@code <screen>} element) in the {@code <compatible-screens>} element.

Caution: Normally, you should not use @@ -360,7 +360,7 @@ with alternative resources.

{@code <supports-gl-texture>} -

Android Market filters the application unless one or more of the GL texture compression +

Google Play filters the application unless one or more of the GL texture compression formats supported by the application are also supported by the device.

@@ -390,10 +390,10 @@ must have a SIM card and be running Android 1.1 or later, and it must be in a country (as determined by SIM carrier) in which paid apps are available.

 @@ -404,22 +404,22 @@ country (as determined by SIM carrier) in which paid apps are available.

Filter Name How It Works
Publishing Status

Only published applications will appear in - searches and browsing within Android Market.

Even if an app is unpublished, it can + searches and browsing within Google Play.

Even if an app is unpublished, it can be installed if users can see it in their Downloads area among their purchased, installed, or recently uninstalled apps.

If an application has been suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.

Country / Carrier Targeting

When you upload your app to - the Android Market, you can select specific countries to target. The app will only + Google Play, you can select specific countries to target. The app will only be visible to the countries (carriers) that you select, as follows:

  • A device's country is determined based on the carrier, if a carrier is - available. If no carrier can be determined, the Market application tries to + available. If no carrier can be determined, Google Play tries to determine the country based on IP.

  • Carrier is determined based on the device's SIM (for GSM devices), not the current roaming carrier.
Copy-Protected Applications

To copy protect an application, set copy protection to "On" when you configure publishing -options for your application. Market will not show copy-protected applications on +options for your application. Google Play will not show copy-protected applications on developer devices or unreleased devices.

Publishing Multiple APKs with Different Filters

-

Some specific Android Market filters allow you to publish multiple APKs for the same +

Some specific Google Play filters allow you to publish multiple APKs for the same application in order to provide a different APK to different device configurations. For example, if you're creating a video game that uses high-fidelity graphic assets, you might want to create two APKs that each support different texture compression formats. This way, you can reduce the size of the APK file by including only the textures that are required for each device -configuration. Depending on each device's support for your texture compression formats, Android -Market will deliver it the APK that you've declared to support that device.

+configuration. Depending on each device's support for your texture compression formats, Google +Play will deliver it the APK that you've declared to support that device.

-

Currently, Android Market allows you to publish multiple APKs for the same application only +

Currently, Google Play allows you to publish multiple APKs for the same application only when each APK provides different filters based on the following configurations:

  • OpenGL texture compression formats @@ -440,7 +440,7 @@ href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code

All other filters still work the same as usual, but these three are the only filters that can -distinguish one APK from another within the same application listing on Android Market. For example, +distinguish one APK from another within the same application listing on Google Play. For example, you cannot publish multiple APKs for the same application if the APKs differ only based on whether the device has a camera.

@@ -450,5 +450,5 @@ APK that supports a wide range of device configurations. Publishing mul requires that you follow specific rules within your filters and that you pay extra attention to the version codes for each APK to ensure proper update paths for each configuration.

-

If you need more information about how to publish multiple APKs on Android Market, read If you need more information about how to publish multiple APKs on Google Play, read Multiple APK Support.

diff --git a/docs/html/guide/developing/building/index.jd b/docs/html/guide/developing/building/index.jd index 59c4645..569cd28 100644 --- a/docs/html/guide/developing/building/index.jd +++ b/docs/html/guide/developing/building/index.jd @@ -27,8 +27,8 @@ page.title=Building and Running

To run an application on an emulator or device, the application must be signed using debug or release mode. You typically want to sign your application in debug mode when you develop and test your application, because the build tools use a debug key with a known password so you do not have - to enter it every time you build. When you are ready to release the application to Android - Market, you must sign the application in release mode, using your own private key.

+ to enter it every time you build. When you are ready to release the application to Google + Play, you must sign the application in release mode, using your own private key.

Fortunately, Eclipse or your Ant build script signs the application for you in debug mode when you build your application. You can also easily setup Eclipse or your Ant build to sign your diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index fd2ec93..9d5064e 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -444,12 +444,12 @@

  • - - Android Market Topics - +

    + Google Play Topics +

  • - Market Filters + Filters on Google Play
  • Multiple APK Support 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.

    -

    You must have an Android Market publisher account to register test accounts. And you must have a +

    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 publisher site. 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 publisher site. If you do not have a Google Checkout merchant account, you can register for one at the Google Checkout site.

    Creating a Product List

    -

    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 +

    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.

    @@ -77,7 +77,7 @@ storing and delivering the digital content that you sell in your applications.

    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 com.android.vending.BILLING 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.

    To add an item to a product list using the In-app Products UI, follow these steps:

      -
    1. Log in to your publisher account.
      2. -
    2. In the All Android Market listings panel, under the application name, click +
    3. Log in to your publisher account.
      4. +
    4. In the All Google Play listings panel, under the application name, click In-app Products.
    5. On the In-app Products List page, click Add in-app product.
    6. 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.

    7. Publishing State

      An item's publishing state can be Published or Unpublished . To be visible to a user during checkout, an item's publishing state must be set to - Published and the item's application must be published on Android Market.

      + Published and the item's application must be published on Google Play.

      Note: 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 Testing In-app @@ -167,9 +167,9 @@ number of in-app items.

      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.

      + page in the Google Play developer console.

      To specify prices in other currencies, you can manually enter the price for each - currency or you can click Auto Fill and let Android Market do a one-time + currency or you can click Auto Fill and let Google Play do a one-time conversion from your home currency to the currencies you are targeting (see figure 4).

      8. @@ -357,8 +357,8 @@ with the locale field.

      To import the items that are specified in your CSV file, do the following:

        -
      1. Log in to your publisher account.
        2. -
      2. In the All Android Market listings panel, under the application name, click +
      3. Log in to your publisher account.
        4. +
      4. In the All Google Play listings panel, under the application name, click In-app Products.
      5. On the In-app Products List page, click Choose File 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

        Choosing a Purchase Type

        -

        An item's purchase type controls how Android Market manages the purchase of the item. There are +

        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."

        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 RESTORE_TRANSACTIONS request and restore the state of the items a specific user has purchased.

        -

        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 +

        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.

        -

        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 +

        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.

        @@ -417,10 +417,10 @@ times.

        Handling Refunds

        -

        In-app billing does not allow users to send a refund request to Android Market. Refunds for +

        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 Handling IN_APP_NOTIFY messages and

        Setting Up Test Accounts

        -

        The Android Market publisher site lets you set up one or more test accounts. A test account is a +

        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.

        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.<

        To add test accounts to your publisher account, follow these steps:

          -
        1. Log in to your publisher account.
          2. +
        2. Log in to your publisher account.
        3. On the upper left part of the page, under your name, click Edit profile.
        4. On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure 5).
          5. @@ -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.

          Table 2. Developer support resources -for Android Market in-app billing.

          +for Google Play in-app billing.

          @@ -502,8 +502,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co android - - + 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

          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.

          +anyone who is using Google Play's in-app billing service.

          Security Best Practices

          @@ -92,7 +92,7 @@ replay attacks.

          nonces on the server.

          Take action against trademark and copyright infringement

          -

          If you see your content being redistributed on Android Market, act quickly and decisively. File a +

          If you see your content being redistributed on Google Play, act quickly and decisively. File a trademark notice of infringement or a copyright notice of infringement.

          @@ -102,7 +102,7 @@ infringement.

          purchase state of the unlocked content whenever a user accesses the content. This allows you to revoke use when necessary and minimize piracy.

          -

          Protect your Android Market public key

          +

          Protect your Google Play public key

          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 -

          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 +

          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.

          @@ -53,23 +53,23 @@ billing.

        5. Update your AndroidManifest.xml file.
        6. Create a Service and bind it to the MarketBillingService so your application can send billing requests and receive - billing responses from the Android Market application.
          7. + billing responses from Google Play.
        7. Create a BroadcastReceiver to handle broadcast - intents from the Android Market application.
          8. + intents from Google Play.
        8. Create a security processing component to verify the - integrity of the transaction messages that are sent by Android Market .
          9. + integrity of the transaction messages that are sent by Google Play.
        9. Modify your application code to support in-app billing.

          10. Downloading the Sample Application

          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:

          +all in-app billing implementations, including:

            -
          • Sending in-app billing requests to the Android Market application.
            • -
          • Handling synchronous responses from the Android Market application.
            • -
          • Handling broadcast intents (asynchronous responses) from the Android Market application.
            • +
          • Sending in-app billing requests to Google Play.
            • +
          • Handling synchronous responses from Google Play.
            • +
          • Handling broadcast intents (asynchronous responses) from Google Play.
          • Using in-app billing security mechanisms to verify the integrity of billing responses.
          • Creating a user interface that lets users select items for purchase.
          @@ -109,12 +109,12 @@ history. - @@ -136,8 +136,8 @@ history. - + @@ -171,7 +171,7 @@ running the sample application involves three tasks:

          • Configuring and building the sample application.
            • -
          • Uploading the sample application to Android Market.
            • +
          • Uploading the sample application to Google Play.
          • Setting up test accounts and running the sample application.
          @@ -186,12 +186,12 @@ your project.

          following:

            -
          1. Add your Android Market public key to the sample application code. +
          2. Add your Google Play public key to the sample application code.

            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:

              -
            1. Log in to your Android Market publisher +
            2. Log in to your Google Play publisher account.
            3. On the upper left part of the page, under your name, click Edit Profile.
              4. @@ -208,7 +208,7 @@ following:

          3. Change the package name of the sample application. -

            The current package name is com.example.dungeons. Android Market does not let +

            The current package name is com.example.dungeons. Google Play does not let you upload applications with package names that contain com.example, so you must change the package name to something else.

            4. @@ -221,14 +221,14 @@ following:

            Uploading the sample application

            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.

              -
            1. Upload the release version of the sample application to Android Market. +
            2. Upload the release version of the sample application to Google Play.

              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 Uploading applications.

              3. @@ -253,7 +253,7 @@ how to do this.

              onto a device to run it. To run the sample application, do the following:

                -
              1. Make sure you have at least one test account registered under your Android Market +
              2. Make sure you have at least one test account registered under your Google Play publisher account.

                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:

                href="{@docRoot}guide/market/billing/billing_testing.html#billing-testing-setup">Setting up Test Accounts.

                3. -
              3. Verify that your device is running a supported version of the Android Market +
              4. Verify that your device is running a supported version of the Google Play application or the MyApps application.

                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 Updating Android - Market.

                + 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 Updating Google + Play.

              5. Install the application onto your device. -

                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 +

                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 Running on a device.

                @@ -280,7 +280,7 @@ onto a device to run it. To run the sample application, do the following:

              6. Make one of your test accounts the primary account on your device.

                The primary account on your device must be one of the test accounts - 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:

                  @@ -306,7 +306,7 @@ to true in the Consts.java file.

                  Adding the AIDL file to your project

                  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 (MarketBillingService). When you add this file to your project, the Android build environment creates an interface file (IMarketBillingService.java). You can then use this interface to make billing requests by invoking IPC method calls.

                  @@ -333,29 +333,29 @@ the gen folder of your project.

                  Updating Your Application's Manifest

                  -

                  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 +

                  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 com.android.vending.BILLING 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 RESULT_DEVELOPER_ERROR +Google Play will refuse the requests and respond with a RESULT_DEVELOPER_ERROR response code.

                  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 IMarketBillingService and send messages to Android -Market. You must also declare IMarketBillingService and send messages to Google +Play. You must also declare intent filters 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.

                  +intents that are sent from the Google Play application.

                  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, BillingReceiver 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 BillingService is the {@link android.app.Service} that sends requests -to the Android Market application.

                  +to the Google Play application.

                   <?xml version="1.0" encoding="utf-8"?>
@@ -391,11 +391,11 @@ to the Android Market application.
                  
 
                  Creating a Local Service
                  
 
 
                  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:
                  
+your application and Google Play. At a minimum, this service must do the following:
                  
 
 
                    
   
                  • Bind to the MarketBillingService.
-  
                  • Send billing requests (as IPC method calls) to the Android Market application. The five types
+  
                  • Send billing requests (as IPC method calls) to the Google Play application. The five types
   of billing requests include:
     
                      
       
                    • CHECK_BILLING_SUPPORTED requests
                      • 
@@ -474,7 +474,7 @@ The five request types are specified using the BILLING_REQUEST Bund
 key can have the following five values:
                      
 
 
                        
-  
                      • CHECK_BILLING_SUPPORTED—verifies that the Android Market application
+  
                      • CHECK_BILLING_SUPPORTED—verifies that the Google Play application
   supports in-app billing.
                        • 
   
                      • REQUEST_PURCHASE—sends a purchase request for an in-app item.
                        • 
   
                      • GET_PURCHASE_INFORMATION—retrieves transaction information for a purchase
@@ -510,7 +510,7 @@ application's main thread.
                        
 
 
                        Verifying that in-app billing is supported (CHECK_BILLING_SUPPPORTED)
                        
 
-
                        The following code sample shows how to verify whether the Android Market application supports
+
                        The following code sample shows how to verify whether the Google Play application supports
 in-app billing. In the sample, mService is an instance of the
 MarketBillingService interface.
                        
 
@@ -533,7 +533,7 @@ android.os.Bundle} response, which contains only a single key: RESPONSE_CO
   
                      • RESULT_BILLING_UNAVAILABLE—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).
                        • 
-  
                      • RESULT_ERROR—there was an error connecting with the Android Market
+  
                      • RESULT_ERROR—there was an error connecting with the Google Play
   application.
                        • 
   
                      • RESULT_DEVELOPER_ERROR—the application is trying to make an in-app billing
   request but the application has not declared the com.android.vending.BILLING
@@ -546,10 +546,10 @@ android.os.Bundle} response, which contains only a single key: RESPONSE_CO
 
 
                        We recommend that you invoke the CHECK_BILLING_SUPPORTED request within a
 RemoteException block. When your code throws a RemoteException 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 Updating Android Market
+href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google Play
 Help topic.
                        
 
 
                        The sample application demonstrates how you can handle this error condition (see
@@ -561,16 +561,16 @@ Help topic.
                        
 
 
                          
   
                        • Send the REQUEST_PURCHASE request.
                          • 
-  
                        • Launch the {@link android.app.PendingIntent} that is returned from the Android Market
+  
                        • Launch the {@link android.app.PendingIntent} that is returned from the Google Play
   application.
                          • 
-  
                        • Handle the broadcast intents that are sent by the Android Market application.
                          • 
+  
                        • Handle the broadcast intents that are sent by the Google Play application.
                          • 
 
                        
 
 
                        Making the request
                        
 
 
                        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,
-mProductId is the Android Market product ID of an in-app item (which is listed in the
+mProductId is the Google Play product ID of an in-app item (which is listed in the
 application's product
 list), and mService is an instance of the MarketBillingService
 interface.
                        
@@ -644,25 +644,25 @@ void startBuyPageActivity(PendingIntent pendingIntent, Intent intent) {
 context and not an application context. Also, you cannot use the singleTop launch mode 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.
                        
 
 
                        Handling broadcast intents
                        
 
 
                        A REQUEST_PURCHASE request also triggers two asynchronous responses (broadcast
-intents). First, the Android Market application sends a RESPONSE_CODE broadcast intent,
+intents). First, the Google Play application sends a RESPONSE_CODE broadcast intent,
 which provides error information about the request. If the request does not generate an
 error, the RESPONSE_CODE broadcast intent returns RESULT_OK, which
 indicates that the request was successfully sent. (To be clear, a RESULT_OK response
 does not indicate that the requested purchase was successful; it indicates that the request was sent
-successfully to Android Market.)
                        
+successfully to Google Play.)
                        
 
 
                        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
 IN_APP_NOTIFY broadcast intent. This message contains a notification ID, which you can
 use to retrieve the transaction details for the REQUEST_PURCHASE request.
                        
 
-
                        Note: The Android Market application also sends
+
                        Note: The Google Play application also sends
 an IN_APP_NOTIFY for refunds. For more information, see Handling
 IN_APP_NOTIFY messages.
                        
@@ -670,7 +670,7 @@ IN_APP_NOTIFY messages.
                        
 
                        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 RESULT_OK
 message until you receive an IN_APP_NOTIFY 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:
                        
@@ -693,12 +693,12 @@ status of pending and completed in-app purchases.
                        
 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.
                        
+receive transaction updates from Google Play.
                        
 
 
                        Important: 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 IN_APP_NOTIFY message
 for the second purchase request.
                        
@@ -730,7 +730,7 @@ three keys that are required for all requests: BILLING_REQUEST,
 API_VERSION, and PACKAGE_NAME. The additional keys are then added to the
 bundle prior to invoking the sendBillingRequest() method. The
 REQUEST_NONCE 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
 PURCHASE_STATE_CHANGED broadcast intent so you can verify the integrity of the
 transaction information. The NOTIFY_IDS key contains an array of notification IDs,
 which you received in the IN_APP_NOTIFY broadcast intent.
                        
@@ -741,9 +741,9 @@ you with the status of the request and the REQUEST_ID key provides
 request identifier for the request.
                        
 
 
                        A GET_PURCHASE_INFORMATION request also triggers two asynchronous responses
-(broadcast intents). First, the Android Market application sends a RESPONSE_CODE
+(broadcast intents). First, the Google Play application sends a RESPONSE_CODE
 broadcast intent, which provides status and error information about the request. Next, if the
-request was successful, the Android Market application sends a PURCHASE_STATE_CHANGED
+request was successful, the Google Play application sends a PURCHASE_STATE_CHANGED
 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.
                        
@@ -783,8 +783,8 @@ request identifier for the request.
                        
 RESPONSE_CODE broadcast intent. This broadcast intent provides status and error
 information about the request.
                        
 
-
                        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
+
                        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
 IN_APP_NOTIFY messages for the transactions you have not confirmed. Also,
 your application must be able to handle IN_APP_NOTIFY messages that contain multiple
 orders.
                        
@@ -792,7 +792,7 @@ orders.
                        
 
                        In addition, as a best practice, you should not send a CONFIRM_NOTIFICATIONS 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 IN_APP_NOTIFY broadcast intent from Android Market indicating
+will still receive an IN_APP_NOTIFY broadcast intent from Google Play indicating
 that you need to deliver the product.
                        
 
 
                        Restoring transaction information (RESTORE_TRANSACTIONS)
                        
@@ -817,7 +817,7 @@ three keys that are required for all requests: BILLING_REQUEST,
 API_VERSION, and PACKAGE_NAME. The additional REQUEST_NONCE
 key is then added to the bundle prior to invoking the sendBillingRequest() method. The
 REQUEST_NONCE 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 PURCHASE_STATE_CHANGED broadcast intent so you can verify the
 integrity of the transaction information.
                        
 
@@ -827,9 +827,9 @@ you with the status of the request and the REQUEST_ID key provides
 request identifier for the request.
                        
 
 
                        A RESTORE_TRANSACTIONS request also triggers two asynchronous responses (broadcast
-intents). First, the Android Market application sends a RESPONSE_CODE broadcast intent,
+intents). First, the Google Play application sends a RESPONSE_CODE broadcast intent,
 which provides status and error information about the request. Next, if the request was successful,
-the Android Market application sends a PURCHASE_STATE_CHANGED broadcast intent. This
+the Google Play application sends a PURCHASE_STATE_CHANGED 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.
                        
@@ -842,7 +842,7 @@ application has been removed from a device and reinstalled.
                        
 
 
                        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 BillingReceiver.java and BillingService.java 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
 
 
                        Creating a BroadcastReceiver
                        
 
-
                        The Android Market application uses broadcast intents to send asynchronous billing responses to
+
                        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:
          + request and is returned by Google Play at the time a request is made. - + @@ -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 { } -

          In addition to receiving broadcast intents from the Android Market application, your {@link +

          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 BillingReceiver.java file in the @@ -985,8 +985,8 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D

          Verifying Signatures and Nonces

          -

          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 +

          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 GET_PURCHASE_INFORMATION and RESTORE_TRANSACTIONS request. The nonce is returned with the PURCHASE_STATE_CHANGED broadcast intent, enabling you to verify that @@ -1023,12 +1023,12 @@ implementation, be sure to follow the guidelines in Security and Design and obfuscate your code.

          -

          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 +

          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.

            -
          1. Log in to your publisher account.
            2. +
          2. Log in to your publisher account.
          3. On the upper left part of the page, under your name, click Edit profile.
          4. On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure 2).
            5. @@ -1080,8 +1080,8 @@ unmanaged items is important because unmanaged items cannot be restored by using

            Creating a user interface for selecting items

            -

            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 +

            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 sendBillingRequest() method when a user selects an item for purchase.

            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 -

            Android Market In-app Billing is an Android Market service that provides checkout processing for +

            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.

            In-app Billing Architecture

            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.

            +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.

            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.

            Figure 1. Your application sends and receives billing messages through the - Android Market application, which handles all communication with the Android Market server.

            + Google Play application, which handles all communication with the Google Play server.

            A typical in-app billing implementation relies on three components:

          Market billing issue trackerMarket billing +Billing issue trackerBilling project issue tracker Bug and issue reports related specifically to in-app billing sample code.
          BillingReceiver.java 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 BillingService.
          BillingService.javaA {@link android.app.Service} that sends messages to Android Market on behalf of the + A {@link android.app.Service} that sends messages to Google Play on behalf of the application by connecting (binding) to the MarketBillingService.
          Consts.javaDefines 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.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.
          com.android.vending.billing.RESPONSE_CODE request_id A long 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.
          com.android.vending.billing.RESPONSE_CODE response_codeAn int representing the actual Android Market server response code.An int representing the actual Google Play server response code.
          com.android.vending.billing.IN_APP_NOTIFY notification_id A String 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 GET_PURCHASE_INFORMATION request.
          @@ -80,13 +80,13 @@ codes returned by Android Market.

           - @@ -108,7 +108,7 @@ purchase an item from yourself, which is not allowed by Google Checkout.

          In-app Billing Service Interface

          -

          The following section describes the interface for Android Market's in-app billing service. The +

          The following section describes the interface for Google Play's in-app billing service. The interface is defined in the IMarketBillingService.aidl file, which is included with the in-app billing sample @@ -144,7 +144,7 @@ pairs, which are summarized in table 2.

           - @@ -160,8 +160,8 @@ pairs, which are summarized in table 2.

           + sell using Google Play's in-app billing service must have a unique product ID, which you + specify on the Google Play publisher site. @@ -172,7 +172,7 @@ pairs, which are summarized in table 2.

           + to verify the integrity of transaction responses form Google Play. @@ -202,20 +202,20 @@ pairs, which are summarized in table 2.

           @@ -398,7 +398,7 @@ a PURCHASE_STATE_CHANGED intent.

           + application's product list on the Google Play publisher site. 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 -

          The Android Market publisher site provides several tools that help you test your in-app billing +

          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.

          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 Using Hardware Devices.

          @@ -50,12 +50,12 @@ Devices.

          Testing in-app purchases with static responses

          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.

          +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.

          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.

          @@ -65,7 +65,7 @@ product ID android.test.purchased.

          Figure 1. Checkout flow for the special reserved item android.test.purchased.

          -

          You do not need to list the reserved products in your application's product list. Android Market +

          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.

          • android.test.purchased -

            When you make an in-app billing request with this product ID, Android Market responds as +

            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.

          • android.test.canceled -

            When you make an in-app billing request with this product ID Android Market responds as +

            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.

          • android.test.refunded -

            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 +

            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 Handling IN_APP_NOTIFY messages and Pricing.

          • android.test.item_unavailable -

            When you make an in-app billing request with this product ID, Android Market responds as +

            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.

          @@ -185,20 +185,20 @@ application's product list you use one of the reserved product IDs.

          You do not need to use a test account if you are testing only with the reserved product IDs.

          -
        10. Verify that your device is running a supported version of the Android Market +
        11. Verify that your device is running a supported version of the Google Play application or the MyApps application.

          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 Updating Android - Market.

          + 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 Updating Google + Play.

        12. Run your application and purchase the reserved product IDs.

          13. Note: 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.

          @@ -207,7 +207,7 @@ environment.

          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.

          Note: 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.

          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 Setting up test @@ -237,7 +237,7 @@ actual payouts to your merchant account.

          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 Uploading applications.

          @@ -257,7 +257,7 @@ actual payouts to your merchant account.

          To perform end-to-end testing of in-app billing, the primary account on your device must be one of the test accounts - 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:

            @@ -269,14 +269,14 @@ actual payouts to your merchant account.

            device setup process.
          -
        13. Verify that your device is running a supported version of the Android Market +
        14. Verify that your device is running a supported version of the Google Play application or the MyApps application.

          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 Updating Android - Market.

          + 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 Updating Google + Play.

        15. Make in-app purchases in your application.
          16. @@ -285,7 +285,7 @@ actual payouts to your merchant account.

          do a factory reset, making sure you log on with your primary account first.

          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 preparing, signing, and publishing your application. 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 -

          Android Market In-app Billing is an Android Market service that lets you sell digital content in +

          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.

          -

          When you use Android Market's in-app billing service to sell an item, Android Market handles all +

          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%).

          -

          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 +

          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.

          @@ -59,11 +59,11 @@ obfuscate the sample code before you use it in a production application. For mor

          Figure 1. 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.

          -

          To learn more about Android Market's in-app billing service and start integrating it into your +

          To learn more about Google Play's in-app billing service and start integrating it into your applications, read the following documents:

          @@ -88,7 +88,7 @@ applications, read the following documents:

          Learn how to set up your product list, register test accounts, and handle refunds.
          In-app Billing Reference
          -
          Get detailed information about Android Market response codes and the in-app billing +
          Get detailed information about Google Play response codes and the in-app billing interface.
          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
          • Recommended for most apps that exceed the 50MB APK limit
          • You can provide up to 4GB of additional data for each APK
            • -
          • Android Market hosts and serves the expansion files at no charge
            • +
          • Google Play hosts and serves the expansion files at no charge
          • The files can be any file type you want and are saved to the device's shared storage
          @@ -61,28 +61,28 @@ APK Support -

          Android Market currently requires that your APK file be no more than 50MB. For most +

          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.

          -

          Android Market hosts the expansion files for your application and serves them to the device at +

          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.

          Overview

          -

          Each time you upload an APK using the Android Market Developer Console, you have the option to +

          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:

          @@ -102,7 +102,7 @@ release or as necessary.

          However, even if your application update requires only a new patch expansion file, you still must upload a new APK with an updated {@code -versionCode} in the manifest. (The Android Market +versionCode} in the manifest. (The Developer Console does not allow you to upload an expansion file to an existing APK.)

          Note: The patch expansion file is semantically the same as the @@ -115,7 +115,7 @@ yourself or be able to distinguish between the two files.

          File name format

          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:

          @@ -133,7 +133,7 @@ only one main file and one patch file for each APK.
 first associated (it matches the application's {@code android:versionCode}
 value).
-    
          "First" is emphasized because although the Android Market Developer Console allows you to
+    
          "First" is emphasized because although the Developer Console allows you to
 re-use an uploaded expansion file with a new APK, the expansion file's name does not change—it
 retains the version applied to it when you first uploaded the file.
          
   
          {@code <package-name>}
           
@@ -147,9 +147,9 @@ upload a main expansion file, the file is renamed to:
          
 
 
          Storage location
          
 
-
          When Android Market downloads your expansion files to a device, it saves them to the system's
+
          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.
          
 
 
          The specific location for your expansion files is:
          
@@ -194,27 +194,27 @@ compressed: 
          
 
 
          Download process
          
 
-
          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
+
          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.
          
+itself when the main activity starts, using a URL provided by Google Play.
          
 
 
          The download process from a high level looks like this:
          
 
 
            
-  
          1. User selects to install your app from Android Market.
            2. 
-  
          2. If Android Market is able to download the expansion files (which is the case for most
+  
          3. User selects to install your app from Google Play.
            4. 
+  
          4. If Google Play is able to download the expansion files (which is the case for most
 devices), it downloads them along with the APK.
-     
            If Android Market is unable to download the expansion files, it downloads the
+     
            If Google Play is unable to download the expansion files, it downloads the
 APK only.
            
   
            5. 
   
          5. When the user launches your application, your app must check whether the expansion files are
 already saved on the device.
     
              
       
            1. If yes, your app is ready to go.
              2. 
-      
            2. 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 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 Application Licensing 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 storage location.
              3. 
@@ -223,7 +223,7 @@ download the files and save them to the proper storag
 
            
 
 
            Caution: 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 Downloading the Expansion Files, 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 APK Expansion Z
 Library.
            
   
            6. 
   
          6. 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 Application Licensing service to request URLs
 for the expansion files, then download and save them.
     
            To greatly reduce the amount of code you must write and ensure a good user experience
@@ -280,15 +280,15 @@ Your Expansion Files.
            
 
            Rules and Limitations
            
 
 
            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:
            
 
 
              
   
            1. Each expansion file can be no more than 2GB.
              2. 
-  
            2. In order to download your expansion files from Android Market, the user must have
-acquired your application from Android Market. Android Market will not
+  
            3. In order to download your expansion files from Google Play, the user must have
+acquired your application from Google Play. Google Play will not
 provide the URLs for your expansion files if the application was installed by other means.
              4. 
-  
            4. When performing the download from within your application, the URL that Android Market
+  
            5. 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.
              6. 
   
            6. If you update your application with a new APK or upload ).
              7. 
 directory              . If you must unpack some data, save it into the location specified by {@link
 android.content.Context#getExternalFilesDir getExternalFilesDir()}.
   
            7. Do not delete or rename the {@code .obb} expansion file (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.
              8. 
   
            8. When updating an expansion file manually, you must delete the previous expansion file.
              9. 
 
            
@@ -328,11 +328,11 @@ download the expansion file.
            7. 
 
 
            Downloading the Expansion Files
            
 
-
            In most cases, Android Market downloads and saves your expansion files to the device at the same
+
            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 Application Licensing service.
            
 
 
            The basic logic you need to download your expansion files is the following:
            
@@ -345,15 +345,15 @@ href="#StorageLocation">shared storage location (in the
       
          7. If the expansion files are there, you're all set and your application can continue.
            8. 
       
          8. If the expansion files are not there:
         
              
-          
            1. Perform a request using Android Market's Perform a request using Google Play's Application Licensing to get your
 app's expansion file names, sizes, and URLs.
              2.  
-          
            2. Use the URLs provided by Android Market to download the expansion files and save
+          
            3. Use the URLs provided by Google Play to download the expansion files and save
 the expansion files. You must save the files to the shared storage location
 (Android/obb/<package-name>/) and use the exact file name provided
-by Android Market's response.
-            
              Note: The URL that Android Market provides for your
+by Google Play's response.
+            
              Note: 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.
              
           
              4. 
@@ -368,16 +368,16 @@ your application.
              
 href="{@docRoot}guide/market/licensing/index.html">Application Licensing service. It's primarily
 designed for you to enforce
 licensing policies for your application and ensure that the user has the right to
-use your app (he or she rightfully paid for it on Android Market). In order to facilitate the
+use your app (he or she rightfully paid for it on Google Play). In order to facilitate the
 expansion file functionality, the licensing service has been enhanced to provide a response
 to your application that includes the URL of your application's expansion files that are hosted
-on Android Market. So, even if your application is free for users, you need to include the Android
-Market License Verification Library (LVL) to use APK expansion files. Of course, if your application
+on Google Play. So, even if your application is free for users, you need to include the
+License Verification Library (LVL) to use APK expansion files. Of course, if your application
 is free, you don't need to enforce license verification—you simply need the
 library to perform the request that returns the URL of your expansion files.
              
 
-
              Note: Whether your application is free or not, Android Market
-returns the expansion file URLs only if the user acquired your application from Android Market.
              
+
              Note: Whether your application is free or not, Google Play
+returns the expansion file URLs only if the user acquired your application from Google Play.
              
 
 
              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 and choose the library from the {@code <sdk>/extras/google/} directory
 ({@code market_licensing/} for the License Verification Library or {@code
 market_apk_expansion/downloader_library/} for the Downloader Library).
-      
            4. Specify a Project Name such as "Android Market License Library" and "Market
+      
            5. Specify a Project Name such as "Google Play License Library" and "Google Play
 Downloader
 Library"
              6. 
       
            6. Click Finish.
              7. 
@@ -495,7 +495,7 @@ android update project --path ~/Android/MyApp \
 
 
              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.
              
 
@@ -518,10 +518,10 @@ are:
              
 
 
               <manifest ...>
-    <!-- Required to access Android Market Licensing -->
+    <!-- Required to access Google Play Licensing -->
     <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
 
-    <!-- Required to download files from Android Market -->
+    <!-- Required to download files from Google Play -->
     <uses-permission android:name="android.permission.INTERNET" />
 
     <!-- Required to keep CPU alive while downloading files (NOT to keep screen awake) -->
@@ -570,7 +570,7 @@ DownloaderService} class and override three methods to provide specific applicat
 
              
   
              {@code getPublicKey()}
              
     
              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 Setting Up for Licensing).
              
   
              {@code getSALT()}
              
     
              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).
              
 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 {
 
              
 
 
              Notice: 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.
              
 
 
              Remember to declare the service in your manifest file:
              
@@ -899,11 +899,11 @@ mRemoteService.setDownloadFlags(IDownloaderService.FLAGS_DOWNLOAD_OVER_CELLULAR)
 
 
              Using APKExpansionPolicy
              
 
-
              If you decide to build your own downloader service instead of using the Android Market
+
              If you decide to build your own downloader service instead of using the Google Play
 Downloader Library, 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.
              
 
 
              Note: If you do use the 
 
 
              Testing file reads
              
 
-
              Before you upload your application to Android Market, you
+
              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:
              
 
 
                
-  
              1. On your device, create the appropriate directory on the shared storage where Android
-Market will save your files.
+  
              2. On your device, create the appropriate directory on the shared storage where Google
+Play will save your files.
   
                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.)
                
   
                3. 
   
              3. Manually add the expansion files to that directory. Be sure that you rename your files to
-match the file name format that Android Market will use.
+match the file name format that Google Play will use.
   
                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:
                
@@ -1166,7 +1166,7 @@ The version code can be whatever value you want. Just remember:
                
     
              4. The main expansion file always starts with {@code main} and the patch file starts with
 {@code patch}.
                5. 
     
              5. The package name always matches that of the APK to which the file is attached on
-Android Market.
+Google Play.
   
   
                6. 
   
              6. 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).
                7. 
 
                Here are some reminders about handling the expansion files:
                
 
                  
   
                • Do not delete or rename 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.
                  • 
   
                • Do not save other data into your obb/
 directory. 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.
                  
 
 
                  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:
                  
 
 
                    
-  
                  1. Upload your APK and corresponding expansion files using the Android Market Developer
+  
                  2. Upload your APK and corresponding expansion files using the Google Play Developer
 Console.
                    3. 
   
                  3. Fill in the necessary application details (title, screenshots, etc.). You can come back and
 finalize these details before publishing your application.
   
                    Click the Save button. Do not click Publish. 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.
                    4. 
   
                  4. Install the application on your test device using the Eclipse tools or {@code adb}.
                    5. 
@@ -1216,14 +1216,14 @@ files as soon as the main activity starts.
                    
 
 
                    Updating Your Application
                    
 
-
                    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
+
                    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.
                    
 
 
                    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.
                    
 
 
                    If you use ZIP files as your expansion files, the APK Expansion Zip
@@ -1232,13 +1232,13 @@ your
 patch file with the main expansion file.
                    
 
 
                    Note: 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 {@code versionCode} in the
 manifest.
                    
 
 
                    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).
                    
 
@@ -1246,7 +1246,7 @@ expansion file (retaining the previous main expansion file).
                    
 
 
                      
   
                    • 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).
                      • 
   
                    • 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.
                      
 
 
                      Adding the Licensing Permission
                      
 
-
                      To use the Android Market application for sending a license check to the
+
                      To use the Google Play application for sending a license check to the
 server, your application must request the proper permission,
 com.android.vending.CHECK_LICENSE. 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">
                      
 
                      <?xml version="1.0" encoding="utf-8"?>
 
 <manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
-    <!-- Devices >= 3 have version of Android Market that supports licensing. -->
+    <!-- Devices >= 3 have version of Google Play that supports licensing. -->
     <uses-sdk android:minSdkVersion="3" />
     <!-- Required permission to check licensing. -->
     <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
@@ -123,7 +123,7 @@ application's manifest. 
                      
 
                      ServerManagedPolicy
                      
 
 
                      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. 
                      
 
 
                      Use of ServerManagedPolicy as the basis for your
@@ -133,7 +133,7 @@ href="#ServerManagedPolicy">ServerManagedPolicy section, below.
                      
 
 
 
-
                      Android Market licensing service does not itself determine whether a
+
                      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.
                      
@@ -227,7 +227,7 @@ extra is highly recommended. See Server Response Extras
 for more information.
                      • 
 
                    • 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.
                      • 
 
                    • 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.
                      
 
                      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.
                      
 
 
                      For convenience, best performance, and the benefit of using license settings
-from the Android Market server, using ServerManagedPolicy as your
+from the Google Play server, using ServerManagedPolicy as your
 licensing {@code Policy} is strongly recommended. 
                      
 
 
                      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
 
 
                      Before requesting new permissions for the sole purpose 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 <uses-feature>).
                      
 
@@ -647,11 +647,11 @@ have determined the exact behaviors you want, you can add more complex handling.
 
                    • Display a "Try again" dialog to the user, including a button to initiate a
 new license check if the reason supplied is {@code Policy.RETRY}. 
                      • 
 
                    • 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 Using Intents to
-Launch the Market Application on a Device. 
                      • 
+href="{@docRoot}guide/publishing/publishing.html#marketintent">Linking to your apps
+on Google Play. 
 
                    • Display a Toast notification that indicates that the features of the
 application are limited because it is not licensed. 
                      • 
 
                    
@@ -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 dontAllow().
                    
 
                    Create a Handler for posting from LicenseCheckerCallback
 to the UI thread
                    
 
-
                    During a license check, the LVL passes the request to the Android Market
+
                    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.
                    
 
 
                    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. 
                    
 
@@ -858,14 +858,14 @@ sample application calls checkAccess() from a
 
 
                    Embed your public key for licensing
                    
 
-
                    For each publisher account, the Android Market service automatically
+
                    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 not the same as
 the key that you use to sign your applications (or derived from it).
                    
 
-
                    The Android Market publisher site exposes the public key for licensing to any
+
                    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:
                    
 
 
                      
-
                    1. Go to the Android Market publisher site and sign in.
+
                    2. Go to the Google Play publisher site 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). 
                      3. 
 
                    3. In the account home page, locate the "Edit profile" link and click it. 
                      4. 
@@ -907,7 +907,7 @@ to close IPC connections
 {@link android.content.Context} changes, add a call to the {@code LicenseChecker}'s
 onDestroy() 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.
                      
 
@@ -992,13 +992,13 @@ and then recompile it.
                      
 
                      Several obfuscator programs are available for Android applications, including
 ProGuard, which also offers
 code-optimization features. The use of ProGuard or a similar program to obfuscate
-your code is strongly recommended for all applications that use Android
-Market Licensing. 
                      
+your code is strongly recommended for all applications that use Google
+Play Licensing. 
                      
 
 
                      Publishing a Licensed Application
                      
 
 
                      When you are finished testing your license implementation, you are ready to
-publish the application on Android Market. Follow the normal steps to prepare, sign, and then publish the application.
@@ -1021,7 +1021,7 @@ table below. By directing your queries to the correct forum, you can get the
 support you need more quickly. 
                      
 
 
                      Table 2. Developer support resources
-for Android Market Licensing Service.
                      
+for Google Play Licensing Service.
          RESULT_BILLING_UNAVAILABLE 3 Indicates that in-app billing is not available because the API_VERSION 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).
          RESULT_ITEM_UNAVAILABLE 4Indicates that Android Market cannot find the requested item in the application's product + 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 REQUEST_PURCHASE request or if an item is unpublished in the application's product list.
          int 1 YesThe version of Android Market's in-app billing service you are using. The current version is + The version of Google Play's in-app billing service you are using. The current version is 1.
          Any valid product identifier. Required for REQUEST_PURCHASE requests. 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.
          NONCEA number used once. Your application must generate and send a nonce with each GET_PURCHASE_INFORMATION and RESTORE_TRANSACTIONS request. The nonce is returned with the PURCHASE_STATE_CHANGED broadcast intent, so you can use this value - to verify the integrity of transaction responses form Android Market.
          NOTIFY_IDS
          nonce A number used once. Your application generates the nonce and sends it with the - GET_PURCHASE_INFORMATION request. Android Market sends the nonce back as part of the + GET_PURCHASE_INFORMATION request. Google Play sends the nonce back as part of the JSON string so you can verify the integrity of the message.
          notificationId A unique identifier that is sent with an IN_APP_NOTIFY broadcast intent. Each notificationId corresponds to a specify message that is waiting to be retrieved on - the Android Market server. Your application sends back the notificationId with the - GET_PURCHASE_INFORMATION message so Android Market can determine which messages you + the Google Play server. Your application sends back the notificationId with the + GET_PURCHASE_INFORMATION message so Google Play can determine which messages you are retrieving.
          productId 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.
          purchaseTime
          @@ -1045,8 +1045,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co - + 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 -

          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 +

          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.

          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.

          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 .apk file and uses it to verify the licensing status response.

          -

          Any application that you publish through Android Market can use the Android Market Licensing +

          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.

          -

          Note: The Android Market Licensing service is primarily intended +

          Note: 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 APK Expansion Files.

          -

          To learn more about Android Market's application licensing service and start integrating it into +

          To learn more about Google Play's application licensing service and start integrating it into your applications, read the following documents:

          @@ -44,7 +44,7 @@ Overview like.
          Setting Up for Licensing
          -
          Explains how to set up your Android Market account, development environment, and +
          Explains how to set up your Google Play account, development environment, and testing environment in order to add licensing to your app.
          Adding Licensing to Your App
          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.
          +Google Play client. @@ -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.

          Table 2. Summary of response codes -returned by the Android Market server in a license response.

          +returned by the Google Play server in a license response.

          Accounts, publishing, and deployment issuesAndroid -Market Help ForumGoogle Play +Help Forum Publisher accounts, licensing key pair, test accounts, server responses, test responses, application deployment and results
          ILicensingService One-way IPC interface over which a license check request is passed to the -Android Market client.
          ILicenseResultListener
          @@ -178,7 +178,7 @@ until upgrade.

           - @@ -217,12 +217,12 @@ application. +Google Play. @@ -233,7 +233,7 @@ implementation.

          href="{@docRoot}guide/market/licensing/setting-up.html#test-env"> Setting Up The Testing Environment, 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.

          Additionally, as noted above, applications that are in draft mode (in other words, applications that have been uploaded but have never been @@ -263,7 +263,7 @@ implementation and an illustration of how to obtain, store, and use the settings.

          Table 3. 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.

          {@code ERROR_CONTACTING_SERVER}Local error — the Android Market application was not able to reach the +Local error — the Google Play application was not able to reach the licensing server, possibly because of network availability problems. No
          {@code ERROR_NOT_MARKET_MANAGED} Server error — the application (package name) was not recognized by -Android Market. No Do not retry the license check.

          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.
          @@ -329,7 +329,7 @@ storage location before downloading.

          License validity period

          -

          The Android Market licensing server sets a license validity period for all +

          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.

          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:

          @@ -381,15 +381,15 @@ the application.

          In some cases, system or network conditions can prevent an application's license check from reaching the licensing server, or prevent the server's -response from reaching the Android Market client application. For example, the +response from reaching the Google Play client application. For example, the user might launch an application when there is no cell network or data connection available—such as when on an airplane—or when the network connection is unstable or the cell signal is weak.

          -

          When network problems prevent or interrupt a license check, the Android -Market client notifies the application by returning a {@code RETRY} response code to +

          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 processServerResponse() 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 processServerResonse() method with a {@code RETRY} response code.

          @@ -397,7 +397,7 @@ Policy processServerResonse() method with a {@code RETRY} response

          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. -

          The Android Market server helps an application to manage licensing under +

          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}.

          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

          Quickview

            -
          • Licensing allows you to verify your app was purchased from Android Market
            • +
          • Licensing allows you to verify your app was purchased from Google Play
          • Your app maintains control of how it enforces its licensing status
            • -
          • The service is free for all developers who publish on Android Market
            • +
          • The service is free for all developers who publish on Google Play

          In this document

          @@ -26,19 +26,19 @@ parent.link=index.html -

          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 +

          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.

          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.

          -

          Note: If a paid application has been uploaded to Android Market but +

          Note: 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.

          Figure 1. Your application initiates a -license check through the License Verification Library and the Android Market -client, which handles communication with the Market server.

          +license check through the License Verification Library and the Google Play +client, which handles communication with the Google Play server.

          To properly identify the user and determine the license status, the licensing server requires -information about the application and user—your application and the Android Market client work -together to assemble the information and the Android Market client passes it to the server.

          +information about the application and user—your application and the Google Play client work +together to assemble the information and the Google Play client passes it to the server.

          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.

          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:

          • 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.
            • -
          • The Android Market client collects the necessary information about the user and the device, +
          • 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.
            • -
          • The Android Market server evaluates the request using all available information, attempting +
          • 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.
          @@ -97,7 +97,7 @@ network connections or use any licensing related APIs in the Android platform.License Responses are Secure

          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.

          The licensing service generates a single licensing key pair for each @@ -120,7 +120,7 @@ tampered with or that are spoofed.

          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:

          @@ -179,17 +179,17 @@ physical device.

          Requirements and Limitations

          -

          Android Market Licensing is designed to let you apply license controls to -applications that you publish through Android Market. The service is not +

          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.

          +through Google Play or that are run on devices that do not offer the Google +Play client.

          Here are some points to keep in mind as you implement licensing in your application:

            -
          • An application can use the service only if the Android Market client is +
          • 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.
          • 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.
          • Adding licensing to an application does not affect the way the application -functions when run on a device that does not offer Android Market.
            • +functions when run on a device that does not offer Google Play.
          • You can implement licensing controls for a free app, but only if you're using the service to provide APK expansion files.
            • @@ -212,20 +212,20 @@ href="{@docRoot}guide/market/expansion-files.html">APK expansion files.

            Replacement for Copy Protection

            -

            Android Market Licensing is a flexible, secure mechanism for controlling +

            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.

              -
            • A limitation of the legacy Copy Protection mechanism on Android Market is +
            • 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.
              • -
            • With Android Market licensing, you can move to a license-based model in +
            • 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.
            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 -

            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 +

            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.

            Setting Up a Publisher Account

            -

            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:

            +

            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:

            http://market.android.com/publish +href="http://play.google.com/apps/publish">http://play.google.com/apps/publish

            For more information, see Publishing on Android Market.

            +href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play.

            -

            If you already have a publisher account on Android Market, use your existing +

            If you already have a publisher account on Google Play, use your existing account to set up licensing.

            -

            Using your publisher account on Android Market, you can:

            +

            Using your publisher account on Google Play, you can:

            • Obtain a public key for licensing
              • @@ -63,7 +63,7 @@ publishing the application

              Administrative settings for licensing

              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:

              @@ -114,17 +114,17 @@ checking and enforcement.

              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.

              There are two types of runtime environment that you can use:

                -
              • An Android-powered device that includes the Android Market application, or
                • +
              • An Android-powered device that includes the Google Play application, or
              • An Android emulator running the Google APIs Add-on, API level 8 (release 2) or higher
              @@ -137,12 +137,12 @@ debugging and testing licensing, the device must:

              • Run a compatible version of Android 1.5 or later (API level 3 or higher) platform, and
                • -
              • Run a system image on which the Android Market client application +
              • Run a system image on which the Google Play client application is preinstalled.
              -

              If Android Market is not preinstalled in the system image, your application won't -be able to communicate with the Android Market licensing server.

              +

              If Google Play is not preinstalled in the system image, your application won't +be able to communicate with the Google Play licensing server.

              For general information about how to set up a device for use in developing Android applications, see Using Hardware Devices.

              licensing.

              Because the Android platforms provided in the Android SDK do -not include Android Market, you need to download the Google APIs Add-On +not 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.

              -

              The Google APIs Add-On does not include the full Android Market client. +

              The Google APIs Add-On does not include the full Google Play client. However, it does provide:

                -
              • An Android Market background service that implements the +
              • An Google Play background service that implements the ILicensingService remote interface, so that your application can send license checks over the network to the licensing server.
              • 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, below.

              Several versions of the add-on are available through the SDK Manager, but only -Google APIs Add-On, API 8 (release 2) or higher includes the necessary Android -Market services.

              +Google APIs Add-On, API 8 (release 2) or higher includes the necessary Google +Play services.

              @@ -256,11 +256,11 @@ classes to check and enforce licensing.

              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 Install Selected to begin the download.

              -

              Figure 3. The Market Licensing package contains the LVL and +

              Figure 3. The Licensing package contains the LVL and the LVL sample application.

              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.

              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.

              @@ -438,7 +438,7 @@ Setting up a Library Project.

              Setting Up the Testing Environment

              -

              The Android Market publisher site provides configuration tools that let you +

              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.

            • 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).
              • -
            • A runtime environment for the application that includes the Android Market +
            • 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.
            @@ -472,7 +472,7 @@ publisher account or one of the test accounts.

            Setting test responses for license checks

            -

            Android Market provides a configuration setting in your publisher account +

            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 only to license checks for applications that you have uploaded, made by @@ -522,7 +522,7 @@ test responses available and their meanings.

            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 test accounts — accounts that are authorized to query the licensing server and receive static test responses from your publisher account.

            @@ -632,11 +632,11 @@ directly.

            environment

            The licensing service is designed to determine whether a given user is -licensed to use a given application — during a license check, the Android -Market application gathers the user ID from the primary account on the system +licensed to use a given application — during a license check, the Google +Play application gathers the user ID from the primary account on the system and sends it to the server, together with the package name of the application and other information. However, if there is no user information available, the -license check cannot succeed, so the Android Market application terminates the +license check cannot succeed, so the Google Play application terminates the request and returns an error to the application.

            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

            See also

              -
            1. Market Filters
              2. +
            2. Filters on Google Play
            3. Supporting Multiple Screens
            4. Compatibility Package
              5. @@ -55,10 +55,10 @@ Package -

              Multiple APK support is a feature in Android Market that allows you to publish different APKs +

              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.

              @@ -73,8 +73,8 @@ prevent a single APK from working on all devices.

              Although we encourage you to develop and publish a single APK that supports as many device configurations as possible, doing so is sometimes not possible. To help -you publish your application for as many devices as possible, Android Market allows you to -publish multiple APKs under the same application listing. Android Market then supplies 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.

              @@ -86,7 +86,7 @@ APK.

            5. Support different platform versions with each APK.
          -

          Currently, these are the only device characteristics that Android Market supports for publishing +

          Currently, these are the only device characteristics that Google Play supports for publishing multiple APKs as the same application.

          Note: You should generally use multiple APKs to support @@ -100,8 +100,8 @@ consider your options before publishing multiple APKs.

          Publishing Concepts

          -

          Before you start publishing multiple APKs on Android Market, you must understand a few -concepts regarding how the Android Market publisher site works.

          +

          Before you start publishing multiple APKs on Google Play, you must understand a few +concepts regarding how the Google Play publisher site works.

          Active APKs

          @@ -111,20 +111,20 @@ concepts regarding how the Android Market publisher site works.

          When editing your application, there are two buttons on the top-right side of the page. The first button is either Publish or Unpublish and the second button is always Save (but its behavior changes).

          -

          When your application is new or you have unpublished it from Market, the first +

          When your application is new or you have unpublished it from Google Play, the first button says Publish. 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 Save will save any changes you've made, such as information added to the Product details and APKs you've uploaded, but nothing is made visible on -Android Market—this allows you to save your changes and sign out of the publisher site before +Google Play—this allows you to save your changes and sign out of the publisher site before deciding to publish.

          Once you've published your application, the first button changes to Unpublish. 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 Save button is different. In this state, clicking Save 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 Save makes all those changes live on Android Market.

          +APKs, clicking Save makes all those changes live on Google Play.

          @@ -135,14 +135,14 @@ moves into the list of Active APKs. This list allows you to preview whi you're about to publish.

          If there are no errors, any "active" APK will be published to -Android Market when you click the Publish button (if the application is +Google Play when you click the Publish button (if the application is unpublished) or when you click the Save button (if the application is already published).

          Simple mode and advanced mode

          -

          The Android Market publisher site provides two modes for managing the APKs associated with +

          The Google Play publisher site provides two modes for managing the APKs associated with your application: simple mode and advanced mode. You can switch between these by clicking the link at the top-right corner of the APK files tab.

          @@ -164,21 +164,21 @@ below.

          How Multiple APKs Work

          -

          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 +

          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:

          • You maintain only one set of product details (app description, icons, screenshots, etc.). This also means you cannot charge a different price for different APKs.
            • -
          • All users see only one version of your application on Android Market, so they are not +
          • 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."
          • All user reviews are applied to the same application listing, even though users on different devices may have different APKs.
          • 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).
          @@ -192,8 +192,8 @@ following sections describe more about how it works.

          Supported filters

          Which devices receive each APK is determined by Android Market filters 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 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:

          @@ -229,7 +229,7 @@ with a single APK.

          href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>} 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 {@code android:minSdkVersion} or {@code @@ -266,7 +266,7 @@ with a higher {@code android:versionCode} 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 Rules for multiple APKs. @@ -286,8 +286,8 @@ higher, as per the previous note).

          Other manifest elements that enable Android Market filters—but are not -listed above—are still applied for each APK as usual. However, Android Market does not allow +href="{@docRoot}guide/appendix/market-filters.html">Google Play filters—but are not +listed above—are still applied for each APK as usual. However, Google Play does not allow you to publish multiple APKs based on variations of them. Thus, you cannot publish multiple APKs if the above listed filters are the same for each APK (but the APKs differ based on other characteristics in the manifest file). For @@ -312,7 +312,7 @@ android:versionCode} attribute.

        16. Each APK must not exactly match the configuration support of another APK.

          That is, each APK must declare slightly different support for at least one of -the supported Market filters (listed above).

          +the supported Google Play filters (listed above).

          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.

        17. An APK that requires a higher API level must have a higher version code.

          This is true only when either: the APKs differ based only on the -supported API levels (no other supported market filters +supported API levels (no other supported filters distinguish the APKs from each other) or when the APKs do use another supported filter, but there is an overlap between the APKs within that filter.

          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.

          @@ -365,7 +365,7 @@ increase from the lower API level to the higher API level.
          18. -

          Failure to abide by the above rules results in an error on the Android Market publisher site +

          Failure to abide by the above rules results in an error on the Google Play publisher site when you activate your APKs—you will be unable to publish your application until you resolve the error.

          @@ -377,7 +377,7 @@ in warnings rather than errors. Warnings can be caused by the following:

          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.
        18. 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 {@code android:versionName}), so that it's easy for you to associate the version code and version name.

          -

          Note: 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 +

          Note: 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.

          @@ -507,7 +507,7 @@ configuration support for one or several of the APKs.

          Using a Single APK Instead

          Creating multiple APKs for your application is not the normal procedure 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.

          @@ -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.)

          19. @@ -586,7 +586,7 @@ public void onSurfaceChanged(GL10 gl, int w, int h) {

          Supporting multiple screens

          -

          Unless your APK file exceeds the Android Market size limit of 50MB, supporting multiple screens +

          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.

          diff --git a/docs/html/guide/practices/compatibility.jd b/docs/html/guide/practices/compatibility.jd index bb7a72e..5e514c4 100644 --- a/docs/html/guide/practices/compatibility.jd +++ b/docs/html/guide/practices/compatibility.jd @@ -7,7 +7,7 @@ page.title=Android Compatibility

          See also

          1. Market Filters
            2. +href="{@docRoot}guide/appendix/market-filters.html">Filtering on Google Play
          2. Providing Alternative Resources
          3. your apps to do that, while at the same time letting you maintain control of what types of devices your app is available to. With a bit of forethought and some minor changes in your app's manifest file, you can ensure that users -whose devices can’t run your app will never see it in the Android Market, and +whose devices can’t run your app will never see it on Google Play, and will not get in trouble by downloading it. This page explains how you can control which devices have access to your apps, and how to prepare your apps to make sure they reach the right audience.

            @@ -64,7 +64,7 @@ every class and every API for that API level.

            corresponding hardware or feature. But that’s not a problem: we also designed Android to prevent apps from being visible to devices which don’t have features the apps require. We’ve built support for this right into the SDK tools, and -it’s part of the Android platform itself, as well as Android Market.

            +it’s part of the Android platform itself, as well as part of Google Play.

            As a developer, you have complete control of how and where your apps are available. Android provides tools as a first-class part of the platform that let @@ -79,9 +79,9 @@ only the devices capable of running them.

          4. You state the features your app requires by declaring <uses-feature> elements its manifest file.
            5. -
          5. Devices are required to declare the features they include to Android -Market.
            6. -
          6. Android Market uses your app’s stated requirements to filter it from devices +
          7. Devices are required to declare the features they include to Google +Play.
            8. +
          8. Google Play uses your app’s stated requirements to filter it from devices that don’t meet those requirements.
          @@ -103,24 +103,24 @@ instead use the fine-grained controls Android provides.

          - -

          Filtering on Android Market

          + +

          Filtering on Google Play

          -

          Android Market filters the applications that are visible to users, so +

          Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with their devices.

          -

          One of the ways Market filters applications is by -feature compatibility. To do this, Market checks the +

          One of the ways Google Play filters applications is by +feature compatibility. To do this, Google Play checks the <uses-feature> elements in each application's manifest, to -establish the app's feature needs. Market then shows or hides the application to +establish the app's feature needs. Google Play then shows or hides the application to each user, based on a comparison with the features available on the user's device.

          For information about other filters that you can use to control the availability of your apps, see the -Market -Filters document.

          +Filters on Google Play +document.

          @@ -142,8 +142,8 @@ future versions, new feature IDs will be added as well.

          When you write your application, you specify which features your app requires by listing their feature IDs in <uses-feature> elements in -the AndroidManifest.xml file. This is the information that Android -Market uses to match your app to devices that can run it. For instance, if you +the AndroidManifest.xml file. This is the information that Google +Play uses to match your app to devices that can run it. For instance, if you state that your app requires android.software.live_wallpapers, it won’t be shown to devices that don’t support Live Wallpapers.

          @@ -170,12 +170,12 @@ audience size and minimizing development costs.

          business or legal reasons. For instance, an app that displays train schedules for the London Underground is unlikely to be useful to users outside the United Kingdom. Other apps might not be permitted in certain countries for business or -legal reasons. For cases such as these, Android Market itself provides +legal reasons. For cases such as these, Google Play itself provides developers with filtering options that allow them control their app’s availability for non-technical reasons.

          -

          The help information for Android Market provides full details, but in a -nutshell, developers can use the Market publisher UI to:

          +

          The help information for Google Play provides full details, but in a +nutshell, developers can use the Google Play publisher UI to:

          • List the countries an app is available in.
            • @@ -185,7 +185,7 @@ nutshell, developers can use the Market publisher UI to:

            Filtering for technical compatibility (such as required hardware components) is always based on information contained within your .apk file. But filtering for non-technical reasons (such as geographic restrictions) is always -handled in the Market user interface.

            +handled in the Google Play user interface.

            Future-proofing

            @@ -206,7 +206,7 @@ capability, though a (fixed-focus) camera was still required. Some apps such as barcode scanners do not function as well with cameras that do not auto-focus. To prevent users from having a bad experience with those apps, existing apps that obtain permission to use the Camera were assumed by default to require -auto-focus. This allowed Android Market to filter those apps from devices that +auto-focus. This allowed Google Play to filter those apps from devices that lack auto-focus.
          • Android 2.2, meanwhile, allowed the microphone to be optional on some diff --git a/docs/html/guide/practices/design/accessibility.jd b/docs/html/guide/practices/design/accessibility.jd index a66a974..72da04e 100644 --- a/docs/html/guide/practices/design/accessibility.jd +++ b/docs/html/guide/practices/design/accessibility.jd @@ -332,11 +332,10 @@ public boolean dispatchPopulateAccessibilityEvent(final AccessibilityEvent event

            You can simulate the experience for many users by enabling an accessibility service that speaks as you move around the screen. One such service is TalkBack, by the +href="https://play.google.com/store/details?id=com.google.android.marvin.talkback">TalkBack, by the Eyes-Free Project. It comes preinstalled on many -Android-powered devices, but is also available for free from Android -Market.

            +Android-powered devices, but is also available for free from the Google Play store.

            This service requires that you have a text-to-speech engine installed on your phone. You can verify if you have one installed in the Text-to-speech settings menu by selecting diff --git a/docs/html/guide/practices/optimizing-for-3.0.jd b/docs/html/guide/practices/optimizing-for-3.0.jd index 39662f1..140c50c 100644 --- a/docs/html/guide/practices/optimizing-for-3.0.jd +++ b/docs/html/guide/practices/optimizing-for-3.0.jd @@ -481,7 +481,7 @@ and densities.

            configurations of screen size and density, you can instead choose to limit the distribution of your application to certain types of screens, such as only tablets or only mobile devices. To do so, you can add elements to your Android manifest file that enable filtering based on screen configuration -by external services such as Android Market.

            +by external services such as Google Play.

            However, before you decide to restrict your application to certain screen configurations, you should understand the techniques for </manifest> -

            External services such as Android Market read this manifest element and use it to ensure that +

            External services such as Google Play read this manifest element and use it to ensure that your application is available only to devices with an extra large screen.

            Note: If you use the {@code <supports-screens>} element for the reverse scenario (when your application is not compatible with larger screens) and set the larger screen size attributes to {@code "false"}, then -external services such as Android Market do not apply filtering. Your application +external services such as Google Play do not apply filtering. Your application will still be available to larger screens, but when it runs, it will not fill the screen—the system will draw it in a "postage stamp" window that's the same relative size as the screen size that your application does support. If you want to prevent your application from being downloaded on @@ -541,7 +541,7 @@ larger devices to download the version designed for smaller screens. In such a c use the {@code <compatible-screens>} element to manage the distribution of your application based on the combination of screen size and density. External services such as -Android Market uses this information to apply filtering to your application, so that only devices +Google Play uses this information to apply filtering to your application, so that only devices that have a screen configuration with which you declare compatibility can download your application.

            @@ -551,7 +551,7 @@ which each specify a screen configuration with which your application is compati the {@code android:screenSize} and {@code android:screenDensity} attributes. Each {@code <screen>} element must include both attributes to specify an individual screen configuration—if either attribute is missing, then the element is invalid -(external services such as Android Market will ignore it).

            +(external services such as Google Play will ignore it).

            For example, if your application is compatible with only small and normal screens, regardless of screen density, then you must specify eight different {@code <screen>} elements, @@ -613,7 +613,7 @@ orientation, you should update your application to support landscape.

          • Not all devices have telephony or other features

            If your application declares the {@code "android.hardware.telephony"} feature in the manifest, then it will not be available to devices that do not offer telephony (such as tablets), based on -Android Market filtering. If your application can function properly without telephony, you should +Google Play filtering. If your application can function properly without telephony, you should update your application to gracefully disable the telephony features when not available on a device.

          @@ -682,7 +682,7 @@ your applications. For example:

          <uses-feature android:name="android.hardware.telephony" />

          By default, this declares that your application requires telephony features. So, -external services such as Android Market use this information to filter your application from +external services such as Google Play use this information to filter your application from devices that do not offer telephony.

          If, however, your application uses, but does not require the feature, you should diff --git a/docs/html/guide/practices/screens-distribution.jd b/docs/html/guide/practices/screens-distribution.jd index 60c9c95..a7c4a8e 100644 --- a/docs/html/guide/practices/screens-distribution.jd +++ b/docs/html/guide/practices/screens-distribution.jd @@ -37,7 +37,7 @@ href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for And configurations of screen size and density, you can instead choose to limit the distribution of your application to certain types of screens, such as only tablets and other large devices or only handsets and similar-sized devices. To do so, you can enable filtering by external services such as -Android Market by adding elements to your manifest file that specify the screen configurations your +Google Play by adding elements to your manifest file that specify the screen configurations your application supports.

          However, before you decide to restrict your application to certain screen configurations, you @@ -58,7 +58,7 @@ might discover that your application can't scale up well or perhaps you've decid versions of your application for different screen configurations. In such a case, you can use the {@code <compatible-screens>} element to manage the distribution of your application based on -combinations of screen size and density. External services such as Android Market use this +combinations of screen size and density. External services such as Google Play use this information to apply filtering to your application, so that only devices that have a screen configuration with which you declare compatibility can download your application.

          @@ -68,7 +68,7 @@ configuration with which you declare compatibility can download your application compatible, using both the {@code android:screenSize} and {@code android:screenDensity} attributes. Each {@code <screen>} element must include both attributes to specify an individual screen configuration—if either attribute is missing, then the element is invalid -(external services such as Android Market will ignore it).

          +(external services such as Google Play will ignore it).

          For example, if your application is compatible with only small and normal size screens, regardless of screen density, you must specify eight different {@code <screen>} elements, @@ -173,7 +173,7 @@ Tools for Managing Screen Sizes.

          href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>} element for the reverse scenario (when your application is not compatible with larger screens) and set the larger screen size attributes to {@code "false"}, then -external services such as Android Market do not apply filtering. Your application +external services such as Google Play do not apply filtering. Your application will still be available to larger screens, but when it runs, it will not resize to fit the screen. Instead, the system will emulate a handset screen size (about 320dp x 480dp; see Screen Compatibility Mode for more @@ -197,13 +197,13 @@ configurations.

          Publishing Multiple APKs for Different Screens

          -

          Although we recommend that you publish one APK for your application, Android Market allows +

          Although we recommend that you publish one APK for your application, Google Play allows you to publish multiple APKs for the same application when each APK supports a different set of screen configurations (as declared in the manifest file). For example, if you want to publish both a handset version and a tablet version of your application, but you're unable to make the same APK work for both screen sizes, you can actually publish two APKs for the same application listing. Depending on each device's -screen configuration, Android Market will deliver it the APK that you've declared to support that +screen configuration, Google Play will deliver it the APK that you've declared to support that device's screen.

          Beware, however, that publishing multiple APKs for the same application is @@ -212,5 +212,5 @@ APK that can support a wide range of device configurations. Supporting sizes, especially, is within reason using a single APK, as long as you follow the guide to Supporting Multiple Screens.

          -

          If you need more information about how to publish multiple APKs on Android Market, read If you need more information about how to publish multiple APKs on Google Play, read Multiple APK Support.

          diff --git a/docs/html/guide/practices/screens_support.jd b/docs/html/guide/practices/screens_support.jd index fb121bd..29dff26 100644 --- a/docs/html/guide/practices/screens_support.jd +++ b/docs/html/guide/practices/screens_support.jd @@ -882,8 +882,8 @@ application requires is the smallest possible on any device.

          Caution: The Android system does not pay attention to this attribute, so it does not affect how your application behaves at runtime. Instead, it is used -to enable filtering for your application on services such as Android Market. However, -Android Market currently does not support this attribute for filtering (on Android +to enable filtering for your application on services such as Google Play. However, +Google Play currently does not support this attribute for filtering (on Android 3.2), so you should continue using the other size attributes if your application does not support small screens.

          diff --git a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd index 9be72ee..f8ca3f8 100644 --- a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd +++ b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd @@ -886,7 +886,7 @@ href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent Fi You can perform this test when initializing the user interface. For instance, you could disable the user control that initiates the Intent object, or display a message to the user that lets them go - to a location, such as the Market, to download its application. + to a location, such as Google Play, to download its application. In this way, your code can start the activity (using either startActivity() or startActivityForResult()) only if the intent has tested to resolve to an activity that is actually present. diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd index 6b686b1..4b6768f 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd @@ -49,9 +49,9 @@ across the range of devices on which your application can be installed. See Tips for Designers for suggestions on how to work with multiple sets of icons.

          -

          A high-resolution version of your application launcher icon is also required by Android Market +

          A high-resolution version of your application launcher icon is also required by Google Play for use in application listings. For more details on this, see Application Icons in Android Market below.

          +href="#icons_in_market">Application Icons on Google Play below.

          Note: @@ -81,7 +81,7 @@ need to review the old guidelines, see the

          1. Promote the brand and tell the story of the app.
            2. -
          2. Help users discover the app in Android Market.
            3. +
          3. Help users discover the app on Google Play.
          4. Function well in the Launcher.
          @@ -100,19 +100,19 @@ app is about. Thus, you should:

          -

          Help users discover the app in Android Market

          +

          Help users discover the app on Google Play

          -

          App launcher icons are the first look that prospective users will get of your app in Android -Market. A high quality app icon can influence users to find out more as they scroll through lists of +

          App launcher icons are the first look that prospective users will get of your app on Google Play. +A high quality app icon can influence users to find out more as they scroll through lists of applications.

          Quality matters here. A well-designed icon can be a strong signal that your app is of similarly high quality. Consider working with an icon designer to develop the app’s launcher icon.

          -

          Note: Android Market requires a high-resolution version of your -icon; for more details on this, see Application Icons in Android -Market below.

          +

          Note: Google Play requires a high-resolution version of your +icon; for more details on this, see Application Icons in Google +Play below.

          Function well in the Launcher

          @@ -239,21 +239,21 @@ This padding can also be used to make room for a subtle drop shadow, which can h that launcher icons are legible across on any background color.

          -

          Application Icons in Android Market

          +

          Application Icons on Google Play

          If you are publishing your application on -Android Market, you will also need to provide a 512 x 512 pixel, high-resolution application icon -in the developer console at upload time. This icon -will be used in various locations in Android Market and does not replace your launcher icon.

          +Google Play, you will also need to provide a 512 x 512 pixel, high-resolution application icon +in the developer console at upload time. This icon +will be used in various locations on Google Play and does not replace your launcher icon.

          For tips and recommendations on creating high-resolution launcher icons that can easily be scaled up to 512x512, see Tips for Designers.

          -

          For information and specifications about high-resolution application icons in Android Market, see +

          For information and specifications about high-resolution application icons on Google Play, see the following article:

          -Graphic Assets for your Application (Android Market Help) » +Graphic Assets for your Application (Google Play Help) »

          diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd index ea036cd..85a3cc8 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd @@ -56,13 +56,13 @@ suggestions on how to work with multiple sets of icons.

          -

          Application Icons in Android Market

          +

          Application Icons on Google Play

          If you are publishing -your application on Android Market, you will also need to provide a 512x512 +your application on Google Play, you will also need to provide a 512x512 pixel, high-resolution application icon in the developer console at upload-time. -This icon will be used in various locations in Android Market and does +href="http://play.google.com/apps/publish">developer console at upload-time. +This icon will be used in various locations on Google Play and does not replace your launcher icon.

          For tips and recommendations on creating high-resolution launcher icons that @@ -71,11 +71,11 @@ can easily be scaled up to 512x512, see Tips for Designers.

          For information and specifications about high-resolution application -icons in Android Market, see the following article:

          +icons on Google Play, see the following article:

          - Graphic Assets for your Application (Android Market Help) » + Graphic Assets for your Application (Google Play Help) » diff --git a/docs/html/guide/publishing/app-signing.jd b/docs/html/guide/publishing/app-signing.jd index 9abcdf7..e86ec30 100644 --- a/docs/html/guide/publishing/app-signing.jd +++ b/docs/html/guide/publishing/app-signing.jd @@ -82,7 +82,7 @@ run it or debug it on an emulator or device.

          use to build your application. There are two build modes: debug mode and release mode. You use debug mode when you are developing and testing your application. You use release mode when you want to build a release version of your application that you can -distribute directly to users or publish on an application marketplace such as Android Market.

          +distribute directly to users or publish on an application marketplace such as Google Play.

          When you build in debug mode the Android SDK build tools use the Keytool utility (included in the JDK) to create a debug key. Because the SDK build tools created the debug key, @@ -158,10 +158,10 @@ you should ensure that your key's validity period exceeds the expected lifespan of all versions of all of the applications, including dependent applications that may be added to the suite in the future. -

        19. If you plan to publish your application(s) on Android Market, the +
        20. If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period -ending after 22 October 2033. The Market server enforces this requirement -to ensure that users can seamlessly upgrade Market applications when +ending after 22 October 2033. Google Play enforces this requirement +to ensure that users can seamlessly upgrade applications when new versions are available.
          21. @@ -292,7 +292,7 @@ key is one that:

          with the application
        21. Has a validity period that exceeds the expected lifespan of the application or application suite. A validity period of more than 25 years is recommended. -

          If you plan to publish your application(s) on Android Market, note that a +

          If you plan to publish your application(s) on Google Play, note that a validity period ending after 22 October 2033 is a requirement. You can not upload an application if it is signed with a key whose validity expires before that date.

          22. diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd index c355479..fe56352 100644 --- a/docs/html/guide/publishing/preparing.jd +++ b/docs/html/guide/publishing/preparing.jd @@ -22,7 +22,7 @@ page.title=Preparing for Release
          1. Publishing Overview
          2. Signing Your Applications
            3. -
          3. Publishing on Android Market
            4. +
          4. Publishing on Google Play
          @@ -39,13 +39,13 @@ similar to the debug build process and can be done using JDK and Android SDK too tasks serve as a final check, ensuring that your application performs as expected under real-world conditions. When you are finished preparing your application for release you have a signed .apk file, which you can distribute directly to users or distribute through an -application marketplace such as Android Market.

          +application marketplace such as Google Play.

          This document summarizes the main tasks you need to perform to prepare your application for release. The tasks that are described in this document apply to all Android applications regardless -how they are released or distributed to users. If you are releasing your application through Android -Market, you should also read Publishing on -Android Market to be sure your release-ready application satisfies all Android Market +how they are released or distributed to users. If you are releasing your application through Google +Play, you should also read Publishing on +Google Play to be sure your release-ready application satisfies all Google Play requirements.

          Note: As a best practice, your application should meet all of your @@ -89,9 +89,9 @@ line.

          To prepare your application for release you typically perform five main tasks (see figure 2). Each main task may include one or more smaller tasks depending on how you are releasing your -application. For example, if you are releasing your application through Android Market you may want +application. For example, if you are releasing your application through Google Play you may want to add special filtering rules to your manifest while you are configuring your application for -release. Similarly, to meet Android Market publishing guidelines you may have to prepare screenshots +release. Similarly, to meet Google Play publishing guidelines you may have to prepare screenshots and create promotional text while you are gathering materials for release.

          You usually perform the tasks listed in figure 2 after you have throroughly debugged and tested @@ -137,9 +137,9 @@ key.

          href="{@docRoot}guide/practices/ui_guidelines/icon_design_launcher.html">icon guidelines. Your application's icon helps users identify your application on a device's Home screen and in the Launcher window. It also appears in Manage Applications, My Downloads, and -elsewhere. In addition, publishing services such as Android Market display your icon to users.

          +elsewhere. In addition, publishing services such as Google Play display your icon to users.

          -

          Note: If you are releasing your application on Android Market, you +

          Note: If you are releasing your application on Google Play, you need to create a high resolution version of your icon. See Graphic @@ -154,7 +154,7 @@ with your application.

          Miscellaneous Materials

          You might also have to prepare promotional and marketing materials to publicize your application. -For example, if you are releasing your application on Android Market you will need to prepare some +For example, if you are releasing your application on Google Play you will need to prepare some promotional text and you will need to create screenshots of your application. For more information, see @@ -242,11 +242,11 @@ tasks:

          There are several additional manifest elements that you can set if you are releasing your -application on Android Market. For example, the android:minSdkVersion and +application on Google Play. For example, the android:minSdkVersion and android:targetSdkVersion attributes, which are located in the <uses-sdk> element. For more -information about these and other Android Market settings, see Market Filters.

          +information about these and other Google Play settings, see Filters on Google Play.

          Address compatibility issues

          @@ -283,16 +283,15 @@ doing the following:

          If your application accesses remote servers or services, make sure you are using the production URL or path for the server or service and not a test URL or path.

          -

          Implement Licensing (if you are releasing on Android Market)

          +

          Implement Licensing (if you are releasing on Google Play)

          -

          If you are releasing a paid application through Android Market, consider adding support for -Android Market Licensing. Licensing lets you control access to your application based on whether the -current user has purchased it. Using Android Market Licensing is optional even if you are -releasing your app through Android Market.

          +

          If you are releasing a paid application through Google Play, consider adding support for +Google Play Licensing. Licensing lets you control access to your application based on whether the +current user has purchased it. Using Google Play Licensing is optional even if you are +releasing your app through Google Play.

          -

          For more information about Android Market Licensing Service and how to use it in your -application, see Application -Licensing.

          +

          For more information about Google Play Licensing Service and how to use it in your +application, see Application Licensing.

          Building Your Application for Release

          @@ -353,7 +352,7 @@ a summary of common Android situations that you should consider when you are tes done testing and you are satisfied that the release version of your application behaves correctly, you can release your application to users. For more information, see Releasing Your -Application to Users. If you are publishing your application on Android Market, see -Publishing on Android Market.

          +Application to Users. If you are publishing your application on Google Play, see +Publishing on Google Play.

          diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd index 27a87f9..952e602 100644 --- a/docs/html/guide/publishing/publishing.jd +++ b/docs/html/guide/publishing/publishing.jd @@ -1,4 +1,4 @@ -page.title=Publishing on Android Market +page.title=Publishing on Google Play @jd:body
          @@ -7,25 +7,25 @@ page.title=Publishing on Android Market

          Quickview

            -
          • Learn how to publish and update apps on Android Market.
            • -
          • Find out how to create links to apps that are published on Android Market.
            • -
          • Learn about Android Market features.
            • +
          • Learn how to publish and update apps on Google Play.
            • +
          • Find out how to create links to apps that are published on Google Play.
            • +
          • Learn about Google Play features.

          In this document

            -
          1. About Android Market -
          2. Publishing Apps on Android Market
            3. -
          3. Publishing Updates on Android Market
            4. -
          4. Using Android Market Licensing Service
            5. -
          5. Using Android Market In-app Billing
            6. -
          6. Linking to Your Apps on Android Market +
          7. About Google Play +
          8. Publishing Apps on Google Play
            9. +
          9. Publishing Updates on Google Play
            10. +
          10. Using Google Play Licensing Service
            11. +
          11. Using Google Play In-app Billing
            12. +
          12. Linking to Your Apps on Google Play
            1. Opening an app's details page
            2. Performing a search
              3. -
            3. Build an Android Market button
              4. +
            4. Build a Google Play button
            5. Summary of URI formats
            13. @@ -41,9 +41,9 @@ page.title=Publishing on Android Market
            - -

            Already know about Android Market and want to get started?

            -

            Go to Android Market, create a developer + +

            Already know about Google Play and want to get started?

            +

            Go to Google Play, create a developer account, and upload your application. For more information about required assets, listing details, and publishing options, see Upload @@ -55,78 +55,78 @@ Applications.

            One of the most effective ways to get your application into users' hands is to -publish it on an application marketplace like Android Market. Publishing on Android Market is a +publish it on an application marketplace like Google Play. Publishing on Google Play is a straightforward process that you can do in just a few simple steps—register, configure, upload, and publish. Registration takes only a few minutes and needs to be done only once. -The configuration and publishing steps can all be done through the Android Market Developer Console -after you register as an Android Market developer.

            +The configuration and publishing steps can all be done through the Google Play Android Developer Console +after you register as a Google Play developer.

            -

            To start publishing on Android Market, first read this topic and then go to the Android Market publisher site and register as -an Android Market developer.

            +

            To start publishing on Google Play, first read this topic and then go to the Google Play Android Developer Console and register as +a Google Play developer.

            -

            About Android Market

            +

            About Google Play

            -

            Android Market is a robust publishing platform that helps you publicize, sell, and distribute +

            Google Play is a robust publishing platform that helps you publicize, sell, and distribute your Android applications to users around the world. When you release your applications through -Android Market you have access to a suite of developer tools that let you analyze your sales, +Google Play you have access to a suite of developer tools that let you analyze your sales, identify market trends, and control who your applications are being distributed to. You also have access to several revenue-enhancing features, such as in-app billing and application licensing.

            -

            Before you can publish applications on Android Market, you need to register as an Android Market developer. During the +

            Before you can publish applications on Google Play, you need to register as a Google Play developer. During the registration process you will need to create a developer profile, pay a registration fee, and agree -to the Android Market -Developer Distribution Agreement. After you register you can access the Android Market Developer +to the Google Play +Developer Distribution Agreement. After you register you can access the Developer Console, where you can upload applications, configure publishing options, and monitor publishing data. If you want to sell your applications or use the in-app billing feature, you will also need to set up a Google Checkout merchant account. For more information about the registration process, see Developer Registration.

            -

            Publishing Apps on Android Market

            +

            Publishing Apps on Google Play

            -

            Publishing your application on Android Market is a simple process that involves three basic +

            Publishing your application on Google Play is a simple process that involves three basic tasks (see figure 1):

            • Creating various graphical assets that -accompany your app on Android Market.
              • -
            • Using the Android Market Developer Console to configure publishing options, -specify listing details, and upload your app and graphical assets to Android Market.
              • +accompany your app on Google Play. +
            • Using the Google Play Developer Console to configure publishing options, +specify listing details, and upload your app and graphical assets to Google Play.
            • Reviewing your publishing settings and changing the release status of your app from Unpublished to Published.
            Shows the three steps that are required to publish on Android Market

            - Figure 1. To publish apps on Android Market you must first Figure 1. To publish apps on Google Play you must first prepare your app for release and then perform three simple tasks.

            Important: You must prepare your application for release before you -can publish it on Android Market. When you prepare your application for release you configure it for +can publish it on Google Play. When you prepare your application for release you configure it for release and build it in release mode. Building in release mode signs your application's {@code .apk} -file with your private release key. You cannot publish an application on Android Market unless it is +file with your private release key. You cannot publish an application on Google Play unless it is signed with your own private release key.

            Preparing promotional materials

            -

            To fully leverage the marketing and publicity capabilities of Android Market, you need to create -several graphical assets that accompany your app on Android Market, such as screenshots, videos, +

            To fully leverage the marketing and publicity capabilities of Google Play, you need to create +several graphical assets that accompany your app on Google Play, such as screenshots, videos, promotional graphics, and promotional text. At a minimum you must provide two screenshots of your application and a high resolution application icon. The screenshots are displayed on the details -page for your application in Android Market, and the high resolution application icon is displayed -in various locations throughout Android Market. The high resolution icon does not replace the +page for your application on Google Play, and the high resolution application icon is displayed +in various locations throughout Google Play. The high resolution icon does not replace the launcher icon for your application, rather, it serves as a supplemental icon and should look the same as your launcher icon. Promotional video, graphics, and text are optional, although we strongly recommended that you prepare these for your @@ -136,8 +136,8 @@ Assets for your Application.

            Configuring options and uploading assets

            -

            Android Market lets you target your application to a worldwide pool of users and devices. To -reach these users you can use the Android Market Developer Console to configure various publishing +

            Google Play lets you target your application to a worldwide pool of users and devices. To +reach these users you can use the Developer Console to configure various publishing options and listing details for your app. For example, you can choose the countries you want to reach, the listing languages you want to use, and the @@ -155,11 +155,11 @@ href="http://grendel.sea.corp.google.com:48014/guide/market/billing/billing_admi app.

            When you are finished setting publishing options and listing details, you can upload your assets -and your application to Android Market. You can also upload your application as a draft +and your application to Google Play. You can also upload your application as a draft (unpublished) application, which lets you do final testing before you publish it for final release.

            -

            To learn more about Android Market publishing settings, see the following resources:

            +

            To learn more about Google Play publishing settings, see the following resources:

          @@ -670,19 +670,19 @@ the web and in the Android application), as discussed in the previous sections.< - - + - + diff --git a/docs/html/guide/publishing/publishing_overview.jd b/docs/html/guide/publishing/publishing_overview.jd index c94d201..6fb77e1 100755 --- a/docs/html/guide/publishing/publishing_overview.jd +++ b/docs/html/guide/publishing/publishing_overview.jd @@ -14,7 +14,7 @@ page.title=Publishing Overview
        22. Preparing Your Application for Release
        23. Releasing Your Application to Users
            -
          1. Releasing on Android Market
            2. +
          2. Releasing on Google Play
          3. Releasing on your own website
          4. Releasing through email
          @@ -23,7 +23,7 @@ page.title=Publishing Overview
          1. Preparing for Release
            2. -
          2. Publishing on Android Market
            3. +
          3. Publishing on Google Play
          @@ -42,7 +42,7 @@ publish an Android application you perform two main tasks:

          24. -

          Usually, you release your application through an application marketplace, such as Android Market. +

          Usually, you release your application through an application marketplace, such as Google Play. However, you can also release applications by sending them directly to users or by letting users download them from your own website.

          @@ -73,7 +73,7 @@ tasks:

          android:versionCode and android:versionName attributes, which are located in the <manifest> - element. You may also have to configure several other settings to meet Android Market + element. You may also have to configure several other settings to meet Google Play requirements or accomodate whatever method you're using to release your application.

        24. Building and signing a release version of your application. @@ -114,28 +114,27 @@ application.

          Releasing Your Application to Users

          You can release your Android applications several ways. Usually, you release applications -through an application marketplace, such as Android Market, but you can also release applications -on your own website or by sending an application directly to a user. Android Market is the +through an application marketplace, such as Google Play, but you can also release applications +on your own website or by sending an application directly to a user. Google Play is the recommended marketplace for Android applications and is particularly useful if you want to distribute your applications to a large global audience. The other two release methods—server distribution and email distribution—are useful if you are releasing an application to a small group of users (for example, a work group in an enterprise environment), or if you do not want to make your application available to the general public.

          -

          Releasing Your Applications on Android Market

          +

          Releasing Your Applications on Google Play

          -

          Android Market is a robust publishing platform that helps you publicize, sell, and distribute +

          Google Play is a robust publishing platform that helps you publicize, sell, and distribute your Android applications to users around the world. When you release your applications through -Android Market you have access to a suite of developer tools that let you analyze your sales, +Google Play you have access to a suite of developer tools that let you analyze your sales, identify market trends, and control who your applications are being distributed to. You also have access to several revenue-enhancing features that are not available anywhere else, such as in-app billing and application licensing. This rich array of -tools -and features, coupled with numerous end-user community features, makes Android Market the premier +href="{@docRoot}guide/market/licensing.html">application licensing. This rich array of tools +and features, coupled with numerous end-user community features, makes Google Play the premier marketplace for selling and buying Android applications.

          -

          Releasing your application on Android Market is a simple process that involves three basic +

          Releasing your application on Google Play is a simple process that involves three basic steps:

          @@ -144,19 +143,19 @@ marketplace for selling and buying Android applications.

          to be installed" />

          Figure 2. The Unknown sources setting lets you install - applications that are not published on Android Market . + applications that are not published on Google Play .

          • Preparing promotional materials. -

            To fully leverage the marketing and publicity capabilities of Android Market, you need to +

            To fully leverage the marketing and publicity capabilities of Google Play, you need to create promotional materials for your application, such as screenshots, videos, graphics, and promotional text.

          • Configuring options and uploading assets. -

            Android Market lets you target your application to a worldwide pool of users and devices. - By configuring various Android Market settings, you can choose the countries you want to +

            Google Play lets you target your application to a worldwide pool of users and devices. + By configuring various Google Play settings, you can choose the countries you want to reach, the listing languages you want to use, and the price you want to charge in each country. You can also configure listing details such as the application type, category, and content rating. When you are done configuring options you can upload your promotional materials @@ -170,21 +169,21 @@ marketplace for selling and buying Android applications.

          -

          For information about Android Market, see Publishing on Android Market. This -topic provides an introduction to Android Market features and provides a step-by-step guide for -distributing your applications on Android Market.

          +

          For information about Google Play, see Publishing on Google Play. This +topic provides an introduction to Google Play features and provides a step-by-step guide for +distributing your applications on Google Play.

          Releasing your application on your own website

          -

          If you do not want to release your application on an application marketplace like Android Market, +

          If you do not want to release your application on an application marketplace like Google Play, you can release your application by making it available for download on your own website or server. To do this, you must first prepare your application for release (that is, you must build it for release and sign it). Then all you need to do is host the release-ready application on your website and provide a download link for the application. When users browse to your website with their Android-powered devices and download your application, the Android system will automatically start installing the application on the device. However, the installation process will start automatically -only if the user has configured their device to allow the installation of non-Android Market +only if the user has configured their device to allow the installation of non-Google Play applications.

          @@ -198,7 +197,7 @@ applications.

          By default, Android-powered devices allow users to install applications only if the applications -have been downloaded from Android Market. To allow the installation of applications from other +have been downloaded from Google Play. To allow the installation of applications from other sources, users need to enable the Unknown sources setting on their devices, and they need to make this configuration change before they download your application to their device (see figure 2).

          @@ -209,7 +208,7 @@ applications from unknown sources.

          Although it is relatively easy to release your application on your own website, it can be inefficient and cumbersome. For example, if you want to monetize your application you will have to process and track all financial transactions yourself and you will not be able to use -Android Market's in-app billing feature to sell in-app products. In addition, you will not be +Google Play's in-app billing feature to sell in-app products. In addition, you will not be able to use the licensing feature to help prevent unauthorized installation and use of your application.

          @@ -223,7 +222,7 @@ button in the email message (see figure 3). Users can install your application b button.

          Note: The Install Now button appears only if a -user has configured their device to allow the installation of non-Android Market applications and +user has configured their device to allow the installation of non-Google Play applications and they open your email with the native Gmail application.

          Releasing applications through email is convenient if you are sending your application to diff --git a/docs/html/guide/publishing/versioning.jd b/docs/html/guide/publishing/versioning.jd index 79ebf96..da57e3e 100644 --- a/docs/html/guide/publishing/versioning.jd +++ b/docs/html/guide/publishing/versioning.jd @@ -25,7 +25,7 @@ page.title=Versioning Your Applications

          1. Preparing to Publish Your Application
            2. -
          2. Publishing On Android Market
            3. +
          3. Publishing On Google Play
          4. The AndroidManifest.xml File
          diff --git a/docs/html/guide/topics/admin/device-admin.jd b/docs/html/guide/topics/admin/device-admin.jd index 820c3c0..4a325db 100644 --- a/docs/html/guide/topics/admin/device-admin.jd +++ b/docs/html/guide/topics/admin/device-admin.jd @@ -75,8 +75,8 @@ server.
          25. not currently have an automated provisioning solution. Some of the ways a sysadmin might distribute the application to users are as follows:
            -
          • Android Market.
            • -
          • Enabling non-market installation.
            • +
          • Google Play.
            • +
          • Enabling installation from another store.
          • Distributing the application through other means, such as email or websites.
          diff --git a/docs/html/guide/topics/data/backup.jd b/docs/html/guide/topics/data/backup.jd index dec2146..4eba4f3 100644 --- a/docs/html/guide/topics/data/backup.jd +++ b/docs/html/guide/topics/data/backup.jd @@ -900,8 +900,8 @@ href="{@docRoot}guide/developing/tools/bmgr.html">{@code bmgr}.

        25. Install your application on a suitable Android system image
          • If using the emulator, create and use an AVD with Android 2.2 (API Level 8).
            • -
          • If using a device, the device must be running Android 2.2 or greater and have Android -Market built in.
            • +
          • If using a device, the device must be running Android 2.2 or greater and have Google +Play built in.
        26. Ensure that backup is enabled diff --git a/docs/html/guide/topics/fundamentals.jd b/docs/html/guide/topics/fundamentals.jd index d1a3786..a86d905 100644 --- a/docs/html/guide/topics/fundamentals.jd +++ b/docs/html/guide/topics/fundamentals.jd @@ -392,13 +392,13 @@ same features and capabilities. In order to prevent your application from being that lack features needed by your application, it's important that you clearly define a profile for the types of devices your application supports by declaring device and software requirements in your manifest file. Most of these declarations are informational only and the system does not read -them, but external services such as Android Market do read them in order to provide filtering +them, but external services such as Google Play do read them in order to provide filtering for users when they search for applications from their device.

          For example, if your application requires a camera and uses APIs introduced in Android 2.1 (API Level 7), you should declare these as requirements in your manifest file. That way, devices that do not have a camera and have an -Android version lower than 2.1 cannot install your application from Android Market.

          +Android version lower than 2.1 cannot install your application from Google Play.

          However, you can also declare that your application uses the camera, but does not require it. In that case, your application must perform a check at runtime to determine @@ -458,12 +458,12 @@ element.

          It's important that you declare all such requirements for your application, because, when you -distribute your application on Android Market, Market uses these declarations to filter which +distribute your application on Google Play, the store uses these declarations to filter which applications are available on each device. As such, your application should be available only to devices that meet all your application requirements.

          -

          For more information about how Android Market filters applications based on these (and other) -requirements, see the Market Filters +

          For more information about how Google Play filters applications based on these (and other) +requirements, see the Filters on Google Play document.

          diff --git a/docs/html/guide/topics/graphics/opengl.jd b/docs/html/guide/topics/graphics/opengl.jd index 6a2a20f..a786d42 100644 --- a/docs/html/guide/topics/graphics/opengl.jd +++ b/docs/html/guide/topics/graphics/opengl.jd @@ -189,7 +189,7 @@ shown below. <uses-feature android:glEsVersion="0x00020000" android:required="true" /> -

          Adding this declaration causes the Android Market to restrict your application from being +

          Adding this declaration causes Google Play to restrict your application from being installed on devices that do not support OpenGL ES 2.0.

        27. Texture compression requirements - If your application uses texture @@ -200,9 +200,9 @@ formats, see Texture compression support.

          Declaring texture compression requirements in your manifest hides your application from users with devices that do not support at least one of your declared compression types. For more -information on how Android Market filtering works for texture compressions, see the -Android Market and texture compression filtering section of the {@code +Google Play and texture compression filtering section of the {@code <supports-gl-texture>} documentation.

          28. @@ -470,7 +470,7 @@ the next section.

          Note: Once you decide which texture compression formats your application will support, make sure you declare them in your manifest using <supports-gl-texture> -. Using this declaration enables filtering by external services such as Android Market, so that +. Using this declaration enables filtering by external services such as Google Play, so that your app is installed only on devices that support the formats your app requires. For details, see OpenGL manifest declarations.

          diff --git a/docs/html/guide/topics/manifest/activity-element.jd b/docs/html/guide/topics/manifest/activity-element.jd index 8b131c8..9dc124b 100644 --- a/docs/html/guide/topics/manifest/activity-element.jd +++ b/docs/html/guide/topics/manifest/activity-element.jd @@ -672,7 +672,7 @@ unspecified}" setting.

          Note: When you declare one of the landscape or portrait values, it is considered a hard requirement for the orientation in which the activity runs. As such, -the value you declare enables filtering by services such as Android Market so your application is +the value you declare enables filtering by services such as Google Play so your application is available only to devices that support the orientation required by your activities. For example, if you declare either {@code "landscape"}, {@code "reverseLandscape"}, or {@code "sensorLandscape"}, then your application will be available only to devices that support @@ -681,7 +681,7 @@ your application requires either portrait or landscape orientation with the {@code <uses-feature>} element. For example, <uses-feature android:name="android.hardware.screen.portrait"/>. This is purely a filtering behavior -provided by Android Market (and other services that support it) and the platform itself does not +provided by Google Play (and other services that support it) and the platform itself does not control whether your app can be installed when a device supports only certain orientations.

          diff --git a/docs/html/guide/topics/manifest/compatible-screens-element.jd b/docs/html/guide/topics/manifest/compatible-screens-element.jd index 5c89869..a27c316 100644 --- a/docs/html/guide/topics/manifest/compatible-screens-element.jd +++ b/docs/html/guide/topics/manifest/compatible-screens-element.jd @@ -27,10 +27,10 @@ specifies a specific screen size-density combination with which the application

          The Android system does not read the {@code <compatible-screens>} manifest element (neither at install-time nor at runtime). This element is informational only and may be used -by external services (such as Android Market) to better understand the application's compatibility +by external services (such as Google Play) to better understand the application's compatibility with specific screen configurations and enable filtering for users. Any screen configuration that is not declared in this element is a screen with which the application is not -compatible. Thus, external services (such as Android Market) should not provide the application to +compatible. Thus, external services (such as Google Play) should not provide the application to devices with such screens.

          Caution: Normally, you should not use this manifest @@ -48,14 +48,14 @@ should use the {@code <supports-screens>} element allows you to declare that your application does not -support small and normal screen sizes. External services (such as Android -Market) will filter your application accordingly. You can also use the small and normal screen sizes. External services (such as Google +Play) will filter your application accordingly. You can also use the {@code <supports-screens>} element to declare whether the system should resize your application for different screen sizes.

          -

          Also see the Market Filters -document for more information about how Android Market filters applications using this and +

          Also see the Filters on Google Play +document for more information about how Google Play filters applications using this and other manifest elements.

          @@ -138,5 +138,5 @@ entry looks like if your application is compatible with only small and normal sc
          see also:
          Supporting Multiple Screens
          -
          Market Filters
          +
          Filters on Google Play
          diff --git a/docs/html/guide/topics/manifest/manifest-element.jd b/docs/html/guide/topics/manifest/manifest-element.jd index c970c72..9788945 100644 --- a/docs/html/guide/topics/manifest/manifest-element.jd +++ b/docs/html/guide/topics/manifest/manifest-element.jd @@ -150,9 +150,9 @@ either internal or external storage through the system settings.
          Display the details screen for a specific applicationhttp://market.android.com/details?id=<package_name> +http://play.google.com/store/details?id=<package_name> market://details?id=<package_name>
          Search for applications using a general string query.http://market.android.com/search?q=<query>http://play.google.com/store/search?q=<query> market://search?q=<query>
          Search for applications by publisher namehttp://market.android.com/search?q=pub:<publisher_name>http://play.google.com/store/search?q=pub:<publisher_name> market://search?q=pub:<publisher_name>
          -

          Caution: If your application uses the Android Market's Copy - Protection feature, it cannot be installed to a device's SD card. However, if you use Android - Market's Application Licensing instead, +

          Caution: If your application uses Google Play's Copy + Protection feature, it cannot be installed to a device's SD card. However, if you use Google + Play's Application Licensing instead, your application can be installed to internal or external storage, including SD cards.

          Note: By default, your application will be installed on the diff --git a/docs/html/guide/topics/manifest/supports-gl-texture-element.jd b/docs/html/guide/topics/manifest/supports-gl-texture-element.jd index 6c4a05a..ebdd0b1 100644 --- a/docs/html/guide/topics/manifest/supports-gl-texture-element.jd +++ b/docs/html/guide/topics/manifest/supports-gl-texture-element.jd @@ -18,20 +18,20 @@ parent.link=manifest-intro.html

          - -

          Android Market and Google Play and <supports-gl-texture> elements

          -

          Android Market filters applications according +

          Google Play filters applications according to the texture compression formats that they support, to ensure that they can be installed only on devices that can handle their textures properly. Developers can use texture compression filtering as a way of targeting specific device types, based on GPU platform.

          For important information about how - Android Market uses <supports-gl-texture> elements as - the basis for filtering, please read Android - Market and texture compression filtering, below.

          + Google Play uses <supports-gl-texture> elements as + the basis for filtering, please read Google + Play and texture compression filtering, below.

          @@ -57,7 +57,7 @@ texture compression formats, you can declare multiple

          Declared <supports-gl-texture> elements are informational, meaning that the Android system itself does not examine the elements at install time to ensure matching support on the device. However, other services -(such as Android Market) or applications can check your application's +(such as Google Play) or applications can check your application's <supports-gl-texture> declarations as part of handling or interacting with your application. For this reason, it's very important that you declare all of the texture compression formats (from the list below) that @@ -141,20 +141,20 @@ and others.

          see also:
          -

          Android Market and texture compression filtering

          +

          Google Play and texture compression filtering

          -

          Android Market filters the applications that are visible to users, so that +

          Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with -their devices. One of the ways Market filters applications is by texture +their devices. One of the ways it filters applications is by texture compression compatibility, giving you control over the availability of your application to various devices, based on the capabilities of their GPUs.

          To determine an application's texture compression compatibility with a given -user's device, Android Market compares:

          +user's device, Google Play compares:

          • Texture compression formats that are supported by the application — @@ -164,26 +164,26 @@ an application declares its supported texture compression formats in a device reports the formats it supports as read-only system properties.
          -

          Each time you upload an application to the Android Market Publisher Site, -Android Market scans the application's manifest file and looks for any +

          Each time you upload an application to the Google Play publisher site, +Google Play scans the application's manifest file and looks for any <supports-gl-texture> elements. It extracts the format descriptors from the elements and stores them internally as metadata associated with the application .apk and the application version.

          -

          When a user searches or browses for applications on Android Market, +

          When a user searches or browses for applications on Google Play, the service compares the texture compression formats supported by the application with those supported by the user's device. The comparison is based on the format descriptor strings and a match must be exact.

          If any of an application's supported texture compression formats is -also supported by the device, Android Market allows the user to see the +also supported by the device, Google Play allows the user to see the application and potentially download it. Otherwise, if none of the application's -formats is supported by the device, Android Market filters the application so +formats is supported by the device, Google Play filters the application so that it is not available for download.

          If an application does not declare any <supports-gl-texture> elements, -Android Market does not apply any filtering based on GL texture compression format.

          +Google Play does not apply any filtering based on GL texture compression format.

          diff --git a/docs/html/guide/topics/manifest/supports-screens-element.jd b/docs/html/guide/topics/manifest/supports-screens-element.jd index 81d6e27..ae14121 100644 --- a/docs/html/guide/topics/manifest/supports-screens-element.jd +++ b/docs/html/guide/topics/manifest/supports-screens-element.jd @@ -80,7 +80,7 @@ should not use it.

          A small screen is defined as one with a smaller aspect ratio than the "normal" (traditional HVGA) screen. An application that does not support small screens will not be available for - small screen devices from external services (such as Android Market), because there is little + small screen devices from external services (such as Google Play), because there is little the platform can do to make such an application work on a smaller screen. This is {@code "true"} by default. @@ -156,8 +156,8 @@ smallest screen width qualifier ({@code sw<N>dp}).

          Caution: The Android system does not pay attention to this attribute, so it does not affect how your application behaves at runtime. Instead, it is used -to enable filtering for your application on services such as Android Market. However, -Android Market currently does not support this attribute for filtering (on Android +to enable filtering for your application on services such as Google Play. However, +Google Play currently does not support this attribute for filtering (on Android 3.2), so you should continue using the other size attributes if your application does not support small screens.

          diff --git a/docs/html/guide/topics/manifest/uses-feature-element.jd b/docs/html/guide/topics/manifest/uses-feature-element.jd index 9f80638..9175566 100644 --- a/docs/html/guide/topics/manifest/uses-feature-element.jd +++ b/docs/html/guide/topics/manifest/uses-feature-element.jd @@ -9,7 +9,7 @@ parent.link=manifest-intro.html

          In this document

            -
          1. Android Market and Feature-Based Filtering +
          2. Google Play and Feature-Based Filtering
            1. Filtering based on explicitly declared features
            2. Filtering based on implicit features
              3. @@ -45,26 +45,26 @@ href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest>
              - -

              Android Market and <uses-feature> elements

              -

              Android Market filters the applications that are visible to users, so + +

              Google Play and <uses-feature> elements

              +

              Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with their -devices. One of the ways Market filters applications is by feature compatibility.

              +devices. One of the ways it filters applications is by feature compatibility.

              -

              To do this, Market checks the +

              To do this, Google Play checks the <uses-feature> elements in each application's manifest, to -establish the app's feature needs. Market then shows or hides the application to +establish the app's feature needs. Google Play then shows or hides the application to each user, based on a comparison with the features available on the user's device.

              By specifying the features that your application requires, -you enable Android Market to present your application only to users whose +you enable Google Play to present your application only to users whose devices meet the application's feature requirements, rather than presenting it to all users.

              For important information about how -Android Market uses features as the basis for filtering, please read Android Market and Feature-Based Filtering, +Google Play uses features as the basis for filtering, please read Google Play and Feature-Based Filtering, below.

              @@ -106,7 +106,7 @@ application requires.

              Declared <uses-feature> elements are informational only, meaning that the Android system itself does not check for matching feature support on the device before installing an application. However, other services -(such as Android Market) or applications may check your application's +(such as Google Play) or applications may check your application's <uses-feature> declarations as part of handling or interacting with your application. For this reason, it's very important that you declare all of the features (from the list below) that your application uses.

              @@ -207,22 +207,22 @@ can check at run-time whether a higher level of OpenGL ES is available.)

            3. {@link android.content.pm.FeatureInfo}
            4. {@link android.content.pm.ConfigurationInfo}
            5. <uses-permission>
              6. -
            6. Android Market Filters
              7. +
            7. Filters on Google Play
              8. -

              Android Market and Feature-Based Filtering

              +

              Google Play and Feature-Based Filtering

              -

              Android Market filters the applications that are visible to users, so that +

              Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with -their devices. One of the ways Market filters applications is by feature +their devices. One of the ways it filters applications is by feature compatibility.

              To determine an application's feature compatibility with a given user's -device, the Android Market service compares:

              +device, Google Play compares:

              • Features required by the application — an application declares features in @@ -238,14 +238,14 @@ are listed in the Features Reference tables at the bottom of this document, and in the class documentation for {@link android.content.pm.PackageManager}.

                -

                When the user launches the Market application, the application queries the +

                When the user launches Google Play, the application queries the Package Manager for the list of features available on the device by calling {@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The -Market application then passes the features list up to the Android Market -service when establishing the session for the user.

                +Store application then passes the features list up to Google Play +when establishing the session for the user.

                -

                Each time you upload an application to the Android Market Publisher Site, -Android Market scans the application's manifest file. It looks for +

                Each time you upload an application to the Google Play publisher site, +Google Play scans the application's manifest file. It looks for <uses-feature> elements and evaluates them in combination with other elements, in some cases, such as <uses-sdk> and <uses-permission> elements. After establishing the @@ -253,17 +253,17 @@ application's set of required features, it stores that list internally as metadata associated with the application .apk and the application version.

                -

                When a user searches or browses for applications using the Android Market +

                When a user searches or browses for applications using the Google Play application, the service compares the features needed by each application with the features available on the user's device. If all of an application's required -features are present on the device, Android Market allows the user to see the +features are present on the device, Google Play allows the user to see the application and potentially download it. If any required feature is not -supported by the device, Android Market filters the application so that it is +supported by the device, Google Play filters the application so that it is not visible to the user and not available for download.

                Because the features you declare in <uses-feature> -elements directly affect how Android Market filters your application, it's -important to understand how Android Market evaluates the application's manifest +elements directly affect how Google Play filters your application, it's +important to understand how Google Play evaluates the application's manifest and establishes the set of required features. The sections below provide more information.

                @@ -277,35 +277,35 @@ application absolutely requires the feature and cannot function properly without it ("true"), or whether the application prefers to use the feature if available, but is designed to run without it ("false").

                -

                Android Market handles explicitly declared features in this way:

                +

                Google Play handles explicitly declared features in this way:

                  -
                • If a feature is explicitly declared as being required, Android Market adds +
                • If a feature is explicitly declared as being required, Google Play adds the feature to the list of required features for the application. It then filters the application from users on devices that do not provide that feature. For example: 
                  <uses-feature android:name="android.hardware.camera" android:required="true" />
                  • -
                • If a feature is explicitly declared as not being required, Android -Market does not add the feature to the list of required features. For +
                • If a feature is explicitly declared as not being required, Google +Play does not add the feature to the list of required features. For that reason, an explicitly declared non-required feature is never considered when filtering the application. Even if the device does not provide the declared -feature, Android Market will still consider the application compatible with the +feature, Google Play will still consider the application compatible with the device and will show it to the user, unless other filtering rules apply. For example: 
                  <uses-feature android:name="android.hardware.camera" android:required="false" />
                • If a feature is explicitly declared, but without an -android:required attribute, Android Market assumes that the feature +android:required attribute, Google Play assumes that the feature is required and sets up filtering on it.

                In general, if your application is designed to run on Android 1.6 and earlier versions, the android:required attribute is not available in the -API and Android Market assumes that any and all +API and Google Play assumes that any and all <uses-feature> declarations are required.

                Note: By declaring a feature explicitly and including an android:required="false" attribute, you can -effectively disable all filtering on Android Market for the specified feature. +effectively disable all filtering on Google Play for the specified feature.

                @@ -317,7 +317,7 @@ function properly, but which is not declared in a speaking, every application should always declare all features that it uses or requires, so the absence of a declaration for a feature used by an application should be considered an error. However, as a safeguard for users and -developers, Android Market looks for implicit features in each application and +developers, Google Play looks for implicit features in each application and sets up filters for those features, just as it would do for an explicitly declared feature.

                @@ -337,25 +337,25 @@ element name or an unrecognized string value for the
              -

              To account for the cases above, Android Market attempts to discover an +

              To account for the cases above, Google Play attempts to discover an application's implied feature requirements by examining other elements declared in the manifest file, specifically, <uses-permission> elements.

              -

              If an application requests hardware-related permissions, Android Market +

              If an application requests hardware-related permissions, Google Play assumes that the application uses the underlying hardware features and therefore requires those features, even though there might be no corresponding to <uses-feature> declarations. For such -permissions, Android Market adds the underlying hardware features to the +permissions, Google Play adds the underlying hardware features to the metadata that it stores for the application and sets up filters for them.

              For example, if an application requests the CAMERA permission but does not declare a <uses-feature> element for -android.hardware.camera, Android Market considers that the +android.hardware.camera, Google Play considers that the application requires a camera and should not be shown to users whose devices do not offer a camera.

              -

              If you don't want Android Market to filter based on a specific implied +

              If you don't want Google Play to filter based on a specific implied feature, you can disable that behavior. To do so, declare the feature explicitly in a <uses-feature> element and include an android:required="false" attribute. For example, to disable @@ -366,30 +366,30 @@ the feature as shown below.

              It's important to understand that the permissions that you request in <uses-permission> elements can directly affect how -Android Market filters your application. The reference section Permissions that Imply Feature Requirements, below, lists the full set of permissions that imply feature requirements and therefore trigger filtering.

              Special handling for Bluetooth feature

              -

              Android Market applies slightly different rules than described above, when +

              Google Play applies slightly different rules than described above, when determining filtering for Bluetooth.

              If an application declares a Bluetooth permission in a <uses-permission> element, but does not explicitly declare -the Bluetooth feature in a <uses-feature> element, Android -Market checks the version(s) of the Android platform on which the application is +the Bluetooth feature in a <uses-feature> element, Google +Play checks the version(s) of the Android platform on which the application is designed to run, as specified in the <uses-sdk> element.

              -

              As shown in the table below, Android Market enables filtering for the +

              As shown in the table below, Google Play enables filtering for the Bluetooth feature only if the application declares its lowest or targeted -platform as Android 2.0 (API level 5) or higher. However, note that Android -market applies the normal rules for filtering when the application explicitly +platform as Android 2.0 (API level 5) or higher. However, note that Google +Play applies the normal rules for filtering when the application explicitly declares the Bluetooth feature in a <uses-feature> element.

              -

              Table 1. How Android Market determines the +

              Table 1. How Google Play determines the Bluetooth feature requirement for an application that requests a Bluetooth permission but does not declare the Bluetooth feature in a <uses-feature> element.

              @@ -403,14 +403,14 @@ permission but does not declare the Bluetooth feature in a <=4 (or uses-sdk is not declared) <=4 -Android Market will not filter the application from any devices +Google Play will not filter the application from any devices based on their reported support for the android.hardware.bluetooth feature. <=4 >=5 -Android Market filters the application from any devices that +Google Play filters the application from any devices that do not support the android.hardware.bluetooth feature (including older releases). @@ -421,13 +421,13 @@ older releases).

              The examples below illustrate the different filtering effects, based on how -Android Market handles the Bluetooth feature.

              +Google Play handles the Bluetooth feature.

              In first example, an application that is designed to run on older API levels declares a Bluetooth permission, but does not declare the Bluetooth feature in a <uses-feature> element.
              -
              Result: Android Market does not filter the application from any device.
              +
              Result: Google Play does not filter the application from any device.
              <manifest ...>
@@ -439,7 +439,7 @@ declares a Bluetooth permission, but does not declare the Bluetooth feature in a
 
              
 
              In the second example, below, the same application also declares a target
 API level of "5". 
              
-
              Result: Android Market now assumes that the feature is required and
+
              Result: Google Play now assumes that the feature is required and
 will filter the application from all devices that do not report Bluetooth support,
 including devices running older versions of the platform. 
              
 
              
@@ -465,7 +465,7 @@ including devices running older versions of the platform. 
 
              
 
              Finally, in the case below, the same application adds an
 android:required="false" attribute.
              
-
              Result: Android Market disables filtering based on Bluetooth
+
              Result: Google Play disables filtering based on Bluetooth
 feature support, for all devices.
              
 
              
 
@@ -481,10 +481,10 @@ feature support, for all devices.
 
              Testing the features required by your application
              
 
 
              You can use the aapt tool, included in the Android SDK, to
-determine how Android Market will filter your application, based on its declared
+determine how Google Play will filter your application, based on its declared
 features and permissions. To do so, run  aapt with the dump
 badging command. This causes aapt to parse your
-application's manifest and apply the same rules as used by Android Market to
+application's manifest and apply the same rules as used by Google Play to
 determine the features that your application requires. 
              
 
 
              To use the tool, follow these steps: 
              
@@ -529,7 +529,7 @@ densities: '160'
 
              Features Reference
              
 
 
              The tables below provide reference information about hardware and software
-features and the permissions that can imply them on Android Market. 
              
+features and the permissions that can imply them on Google Play. 
              
 
 
              Hardware features
              
 
@@ -873,12 +873,12 @@ level 5). Because of this, some apps were able to use the API before they had
 the ability to declare that they require the API via the
 <uses-feature> system. 
              
 
-
              To prevent those apps from being made available unintentionally,  Android
-Market assumes that certain hardware-related permissions indicate that the
+
              To prevent those apps from being made available unintentionally,  Google
+Play assumes that certain hardware-related permissions indicate that the
 underlying hardware features are required by default. For instance, applications
 that use Bluetooth must request the BLUETOOTH permission in a
-<uses-permission> element — for legacy apps, Android
-Market assumes that the permission declaration means that the underlying
+<uses-permission> element — for legacy apps, Google
+Play assumes that the permission declaration means that the underlying
 android.hardware.bluetooth feature is required by the application
 and sets up filtering based on that feature. 
              
 
diff --git a/docs/html/guide/topics/manifest/uses-library-element.jd b/docs/html/guide/topics/manifest/uses-library-element.jd
index d94ad9f..2f8eb50 100644
--- a/docs/html/guide/topics/manifest/uses-library-element.jd
+++ b/docs/html/guide/topics/manifest/uses-library-element.jd
@@ -33,7 +33,7 @@ parent.link=manifest-intro.html
     
              
     
              
         This element also affects the installation of the application on a particular device and
-        the availability of the application in Android Market:
+        the availability of the application on Google Play:
     
              
     
              
         
              Installation
              
@@ -42,11 +42,11 @@ parent.link=manifest-intro.html
             {@code true}, the {@link android.content.pm.PackageManager} framework won't let the user
             install the application unless the library is present on the user's device.
         
-        
              Market
              
+        
              Google Play
              
         
              
-            Android Market filters applications based on the libraries installed on the
+            Google Play filters applications based on the libraries installed on the
             user's device. For more information about filtering, see the topic
-            Market Filters.
+            Filters on Google Play.
         
              
     
              
     
              
diff --git a/docs/html/guide/topics/manifest/uses-permission-element.jd b/docs/html/guide/topics/manifest/uses-permission-element.jd
index 967fc5a..6c71fb4 100644
--- a/docs/html/guide/topics/manifest/uses-permission-element.jd
+++ b/docs/html/guide/topics/manifest/uses-permission-element.jd
@@ -8,21 +8,21 @@ parent.link=manifest-intro.html
  
               
    
   
               
-     
-    
              <uses-permission> and filtering on Android Market. 
              
+     
+    
              <uses-permission> and filtering on Google Play. 
              
 
 
              In some cases, the permissions that you request
 through <uses-permission> can affect how
-your application is filtered by Android Market.
              
+your application is filtered by Google Play.
              
 
 
              If you request a hardware-related permission —
-CAMERA, for example — Android Market assumes that your
+CAMERA, for example — Google Play assumes that your
 application requires the underlying hardware feature and filters the application
 from devices that do not offer it.
              
 
 
              To control filtering, always explicitly declare
 hardware features in <uses-feature> elements, rather than
-relying on Android Market to "discover" the requirements in
+relying on Google Play to "discover" the requirements in
 <uses-permission> elements. Then, if you want to disable
 filtering for a particular feature, you can add a
 android:required="false" attribute to the
diff --git a/docs/html/guide/topics/manifest/uses-sdk-element.jd b/docs/html/guide/topics/manifest/uses-sdk-element.jd
index 99c91f6..8fa39d1 100644
--- a/docs/html/guide/topics/manifest/uses-sdk-element.jd
+++ b/docs/html/guide/topics/manifest/uses-sdk-element.jd
@@ -33,16 +33,16 @@ major version or the sum of the major and minor versions).
              
  
               
    
   
               
-     
-    
              Android Market and <uses-sdk> attributes
               
-    
              Android Market filters the applications that are visible to users, so
+     
+    
              Google Play and <uses-sdk> attributes
               
+    
              Google Play filters the applications that are visible to users, so
 that users can only see and download applications that are compatible with their
-devices. One of the ways Market filters applications is by Android
-version-compatibility. To do this, Market checks the <uses-sdk>
+devices. One of the ways it filters applications is by Android
+version-compatibility. To do this, Google Play checks the <uses-sdk>
 attributes in each application's manifest to establish its version-compatibility
 range, then shows or hides the application based on a comparison with the API
 Level of the user's Android system version. For more information, see Market Filters.
              
+href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play.
              
   
              
 
              
 
@@ -114,7 +114,7 @@ the corresponding platform version.
              
   updates, consider the following example: 
              
 
   
              An application declaring maxSdkVersion="5" in its
-  manifest is published on Android Market. A user whose device is running Android
+  manifest is published on Google Play. A user whose device is running Android
   1.6 (API Level 4) downloads and installs the app. After a few weeks, the user
   receives an over-the-air system update to Android 2.0 (API Level 5). After the
   update is installed, the system checks the application's
@@ -143,7 +143,7 @@ the corresponding platform version.
              
 
   
              Future versions of Android (beyond Android 2.0.1) will no
 longer check or enforce the maxSdkVersion attribute during
-installation or re-validation. Android Market will continue to use the attribute
+installation or re-validation. Google Play will continue to use the attribute
 as a filter, however, when presenting users with applications available for
 download. 
              
   
diff --git a/docs/html/guide/topics/media/camera.jd b/docs/html/guide/topics/media/camera.jd
index 4e928b3..a76c3c7 100644
--- a/docs/html/guide/topics/media/camera.jd
+++ b/docs/html/guide/topics/media/camera.jd
@@ -131,11 +131,11 @@ for example:
   
              For a list of camera features, see the manifest
 Features
 Reference.
              
-  
              Adding camera features to your manifest causes Android Market to prevent your application from
+  
              Adding camera features to your manifest causes Google Play to prevent your application from
 being installed to devices that do not include a camera or do not support the camera features you
-specify. For more information about using feature-based filtering with Android Market, see Android
-Market and Feature-Based Filtering.
              
+specify. For more information about using feature-based filtering with Google Play, see Google
+Play and Feature-Based Filtering.
              
   
              If your application can use a camera or camera feature for proper operation, but does
 not require it, you should specify this in the manifest by including the {@code
 android:required} attribute, and setting it to {@code false}:
              
@@ -1260,7 +1260,7 @@ supported.
              
 
 
              If your application requires certain camera features in order to function properly, you can
 require them through additions to your application manifest. When you declare the use of specific
-camera features, such as flash and auto-focus, the Android Market restricts your application from
+camera features, such as flash and auto-focus, Google Play restricts your application from
 being installed on devices which do not support these features. For a list of camera features that
 can be declared in your app manifest, see the manifest
  Features
diff --git a/docs/html/guide/topics/network/sip.jd b/docs/html/guide/topics/network/sip.jd
index 276adb6..600da78 100644
--- a/docs/html/guide/topics/network/sip.jd
+++ b/docs/html/guide/topics/network/sip.jd
@@ -147,7 +147,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk>
 
 
              To control how your application is filtered from devices that do not support
-SIP (for example, in Android Market), add the following to your application's
+SIP (for example, on Google Play), add the following to your application's
 manifest:
              
 
 
                
diff --git a/docs/html/guide/topics/nfc/nfc.jd b/docs/html/guide/topics/nfc/nfc.jd
index 83873c3..834656a 100644
--- a/docs/html/guide/topics/nfc/nfc.jd
+++ b/docs/html/guide/topics/nfc/nfc.jd
@@ -318,8 +318,8 @@ other two intents, giving the user a better experience.
              -
            8. The uses-feature element so that your application shows up in the Android -Market only for devices that have NFC hardware: +
            9. The uses-feature element so that your application shows up in Google +Play only for devices that have NFC hardware: 
               <uses-feature android:name="android.hardware.nfc" android:required="true" />
              @@ -660,7 +660,7 @@ certainty that your application is started when an NFC tag is scanned. An AAR ha of an application embedded inside an NDEF record. You can add an AAR to any NDEF record of your NDEF message, because Android searches the entire NDEF message for AARs. If it finds an AAR, it starts the application based on the package name inside the AAR. If the application is not present on the device, -Android Market is launched to download the application.

              +Google Play is launched to download the application.

              AARs are useful if you want to prevent other applications from filtering for the same intent and potentially handling specific tags that you have deployed. AARs are only supported at the @@ -678,7 +678,7 @@ the intent also matches the AAR, start the Activity.

            10. If the Activity that filters for the intent does not match the AAR, if multiple Activities can handle the intent, or if no Activity handles the intent, start the application specified by the AAR.
              11. -
            11. If no application can start with the AAR, go to the Android Market to download the +
            12. If no application can start with the AAR, go to Google Play to download the application based on the AAR.
            @@ -897,7 +897,7 @@ public class Beam extends Activity implements CreateNdefMessageCallback {

            Note that this code comments out an AAR, which you can remove. If you enable the AAR, the application specified in the AAR always receives the Android Beam message. If the application is not -present, the Android Market is started to download the application. Therefore, the following intent +present, Google Play launches to download the application. Therefore, the following intent filter is not technically necessary for Android 4.0 devices or later if the AAR is used:

            diff --git a/docs/html/guide/topics/resources/localization.jd b/docs/html/guide/topics/resources/localization.jd index 9affb15..c2b668d 100755 --- a/docs/html/guide/topics/resources/localization.jd +++ b/docs/html/guide/topics/resources/localization.jd @@ -186,7 +186,7 @@ speak.

            and can include other types of resources such as animations.
                res/drawable/(required directory holding at least - one graphic file, for the application's icon in the Market)
            + one graphic file, for the application's icon on Google Play)
                res/layout/ (required directory holding an XML file that defines the default layout)
                res/anim/ (required if you have any @@ -507,7 +507,7 @@ the new locale.

            Publishing Localized Applications

            -

            The Android Market is +

            The Google Play is the main application distribution system for Android devices. To publish a localized application, you need to sign your application, version it, and go through all the other steps described in href="{@docRoot}guide/publishing/app-signing.html#strategies">Signing Strategies.

          3. Give each .apk file a different application name. Currently it is -impossible to put two applications into the Android Market that have exactly the +impossible to publish two applications on Google Play that have exactly the same name.
          4. Include a complete set of default resources in each .apk file.
            5. @@ -638,7 +638,7 @@ border="0"> arrow - Upload your .apk file or files to Market, selecting the appropriate + Upload your .apk file or files to Google Play, selecting the appropriate languages as you upload. (For more details, see Publishing Your diff --git a/docs/html/guide/topics/sensors/sensors_overview.jd b/docs/html/guide/topics/sensors/sensors_overview.jd index 3c5e94c..543872c 100644 --- a/docs/html/guide/topics/sensors/sensors_overview.jd +++ b/docs/html/guide/topics/sensors/sensors_overview.jd @@ -606,7 +606,7 @@ sensor is present on a device so your app can run successfully. You have two opt that a given sensor is present on a device:

            • Detect sensors at runtime and enable or disable application features as appropriate.
              • -
            • Use Android Market filters to target devices with specific sensor configurations.
              • +
            • Use Google Play filters to target devices with specific sensor configurations.

            Each option is discussed in the following sections.

            @@ -633,9 +633,9 @@ whether there's a pressure sensor on a device:

            } -

            Using Android Market filters to target specific sensor configurations

            +

            Using Google Play filters to target specific sensor configurations

            -

            If you are publishing your application on Android Market you can use the +

            If you are publishing your application on Google Play you can use the <uses-feature> element in your manifest file to filter your application from devices that do not have the appropriate sensor configuration for your application. The @@ -650,7 +650,7 @@ following is an example manifest entry that filters apps that do not have an acc

            If you add this element and descriptor to your application's manifest, users will see your -application on Android Market only if their device has an accelerometer.

            +application on Google Play only if their device has an accelerometer.

            You should set the descriptor to android:required="true" only if your application relies entirely on a specific sensor. If your application uses a sensor for some functionality, but diff --git a/docs/html/guide/topics/ui/actionbar.jd b/docs/html/guide/topics/ui/actionbar.jd index e59fa0f..bf7369a 100644 --- a/docs/html/guide/topics/ui/actionbar.jd +++ b/docs/html/guide/topics/ui/actionbar.jd @@ -349,7 +349,7 @@ of the following:

          5. Frequently used: It's an action that your users need seven out of ten visits or they use it several times in a row.

            Example frequent actions: "New message" in the Messaging app and -"Search" in Android Market.

            +"Search" on Google Play.

          6. Important: It's an action that you need users to easily discover or, if it's -- cgit v1.1