</ul>
</li>
+
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>google/play/billing/index.html">
<span class="en">Google Play In-app Billing</span></a>
</div>
<ul>
- <li><a href="<?cs var:toroot?>google/play/billing/billing_overview.html">
- <span class="en">In-app Billing Overview</span></a>
- </li>
- <li><a href="<?cs var:toroot?>google/play/billing/billing_integrate.html">
- <span class="en">Implementing In-app Billing</span></a>
- </li>
- <li><a href="<?cs var:toroot?>google/play/billing/billing_subscriptions.html">
- <span class="en">Subscriptions</span></a>
- </li>
- <li><a href="<?cs var:toroot?>google/play/billing/billing_best_practices.html">
+ <li><a href="<?cs var:toroot?>google/play/billing/billing_overview.html">
+ <span class="en">Overview</span></a>
+ </li>
+ <li class="nav-section"><div class="nav-section-header"><a href="<?cs var:toroot?>google/play/billing/api.html">
+ <span class="en">Version 3 API</span></a></div>
+ <ul>
+ <li><a href="<?cs var:toroot?>google/play/billing/billing_integrate.html">
+ <span class="en">Implementing the API</span></a></li>
+ <li><a href="<?cs var:toroot?>google/play/billing/billing_reference.html">
+ <span class="en">Reference</span></a></li>
+ </ul>
+ </li>
+ <li class="nav-section"><div class="nav-section-header"><a href="<?cs var:toroot?>google/play/billing/v2/api.html">
+ <span class="en">Version 2 API</span></a></div>
+ <ul>
+ <li><a href="<?cs var:toroot?>google/play/billing/v2/billing_integrate.html">
+ <span class="en">Implementing the API</span></a></li>
+ <li><a href="<?cs var:toroot?>google/play/billing/v2/billing_subscriptions.html">
+ <span class="en">Subscriptions</span></a></li>
+ <li><a href="<?cs var:toroot?>google/play/billing/v2/billing_reference.html">
+ <span class="en">Reference</span></a></li>
+ </ul>
+ </li>
+ <li><a href="<?cs var:toroot?>google/play/billing/billing_best_practices.html">
<span class="en">Security and Design</span></a>
- </li>
-
<li><a href="<?cs var:toroot?>google/play/billing/billing_testing.html">
+ </li>
+ <li><a href="<?cs var:toroot?>google/play/billing/billing_testing.html">
<span class="en">Testing In-app Billing</span></a>
- </li>
-
<li><a href="<?cs var:toroot?>google/play/billing/billing_admin.html">
+ </li>
+ <li><a href="<?cs var:toroot?>google/play/billing/billing_admin.html">
<span class="en">Administering In-app Billing</span></a>
- </li>
- <li><a href="<?cs var:toroot?>google/play/billing/billing_reference.html">
- <span class="en">Reference</span></a>
- </li>
+ </li>
+ <li><a href="<?cs var:toroot?>google/play/billing/versions.html">
+ <span class="en">Version Notes</span></a>
+ </li>
</ul>
</li>
<li><a href="<?cs var:toroot ?>google/play/publishing/multiple-apks.html">
<span class="en">Multiple APK Support</span></a>
</li>
-
<li><a href="<?cs var:toroot ?>google/play/expansion-files.html">
<span class="en">APK Expansion Files</span></a>
</li>
-
<li class="nav-section">
<div class="nav-section-header"><a href="<?cs var:toroot ?>google/play/licensing/index.html">
<span class="en">Application Licensing</span></a>
--- /dev/null
+page.title=In-app Billing Version 3
+parent.title=In-app Billing
+parent.link=index.html
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+ <h2>Topics</h2>
+ <ol>
+ <li><a href="#producttypes">Product Types</a>
+ <ol>
+ <li><a href="#managed">Managed In-app Products</a><li>
+ </ol>
+ </li>
+ <li><a href="#purchase">Purchasing Items</a></li>
+ <li><a href="#consume">Consuming Items</a>
+ <ol>
+ <li><a href="#consumetypes">Non-consumable and Consumable Items</a><li>
+ <li><a href="#managingconsumables">Managing Consumable Purchases</a><li>
+ </ol>
+ </li>
+ <li><a href="#caching">Local Caching</a></li>
+ </ol>
+
+ <h2>Reference</h2>
+ <ol>
+ <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
+ Reference (V3)</a></li>
+ </ol>
+
+ <h2>See also</h2>
+ <ol>
+ <li><a href="{@docRoot}training/in-app-billing/index.html">Selling In-app Products</a></li>
+ </ol>
+</div>
+</div>
+
+<p>The In-app Billing Version 3 API makes it easier for you to integrate In-app Billing into your applications. The features in this version include improved synchronous purchase flow, APIs to let you easily track ownership of consumable goods, and local caching of in-app purchase data.</p>
+
+<h2 id="producttypes">Product Types</h2>
+<p>You define your products using the Google Play Developer Console, including product type, SKU, price, description, and so on. For more information, see <a
+href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app Billing</a>. The Version 3 API only supports the managed in-app product type.</p>
+<h3 id="managed">Managed In-app Products</h3>
+<p>Managed in-app products are items that have their ownership information tracked and managed by Google Play. When a user purchases a managed in-app item, Google Play stores the purchase information for each item on a per-user basis. This enables you to later query Google Play at any time to restore the state of the items a specific user has purchased. This information is persistent on the Google Play servers even if the user uninstalls the application or if they change devices.</p>
+<p>If you are using the Version 3 API, you can also consume managed items within your application. You would typically implement consumption for items that can be purchased multiple times (such as in-game currency, fuel, or magic spells). Once purchased, a managed item cannot be purchased again until you consume the item, by sending a consumption request to Google Play. To learn more about in-app product consumption, see <a href="#consume">Consuming Items</a></p>
+
+
+<h2 id="purchase">Purchasing Items</h2>
+
+<div class="figure" style="width:430px">
+<img src="{@docRoot}images/in-app-billing/v3/iab_v3_purchase_flow.png" id="figure1" height="530"/>
+<p class="img-caption">
+ <strong>Figure 1.</strong> The basic sequence for a purchase request.
+</p>
+</div>
+
+<p>A typical purchase flow with the Version 3 API is as follows:
+<ol>
+<li>Your application sends a {@code isBillingSupported} request to Google Play to determine that the target version of the In-app Billing API that you are using is supported. </li>
+<li>When your application starts or user logs in, it's good practice to check with Google Play to determine what items are owned by the user. To query the user's in-app purchases, send a {@code getPurchases} request. If the request is successful, Google Play returns a {@code Bundle} containing a list of product IDs of the purchased items, a list of the individual purchase details, and a list of the signatures for the purchases.</li>
+<li>Usually, you'll want to inform the user of the products that are available for purchase. To query the details of the in-app products that you defined in Google Play, your application can send a {@code getSkuDetails} request. You must specify a list of product IDs in the query request. If the request is successful, Google Play returns a {@code Bundle} containing product details including the product’s price, title, description, and the purchase type.
+</li>
+<li>If an in-app product is not owned by the user, you can initiate a purchase for it. To start a purchase request, your application sends a {@code getBuyIntent} request, specifying the product ID of the item to purchase, along with other parameters. You should record the product ID when you create a new in-app product in the Developer Console.
+ <ol type="a">
+ <li>Google Play returns a {@code Bundle} that contains a {@code PendingIntent} which you application uses to start the checkout UI for the purchase.</li>
+ <li>Your application launches the pending intent by calling the {@code startIntentSenderForResult} method.</li>
+ <li>When the checkout flow finishes (that is, the user successfully purchases the item or cancels the purchase), Google Play sends a response {@code Intent} to your {@code onActivityResult} method. The result code of the {@code onActivityResult} has a result code that indicates whether the purchase was successful or canceled. The response {@code Intent} contains information about the purchased item, including a {@code purchaseToken} String that is generated by Google Play to uniquely identify this purchase transaction. The {@code Intent} also contains the signature of the purchase, signed with your private developer key.</li>
+ </ol>
+</li>
+</ol>
+</p>
+<p>To learn more about the Version 3 API calls and server responses, see <a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing Reference</a>.</p>
+
+<h2 id="consume">Consuming Items</h2>
+<p>You can use the consumption mechanism to track the user's ownership of in-app products.</p>
+<p>In Version 3, all in-app products are managed. This means that the user's ownership of all in-app item purchases is maintained by Google Play, and your application can query the user's purchase information when needed. When the user successfully purchases an item, that purchase is recorded in Google Play. Once an item is purchased, it is considered to be "owned". Items in the "owned" state cannot be purchased from Google Play. You must send a consumption request for the "owned" item before Google Play makes it available for purchase again. Consuming the item reverts it to the "unowned" state, and discards the previous purchase data.</p>
+<div class="figure" style="width:420px">
+<img src="{@docRoot}images/in-app-billing/v3/iab_v3_consumption_flow.png" id="figure2" height="300"/>
+<p class="img-caption">
+ <strong>Figure 2.</strong> The basic sequence for a consumption request.
+</p>
+</div>
+<p>To retrieve the list of product's owned by the user, your application sends a {@code getPurchases} call to Google Play. Your application can make a consumption request by sending a {@code consumePurchase} call. In the request argument, you must specify the item's unique {@code purchaseToken} String that you obtained from Google Play when it was purchased. Google Play returns a status code indicating if the consumption was recorded successfully.</p>
+
+<h3 id="consumetypes">Non-consumable and Consumable Items</h3>
+<p>It's up to you to decide if you want to handle your in-app products as non-consumable or consumable items.</p>
+<dl>
+<dt>Non-consumable Items</dt>
+<dd>Typically, you would not implement consumption for items that can only be purchased once in your application and provide a permanent benefit. Once purchased, these items will be permanently associated to the user's Google account. An example of a non-consumable item is a premium upgrade or a level pack.</dd>
+<dt>Consumable items</dt>
+<dd>In contrast, you can implement consumption for items that can be made available for purchase multiple times. Typically, these items provide certain temporary effects. For example, the user's in-game character might gain life points or gain extra gold coins in their inventory. Dispensing the benefits or effects of the purchased item in your application is called <em>provisioning</em> the in-app product. You are responsible for controlling and tracking how in-app products are provisioned to the users.
+<p class="note"><strong>Important:</strong> Before provisioning the consumable item in your application, you must send a consumption request to Google Play and receive a successful response indicating that the consumption was recorded.</p>
+</dd>
+</dl>
+<h3 id="managingconsumables">Managing consumable purchases in your application</h3>
+<p>Here is the basic flow for purchasing a consumable item:</p>
+<ol>
+<li>Launch a purchase flow with a {@code getBuyIntent} call</li>
+<li>Get a response {@code Bundle}from Google Play indicating if the purchase completed successfully.</li>
+<li>If the purchase was successful, consume the purchase by making a {@code consumePurchase} call.</li>
+<li>Get a response code from Google Play indicating if the consumption completed successfully.</li>
+<li>If the consumption was successful, provision the product in your application.</li>
+</ol>
+<p>Subsequently, when the user starts up or logs in to your application, you should check if the user owns any outstanding consumable items; if so, make sure to consume and provision those items. Here's the recommended application startup flow if you implement consumable items in your application:</p>
+<ol>
+<li>Send a {@code getPurchases} request to query the owned items for the user.</li>
+<li>If there are any consumable items, consume the items by calling {@code consumePurchase}. This step is necessary because the application might have completed the purchase order for the consumable item, but stopped or got disconnected before the application had the chance to send a consumption request.</li>
+<li>Get a response code from Google Play indicating if the consumption completed successfully.</li>
+<li>If the consumption was successful, provision the product in your application.</li>
+</ol>
+
+<h2 id="caching">Local Caching</h2>
+<p>Because the Google Play client now caches In-app Billing information locally on the device, you can use the Version 3 API to query for this information more frequently, for example through a {@code getPurchases} call. Unlike with previous versions of the API, many Version 3 API calls will be serviced through cache lookups instead of through a network connection to Google Play, which significantly speeds up the API's response time. </p>
+
+
+++ /dev/null
-<html>
-<head>
-<meta http-equiv="refresh"
-content="0;url=http://developer.android.com/google/play/billing/index.html">
-<title>Redirecting...</title>
-</head>
-<body>
-<p>You should be redirected. Please <a
-href="http://developer.android.com/google/play/billing/index.html">click
-here</a>.</p>
-</body>
-</html>
\ No newline at end of file
<h2>In this document</h2>
<ol>
<li><a href="#billing-list-setup">Creating a Product List</a></li>
- <li><a href="#billing-purchase-type">Choosing a Purchase Type</a></li>
+ <li><a href="#billing-purchase-type">Choosing a Product Type</a></li>
<li><a href="#billing-testing-setup">Setting up Test Accounts</a></li>
<li><a href="#billing-refunds">Handling Refunds</a></li>
<li><a href="#billing-refunds">Working with Order Numbers</a></li>
<li><a href="#billing-support">Where to Get Support</a></li>
</ol>
- <h2>Downloads</h2>
- <ol>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">Sample
- Application</a></li>
+
</ol>
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html">Implementing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
- Design</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
- Reference</a></li>
</ol>
</div>
</div>
<p>In-app billing frees you from processing financial transactions, but you still need to perform a
-few administrative tasks, including setting up and maintaining your product list on the publisher
-site, registering test accounts, and handling refunds when necessary.</p>
+few administrative tasks, including setting up and maintaining your product list on the Google Play
+Developer Console, registering test accounts, and handling refunds when necessary.</p>
<p>You must have a Google Play publisher account to register test accounts. And you must have a
Google Checkout merchant account to create a product list and issue refunds to your users. If you
already have a publisher account on 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 a Google Play developer and set up a publisher account at the
-Google Play <a href="http://play.google.com/apps/publish">publisher site</a>. If you do not have a
-Google Checkout merchant account, you can register for one at the <a
+need to register for a new account to support in-app billing.</p>
+
+<p>If you do not have a publisher account, you can register as a Google Play
+developer and set up a publisher account at the <a
+href="http://play.google.com/apps/publish">Google Play Developer Console</a>. If you do not
+have a Google Checkout merchant account, you can register for one at the <a
href="http://checkout.google.com">Google Checkout site</a>.</p>
<h2 id="billing-list-setup">Creating a Product List</h2>
-<p>The Google Play publisher site provides a product list for each of your published
+<p>The Google Play Developer Console provides a product list for each of your published
applications. You can sell an item using Google Play's in-app billing feature only if the item is
listed on an application's product list. Each application has its own product list; you cannot sell
items that are listed in another application's product list.</p>
<p>You can access an application's product list by clicking the <strong>In-App Products</strong>
-link that appears under each of the applications that are listed for your publisher account (see
+link in applications listed in your developer account (see
figure 1). The <strong>In-App Products</strong> link appears only if you have a Google Checkout
-merchant account and an application's manifest includes the <code>com.android.vending.BILLING</code>
+merchant account and the application's manifest includes the <code>com.android.vending.BILLING</code>
permission.</p>
-<img src="{@docRoot}images/billing_product_list_entry.png" height="548" id="figure1" />
-<p class="img-caption">
- <strong>Figure 1.</strong> You can access an application's product list by clicking the
- <strong>In-App Products</strong> link.
-</p>
-
<p>A product list specifies items you are selling in an application — in-app products,
subscriptions, or a combination of both. For each item, the product list contains information such as a product id,
-product description, and price (see figure 2). The product list stores only metadata about the items
+product description, and price. The product list stores only metadata about the items
you are selling in your application. It does not store any digital content. You are responsible for
storing and delivering the digital content that you sell in your applications.</p>
-<img src="{@docRoot}images/billing_product_list.png" height="658" id="figure2" />
-<p class="img-caption">
- <strong>Figure 2.</strong> An application's product list.
+<div style="margin:1em;">
+<img style="border:1px solid #ddd;padding-bottom:.5em" src="{@docRoot}images/in-app-billing/billing_product_list.png" xheight="548" id="figure1" />
+<p class="img-caption" style="padding-left:.5em;">
+ <strong>Figure 1.</strong> You can access an application's product list by clicking the
+ <strong>In-App Products</strong> link in the main Apps navigation.
</p>
+</div>
<p>You can create a product list for any published application or any draft application that's been
-uploaded and saved to the Google Play site. However, you must have a Google Checkout merchant
+uploaded and saved to the Developer Console. However, you must have a Google Checkout merchant
account and the application's manifest must include the <code>com.android.vending.BILLING</code>
permission. If an application's manifest does not include this permission, you will be able to edit
existing items in the product list but you will not be able to add new items to the list. For more
you are using the multiple APK feature.</p>
<p>You can add items to a product list two ways: you can add items one at a time by using the In-app
-Products UI (see figure 3), or you can add a batch of items by importing the items from a
-comma-separated values (CSV) file (see figure 2). Adding items one at a time is useful if your
+Products UI (see figure 2), or you can add a batch of items by importing the items from a
+comma-separated values (CSV) file. Adding items one at a time is useful if your
application has only a few in-app items or you are adding only a few items to a
product list for testing purposes. The CSV file method is useful if your application has a large
number of in-app items.</p>
<li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li>
<li>In the <strong>All Google Play listings</strong> panel, under the application name, click
<strong>In-app Products</strong>.</li>
- <li>On the In-app Products List page, click <strong>Add in-app product</strong>.</li>
- <li>On the Create New In-app Product page (see figure 3), provide details about the item you are
+ <li>Click <strong>Add new product</strong> (see figure 2) and provide details about the item you are
selling and then click <strong>Save</strong> or <strong>Publish</strong>.</li>
</ol>
-<img src="{@docRoot}images/billing_list_form.png" height="840" id="figure3" />
-<p class="img-caption">
- <strong>Figure 3.</strong> The Create New In-app Product page lets you add items to an
+<div style="margin:1em;">
+<img style="border:1px solid #ddd;padding-bottom:.5em;" src="{@docRoot}images/in-app-billing/billing_add.png" height="300" id="figure2" />
+<p class="img-caption" style="padding-left:.5em;">
+ <strong>Figure 2.</strong> The Add New Product page lets you add items to an
application's product list.
</p>
+</div>
<p>You must enter the following information for each item in a product list:</p>
<ul>
<p>In addition, you cannot modify an item's product ID after it is created, and you cannot reuse
a product ID.</p>
</li>
- <li><strong>Purchase Type</strong>
- <p>The purchase type can be <strong>Managed per user account</strong>, <strong>Unmanaged</strong>,
- or <strong>Subscription</strong>. You can never change an item's purchase type after you set it. For more
- information, see <a href="#billing-purchase-type">Choosing a purchase type</a> later in this
+ <li><strong>Product Type</strong>
+ <p>The product type can be <strong>Managed per user account</strong>, <strong>Unmanaged</strong>,
+ or <strong>Subscription</strong>. You can never change an item's product type after you set it. For more
+ information, see <a href="#billing-purchase-type">Choosing a product type</a> later in this
document.</p>
</li>
<li><strong>Publishing State</strong>
href="{@docRoot}google/play/billing/billing_testing.html#billing-testing-real">Testing In-app
Billing</a> for more information.</p>
</li>
- <li><strong>Language</strong>
- <p>The language setting determines which languages are used to display the item title and
- item description during checkout. A product list inherits its default language from the
- parent application. You can add more languages by clicking <strong>add language</strong>. You
- can also choose to have the title and description automatically translated from the default
- language by selecting the <strong>Fill fields with auto translation</strong> checkbox (see
- figure 4). If you do not use the auto translation feature, you must provide the translated
- versions of the title and description.</p>
+ <li><strong>Languages and Translations</strong>
+ <p>You can provide localized titles and descriptions for your in-app
+ products using the Add Translations button. If you want Google Play to translate
+ your title and description for you, based on the title and description in the
+ default language, just click the languages that you want to offer. If you want
+ to provide custom translations in specific languages, you can also do that. By
+ default, an in-app product inherits its default language from the parent
+ application.</p>
</li>
<li><strong>Title</strong>
<p>The title is a short descriptor for the item. For example, "Sleeping potion." Titles must be
page in the Google Play developer console.</p>
<p>To specify prices in other currencies, you can manually enter the price for each
currency or you can click <strong>Auto Fill</strong> and let Google Play do a one-time
- conversion from your home currency to the currencies you are targeting (see figure 4).</p>
+ conversion from your home currency to the currencies you are targeting (see figure 3).</p>
<p>For subscription items, note that you can not change the item's price once you have published it. </p>
</li>
</ul>
-<img src="{@docRoot}images/billing_list_form_2.png" height="1226" id="figure4" />
-<p class="img-caption">
- <strong>Figure 4.</strong> Specifying additional currencies and additional languages for the
- item title and description.
+
+<div style="margin:1em;">
+<img style="border:1px solid #ddd;padding-bottom:.5em" src="{@docRoot}images/in-app-billing/billing_list_form_2.png" xheight="1226" id="figure3" />
+<p class="img-caption" style="padding-left:.5em;">
+ <strong>Figure 3.</strong> Specifying additional currencies for an in-app product.
</p>
+</div>
<p>For more information about product IDs and product lists, see <a
-href="http://market.android.com/support/bin/answer.py?answer=1072599">Creating In-App Product
+href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=1072599">Creating In-App Product
IDs</a>. For more information about pricing, see <a
-href="http://market.android.com/support/bin/answer.py?answer=1153485">In-App Billing
+href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=1153485">In-App Billing
Pricing</a>.</p>
<p class="note"><strong>Note</strong>: Be sure to plan your product ID namespace. You cannot reuse
published</code> or <code>unpublished</code>.</p>
</li>
<li><em>purchase_type</em>
- <p>This is equivalent to the Purchase Type setting in the In-app Products UI. Can be <code>
+ <p>This is equivalent to the Product Type setting in the In-app Products UI. Can be <code>
managed_by_android</code>, which is equivalent to <strong>Managed per user account
</strong> in the In-app Products UI, or <code>managed_by_publisher</code>, which is equivalent
to <strong>Unmanaged</strong> in the In-app Products UI.</p>
</strong> on the In-app Product List page. This is useful if you have manually added items to
a product list and you want to start managing the product list through a CSV file.</p>
-<h3 id="billing-purchase-type">Choosing a Purchase Type</h3>
-
-<p>An item's purchase type controls how Google Play manages the purchase of the item. There are
-two purchase types: "managed per user account" and "unmanaged."</p>
-
-<p>Items that are managed per user account can be purchased only once per user account. When an item
-is managed per user account, Google Play permanently stores the transaction information for each
-item on a per-user basis. This enables you to query Google Play with the
-<code>RESTORE_TRANSACTIONS</code> request and restore the state of the items a specific user has
-purchased.</p>
-
-<p>If a user attempts to purchase a managed item that has already been purchased, 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
-demonstrates how you can do this by keeping track of items that are managed and already purchased
-and not allowing users to select those items from the list. Your application should do something
-similar—either graying out the item or hiding it so that it cannot be selected.</p>
-
-<p>The "manage by user account" purchase type is useful if you are selling items such as game levels
-or application features. These items are not transient and usually need to be restored whenever a
-user reinstalls your application, wipes the data on their device, or installs your application on a
-new device.</p>
-
-<p>Items that are unmanaged do not have their transaction information stored on 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 Google Play
-is concerned, so it's also up to you to control how many times an unmanaged item can be
-purchased.</p>
-
-<p>The "unmanaged" purchase type is useful if you are selling consumable items, such as fuel or
-magic spells. These items are consumed within your application and are usually purchased multiple
-times.</p>
+<h3 id="billing-purchase-type">Choosing a Product Type</h3>
+
+<p>An item's product type controls how Google Play manages the purchase of the item. There are
+several product types, including "managed per user account", "unmanaged," and "subscription." However,
+note that the product types supported vary
+across In-app Billing Version, so you should always choose a product type that's valid for the
+version of In-app BIlling that your app uses. </p>
+
+<p>For details, refer to the documentation for <a
+href="{@docRoot}google/play/billing/api.html#producttype">In-app Billing Version
+3</a> or <a href="{@docRoot}google/play/billing/v2/api.html#producttype">In-app
+Billing Version 2</a>.
<h2 id="billing-refunds">Handling Refunds</h2>
refund through your Google Checkout merchant account. When you do this, Google Play receives a
refund notification from Google Checkout, and Google Play sends a refund message to your
application. For more information, see <a
-href="{@docRoot}google/play/billing/billing_overview.html#billing-action-notify">Handling
+href="{@docRoot}google/play/billing/v2/api.html#billing-action-notify">Handling
IN_APP_NOTIFY messages</a> and <a
-href="http://www.google.com/support/androidmarket/bin/answer.py?answer=1153485">In-app Billing
+href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=1153485">In-app Billing
Pricing</a>.</p>
<p class="caution"><strong>Important:</strong> You cannot use the Google Checkout API to issue
-refunds or cancel in-app billing transactions. You must do this manually through your Google
+refunds or cancel In-app Billing transactions. You must do this manually through your Google
Checkout merchant account. However, you can use the Google Checkout API to retrieve order
information.</p>
<h2 id="billing-testing-setup">Setting Up Test Accounts</h2>
-<p>The 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
+<p>The Google Play Developer Console lets you set up one or more test accounts. A test account is a
+regular Google account that you register on the Developer Console as a test account. Test accounts are
authorized to make in-app purchases from applications that you have uploaded to the Google Play
-site but have not yet published.</p>
+Developer Console but have not yet published.</p>
<p>You can use any Google account as a test account. Test accounts are useful if you want to let
-multiple people test in-app billing on applications without giving them access to your publisher
+multiple people test In-app Billing on applications without giving them access to your publisher
account's sign-in credentials. If you want to own and control the test accounts, you can create the
accounts yourself and distribute the credentials to your developers or testers.</p>
<ol>
<li><a href="http://play.google.com/apps/publish">Log in</a> to your publisher account.</li>
- <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li>
- <li>On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure
- 5).</li>
- <li>In Test Accounts, add the email addresses for the test accounts you want to register,
+ <li>Click the <strong>Settings</strong> icon. (If you are using the old Developer Console UI, click
+ <strong>Edit profile</strong> in the upper left part of the page, under your name,)</li>
+ <li>Locate the License Testing panel. (In the old UI, scroll down to the Licensing & In-app Billing panel.)</li>
+ <li>Add the email addresses for the test accounts you want to register,
separating each account with a comma.</li>
<li>Click <strong>Save</strong> to save your profile changes.</li>
</ol>
-<img src="{@docRoot}images/billing_public_key.png" height="510" id="figure5" />
-<p class="img-caption">
- <strong>Figure 5.</strong> The Licensing and In-app Billing panel of your account's Edit Profile
- page lets you register test accounts.
+<h3 id="license_key">Getting an app's license key</h3>
+
+<p>The Google Play Developer Console provides a public licensing key for each app. To get the key for an app,
+load the app's publishing details in the Developer Console and click the <strong>Settings</strong> icon. The key
+for the app is available for copy/paste in License Key for this Application field, as shown in the figure below.</p>
+
+<p>Previously, the Developer Console provided a single public key per developer account. To transition apps to the
+new per-app public key, the Developer Console set the app-specific key as the former developer key. This ensures
+compatibility for apps that depend on the (former) developer key. </p>
+
+<div style="margin:1em;">
+<img style="border:1px solid #ddd;padding-bottom:.5em" src="{@docRoot}images/in-app-billing/billing_app_key.png" xheight="510" id="figure4" />
+<p class="img-caption" style="padding-left:.5em;">
+ <strong>Figure 4.</strong> You can find the license key for each app in the <strong>Services & APIs</strong> panel.
</p>
+</div>
<h2 id="billing-support">Where to Get Support</h2>
-<p>If you have questions or encounter problems while implementing in-app billing, contact the
+<p>If you have questions or encounter problems while implementing In-app Billing, contact the
support resources listed in the following table (see table 2). By directing your queries to the
correct forum, you can get the support you need more quickly.</p>
<p class="table-caption" id="support-table"><strong>Table 2.</strong> Developer support resources
-for Google Play in-app billing.</p>
+for Google Play In-app Billing.</p>
<table>
<td>Billing issue tracker</td>
<td><a href="http://code.google.com/p/marketbilling/issues/">Billing
project issue tracker</a></td>
-<td>Bug and issue reports related specifically to in-app billing sample code.</td>
+<td>Bug and issue reports related specifically to In-app Billing sample code.</td>
</tr>
</table>
<div id="qv">
<h2>In this document</h2>
<ol>
- <li><a href="#billing-security">Security Best Practices</a></li>
- </ol>
- <h2>Downloads</h2>
- <ol>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">Sample
- Application</a></li>
+ <li><a href="#billing-security">Security Best Practices</a>
+ <ol>
+ <li><a href="#unlocked">Protect Unlocked Content</a></li>
+ <li><a href="#obfuscate">Obfuscate Your Code</a></li>
+ <li><a href="#sample">Modify Sample Code</a></li>
+ <li><a href="#nonce">Use Secure Random Nonces</a></li>
+ <li><a href="#payload">Set the Developer Payload String</a></li>
+ <li><a href="#trademark">Report Trademark and Copyright Infringement</a></li>
+ <li><a href="#revocable">Implement a Revocability scheme</a></li>
+ <li><a href="#key">Protect Your Public Key</a></li>
+ </ol>
+ </li>
</ol>
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html">Implementing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
- Reference</a></li>
</ol>
</div>
</div>
-<p>As you design your in-app billing implementation, be sure to follow the security and design
+<p>As you design your In-app Billing implementation, be sure to follow the security and design
guidelines that are discussed in this document. These guidelines are recommended best practices for
-anyone who is using Google Play's in-app billing service.</p>
+anyone who is using Google Play's In-app Billing service.</p>
<h2>Security Best Practices</h2>
-<h4>Perform signature verification tasks on a server</h4>
+<h3 id="sign">Perform signature verification tasks on a server</h3>
<p>If practical, you should perform signature verification on a remote server and not on a device.
Implementing the verification process on a server makes it difficult for attackers to break the
verification process by reverse engineering your .apk file. If you do offload security processing to
a remote server, be sure that the device-server handshake is secure.</p>
-<h4>Protect your unlocked content</h4>
+<h3 id="unlocked">Protect your unlocked content</h3>
<p>To prevent malicious users from redistributing your unlocked content, do not bundle it in your
.apk file. Instead, do one of the following:</p>
<ul>
content in device memory or store it on the device's SD card. If you store content on an SD card, be
sure to encrypt the content and use a device-specific encryption key.</p>
-<h4>Obfuscate your code</h4>
-<p>You should obfuscate your in-app billing code so it is difficult for an attacker to reverse
+<h3 id="obfuscate">Obfuscate your code</h3>
+<p>You should obfuscate your In-app Billing code so it is difficult for an attacker to reverse
engineer security protocols and other application components. At a minimum, we recommend that you
run an obfuscation tool like <a
href="{@docRoot}tools/help/proguard.html">Proguard</a> on your
code.</p>
<p>In addition to running an obfuscation program, we recommend that you use the following techniques
-to obfuscate your in-app billing code.</p>
+to obfuscate your In-app Billing code.</p>
<ul>
<li>Inline methods into other methods.</li>
<li>Construct strings on the fly instead of defining them as constants.</li>
<li>Use Java reflection to call methods.</li>
</ul>
<p>Using these techniques can help reduce the attack surface of your application and help minimize
-attacks that can compromise your in-app billing implementation.</p>
+attacks that can compromise your In-app Billing implementation.</p>
<div class="note">
<p><strong>Note:</strong> If you use Proguard to obfuscate your code, you must add the following
line to your Proguard configuration file:</p>
<p><code>-keep class com.android.vending.billing.**</code></p>
</div>
-<h4>Modify all sample application code</h4>
-<p>The in-app billing sample application is publicly distributed and can be downloaded by anyone,
+<h3 id="sample">Modify all sample application code</h3>
+<p>The In-app Billing sample application is publicly distributed and can be downloaded by anyone,
which means it is relatively easy for an attacker to reverse engineer your application if you use
the sample code exactly as it is published. The sample application is intended to be used only as an
example. If you use any part of the sample application, you must modify it before you publish it or
<p>In particular, attackers look for known entry points and exit points in an application, so it is
important that you modify these parts of your code that are identical to the sample application.</p>
-<h4>Use secure random nonces</h4>
+<h3 id="nonce">Use secure random nonces</h3>
<p>Nonces must not be predictable or reused. Always use a cryptographically secure random number
generator (like {@link java.security.SecureRandom}) when you generate nonces. This can help reduce
replay attacks.</p>
<p>Also, if you are performing nonce verification on a server, make sure that you generate the
nonces on the server.</p>
-<h4>Take action against trademark and copyright infringement</h4>
+<h3 id="payload">Set the developer payload string when making purchase requests</h3>
+<p>With the In-app Billing Version 3 API, you can include a 'developer payload' string token when sending your purchase request to Google Play. Typically, this is used to pass in a string token that uniquely identifies this purchase request. If you specify a string value, Google Play returns this string along with the purchase response. Subsequently, when you make queries about this purchase, Google Play returns this string together with the purchase details.</p>
+<p>You should pass in a string token that helps your application to identify the user who made the purchase, so that you can later verify that this is a legitimate purchase by that user. For consumable items, you can use a randomly generated string, but for non-consumable items you should use a string that uniquely identifies the user.</p>
+<p>When you get back the response from Google Play, make sure to verify that the developer payload string matches the token that you sent previously with the purchase request. As a further security precaution, you should perform the verification on your own secure server.</p>
+
+
+<h3 id="trademark">Take action against trademark and copyright infringement</h3>
<p>If you see your content being redistributed on Google Play, act quickly and decisively. File a
-<a href="http://market.android.com/support/bin/answer.py?hl=en&answer=141511">trademark notice
+<a href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=141511">trademark notice
of infringement</a> or a <a href="http://www.google.com/android_dmca.html">copyright notice of
infringement</a>.</p>
-<h4>Implement a revocability scheme for unlocked content</h4>
+<h3 id="revocable">Implement a revocability scheme for unlocked content</h3>
<p>If you are using a remote server to deliver or manage content, have your application verify the
purchase state of the unlocked content whenever a user accesses the content. This allows you to
revoke use when necessary and minimize piracy.</p>
-<h4>Protect your Google Play public key</h4>
+<h3 id="key">Protect your Google Play public key</h3>
<p>To keep your public key safe from malicious users and hackers, do not embed it in any code as a
literal string. Instead, construct the string at runtime from pieces or use bit manipulation (for
example, XOR with some other string) to hide the actual key. The key itself is not secret
-page.title=Implementing In-app Billing
+page.title=Implementing In-app Billing <span style="font-size:16px;">(IAB Version 3)</span>
parent.title=In-app Billing
parent.link=index.html
@jd:body
<div id="qv">
<h2>In this document</h2>
<ol>
- <li><a href="#billing-download">Downloading the Sample Application</a></li>
- <li><a href="#billing-add-aidl">Adding the AIDL file to your project</a></li>
- <li><a href="#billing-permission">Updating Your Application's Manifest</a></li>
- <li><a href="#billing-service">Creating a Service</a></li>
- <li><a href="#billing-broadcast-receiver">Creating a BroadcastReceiver</a></li>
- <li><a href="#billing-signatures">Creating a security processing component</a></li>
- <li><a href="#billing-implement">Modifying Your Application Code</a></li>
+ <li><a href="#billing-add-aidl">Adding the AIDL file</a></li>
+ <li><a href="#billing-permission">Updating Your Manifest</a></li>
+ <li><a href="#billing-service">Creating a ServiceConnection</a></li>
+ <li><a href="#billing-requests">Making In-app Billing Requests</a>
+ <ol>
+ <li><a href="#QueryDetails">Querying Items Available for Purchase</a><li>
+ <li><a href="#Purchase">Purchasing an Item</a></li>
+ <li><a href="QueryPurchases">Querying Purchased Items</a></li>
+ <li><a href="Consume">Consuming a Purchase</a><li>
+ </ol>
+ </li>
</ol>
- <h2>Downloads</h2>
+ <h2>Reference</h2>
<ol>
- <li><a href="#billing-download">Sample Application</a></li>
+ <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
+ Reference (V3)</a></li>
</ol>
- <h2>See also</h2>
+ <h2>Related Samples</h2>
<ol>
- <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
- Design</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
- Reference</a></li>
+ <li><a href="{@docRoot}training/in-app-billing/preparing-iab-app.html#GetSample">Sample Application (V3)</a></li>
</ol>
+ <h2>See also</h2>
+ <ol>
+ <li><a href="{@docRoot}training/in-app-billing/index.html">Selling In-app Products</a></li>
+ </ol>
</div>
</div>
-<p>In-app Billing on Google Play provides a straightforward, simple interface for sending in-app
-billing requests and managing in-app billing transactions using Google Play. This document helps
-you implement in-app billing by stepping through the primary implementation tasks, using the in-app
-billing sample application as an example.</p>
-
-<p>Before you implement in-app billing in your own application, be sure that you read <a
-href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app Billing</a> and <a
-href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>. These
-documents provide background information that will make it easier for you to implement in-app
-billing.</p>
-
-<p>To implement in-app billing in your application, you need to do the following:</p>
-<ol>
- <li><a href="#billing-download">Download the in-app billing sample application</a>.</li>
- <li><a href="#billing-add-aidl">Add the IMarketBillingService.aidl file</a> to your project.</li>
- <li><a href="#billing-permission">Update your AndroidManifest.xml file</a>.</li>
- <li><a href="#billing-service">Create a Service</a> and bind it to the
- <code>MarketBillingService</code> so your application can send billing requests and receive
- billing responses from Google Play.</li>
- <li><a href="#billing-broadcast-receiver">Create a BroadcastReceiver</a> to handle broadcast
- intents from Google Play.</li>
- <li><a href="#billing-signatures">Create a security processing component</a> to verify the
- integrity of the transaction messages that are sent by Google Play.</li>
- <li><a href="#billing-implement">Modify your application code</a> to support in-app billing.</li>
-</ol>
-
-<h2 id="billing-download">Downloading the Sample Application</h2>
-
-<p>The in-app billing sample application shows you how to perform several tasks that are common to
-all in-app billing implementations, including:</p>
-
-<ul>
- <li>Sending in-app billing requests to Google Play.</li>
- <li>Handling synchronous responses from Google Play.</li>
- <li>Handling broadcast intents (asynchronous responses) from Google Play.</li>
- <li>Using in-app billing security mechanisms to verify the integrity of billing responses.</li>
- <li>Creating a user interface that lets users select items for purchase.</li>
-</ul>
-
-<p>The sample application includes an application file (<code>Dungeons.java</code>), the AIDL file
-for the <code>MarketBillingService</code> (<code>IMarketBillingService.aidl</code>), and several
-classes that demonstrate in-app billing messaging. It also includes a class that demonstrates basic
-security tasks, such as signature verification.</p>
-
-<p>Table 1 lists the source files that are included with the sample application.</p>
-<p class="table-caption" id="source-files-table"><strong>Table 1.</strong> In-app billing sample
-application source files.</p>
-
-<table>
-<tr>
-<th>File</th>
-<th>Description</th>
-</tr>
-
-<tr>
-<td>IMarketBillingService.aidl</td>
-<td>Android Interface Definition Library (AIDL) file that defines the IPC interface to Google
-Play's in-app billing service (<code>MarketBillingService</code>).</td>
-</tr>
-
-<tr>
-<td>Dungeons.java</td>
-<td>Sample application file that provides a UI for making purchases and displaying purchase
-history.</td>
-</tr>
-
-<tr>
-<td>PurchaseDatabase.java</td>
-<td>A local database for storing purchase information.</td>
-</tr>
-
-<tr>
- <td>BillingReceiver.java</td>
- <td>A {@link android.content.BroadcastReceiver} that receives asynchronous response messages
- (broadcast intents) from Google Play. Forwards all messages to the
- <code>BillingService</code>.</td>
-</tr>
-<tr>
- <td>BillingService.java</td>
- <td>A {@link android.app.Service} that sends messages to Google Play on behalf of the
- application by connecting (binding) to the <code>MarketBillingService</code>.</td>
-</tr>
-
-<tr>
- <td>ResponseHandler.java</td>
- <td>A {@link android.os.Handler} that contains methods for updating the purchases database and the
- UI.</td>
-</tr>
-
-<tr>
- <td>PurchaseObserver.java</td>
- <td>An abstract class for observing changes related to purchases.</td>
-</tr>
-
-<tr>
-<td>Security.java</td>
-<td>Provides various security-related methods.</td>
-</tr>
-
-<tr>
-<td>Consts.java</td>
-<td>Defines various Google Play constants and sample application constants. All constants that
-are defined by Google Play must be defined the same way in your application.</td>
-</tr>
-
-<tr>
-<td>Base64.java and Base64DecoderException.java</td>
-<td>Provides conversion services from binary to Base64 encoding. The <code>Security</code> class
-relies on these utility classes.</td>
-</tr>
-
-</table>
-
-<p>The in-app billing sample application is available as a downloadable component of the Android
-SDK. To download the sample application component, launch the Android SDK Manager and then
-select the <strong>Google Market Billing package</strong> component (see figure 1), and click <strong>Install
-Selected</strong> to begin the download.</p>
-
-
-<img src="{@docRoot}images/billing_package.png" height="325" id="figure1" />
-<p class="img-caption">
- <strong>Figure 1.</strong> The Google Market Billing package contains the sample application and
- the AIDL file.
-</p>
-
-<p>When the download is complete, the Android SDK Manager saves the component into the
-following directory:</p>
-
-<p><code><sdk>/extras/google/market_billing/</code></p>
-
-<p>If you want to see an end-to-end demonstration of in-app billing before you integrate in-app
-billing into your own application, you can build and run the sample application. Building and
-running the sample application involves three tasks:</p>
-
-<ul>
- <li>Configuring and building the sample application.</li>
- <li>Uploading the sample application to Google Play.</li>
- <li>Setting up test accounts and running the sample application.</li>
-</ul>
-
-<p class="note"><strong>Note:</strong> Building and running the sample application is necessary only
-if you want to see a demonstration of in-app billing. If you do not want to run the sample
-application, you can skip to the next section, <a href="#billing-add-aidl">Adding the AIDL file to
-your project</a>.</p>
-
-<h3>Configuring and building the sample application</h3>
-
-<p>Before you can run the sample application, you need to configure it and build it by doing the
-following:</p>
-
-<ol>
- <li><strong>Add your Google Play public key to the sample application code.</strong>
- <p>This enables the application to verify the signature of the transaction information that is
- returned from Google Play. To add your public key to the sample application code, do the
- following:</p>
- <ol>
- <li>Log in to your Google Play <a href="http://play.google.com/apps/publish">publisher
- account</a>.</li>
- <li>On the upper left part of the page, under your name, click <strong>Edit
- Profile</strong>.</li>
- <li>On the Edit Profile page, scroll down to the <strong>Licensing & In-app
- Billing</strong> panel.</li>
- <li>Copy your public key.</li>
- <li>Open <code>src/com/example/dungeons/Security.java</code> in the editor of your choice.
- <p>You can find this file in the sample application's project folder.</p>
- </li>
- <li>Add your public key to the following line of code:
- <p><code>String base64EncodedPublicKey = "your public key here";</code></p>
- </li>
- <li>Save the file.</li>
- </ol>
- </li>
- <li><strong>Change the package name of the sample application.</strong>
- <p>The current package name is <code>com.example.dungeons</code>. Google Play does not let
- you upload applications with package names that contain <code>com.example</code>, so you must
- change the package name to something else.</p>
- </li>
- <li><strong>Build the sample application in release mode and sign it.</strong>
- <p>To learn how to build and sign applications, see <a
- href="{@docRoot}tools/building/index.html">Building and Running</a>.</p>
- </li>
-</ol>
-
-<h3>Uploading the sample application</h3>
-
-<p>After you build a release version of the sample application and sign it, you need to upload it as
-a draft to the Google Play publisher site. You also need to create a product list for the in-app
-items that are available for purchase in the sample application. The following instructions show you
-how to do this.</p>
-<ol>
- <li><strong>Upload the release version of the sample application to Google Play.</strong>
- <p>Do not publish the sample application; leave it as an unpublished draft application. The
- sample application is for demonstration purposes only and should not be made publicly available
- on Google Play. To learn how to upload an application to Google Play, see <a
- href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading
- applications</a>.</p>
- </li>
- <li><strong>Create a product list for the sample application.</strong>
- <p>The sample application lets you purchase two items: a two-handed sword
- (<code>sword_001</code>) and a potion (<code>potion_001</code>). We recommend that you set up
- your product list so that <code>sword_001</code> has a purchase type of "Managed per user
- account" and <code>potion_001</code> has a purchase type of "Unmanaged" so you can see how these
- two purchase types behave. To learn how to set up a product list, see <a
- href="{@docRoot}google/play/billing/billing_admin.html#billing-list-setup">Creating a Product
- List</a>.</p>
- <p class="note"><strong>Note:</strong> You must publish the items in your product
- list (<code>sword_001</code> and <code>potion_001</code>) even though you are not publishing the
- sample application. Also, you must have a Google Checkout Merchant account to add items to the
- sample application's product list.</p>
- </li>
-</ol>
+<p>In-app Billing on Google Play provides a straightforward, simple interface for sending In-app Billing requests and managing In-app Billing transactions using Google Play. The information below covers the basics of how to make calls from your application to the In-app Billing service using the Version 3 API. </p>
-<h3>Running the sample application</h3>
+<p class="note"><strong>Note:</strong> To see a complete implementation and learn how to test your application, see the <a href="{@docRoot}training/in-app-billing/index.html">Selling In-app Products</a> training class. The training class provides a complete sample In-app Billing application, including convenience classes to handle key tasks related to setting up your connection, sending billing requests and processing responses from Google Play, and managing background threading so that you can make In-app Billing calls from your main activity.</p>
-<p>You cannot run the sample application in the emulator. You must install the sample application
-onto a device to run it. To run the sample application, do the following:</p>
+<p>Before you start, be sure that you read the <a href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing Overview</a> to familiarize yourself with concepts that will make it easier for you to implement In-app Billing.</p>
+<p>To implement In-app Billing in your application, you need to do the following:</p>
<ol>
- <li><strong>Make sure you have at least one test account registered under your Google Play
- publisher account.</strong>
- <p>You cannot purchase items from yourself (Google Checkout prohibits this), so you need to
- create at least one test account that you can use to purchase items in the sample application.
- To learn how to set up a test account, see <a
- href="{@docRoot}google/play/billing/billing_testing.html#billing-testing-setup">Setting up Test
- Accounts</a>.</p>
- </li>
- <li><strong>Verify that your device is running a supported version of the Google Play
- application or the MyApps application.</strong>
- <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
- the MyApps application. If your device is running any other version of Android, in-app billing
- requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
- version of the Google Play application, see <a
- href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
- Play</a>.</p>
- </li>
- <li><strong>Install the application onto your device.</strong>
- <p>Even though you uploaded the application to Google Play, the application is not published,
- so you cannot download it from Google Play to a device. Instead, you must install the
- application onto your device. To learn how to install an application onto a device, see <a
- href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
- device</a>.</p>
- </li>
- <li><strong>Make one of your test accounts the primary account on your device.</strong>
- <p>The primary account on your device must be one of the <a
- href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test accounts</a>
- that you registered on the Google Play publisher site. If the primary account on your device is not a
- test account, you must do a factory reset of the device and then sign in with one of your test
- accounts. To perform a factory reset, do the following:</p>
- <ol>
- <li>Open Settings on your device.</li>
- <li>Touch <strong>Privacy</strong>.</li>
- <li>Touch <strong>Factory data reset</strong>.</li>
- <li>Touch <strong>Reset phone</strong>.</li>
- <li>After the phone resets, be sure to sign in with one of your test accounts during the
- device setup process.</li>
- </ol>
- </li>
- <li><strong>Run the application and purchase the sword or the potion.</strong>
- <p>When you use a test account to purchase items, the test account is billed through Google
- Wallet and your Google Checkout Merchant account receives a payout for the purchase.
- Therefore, you may want to refund purchases that are made with test accounts, otherwise the
- purchases will show up as actual payouts to your merchant account.</p>
+ <li>Add the In-app Billing library to your project.</li>
+ <li>Update your {@code AndroidManifest.xml} file.</li>
+ <li>Create a {@code ServiceConnection} and bind it to {@code IInAppBillingService}.</li>
+ <li>Send In-app Billing requests from your application to {@code IInAppBillingService}.</li>
+ <li>Handle In-app Billing responses from Google Play.</li>
</ol>
-<p class="note"><strong>Note</strong>: Debug log messages are turned off by default in the
-sample application. You can turn them on by setting the variable <code>DEBUG</code>
-to <code>true</code> in the <code>Consts.java</code> file.</p>
-
<h2 id="billing-add-aidl">Adding the AIDL file to your project</h2>
-<p>The sample application contains an Android Interface Definition Language (AIDL) file, which
-defines the interface to Google Play's in-app billing service
-(<code>MarketBillingService</code>). When you add this file to your project, the Android build
-environment creates an interface file (<code>IMarketBillingService.java</code>). You can then use
-this interface to make billing requests by invoking IPC method calls.</p>
-
-<p>If you are using the ADT plug-in with Eclipse, you can just add this file to your
-<code>/src</code> directory. Eclipse will automatically generate the interface file when you build
-your project (which should happen immediately). If you are not using the ADT plug-in, you can put
-the AIDL file into your project and use the Ant tool to build your project so that the
-<code>IMarketBillingService.java</code> file gets generated.</p>
-
-<p>To add the <code>IMarketBillingService.aidl</code> file to your project, do the following:</p>
+<p>The {@code TriviaDriva} sample application contains an Android Interface Definition Language (AIDL) file which defines the interface to Google Play's In-app Billing service. When you add this file to your project, the Android build environment creates an interface file (<code>IIAppBillingService.java</code>). You can then use this interface to make billing requests by invoking IPC method calls.</p>
+<p>To add the In-app Billing Version 3 library to your project:</p>
<ol>
- <li>Create the following directory in your application's <code>/src</code> directory:
- <p><code>com/android/vending/billing/</code></p>
- </li>
- <li>Copy the <code>IMarketBillingService.aidl</code> file into the
- <code>sample/src/com/android/vending/billing/</code> directory.</li>
- <li>Build your application.</li>
+<li>Copy the {@code IInAppBillingService.aidl} file to your Android project.
+ <ul>
+ <li>If you are using Eclipse: Import the {@code IInAppBillingService.aidl} file into your {@code /src} directory. Eclipse automatically generates the interface file when you build your project.</li>
+ <li>If you are developing in a non-Eclipse environment: Create the following directory {@code /src/com/android/vending/billing} and copy the {@code IInAppBillingService.aidl} file into this directory. Put the AIDL file into your project and use the Ant tool to build your project so that the
+<code>IInAppBillingService.java</code> file gets generated.</li>
+ </ul>
+</li>
+<li>Build your application. You should see a generated file named {@code IInAppBillingService.java} in the {@code /gen} directory of your project.</li>
</ol>
-<p>You should now find a generated interface file named <code>IMarketBillingService.java</code> in
-the <code>gen</code> folder of your project.</p>
<h2 id="billing-permission">Updating Your Application's Manifest</h2>
-<p>In-app billing relies on the Google Play application, which handles all communication between
-your application and the Google Play server. To use the Google Play application, your
-application must request the proper permission. You can do this by adding the
-<code>com.android.vending.BILLING</code> permission to your AndroidManifest.xml file. If your
-application does not declare the in-app billing permission, but attempts to send billing requests,
-Google Play will refuse the requests and respond with a <code>RESULT_DEVELOPER_ERROR</code>
-response code.</p>
-
-<p>In addition to the billing permission, you need to declare the {@link
-android.content.BroadcastReceiver} that you will use to receive asynchronous response messages
-(broadcast intents) from Google Play, and you need to declare the {@link android.app.Service}
-that you will use to bind with the <code>IMarketBillingService</code> and send messages to Google
-Play. You must also declare <a
-href="{@docRoot}guide/topics/manifest/intent-filter-element.html">intent filters</a> for the {@link
-android.content.BroadcastReceiver} so that the Android system knows how to handle the broadcast
-intents that are sent from the Google Play application.</p>
-
-<p>For example, here is how the in-app billing sample application declares the billing permission,
-the {@link android.content.BroadcastReceiver}, the {@link android.app.Service}, and the intent
-filters. In the sample application, <code>BillingReceiver</code> is the {@link
-android.content.BroadcastReceiver} that handles broadcast intents from the Google Play
-application and <code>BillingService</code> is the {@link android.app.Service} that sends requests
-to the Google Play application.</p>
+<p>In-app billing relies on the Google Play application, which handles all communication between your application and the Google Play server. To use the Google Play application, your application must request the proper permission. You can do this by adding the {@code com.android.vending.BILLING} permission to your AndroidManifest.xml file. If your application does not declare the In-app Billing permission, but attempts to send billing requests, Google Play will refuse the requests and respond with an error.</p>
+<p>To give your app the necessary permission, add this line in your {@code Android.xml} manifest file:</p>
<pre>
-<?xml version="1.0" encoding="utf-8"?>
-<manifest xmlns:android="http://schemas.android.com/apk/res/android"
- package="com.example.dungeons"
- android:versionCode="1"
- android:versionName="1.0">
-
- <uses-permission android:name="com.android.vending.BILLING" />
-
- <application android:icon="@drawable/icon" android:label="@string/app_name">
- <activity android:name=".Dungeons" android:label="@string/app_name">
- <intent-filter>
- <action android:name="android.intent.action.MAIN" />
- <category android:name="android.intent.category.LAUNCHER" />
- </intent-filter>
- </activity>
-
- <service android:name="BillingService" />
-
- <receiver android:name="BillingReceiver">
- <intent-filter>
- <action android:name="com.android.vending.billing.IN_APP_NOTIFY" />
- <action android:name="com.android.vending.billing.RESPONSE_CODE" />
- <action android:name="com.android.vending.billing.PURCHASE_STATE_CHANGED" />
- </intent-filter>
- </receiver>
-
- </application>
-</manifest>
+<uses-permission android:name="com.android.vending.BILLING" />
</pre>
-<h2 id="billing-service">Creating a Local Service</h2>
+<h2 id="billing-service">Creating a ServiceConnection</h2>
-<p>Your application must have a local {@link android.app.Service} to facilitate messaging between
-your application and Google Play. At a minimum, this service must do the following:</p>
+<p>Your application must have a {@link android.content.ServiceConnection} to facilitate messaging between
+your application and Google Play. At a minimum, your application must do the following:</p>
<ul>
- <li>Bind to the <code>MarketBillingService</code>.
- <li>Send billing requests (as IPC method calls) to the Google Play application. The five types
- of billing requests include:
- <ul>
- <li><code>CHECK_BILLING_SUPPORTED</code> requests</li>
- <li><code>REQUEST_PURCHASE</code> requests</li>
- <li><code>GET_PURCHASE_INFORMATION</code> requests</li>
- <li><code>CONFIRM_NOTIFICATIONS</code> requests</li>
- <li><code>RESTORE_TRANSACTIONS</code> requests</li>
- </ul>
- </li>
+ <li>Bind to {@code IInAppBillingService}.
+ <li>Send billing requests (as IPC method calls) to the Google Play application.</li>
<li>Handle the synchronous response messages that are returned with each billing request.</li>
</ul>
-<h3>Binding to the MarketBillingService</h3>
-
-<p>Binding to the <code>MarketBillingService</code> is relatively easy if you've already added the
-<code>IMarketBillingService.aidl</code> file to your project. The following code sample shows how to
-use the {@link android.content.Context#bindService bindService()} method to bind a service to the
-<code>MarketBillingService</code>. You could put this code in your service's {@link
-android.app.Activity#onCreate onCreate()} method.</p>
-
+<h3>Binding to IInAppBillingService</h3>
+<p>To establish a connection with the In-app Billing service on Google Play, implement a {@link android.content.ServiceConnection} to bind your activity to {@code IInAppBillingService}. Override the {@link android.content.ServiceConnection#onServiceDisconnected onServiceDisconnected} and {@link
+android.content.ServiceConnection#onServiceConnected onServiceConnected} methods to get a reference to the {@code IInAppBillingService} instance after a connection has been established.</p>
<pre>
-try {
- boolean bindResult = mContext.bindService(
- new Intent("com.android.vending.billing.MarketBillingService.BIND"), this,
- Context.BIND_AUTO_CREATE);
- if (bindResult) {
- Log.i(TAG, "Service bind successful.");
- } else {
- Log.e(TAG, "Could not bind to the MarketBillingService.");
- }
-} catch (SecurityException e) {
- Log.e(TAG, "Security exception: " + e);
-}
+IInAppBillingService mService;
+
+ServiceConnection mServiceConn = new ServiceConnection() {
+ @Override
+ public void onServiceDisconnected(ComponentName name) {
+ mService = null;
+ }
+
+ @Override
+ public void onServiceConnected(ComponentName name,
+ IBinder service) {
+ mService = IInAppBillingService.Stub.asInterface(service);
+ }
+};
</pre>
-<p>After you bind to the service, you need to create a reference to the
-<code>IMarketBillingService</code> interface so you can make billing requests via IPC method calls.
-The following code shows you how to do this using the {@link
-android.content.ServiceConnection#onServiceConnected onServiceConnected()} callback method.</p>
-
+<p>In your activity’s {@link android.app.Activity#onCreate onCreate} method, perform the binding by calling the {@link android.content.Context#bindService bindService} method. Pass the method an {@link android.content.Intent} that references the In-app Billing service and an instance of the {@link android.content.ServiceConnection} that you created.</p>
<pre>
-/**
- * The Android system calls this when we are connected to the MarketBillingService.
- */
- public void onServiceConnected(ComponentName name, IBinder service) {
- Log.i(TAG, "MarketBillingService connected.");
- mService = IMarketBillingService.Stub.asInterface(service);
- }
+@Override
+public void onCreate(Bundle savedInstanceState) {
+ super.onCreate(savedInstanceState);
+ setContentView(R.layout.activity_main);
+ bindService(new
+ Intent("com.android.vending.billing.InAppBillingService.BIND"),
+ mServiceConn, Context.BIND_AUTO_CREATE);
</pre>
-
-<p>You can now use the <code>mService</code> reference to invoke the
-<code>sendBillingRequest()</code> method.</p>
-
-<p>For a complete implementation of a service that binds to the <code>MarketBillingService</code>,
-see the <code>BillingService</code> class in the sample application.</p>
-
-<h3>Sending billing requests to the MarketBillingService</h3>
-
-<p>Now that your {@link android.app.Service} has a reference to the
-<code>IMarketBillingService</code> interface, you can use that reference to send billing requests
-(via IPC method calls) to the <code>MarketBillingService</code>. The
-<code>MarketBillingService</code> IPC interface exposes a single public method
-(<code>sendBillingRequest()</code>), which takes a single {@link android.os.Bundle} parameter. The
-Bundle that you deliver with this method specifies the type of request you want to perform, using
-various key-value pairs. For instance, one key indicates the type of request you are making, another
-indicates the item being purchased, and another identifies your application. The
-<code>sendBillingRequest()</code> method immediately returns a Bundle containing an initial response
-code. However, this is not the complete purchase response; the complete response is delivered with
-an asynchronous broadcast intent. For more information about the various Bundle keys that are
-supported by the <code>MarketBillingService</code>, see <a
-href="{@docRoot}google/play/billing/billing_reference.html#billing-interface">In-app Billing
-Service Interface</a>.</p>
-
-<p>You can use the <code>sendBillingRequest()</code> method to send five types of billing requests.
-The five request types are specified using the <code>BILLING_REQUEST</code> Bundle key. This Bundle
-key can have the following five values:</p>
-
-<ul>
- <li><code>CHECK_BILLING_SUPPORTED</code>—verifies that the Google Play application
- supports in-app billing and the version of the In-app Billing API available.</li>
- <li><code>REQUEST_PURCHASE</code>—sends a purchase request for an in-app item.</li>
- <li><code>GET_PURCHASE_INFORMATION</code>—retrieves transaction information for a purchase
- or refund.</li>
- <li><code>CONFIRM_NOTIFICATIONS</code>—acknowledges that you received the transaction
- information for a purchase or refund.</li>
- <li><code>RESTORE_TRANSACTIONS</code>—retrieves a user's transaction history for <a
- href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">managed
- purchases</a>.</li>
-</ul>
-
-<p>To make any of these billing requests, you first need to build an initial {@link
-android.os.Bundle} that contains the three keys that are required for all requests:
-<code>BILLING_REQUEST</code>, <code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The following
-code sample shows you how to create a helper method named <code>makeRequestBundle()</code> that does
-this.</p>
-
+<p>You can now use the mService reference to communicate with the Google Play service.</p>
+<p class="note"><strong>Important:</strong> Remember to unbind from the In-app Billing service when you are done with your {@link android.app.Activity}. If you don’t unbind, the open service connection could cause your device’s performance to degrade. This example shows how to perform the unbind operation on a service connection to In-app Billing called {@code mServiceConn} by overriding the activity’s {@link android.app.Activity#onDestroy onDestroy} method.</p>
<pre>
-protected Bundle makeRequestBundle(String method) {
- Bundle request = new Bundle();
- request.putString(BILLING_REQUEST, method);
- request.putInt(API_VERSION, 1);
- request.putString(PACKAGE_NAME, getPackageName());
- return request;
+@Override
+public void onDestroy() {
+ if (mServiceConn != null) {
+ unbindService(mServiceConn);
+ }
+}
</pre>
-<p>To use this helper method, you pass in a <code>String</code> that corresponds to one of the five
-types of billing requests. The method returns a Bundle that has the three required keys defined. The
-following sections show you how to use this helper method when you send a billing request.</p>
-
-<p class="caution"><strong>Important</strong>: You must make all in-app billing requests from your
-application's main thread.</p>
-
-<h4>Verifying that in-app billing is supported (CHECK_BILLING_SUPPPORTED)</h4>
+<p>For a complete implementation of a service connection that binds to the {@code IInAppBillingService}, see the <a href="{@docRoot}/training/in-app-billing/preparing-iab-app.html#Connect">Selling In-app Products</a> training class.</p>
-<p>The following code sample shows how to verify whether the Google Play application supports
-in-app billing and confirm what version of the API it supports. In the sample, <code>mService</code>
-is an instance of the <code>MarketBillingService</code> interface.</p>
+<h2 id="billing-requests">Making In-app Billing Requests</h2>
+<p>Once your application is connected to Google Play, you can initiate purchase requests for in-app products. Google Play provides a checkout interface for users to enter their payment method, so your application does not need to handle payment transactions directly. When an item is purchased, Google Play recognizes that the user has ownership of that item and prevents the user from purchasing another item with the same product ID until it is consumed. You can control how the item is consumed in your application, and notify Google Play to make the item available for purchase again. You can also query Google Play to quickly retrieve the list of purchases that were made by the user. This is useful, for example, when you want to restore the user's purchases when your user launches your app.
+</p>
+<h3 id="QueryDetails">Querying for Items Available for Purchase</h3>
+<p>In your application, you can query the item details from Google Play using the In-app Billing Version 3 API. To pass a request to the In-app Billing service, first create a {@link android.os.Bundle} that contains a String {@link java.util.ArrayList} of product IDs with key "ITEM_ID_LIST", where each string is a product ID for an purchasable item.</p>
<pre>
-/**
-* Request type is CHECK_BILLING_SUPPORTED
-*/
- Bundle request = makeRequestBundle("CHECK_BILLING_SUPPORTED");
- Bundle response = mService.sendBillingRequest(request);
- // Do something with this response.
-}
+ArrayList<String> skuList = new ArrayList<String>();
+skuList.add("premiumUpgrade");
+skuList.add("gas");
+Bundle querySkus = new Bundle();
+querySkus.putStringArrayList(“ITEM_ID_LIST”, skuList);
</pre>
-
-<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
-three keys that are required for all requests: <code>BILLING_REQUEST</code>,
-<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. If you are offering subscriptions in
-your app, set the API_VERSION key to a value of "2", to confirm that In-app Billing v2 is
-available. For an examnple, see
-<a href="{@docRoot}google/play/billing/billing_subscriptions.html#version">Subscriptions</a>.</p>
-
-<p>The <code>CHECK_BILLING_SUPPORTED</code> request returns a synchronous {@link
-android.os.Bundle} response, which contains only a single key: <code>RESPONSE_CODE</code>. The
-<code>RESPONSE_CODE</code> key can have the following values:</p>
-<ul>
- <li><code>RESULT_OK</code>—the spedified version of in-app billing is supported.</li>
- <li><code>RESULT_BILLING_UNAVAILABLE</code>—in-app billing is not available because the API
- version you specified is not recognized or the user is not eligible to make in-app purchases (for
- example, the user resides in a country that prohibits in-app purchases).</li>
- <li><code>RESULT_ERROR</code>—there was an error connecting with the Google Play
- application.</li>
- <li><code>RESULT_DEVELOPER_ERROR</code>—the application is trying to make an in-app billing
- request but the application has not declared the <code>com.android.vending.BILLING</code>
- permission in its manifest. Can also indicate that an application is not properly signed, or that
- you sent a malformed request.</li>
-</ul>
-
-<p>The <code>CHECK_BILLING_SUPPORTED</code> request does not trigger any asynchronous responses
-(broadcast intents).</p>
-
-<p>We recommend that you invoke the <code>CHECK_BILLING_SUPPORTED</code> request within a
-<code>RemoteException</code> block. When your code throws a <code>RemoteException</code> it
-indicates that the remote method call failed, which means that the Google Play application is out
-of date and needs to be updated. In this case, you can provide users with an error message that
-contains a link to the <a
-href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google Play</a>
-Help topic.</p>
-
-<p>The sample application demonstrates how you can handle this error condition (see
-<code>DIALOG_CANNOT_CONNECT_ID</code> in <code>Dungeons.java</code>).</p>
-
-<h4>Making a purchase request (REQUEST_PURCHASE)</h4>
-
-<p>To make a purchase request you must do the following:</p>
-
-<ul>
- <li>Send the <code>REQUEST_PURCHASE</code> request.</li>
- <li>Launch the {@link android.app.PendingIntent} that is returned from the Google Play
- application.</li>
- <li>Handle the broadcast intents that are sent by the Google Play application.</li>
-</ul>
-
-<h5>Making the request</h5>
-
-<p>You must specify four keys in the request {@link android.os.Bundle}. The following code sample
-shows how to set these keys and make a purchase request for a single in-app item. In the sample,
-<code>mProductId</code> is the Google Play product ID of an in-app item (which is listed in the
-application's <a href="{@docRoot}google/play/billing/billing_admin.html#billing-list-setup">product
-list</a>), and <code>mService</code> is an instance of the <code>MarketBillingService</code>
-interface.</p>
-
+<p>To retrieve this information from Google Play, call the {@code getSkuDetails} method on the In-app Billing Version 3 API, and pass the method the In-app Billing API version (“3”), the package name of your calling app, the purchase type (“inapp”), and the {@link android.os.Bundle} that you created.</p>
<pre>
-/**
-* Request type is REQUEST_PURCHASE
-*/
- Bundle request = makeRequestBundle("REQUEST_PURCHASE");
- request.putString(ITEM_ID, mProductId);
- // Request is for a standard in-app product
- request.putString(ITEM_TYPE, "inapp");
- // Note that the developer payload is optional.
- if (mDeveloperPayload != null) {
- request.putString(DEVELOPER_PAYLOAD, mDeveloperPayload);
- }
- Bundle response = mService.sendBillingRequest(request);
- // Do something with this response.
+Bundle skuDetails = mService.getSkuDetails(3,
+ getPackageName(), “inapp”, querySkus);
</pre>
-<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
-three keys that are required for all requests: <code>BILLING_REQUEST</code>,
-<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The <code>ITEM_ID</code> key is then added
-to the Bundle prior to invoking the <code>sendBillingRequest()</code> method.</p>
-
-<p>The request returns a synchronous {@link android.os.Bundle} response, which contains three keys:
-<code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and <code>REQUEST_ID</code>. The
-<code>RESPONSE_CODE</code> key provides you with the status of the request and the
-<code>REQUEST_ID</code> key provides you with a unique request identifier for the request. The
-<code>PURCHASE_INTENT</code> key provides you with a {@link android.app.PendingIntent}, which you
-can use to launch the checkout UI.</p>
+<p>If the request is successful, the returned {@link android.os.Bundle}has a response code of {@code BILLING_RESPONSE_RESULT_OK} (0).</p>
+<p class="note"><strong>Warning:</strong> Do not call the {@code getSkuDetails} method on the main thread. Calling this method triggers a network request which could block your main thread. Instead, create a separate thread and call the {@code getSkuDetails} method from inside that thread.</p>
-<h5>Using the pending intent</h5>
+<p>To see all the possible response codes from Google Play, see <a href="{@docRoot}google/play/billing/billing_reference.html#billing-codes">In-app Billing Reference</a>.</p>
-<p>How you use the pending intent depends on which version of Android a device is running. On
-Android 1.6, you must use the pending intent to launch the checkout UI in its own separate task
-instead of your application's activity stack. On Android 2.0 and higher, you can use the pending
-intent to launch the checkout UI on your application's activity stack. The following code shows you
-how to do this. You can find this code in the <code>PurchaseObserver.java</code> file in the sample
-application.</p>
+<p>The query results are stored in a String ArrayList with key {@code DETAILS_LIST}. The purchase information is stored in the String in JSON format. To see the types of product detail information that are returned, see <a href="{@docRoot}google/play/billing/billing_reference.html#getSkuDetails">In-app Billing Reference</a>.</p>
+<p>In this example, you are retrieving the prices for your in-app items from the skuDetails {@link android.os.Bundle} returned from the previous code snippet.</p>
<pre>
-void startBuyPageActivity(PendingIntent pendingIntent, Intent intent) {
- if (mStartIntentSender != null) {
- // This is on Android 2.0 and beyond. The in-app checkout page activity
- // will be on the activity stack of the application.
- try {
- // This implements the method call:
- // mActivity.startIntentSender(pendingIntent.getIntentSender(),
- // intent, 0, 0, 0);
- mStartIntentSenderArgs[0] = pendingIntent.getIntentSender();
- mStartIntentSenderArgs[1] = intent;
- mStartIntentSenderArgs[2] = Integer.valueOf(0);
- mStartIntentSenderArgs[3] = Integer.valueOf(0);
- mStartIntentSenderArgs[4] = Integer.valueOf(0);
- mStartIntentSender.invoke(mActivity, mStartIntentSenderArgs);
- } catch (Exception e) {
- Log.e(TAG, "error starting activity", e);
- }
- } else {
- // This is on Android 1.6. The in-app checkout page activity will be on its
- // own separate activity stack instead of on the activity stack of
- // the application.
- try {
- pendingIntent.send(mActivity, 0 /* code */, intent);
- } catch (CanceledException e) {
- Log.e(TAG, "error starting activity", e);
- }
- }
+int response = skuDetails.getInt("RESPONSE_CODE");
+if (response == 0) {
+ ArrayList<String> responseList
+ = skuDetails.getStringArrayList("DETAILS_LIST");
+
+ for (String thisResponse : responseList) {
+ JSONObject object = new JSONObject(thisResponse);
+ String sku = object.getString("productId");
+ String price = object.getString("price");
+ if (sku.equals(“premiumUpgrade”)) mPremiumUpgradePrice = price;
+ else if (sku.equals(“gas”)) mGasPrice = price;
+ }
}
</pre>
-<p class="caution"><strong>Important:</strong> You must launch the pending intent from an activity
-context and not an application context. Also, you cannot use the <code>singleTop</code> <a
-href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">launch mode</a> to launch the
-pending intent. If you do either of these, the Android system will not attach the pending intent to
-your application process. Instead, it will bring Google Play to the foreground, disrupting your
-application.</p>
-
-<h5>Handling broadcast intents</h5>
-
-<p>A <code>REQUEST_PURCHASE</code> request also triggers two asynchronous responses (broadcast
-intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent,
-which provides error information about the request. If the request does not generate an
-error, the <code>RESPONSE_CODE</code> broadcast intent returns <code>RESULT_OK</code>, which
-indicates that the request was successfully sent. (To be clear, a <code>RESULT_OK</code> response
-does not indicate that the requested purchase was successful; it indicates that the request was sent
-successfully to Google Play.)</p>
-
-<p>Next, when the requested transaction changes state (for example, the purchase is successfully
-charged to a credit card or the user cancels the purchase), the Google Play application sends an
-<code>IN_APP_NOTIFY</code> broadcast intent. This message contains a notification ID, which you can
-use to retrieve the transaction details for the <code>REQUEST_PURCHASE</code> request.</p>
-
-<p class="note"><strong>Note:</strong> The Google Play application also sends
-an <code>IN_APP_NOTIFY</code> for refunds. For more information, see <a
-href="{@docRoot}google/play/billing/billing_overview.html#billing-action-notify">Handling
-IN_APP_NOTIFY messages</a>.</p>
-
-<p>Because the purchase process is not instantaneous and can take several seconds (or more), you
-must assume that a purchase request is pending from the time you receive a <code>RESULT_OK</code>
-message until you receive an <code>IN_APP_NOTIFY</code> message for the transaction. While the
-transaction is pending, the Google Play checkout UI displays an "Authorizing purchase..."
-notification; however, this notification is dismissed after 60 seconds and you should not rely on
-this notification as your primary means of conveying transaction status to users. Instead, we
-recommend that you do the following:</p>
-
-<ul>
- <li>Add an {@link android.app.Activity} to your application that shows users the status of pending
-and completed in-app purchases.</li>
- <li>Use a <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html">status
-bar notification</a> to keep users informed about the progress of a purchase.</li>
-</ul>
-
-<p>To use these two UI elements, you could invoke a status bar notification with a ticker-text
-message that says "Purchase pending" when your application receives a <code>RESULT_OK</code>
-message. Then, when your application receives an <code>IN_APP_NOTIFY</code> message, you could
-update the notification with a new message that says "Purchase succeeded" or "Purchase failed." When
-a user touches the expanded status bar notification, you could launch the activity that shows the
-status of pending and completed in-app purchases.</p>
-
-<p>If you use some other UI technique to inform users about the state of a pending transaction,
-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 Google Play.</p>
-
-<p class="caution"><strong>Important:</strong> If a user purchases a managed item, you must prevent
-the user from purchasing the item again while the original transaction is pending. If a user
-attempts to purchase a managed item twice, and the first transaction is still pending, Google
-Play will display an error to the user; however, Google Play will not send an error to your
-application notifying you that the second purchase request was canceled. This might cause your
-application to get stuck in a pending state while it waits for an <code>IN_APP_NOTIFY</code> message
-for the second purchase request.</p>
-
-<h4>Retrieving transaction information for a purchase or refund (GET_PURCHASE_INFORMATION)</h4>
-
-<p>You retrieve transaction information in response to an <code>IN_APP_NOTIFY</code> broadcast
-intent. The <code>IN_APP_NOTIFY</code> message contains a notification ID, which you can use to
-retrieve transaction information.</p>
-
-<p>To retrieve transaction information for a purchase or refund you must specify five keys in the
-request {@link android.os.Bundle}. The following code sample shows how to set these keys and make
-the request. In the sample, <code>mService</code> is an instance of the
-<code>MarketBillingService</code> interface.</p>
+<h3 id="Purchase">Purchasing an Item</h3>
+<p>To start a purchase request from your app, call the {@code getBuyIntent} method on the In-app Billing service. Pass in to the method the In-app Billing API version (“3”), the package name of your calling app, the product ID for the item to purchase, the purchase type (“inapp”), and a {@code developerPayload} String. The {@code developerPayload} String is used to specify any additional arguments that you want Google Play to send back along with the purchase information.</p>
<pre>
-/**
-* Request type is GET_PURCHASE_INFORMATION
-*/
- Bundle request = makeRequestBundle("GET_PURCHASE_INFORMATION");
- request.putLong(REQUEST_NONCE, mNonce);
- request.putStringArray(NOTIFY_IDS, mNotifyIds);
- Bundle response = mService.sendBillingRequest(request);
- // Do something with this response.
-}
+Bundle buyIntentBundle = mService.getBuyIntent(3, getPackageName(),
+ sku, "inapp", "bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ");
</pre>
-<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
-three keys that are required for all requests: <code>BILLING_REQUEST</code>,
-<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional keys are then added to the
-bundle prior to invoking the <code>sendBillingRequest()</code> method. The
-<code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you
-must generate. The Google Play application returns this nonce with the
-<code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the integrity of the
-transaction information. The <code>NOTIFY_IDS</code> key contains an array of notification IDs,
-which you received in the <code>IN_APP_NOTIFY</code> broadcast intent.</p>
-
-<p>The request returns a synchronous {@link android.os.Bundle} response, which contains two keys:
-<code>RESPONSE_CODE</code> and <code>REQUEST_ID</code>. The <code>RESPONSE_CODE</code> key provides
-you with the status of the request and the <code>REQUEST_ID</code> key provides you with a unique
-request identifier for the request.</p>
-
-<p>A <code>GET_PURCHASE_INFORMATION</code> request also triggers two asynchronous responses
-(broadcast intents). First, the Google Play application sends a <code>RESPONSE_CODE</code>
-broadcast intent, which provides status and error information about the request. Next, if the
-request was successful, the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code>
-broadcast intent. This message contains detailed transaction information. The transaction
-information is contained in a signed JSON string (unencrypted). The message includes the signature
-so you can verify the integrity of the signed string.</p>
-
-<h4>Acknowledging transaction information (CONFIRM_NOTIFICATIONS)</h4>
-
-<p>To acknowledge that you received transaction information you send a
-<code>CONFIRM_NOTIFICATIONS</code> 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 the request. In
-the sample, <code>mService</code> is an instance of the <code>MarketBillingService</code>
-interface.</p>
-
+<p>
+If the request is successful, the returned {@link android.os.Bundle} has a response code of {@code BILLING_RESPONSE_RESULT_OK} (0) and a {@link android.app.PendingIntent} that you can use to start the purchase flow. To see all the possible response codes from Google Play, see <a href="{@docRoot}google/play/billing/billing_reference.html#billing-codes">In-app Billing Reference</a>. Next, extract a {@link android.app.PendingIntent} from the response {@link android.os.Bundle} with key {@code BUY_INTENT}.
+</p>
<pre>
-/**
-* Request type is CONFIRM_NOTIFICATIONS
-*/
- Bundle request = makeRequestBundle("CONFIRM_NOTIFICATIONS");
- request.putStringArray(NOTIFY_IDS, mNotifyIds);
- Bundle response = mService.sendBillingRequest(request);
- // Do something with this response.
-}
+PendingIntent pendingIntent = buyIntentBundle.getParcelable(“BUY_INTENT”);
</pre>
-<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
-three keys that are required for all requests: <code>BILLING_REQUEST</code>,
-<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional <code>NOTIFY_IDS</code> key
-is then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The
-<code>NOTIFY_IDS</code> key contains an array of notification IDs, which you received in an
-<code>IN_APP_NOTIFY</code> broadcast intent and also used in a <code>GET_PURCHASE_INFORMATION</code>
-request.</p>
-
-<p>The request returns a synchronous {@link android.os.Bundle} response, which contains two keys:
-<code>RESPONSE_CODE</code> and <code>REQUEST_ID</code>. The <code>RESPONSE_CODE</code> key provides
-you with the status of the request and the <code>REQUEST_ID</code> key provides you with a unique
-request identifier for the request.</p>
-
-<p>A <code>CONFIRM_NOTIFICATIONS</code> request triggers a single asynchronous response—a
-<code>RESPONSE_CODE</code> broadcast intent. This broadcast intent provides status and error
-information about the request.</p>
-
-<p>You must send a confirmation when you receive transaction information from Google Play. If you
-don't send a confirmation message, Google Play will continue sending
-<code>IN_APP_NOTIFY</code> messages for the transactions you have not confirmed. Also,
-your application must be able to handle <code>IN_APP_NOTIFY</code> messages that contain multiple
-orders.</p>
-
-<p>In addition, as a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request
-for a purchased item until you have delivered the item to the user. This way, if your application
-crashes or something else prevents your application from delivering the product, your application
-will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating
-that you need to deliver the product.</p>
-
-<h4>Restoring transaction information (RESTORE_TRANSACTIONS)</h4>
-
-<p>To restore a user's transaction information, you send a <code>RESTORE_TRANSACTIONS</code>
-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 the request. In the sample, <code>mService</code> is an
-instance of the <code>MarketBillingService</code> interface.</p>
-
+<p>
+To complete the purchase transaction, call the {@link android.app.Activity#startIntentSenderForResult startIntentSenderForResult} method and use the {@link android.app.PendingIntent} that you created. In this example, you are using an arbitrary value of 1001 for the request code.</p>
<pre>
-/**
-* Request type is RESTORE_TRANSACTIONS
-*/
- Bundle request = makeRequestBundle("RESTORE_TRANSACTIONS");
- request.putLong(REQUEST_NONCE, mNonce);
- Bundle response = mService.sendBillingRequest(request);
- // Do something with this response.
-}
+startIntentSenderForResult(pendingIntent.getIntentSender(),
+ 1001, new Intent(), Integer.valueOf(0), Integer.valueOf(0),
+ Integer.valueOf(0));
</pre>
-<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
-three keys that are required for all requests: <code>BILLING_REQUEST</code>,
-<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional <code>REQUEST_NONCE</code>
-key is then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The
-<code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you
-must generate. The Google Play application returns this nonce with the transactions information
-contained in the <code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the
-integrity of the transaction information.</p>
-
-<p>The request returns a synchronous {@link android.os.Bundle} response, which contains two keys:
-<code>RESPONSE_CODE</code> and <code>REQUEST_ID</code>. The <code>RESPONSE_CODE</code> key provides
-you with the status of the request and the <code>REQUEST_ID</code> key provides you with a unique
-request identifier for the request.</p>
-
-<p>A <code>RESTORE_TRANSACTIONS</code> request also triggers two asynchronous responses (broadcast
-intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent,
-which provides status and error information about the request. Next, if the request was successful,
-the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This
-message contains the detailed transaction information. The transaction information is contained in a
-signed JSON string (unencrypted). The message includes the signature so you can verify the integrity
-of the signed string.</p>
-
-<p class="note"><strong>Note:</strong> You should use the <code>RESTORE_TRANSACTIONS</code>
-request type only when your application is installed for the first time on a device or when your
-application has been removed from a device and reinstalled.</p>
-
-<h3>Other service tasks</h3>
-
-<p>You may also want your {@link android.app.Service} to receive intent messages from your {@link
-android.content.BroadcastReceiver}. You can use these intent messages to convey the information that
-was sent asynchronously from the Google Play application to your {@link
-android.content.BroadcastReceiver}. To see an example of how you can send and receive these intent
-messages, see the <code>BillingReceiver.java</code> and <code>BillingService.java</code> files in
-the sample application. You can use these samples as a basis for your own implementation. However,
-if you use any of the code from the sample application, be sure you follow the guidelines in <a
-href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>.</p>
-
-<h2 id="billing-broadcast-receiver">Creating a BroadcastReceiver</h2>
-
-<p>The Google Play application uses broadcast intents to send asynchronous billing responses to
-your application. To receive these intent messages, you need to create a {@link
-android.content.BroadcastReceiver} that can handle the following intents:</p>
-
-<ul>
- <li>com.android.vending.billing.RESPONSE_CODE
- <p>This broadcast intent contains a Google Play response code, and is sent after you make an
- in-app billing request. For more information about the response codes that are sent with this
- response, see <a
- href="{@docRoot}google/play/billing/billing_reference.html#billing-codes">Google Play Response
- Codes for In-app Billing</a>.</p>
- </li>
- <li>com.android.vending.billing.IN_APP_NOTIFY
- <p>This response indicates that a purchase has changed state, which means a purchase succeeded,
- was canceled, or was refunded. For more information about notification messages, see <a
- href="{@docRoot}google/play/billing/billing_reference.html#billing-intents">In-app Billing
- Broadcast Intents</a></p>
- </li>
- <li>com.android.vending.billing.PURCHASE_STATE_CHANGED
- <p>This broadcast intent contains detailed information about one or more transactions. For more
- information about purchase state messages, see <a
- href="{@docRoot}google/play/billing/billing_reference.html#billing-intents">In-app Billing
- Broadcast Intents</a></p>
- </li>
-</ul>
-
-<p>Each of these broadcast intents provide intent extras, which your {@link
-android.content.BroadcastReceiver} must handle. The intent extras are listed in the following table
-(see table 1).</p>
-
-<p class="table-caption"><strong>Table 1.</strong> Description of broadcast intent extras that are
-sent in response to billing requests.</p>
-
-<table>
-
-<tr>
-<th>Intent</th>
-<th>Extra</th>
-<th>Description</th>
-</tr>
-<tr>
- <td><code>com.android.vending.billing.RESPONSE_CODE</code></td>
- <td><code>request_id</code></td>
- <td>A <code>long</code> representing a request ID. A request ID identifies a specific billing
- request and is returned by Google Play at the time a request is made.</td>
-</tr>
-<tr>
- <td><code>com.android.vending.billing.RESPONSE_CODE</code></td>
- <td><code>response_code</code></td>
- <td>An <code>int</code> representing the actual Google Play server response code.</td>
-</tr>
-<tr>
- <td><code>com.android.vending.billing.IN_APP_NOTIFY</code></td>
- <td><code>notification_id</code></td>
- <td>A <code>String</code> representing the notification ID for a given purchase state change.
- Google Play notifies you when there is a purchase state change and the notification includes a
- unique notification ID. To get the details of the purchase state change, you send the notification
- ID with the <code>GET_PURCHASE_INFORMATION</code> request.</td>
-</tr>
-<tr>
- <td><code>com.android.vending.billing.PURCHASE_STATE_CHANGED</code></td>
- <td><code>inapp_signed_data</code></td>
- <td>A <code>String</code> representing the signed JSON string. The JSON string contains
- information about the billing transaction, such as order number, amount, and the item that was
- purchased or refunded.</td>
-</tr>
-<tr>
- <td><code>com.android.vending.billing.PURCHASE_STATE_CHANGED</code></td>
- <td><code>inapp_signature</code></td>
- <td>A <code>String</code> representing the signature of the JSON string.</td>
-</tr>
-</table>
-
-<p>The following code sample shows how to handle these broadcast intents and intent extras within a
-{@link android.content.BroadcastReceiver}. The BroadcastReceiver in this case is named
-<code>BillingReceiver</code>, just as it is in the sample application.</p>
+<p>Google Plays sends a response to your {@link android.app.PendingIntent} to the {@link android.app.Activity#onActivityResult onActivityResult} method of your application. The {@link android.app.Activity#onActivityResult onActivityResult} method will have a result code of {@code Activity.RESULT_OK} (1) or {@code Activity.RESULT_CANCELED} (0). To see the types of order information that is returned in the response {@link android.content.Intent}, see <a href="{@docRoot}google/play/billing/billing_reference.html#getBuyIntent">In-app Billing Reference</a>.</p>
+<p>The purchase data for the order is a String in JSON format that is mapped to the {@code INAPP_PURCHASE_DATA} key in the response {@link android.content.Intent}, for example:
<pre>
-public class BillingReceiver extends BroadcastReceiver {
-
- private static final String TAG = "BillingReceiver";
-
- // 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 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";
- public static final String INAPP_SIGNATURE = "inapp_signature";
- public static final String INAPP_REQUEST_ID = "request_id";
- public static final String INAPP_RESPONSE_CODE = "response_code";
-
+'{
+ "orderId":"12999763169054705758.1371079406387615",
+ "packageName":"com.example.app",
+ "productId":"exampleSku",
+ "purchaseTime":1345678900000,
+ "purchaseState":0,
+ "developerPayload":"bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ",
+ “purchaseToken”:“rojeslcdyyiapnqcynkjyyjh”
+ }'
+</pre>
+</p>
- @Override
- public void onReceive(Context context, Intent intent) {
- String action = intent.getAction();
- if (ACTION_PURCHASE_STATE_CHANGED.equals(action)) {
- String signedData = intent.getStringExtra(INAPP_SIGNED_DATA);
- String signature = intent.getStringExtra(INAPP_SIGNATURE);
- // Do something with the signedData and the signature.
- } else if (ACTION_NOTIFY.equals(action)) {
- String notifyId = intent.getStringExtra(NOTIFICATION_ID);
- // Do something with the notifyId.
- } else if (ACTION_RESPONSE_CODE.equals(action)) {
- long requestId = intent.getLongExtra(INAPP_REQUEST_ID, -1);
- int responseCodeIndex = intent.getIntExtra(INAPP_RESPONSE_CODE,
- ResponseCode.RESULT_ERROR.ordinal());
- // Do something with the requestId and the responseCodeIndex.
- } else {
- Log.w(TAG, "unexpected action: " + action);
- }
- }
- // Perform other processing here, such as forwarding intent messages to your local service.
+<p>Continuing from the previous example, you get the response code, purchase data, and signature from the response {@link android.content.Intent}.</p>
+<pre>
+@Override
+protected void onActivityResult(int requestCode, int resultCode, Intent data) {
+ if (requestCode == 1001) {
+ int responseCode = data.getIntExtra("RESPONSE_CODE", 0);
+ String purchaseData = data.getStringExtra(“INAPP_PURCHASE_DATA”);
+ String dataSignature = data.getStringExtra(“INAPP_DATA_SIGNATURE”);
+
+ if (resultCode == RESULT_OK) {
+ try {
+ JSONObject jo = new JSONObject(purchaseData);
+ String sku = jo.getString("productId");
+ alert("You have bought the " + sku + ". Excellent choice,
+ adventurer!");
+ }
+ catch (JSONException e) {
+ alert("Failed to parse purchase data.");
+ e.printStackTrace();
+ }
+ }
+ }
}
</pre>
+<p class="note"><strong>Security Recommendation:</strong> When you send a purchase request, create a String token that uniquely identifies this purchase request and include this token in the {@code developerPayload}.You can use a randomly generated string as the token. When you receive the purchase response from Google Play, make sure to check the returned data signature, the {@code orderId}, and the {@code developerPayload} String. For added security, you should perform the checking on your own secure server. Make sure to verify that the {@code orderId} is a unique value that you have not previously processed, and the {@code developerPayload} String matches the token that you sent previously with the purchase request.</p>
-<p>In addition to receiving broadcast intents from the Google Play application, your {@link
-android.content.BroadcastReceiver} must handle the information it received in the broadcast intents.
-Usually, your {@link android.content.BroadcastReceiver} does this by sending the information to a
-local service (discussed in the next section). The <code>BillingReceiver.java</code> file in the
-sample application shows you how to do this. You can use this sample as a basis for your own {@link
-android.content.BroadcastReceiver}. However, if you use any of the code from the sample application,
-be sure you follow the guidelines that are discussed in <a
-href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design </a>.</p>
-
-<h2 id="billing-signatures">Verifying Signatures and Nonces</h2>
-
-<p>Google Play's in-app billing service uses two mechanisms to help verify the integrity of the
-transaction information you receive from Google Play: nonces and signatures. A nonce (number used
-once) is a cryptographically secure number that your application generates and sends with every
-<code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is
-returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, enabling you to verify that
-any given <code>PURCHASE_STATE_CHANGED</code> response corresponds to an actual request that you
-made. Every <code>PURCHASE_STATE_CHANGED</code> broadcast intent also includes a signed JSON string
-and a signature, which you can use to verify the integrity of the response.</p>
-
-<p>Your application must provide a way to generate, manage, and verify nonces. The following sample
-code shows some simple methods you can use to do this.</p>
-
+<h3 id="QueryPurchases">Querying for Purchased Items</h3>
+<p>To retrieve information about purchases made by a user from your app, call the {@code getPurchases} method on the In-app Billing Version 3 service. Pass in to the method the In-app Billing API version (“3”), the package name of your calling app, and the purchase type (“inapp”).</p>
<pre>
- private static final SecureRandom RANDOM = new SecureRandom();
- private static HashSet<Long> sKnownNonces = new HashSet<Long>();
-
- public static long generateNonce() {
- long nonce = RANDOM.nextLong();
- sKnownNonces.add(nonce);
- return nonce;
- }
-
- public static void removeNonce(long nonce) {
- sKnownNonces.remove(nonce);
- }
-
- public static boolean isNonceKnown(long nonce) {
- return sKnownNonces.contains(nonce);
- }
+Bundle ownedItems = mService.getPurchases(3, getPackageName(), “inapp”, null);
</pre>
+<p>The Google Play service returns only the purchases made by the user account that is currently logged in to the device. If the request is successful, the returned {@link android.os.Bundle} has a response code of 0. The response {@link android.os.Bundle} also contains a list of the product IDs, a list of the order details for each purchase, and the signatures for each purchase.</p>
+<p>To improve performance, the In-app Billing service returns only up to 700 products that are owned by the user when {@code getPurchase} is first called. If the user owns a large number of products, Google Play includes a String token mapped to the key {@code INAPP_CONTINUATION_TOKEN} in the response {@link android.os.Bundle} to indicate that more products can be retrieved. Your application can then make a subsequent {@code getPurchases} call, and pass in this token as an argument. Google Play continues to return a continuation token in the response {@link android.os.Bundle} until all products that are owned by the user has been sent to your app.</p>
+<p>For more information about the data returned by {@code getPurchases}, see <a href="{@docRoot}google/play/billing/billing_reference.html#getPurchases">In-app Billing Reference</a>. The following example shows how you can retrieve this data from the response.
+<pre>
+int response = ownedItems.getInt("RESPONSE_CODE");
+if (response == 0) {
+ ArrayList<String> ownedSkus =
+ ownedItems.getStringArrayList("INAPP_PURCHASE_ITEM_LIST");
+ ArrayList<String> purchaseDataList =
+ ownedItems.getStringArrayList("INAPP_PURCHASE_DATA_LIST");
+ ArrayList<String> signatureList =
+ ownedItems.getStringArrayList("INAPP_DATA_SIGNATURE");
+ String continuationToken =
+ ownedItems.getString("INAPP_CONTINUATION_TOKEN");
+
+ for (int i = 0; i < purchaseDataList.size(); ++i) {
+ String purchaseData = purchaseDataList.get(i);
+ String signature = signatureList.get(i);
+ String sku = ownedSkus.get(i);
+
+ // do something with this purchase information
+ // e.g. display the updated list of products owned by user
+ }
+
+ // if continuationToken != null, call getPurchases again
+ // and pass in the token to retrieve more items
+}
-<p>Your application must also provide a way to verify the signatures that accompany every
-<code>PURCHASE_STATE_CHANGED</code> broadcast intent. The <code>Security.java</code> file in the
-sample application shows you how to do this. If you use this file as a basis for your own security
-implementation, be sure to follow the guidelines in <a
-href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a> and
-obfuscate your code.</p>
-
-<p>You will need to use your Google Play public key to perform the signature verification. The
-following procedure shows you how to retrieve Base64-encoded public key from the Google Play
-publisher site.</p>
-
-<ol>
- <li>Log in to your <a href="http://play.google.com/apps/publish">publisher account</a>.</li>
- <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li>
- <li>On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure
- 2).</li>
- <li>Copy your public key.</li>
-</ol>
-
-<p class="caution"><strong>Important</strong>: To keep your public key safe from malicious users and
-hackers, do not embed your public key as an entire 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 information, but you do not want to make it easy for a
-hacker or malicious user to replace the public key with another key.</p>
-
-<img src="{@docRoot}images/billing_public_key.png" height="510" id="figure2" />
-<p class="img-caption">
- <strong>Figure 2.</strong> The Licensing and In-app Billing panel of your account's Edit Profile
- page lets you see your public key.
-</p>
+</pre>
-<h2 id="billing-implement">Modifying Your Application Code</h2>
+<h3 id="Consume">Consuming a Purchase</h3>
+<p>You can use the In-app Billing Version 3 API to track the ownership of purchased items in Google Play. Once an item is purchased, it is considered to be "owned" and cannot be purchased from Google Play. You must send a consumption request for the item before Google Play makes it available for purchase again. All managed in-app products are consumable. How you use the consumption mechanism in your app is up to you. Typically, you would implement consumption for products with temporary benefits that users may want to purchase multiple times (for example, in-game currency or equipment). You would typically not want to implement consumption for products that are purchased once and provide a permanent effect (for example, a premium upgrade).</p>
+<p>To record a purchase consumption, send the {@code consumePurchase} method to the In-app Billing service and pass in the {@code purchaseToken} String value that identifies the purchase to be removed. The {@code purchaseToken} is part of the data returned in the {@code INAPP_PURCHASE_DATA} String by the Google Play service following a successful purchase request. In this example, you are recording the consumption of a product that is identified with the {@code purchaseToken} in the {@code token} variable.</p>
+<pre>
+int response = mService.consumePurchase(3, getPackageName(), token);
+</pre>
+<p class="note"><strong>Warning:</strong> Do not call the {@code consumePurchase} method on the main thread. Calling this method triggers a network request which could block your main thread. Instead, create a separate thread and call the {@code consumePurchase} method from inside that thread.</p>
+<p>It's your responsibility to control and track how the in-app product is provisioned to the user. For example, if the user purchased in-game currency, you should update the player's inventory with the amount of currency purchased.</p>
+<p class="note"><strong>Security Recommendation:</strong> You must send a consumption request before provisioning the benefit of the consumable in-app purchase to the user. Make sure that you have received a successful consumption response from Google Play before you provision the item.</p>
-<p>After you finish adding in-app billing components to your project, you are ready to modify your
-application's code. For a typical implementation, like the one that is demonstrated in the sample
-application, this means you need to write code to do the following: </p>
-<ul>
- <li>Create a storage mechanism for storing users' purchase information.</li>
- <li>Create a user interface that lets users select items for purchase.</li>
-</ul>
-<p>The sample code in <code>Dungeons.java</code> shows you how to do both of these tasks.</p>
-<h3>Creating a storage mechanism for storing purchase information</h3>
-<p>You must set up a database or some other mechanism for storing users' purchase information. The
-sample application provides an example database (PurchaseDatabase.java); however, the example
-database has been simplified for clarity and does not exhibit the security best practices that we
-recommend. If you have a remote server, we recommend that you store purchase information on your
-server instead of in a local database on a device. For more information about security best
-practices, see <a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
-Design</a>.</p>
-<p class="note"><strong>Note</strong>: If you store any purchase information on a device, be sure to
-encrypt the data and use a device-specific encryption key. Also, if the purchase type for any of
-your items is "unmanaged," we recommend that you back up the purchase information for these items to
-a remote server or use Android's <a href="{@docRoot}guide/topics/data/backup.html">data
-backup</a> framework to back up the purchase information. Backing up purchase information for
-unmanaged items is important because unmanaged items cannot be restored by using the
-<code>RESTORE_TRANSACTIONS</code> request type.</p>
-<h3>Creating a user interface for selecting items</h3>
-<p>You must provide users with a means for selecting items that they want to purchase. Google
-Play provides the checkout user interface (which is where the user provides a form of payment and
-approves the purchase), but your application must provide a control (widget) that invokes the
-<code>sendBillingRequest()</code> method when a user selects an item for purchase.</p>
-<p>You can render the control and trigger the <code>sendBillingRequest()</code> method any way you
-want. The sample application uses a spinner widget and a button to present items to a user and
-trigger a billing request (see <code>Dungeons.java</code>). The user interface also shows a list of
-recently purchased items.</p>
<div id="qv-wrapper">
<div id="qv">
+ <h2>Quickview</h2>
+ <ul>
+ <li>Use In-app Billing to sell digital goods, including one-time items and recurring subscriptions.</li>
+ <li>Supported for any app published on Google Play. You only need a Google Play publisher account and a Google Checkout Merchant account.</li>
+ <li>Checkout processing is automatically handled by Google Play, with the same look-and-feel as for app purchases.</li>
+ </ul>
<h2>In this document</h2>
<ol>
- <li><a href="#billing-types">Product and Purchase Types</a></li>
- <li><a href="#billing-arch">In-app Billing Architecture</a></li>
- <li><a href="#billing-msgs">In-app Billing Messages</a></li>
- <ol>
- <li><a href="#billing-request">Request messages</a></li>
- <li><a href="#billing-response">Broadcast intents</a></li>
- <li><a href="#billing-message-sequence">Messaging sequence</a></li>
- <li><a href="#billing-action-notify">Handling IN_APP_NOTIFY messages</a></li>
- </ol>
- <li><a href="#billing-security">Security Controls</a></li>
- <li><a href="#billing-limitations">Requirements and Limitations</a></li>
+ <li><a href="#api">In-app Billing API</a></li>
+ <li><a href="#products">In-app Products</a>
+ <ol>
+ <li><a href="#prodtypes">Product Types</a>
+ </ol>
+ </li>
+ <li><a href="#console">Google Play Developer Console</a></li>
+ <li><a href="#checkout">Google Play Purchase Flow</a></li>
+ <li><a href="#samples">Sample Apps</a></li>
+ <li><a href="#migration">Migration Considerations</a></li>
</ol>
- <h2>Downloads</h2>
+ <h2>Related Samples</h2>
<ol>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">Sample
- Application</a></li>
- </ol>
- <h2>See also</h2>
- <ol>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html">Implementing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
- Design</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
- Reference</a></li>
- </ol>
+ <li><a href="{@docRoot}training/in-app-billing/preparing-iab-app.html#GetSample">Sample Application (V3)</a></li>
+ <li><a href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">Sample
+ Application (V2)</a></li>
+ </ol>
</div>
</div>
-<p>In-app Billing is a Google Play service that provides checkout processing for
-in-app purchases. To use the service, your application sends a billing request for a specific in-app
-product. The service then handles all of the checkout details for the transaction, including
-requesting and validating the form of payment and processing the financial transaction. When the
-checkout process is complete, the service sends your application the purchase details, such as the
-order number, the order date and time, and the price paid. At no point does your application have to
-handle any financial transactions; that role is provided by Google Play's in-app billing
-service.</p>
-
-<h2 id="billing-types">Product and Purchase Types</h2>
-
-<p>In-app Billing supports different product types and purchase types to give you flexibility in how you monetize your app. In all cases, you define your products using the Google Play Developer Console, including product type, purchase type, SKU, price, description, and so on. For more information, see <a href="billing_admin.html">Administering In-app Billing</a>.</p>
-
-<h3 id="producttypes">Product Types</h3>
-
-<p>With In-app Billing, you can sell two types of products — <em>in-app products</em> and <em>subscriptions</em>. The billing characteristics of the two types are very different, but the In-app Billing API lets you handle the two product types in your app using the same communication model, data structures, and user interactions, as described later in this document.</p>
-
+<p>This documentation describes the fundamental In-app Billing components and
+features that you need to understand in order to implement your own In-app
+Billing application.</p>
+
+<h2 id="api">In-app Billing API</h2>
+<p>Your application accesses the In-app Billing service using an API that is
+exposed by the Google Play app that is installed on the device. The Google Play
+app then conveys billing requests and responses between your
+application and the Google Play server. In practice, your application never
+directly communicates with the Google Play server. Instead, your application
+sends billing requests to the Google Play application over interprocess
+communication (IPC) and receives responses from the Google Play app.
+Your application does not manage any network connections between itself and
+the Google Play server.</p>
+<p>In-app Billing can be implemented only in applications that you publish
+through Google Play. To complete in-app purchase requests, the Google Play app
+must be able to access the Google Play server over the network.</p>
+
+<p>Currently, Google Play supports two versions of the In-app Billing API.
+To determine which version you should use, see <a href="#migration">Migration
+Considerations</a>.</p>
+<h4><a href="{@docRoot}google/play/billing/api.html">Version 3</a> (recommended)</h4>
<ul>
-<li><em>In-app products</em> — Items that a user would purchase one-at-a-time. For example, typical in-app products would let users purchase digital content, unlock functionality in an app, pay for one-time charges, or add almost anything to the application experience. Unlike with priced applications, once the user has purchased an in-app product there is no refund window. Users desiring refunds must contact the developer directly.
-
-<p>In-app products can be sold using either the "managed per user account" or "unmanaged" purchase type. In-app products are always explicitly associated with one and only one app. That is, one app cannot purchase an in-app product published for another app, even if they are from the same developer. In-app products are supported in all versions of In-app Billing.</p></li>
-
-<li><em>Subscriptions</em> — Items that are sold with a developer-specified, recurring billing interval. When a user purchases a subscription, Google Play and its payment processor automatically bill the user's account at the specified interval and price, charging the amount to the original payment method. Once the user purchases a subscription, Google Play continues billing the account indefinitely, without requiring approval or action from the user. The user can cancel the subscription at any time.
-
-<p>Subscriptions can only be sold using the "managed per user account" purchase type. As with in-app products, once the user has purchased an in-app product there is no refund window. Users desiring refunds must contact the developer directly. For more information about subscriptions and how to sell them in your apps, see the <a href="billing_subscriptions.html">Subscriptions</a> document.</p></li>
+<li>Requests are sent through a streamlined API that allows you to easily request
+product details from Google Play, order in-app products, and quickly restore
+items based on users' product ownership</li>
+<li>Order information is synchronously propagated to the device on purchase
+completion</li>
+<li>All purchases are “managed” (that is, Google Play keeps track of the user's
+ownership of in-app products). The user cannot own multiple copies of an in-app
+item; only one copy can be owned at any point in time</li>
+<li>Purchased items can be consumed. When consumed, the item reverts to the
+"unowned" state and can be purchased again from Google Play</li>
</ul>
-
-<h3 id="purchasetypes">Purchase Types</h3>
-
-<p>In-app Billing offers two purchase types that you can use when selling in-app products, "managed per user account" and "unmanaged". The purchase type controls how Google Play handles and tracks purchases for the products. </p>
-
+<h4><a href="{@docRoot}google/play/billing/v2/api.html">Version 2</a></h4>
<ul>
-<li><em>Managed per user account</em> — Items that can be purchased only once per user account on Google Play. When a user purchases an item that uses the "managed per user account" purchase type, Google Play permanently stores the transaction information for each item on a per-user basis. This enables you to later query Google Play to 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, Google Play prevents the user from purchasing the item again and displays an "Item already purchased" error.
-
-<p>The "managed per user account" purchase type is useful if you are selling items such as game levels or application features. These items are not transient and usually need to be restored whenever a user reinstalls your application, wipes the data on their device, or installs your application on a new device.</p>
-
-<li><em>Unmanaged</em> — Items that do not have their transaction information stored on Google Play. This means that you cannot later query Google Play to retrieve transaction information for those items. For "unmanaged" purchases, you are responsible for managing the transaction information. Also, Google Play does not attempt to prevent the user from purchasing an item multiple times if it uses the "unmanaged" purchase type. It's up to you to control how many times an unmanaged item can be purchased.</p>
-
-<p>The "unmanaged" purchase type is useful if you are selling consumable items, such as fuel or magic spells. These items are consumed within your application and are usually purchased multiple times.</p></li>
+<li>Requests are sent via a single API interface ({@code sendBillingRequest})</li>
+<li>Responses from Google Play are asynchronous, in the form of broadcast intents</li>
+<li>No consumption model provided. You have to implement your own solution</li>
+<li>Provides support for subscriptions and unmanaged in-app purchase items,
+as well as managed in-app products</li>
</ul>
-
-<h2 id="billing-arch">In-app Billing Architecture</h2>
-
-<p>Your app accesses the In-app Billing service using an API that is exposed by
-the Google Play app installed on the device. The Google Play app then uses an
-asynchronous message loop to convey billing requests and responses between your
-application and the Google Play server. In practice, your application never
-directly communicates with the Google Play server (see figure 1). Instead, your
-application sends billing requests to the Google Play application over
-interprocess communication (IPC) and receives purchase responses from the Google
-Play application in the form of asynchronous broadcast intents. Your application
-does not manage any network connections between itself and the Google Play
-server or use any special APIs from the Android platform.</p>
-
-<div class="figure" style="width:440px">
-<img src="{@docRoot}images/billing_arch.png" alt="" height="582" />
+<p>Both versions offer very broad compatibility across the range of Android
+devices. In-app Billing Version 3 is supported on devices running Android 2.2 or
+higher that have the latest version of the Google Play store installed
+(over 90% of active devices). Version 2 offers similar compatibility. See
+<a href="{@docRoot}google/play/billing/versions.html">Version Notes</a> for
+more details.</p>
+
+<h2 id="products">In-app Products</h2>
+<p>In-app products are the digital goods that you offer for sale from inside your
+application to users. Examples of digital goods includes in-game currency,
+application feature upgrades that enhance the user experience, and new content
+for your application.</p>
+<p>You can use In-app Billing to sell only digital content.
+You cannot use In-app Billing to sell physical goods, personal services, or
+anything that requires physical delivery. Unlike with priced applications, once
+the user has purchased an in-app product there is no refund window.</p>
+<p>Google Play does not provide any form of content delivery. You are
+responsible for delivering the digital content that you sell in your
+applications. In-app products are always explicitly associated with one and
+only one app. That is, one application cannot purchase an in-app product
+published for another app, even if they are from the same developer.</p>
+
+<h3 id="prodtypes">Product types</h3>
+<p>In-app Billing supports different product types to give you flexibility in
+how you monetize your application. In all cases, you define your products using
+the Google Play Developer Console.</p>
+<p>You can specify these types of products for your In-app Billing application
+— <em>managed in-app products</em>, <em>subscriptions</em>, and <em>unmanaged
+in-app products</em>. The term “managed” indicates that Google Play handles and
+tracks ownership for in-app products on your application on a per user account
+basis, while “unmanaged” indicates that you will manage the ownership information yourself.</p>
+<p>To learn more about the product types supported by the different API versions,
+see the related documentation for <a href="{@docRoot}google/play/billing/v2/api.html#billing-types">Version 2</a> and <a href="{@docRoot}google/play/billing/api.html#producttypes">Version 3</a>.</p>
+
+<h2 id="console">Google Play Developer Console</h2>
+<p>The Developer Console is where you can publish your
+In-app Billing application, and manage the various in-app products that are
+available for purchase from your application.</p>
+<p>You can create a product list of
+digital goods that are associated with your application, including items for
+one-time purchase and recurring subscriptions. For each item, you can define
+information such as the item’s unique product ID (also called its SKU), product
+type, pricing, description, and how Google Play should handle and track
+purchases for that product.</p>
+<p>You can also create test accounts to authorize
+access for testing applications that are unpublished.</p>
+<p>To learn how to use the Developer Console to configure your in-app
+products and product list, see
+<a href="{@docRoot}google/play/billing/billing_admin.html">Administering
+In-app Billing</a>.</p>
+
+<h2 id="checkout">Google Play Purchase Flow</h2>
+<p>Google Play uses the same checkout backend service as is used for application
+purchases, so your users experience a consistent and familiar purchase flow.</p>
+<p class="note"><strong>Important:</strong> You must have a Google Checkout
+Merchant account to use the In-app Billing service on Google Play.</p>
+<p>To initiate a purchase, your application sends a billing request for a
+specific in-app product. Google Play then handles all of the checkout details for
+the transaction, including requesting and validating the form of payment and
+processing the financial transaction.</p>
+<p>When the checkout process is complete,
+Google Play 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
+Google Play.</p>
+<img src="{@docRoot}images/in-app-billing/v3/iab_v3_checkout_flow.png" height="382" id="figure1" />
<p class="img-caption">
- <strong>Figure 1.</strong> Your application sends and receives billing messages through the
- Google Play application, which handles all communication with the Google Play server.</p>
-</div>
-
-<p>Some in-app billing implementations may also use a private remote server to deliver content or
-validate transactions, but a remote server is not required to implement in-app billing. A remote
-server can be useful if you are selling digital content that needs to be delivered to a user's
-device, such as media files or photos. You might also use a remote server to store users'
-transaction history or perform various in-app billing security tasks, such as signature
-verification. Although you can handle all security-related tasks in your application, performing
-those tasks on a remote server is recommended because it helps make your application less vulnerable
-to security attacks.</p>
-
-<p>A typical in-app billing implementation relies on three components:</p>
-<ul>
- <li>A {@link android.app.Service} (named <code>BillingService</code> in the sample application),
- which processes purchase messages from the application and sends billing requests to the Google
- Play in-app billing service.</li>
- <li>A {@link android.content.BroadcastReceiver} (named <code>BillingReceiver</code> in the sample
- application), which receives all asynchronous billing responses from the Google Play
- application.</li>
- <li>A security component (named <code>Security</code> in the sample application), which performs
- security-related tasks, such as signature verification and nonce generation. For more information
- about in-app billing security, see <a href="#billing-security">Security controls</a> later in this
- document.</li>
-</ul>
-
-<p>You may also want to incorporate two other components to support in-app billing:</p>
-<ul>
- <li>A response {@link android.os.Handler} (named <code>ResponseHandler</code> in the sample
- application), which provides application-specific processing of purchase notifications, errors,
- and other status messages.</li>
- <li>An observer (named <code>PurchaseObserver</code> in the sample application), which is
- responsible for sending callbacks to your application so you can update your user interface with
- purchase information and status.</li>
-</ul>
-
-<p>In addition to these components, your application must provide a way to store information about
-users' purchases and some sort of user interface that lets users select items to purchase. You do
-not need to provide a checkout user interface. When a user initiates an in-app purchase, the Google
-Play application presents the checkout user interface to your user. When the user completes the
-checkout process, your application resumes.</p>
-
-<h2 id="billing-msgs">In-app Billing Messages</h2>
-
-<p>When the user initiates a purchase, your application sends billing messages to Google Play's
-in-app billing service (named <code>MarketBillingService</code>) using simple IPC method calls. The
-Google Play application responds to all billing requests synchronously, providing your
-application with status notifications and other information. The Google Play application also
-responds to some billing requests asynchronously, providing your application with error messages and
-detailed transaction information. The following section describes the basic request-response
-messaging that takes place between your application and the Google Play application.</p>
-
-<h3 id="billing-request">In-app billing requests</h3>
-
-<p>Your application sends in-app billing requests by invoking a single IPC method
-(<code>sendBillingRequest()</code>), which is exposed by the <code>MarketBillingService</code>
-interface. This interface is defined in an <a
-href="{@docRoot}guide/components/aidl.html">Android Interface Definition Language</a> file
-(<code>IMarketBillingService.aidl</code>). You can <a
-href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">download</a> this AIDL
-file with the in-app billing sample application.</p>
-
-<p>The <code>sendBillingRequest()</code> method has a single {@link android.os.Bundle} parameter.
-The Bundle that you deliver must include several key-value pairs that specify various parameters for
-the request, such as the type of billing request you are making, the item that is being purchased and
-its type, and the application that is making the request. For more information about the Bundle keys
-that are sent with a request, see <a
-href="{@docRoot}google/play/billing/billing_reference.html#billing-interface">In-app Billing
-Service Interface</a>.
-
-<p>One of the most important keys that every request Bundle must have is the
-<code>BILLING_REQUEST</code> key. This key lets you specify the type of billing request you are
-making. Google Play's in-app billing service supports the following five types of billing
-requests:</p>
-
-<ul>
- <li><code>CHECK_BILLING_SUPPORTED</code>
- <p>This request verifies that the Google Play application supports in-app billing. You
- usually send this request when your application first starts up. This request is useful if you
- want to enable or disable certain UI features that are relevant only to in-app billing.</p>
- </li>
- <li><code>REQUEST_PURCHASE</code>
- <p>This request sends a purchase message to the Google Play application and is the foundation
- of in-app billing. You send this request when a user indicates that he or she wants to purchase
- an item in your application. Google Play then handles the financial transaction by displaying
- the checkout user interface.</p>
- </li>
- <li><code>GET_PURCHASE_INFORMATION</code>
- <p>This request retrieves the details of a purchase state change. A purchase changes state when
- a requested purchase is billed successfully or when a user cancels a transaction during
- checkout. It can also occur when a previous purchase is refunded. Google Play notifies your
- application when a purchase changes state, so you only need to send this request when there is
- transaction information to retrieve.</p>
- </li>
- <li><code>CONFIRM_NOTIFICATIONS</code>
- <p>This request acknowledges that your application received the details of a purchase state
- change. Google Play sends purchase state change notifications to your application until you
- confirm that you received them.</p>
- </li>
- <li><code>RESTORE_TRANSACTIONS</code>
- <p>This request retrieves a user's transaction status for <a
- href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">managed
- purchases</a> and <a
- href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">subscriptions</a>.
- You should send this request only when you need to retrieve a user's transaction
- status, which is usually only when your application is reinstalled or installed for the first
- time on a device.</p>
- </li>
-</ul>
-
-<h3 id="billing-response">In-app Billing Responses</h3>
-
-<p>The Google Play application responds to in-app billing requests with both synchronous and
-asynchronous responses. The synchronous response is a {@link android.os.Bundle} with the following
-three keys:</p>
-
-<ul>
- <li><code>RESPONSE_CODE</code>
- <p>This key provides status information and error information about a request.</p>
- </li>
- <li><code>PURCHASE_INTENT</code>
- <p>This key provides a {@link android.app.PendingIntent}, which you use to launch the checkout
- activity.</p>
- </li>
- <li><code>REQUEST_ID</code>
- <p>This key provides you with a request identifier, which you can use to match asynchronous
- responses with requests.</p>
- </li>
-</ul>
-<p>Some of these keys are not relevant to every request. For more information, see <a
-href="#billing-message-sequence">Messaging sequence</a> later in this document.</p>
-
-<p>The asynchronous response messages are sent in the form of individual broadcast intents and
-include the following:</p>
+ <strong>Figure 1.</strong> Applications initiate In-app Billing requests
+through their own UI (first screen). Google Play responds to the request by
+providing the checkout user interface (middle screen). When checkout is
+complete, the application resumes.
+</p>
+<h2>The Sample Applications</h2>
+<p>To help you integrate In-app Billing into your application, the Android SDK
+provides two sample applications that demonstrate how to sell in-app products
+from inside an app.</p>
+
+<dl>
+<dt><a href="{@docRoot}training/in-app-billing/preparing-iab-app.html#GetSample">TrivialDrive sample for the Version 3 API</a></dt>
+<dd>This sample shows how to use the In-app Billing Version 3 API to implement
+in-app product purchases for a driving game. The application demonstrates how to
+send In-app Billing requests, and handle synchronous responses from Google Play.
+The application also shows how to record item consumption with the API. The
+Version 3 sample includes convenience classes for processing In-app Billing
+operations as well as perform automatic signature verification.</dd>
+
+<dt><a href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">Dungeons sample for the Version 2 API</a></dt>
+<dd>This sample demonstrates how to use the In-app Billing Version 2 API to sell
+standard in-app products and subscriptions for an adventuring game. It also
+contains examples of the database, user interface, and business logic you might
+use to implement In-app Billing.</dd>
+</dl>
+<p class="caution"><strong>Important</strong>: It's <em>strongly recommended</em>
+that you obfuscate the code in your application before you publish it. For
+more information, see
+<a href="{@docRoot}google/play/billing/billing_best_practices.html">Security
+and Design</a>.</p>
+
+<h2 id="migration">Migration Considerations</h2>
+<p>The following considerations may be applicable if you are planning to create a new
+in-app biling application, or migrate your existing In-app Billing implementation
+from the <a href="{@docRoot}google/play/billing/v2/api.html">Version 2</a> or
+earlier API to the <a href="{@docRoot}google/play/billing/api.html">Version 3</a> API.</p>
+<p>Google Play will continue to support both the Version 2 and Version 3 APIs for
+some time, so you can plan to migrate to Version 3 at your own pace. The Google
+Play team will give advance notice of any upcoming changes to the support
+status of In-app Billing Version 2.</p>
+<p>You can use the following table to decide which version of the API to use,
+depending on the needs of your application.</p>
+<p class="table-caption" id="table1">
+ <strong>Table 1.</strong> Selecting the In-app Billing API Version for Your
+Project</p>
+
+<table>
+<tr>
+<th scope="col">Choose Version 3 if ...</th>
+<th scope="col">Choose Version 2 if ...</th>
+</tr>
+<tr>
+<td>
+ <ul>
+ <li>You want to sell in-app products only (and not subscriptions)</li>
+ <li>You need synchronous order confirmations when purchases complete</li>
+ <li>You need to synchronously restore a user's current purchases</li>
+ </ul>
+</td>
+<td>
+ <ul>
+ <li>You want to sell subscriptions in your app</li>
+ </ul>
+</td>
+</tr>
+</table>
+<p>If you have published apps selling in-app products, note that:</p>
<ul>
- <li><code>com.android.vending.billing.RESPONSE_CODE</code>
- <p>This response contains a Google Play server response code, and is sent after you make an
- in-app billing request. A server response code can indicate that a billing request was
- successfully sent to Google Play or it can indicate that some error occurred during a billing
- request. This response is <em>not</em> used to report any purchase state changes (such as refund
- or purchase information). For more information about the response codes that are sent with this
- response, see <a
- href="{@docRoot}google/play/billing/billing_reference.html#billing-codes">Server Response Codes
- for In-app Billing</a>.</p>
- </li>
- <li><code>com.android.vending.billing.IN_APP_NOTIFY</code>
- <p>This response indicates that a purchase has changed state, which means a purchase succeeded,
- was canceled, or was refunded. This response contains one or more notification IDs. Each
- notification ID corresponds to a specific server-side message, and each messages contains
- information about one or more transactions. After your application receives an
- <code>IN_APP_NOTIFY</code> broadcast intent, you send a <code>GET_PURCHASE_INFORMATION</code>
- request with the notification IDs to retrieve message details.</p>
- </li>
- <li><code>com.android.vending.billing.PURCHASE_STATE_CHANGED</code>
- <p>This response contains detailed information about one or more transactions. The transaction
- information is contained in a JSON string. The JSON string is signed and the signature is sent
- to your application along with the JSON string (unencrypted). To help ensure the security of
- your in-app billing messages, your application can verify the signature of this JSON string.</p>
- </li>
+<li>Managed items that you have previously defined in the Developer Console will
+work with Version 3 as before.</li>
+<li>Unmanaged items that you have defined for existing applications will be
+treated as managed products if you make a purchase request for these items using
+the Version 3 API. You do not need to create a new product entry in Developer
+Console for these items, and you can use the same product IDs to purchase these
+items. They will still continue to be treated as unmanaged items if you make a
+purchase request for them using the Version 2 or earlier API.
</ul>
-<p>The JSON string that is returned with the <code>PURCHASE_STATE_CHANGED</code> intent provides
-your application with the details of one or more billing transactions. An example of this JSON
-string for a subscription item is shown below:</p>
-<pre class="no-pretty-print" style="color:black">{ "nonce" : 1836535032137741465,
- "orders" :
- [{ "notificationId" : "android.test.purchased",
- "orderId" : "12999556515565155651.5565135565155651",
- "packageName" : "com.example.dungeons",
- "productId" : "android.test.purchased",
- "developerPayload" : "bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ",
- "purchaseTime" : 1290114783411,
- "purchaseState" : 0,
- "purchaseToken" : "rojeslcdyyiapnqcynkjyyjh" }]
-}
-</pre>
-
-<p>For more information about the fields in this JSON string, see <a
-href="{@docRoot}google/play/billing/billing_reference.html#billing-intents">In-app Billing
-Broadcast Intents</a>.</p>
-
-<h3 id="billing-message-sequence">Messaging sequence</h3>
-
-<p>The messaging sequence for a typical purchase request is shown in figure 2. Request types for
-each <code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents
-are shown in <em>italic</em>. For clarity, figure 2 does not show the <code>RESPONSE_CODE</code>
-broadcast intents that are sent for every request.</p>
-
-<p>The basic message sequence for an in-app purchase request is as follows:</p>
-
-<ol>
- <li>Your application sends a purchase request (<code>REQUEST_PURCHASE</code> type), specifying a
- product ID and other parameters.</li>
- <li>The Google Play application sends your application a Bundle with the following keys:
- <code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and <code>REQUEST_ID</code>. The
- <code>PURCHASE_INTENT</code> key provides a {@link android.app.PendingIntent}, which your
- application uses to start the checkout UI for the given product ID.</li>
- <li>Your application launches the pending intent, which launches the checkout UI.
- <p class="note"><strong>Note:</strong> You must launch the pending intent from an activity
- context and not an application context.</p>
- </li>
- <li>When the checkout flow finishes (that is, the user successfully purchases the item or cancels
- the purchase), Google Play sends your application a notification message (an
- <code>IN_APP_NOTIFY</code> broadcast intent). The notification message includes a notification ID,
- which references the transaction.</li>
- <li>Your application requests the transaction information by sending a
- <code>GET_PURCHASE_STATE_CHANGED</code> request, specifying the notification ID for the
- transaction.</li>
- <li>The Google Play application sends a Bundle with a <code>RESPONSE_CODE</code> key and a
- <code>REQUEST_ID</code> key.
- <li>Google Play sends the transaction information to your application in a
- <code>PURCHASE_STATE_CHANGED</code> broadcast intent.</li>
- <li>Your application confirms that you received the transaction information for the given
- notification ID by sending a confirmation message (<code>CONFIRM_NOTIFICATIONS</code> type),
- specifying the notification ID for which you received transaction information.</li>
- <li>The Google Play application sends your application a Bundle with a
- <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key.</li>
-</ol>
-<img src="{@docRoot}images/billing_request_purchase.png" height="231" id="figure2" />
-<p class="img-caption">
- <strong>Figure 2.</strong> Message sequence for a purchase request.
-</p>
-
-<p>Keep in mind, you must send a confirmation when you receive transaction information from Google
-Play (step 8 in figure 2). If you don't send a confirmation message, Google Play will
-continue sending <code>IN_APP_NOTIFY</code> messages for the transactions you have not
-confirmed. As a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request for
-a purchased item until you have delivered the item to the user. This way, if your application
-crashes or something else prevents your application from delivering the product, your application
-will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating
-that you need to deliver the product. Also, as a best practice, your application must be able to
-handle <code>IN_APP_NOTIFY</code> messages that contain multiple orders.</p>
-<p>The messaging sequence for a restore transaction request is shown in figure 3. Request types for
-each <code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents
-are shown in <em>italic</em>. For clarity, figure 3 does not show the <code>RESPONSE_CODE</code>
-broadcast intents that are sent for every request.</p>
-
-<div class="figure" style="width:490px">
-<img src="{@docRoot}images/billing_restore_transactions.png" alt="" height="168" />
-<p class="img-caption">
- <strong>Figure 3.</strong> Message sequence for a restore transactions request.
-</p>
-</div>
-
-<p>The request triggers three responses. The first is a {@link android.os.Bundle} with a
-<code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. Next, the Google Play
-application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides status information
-or error information about the request. As always, the <code>RESPONSE_CODE</code> message references
-a specific request ID, so you can determine which request a <code>RESPONSE_CODE</code> message
-pertains to.</p>
-
-<p>The <code>RESTORE_TRANSACTIONS</code> request type also triggers a
-<code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the same type of transaction
-information that is sent during a purchase request. Unlike with a purchase request, however, the transactions
-are given without any associated notification IDs, so you do not need to respond to this
-intent with a <code>CONFIRM_NOTIFICATIONS</code> message. </p>
-
-<p class="note"><strong>Note:</strong> You should use the <code>RESTORE_TRANSACTIONS</code> request
-type only when your application is installed for the first time on a device or when your
-application has been removed from a device and reinstalled.</p>
-
-<p>The messaging sequence for checking whether in-app billing is supported is shown in figure 4. The
-request type for the <code>sendBillingRequest()</code> method is shown in <strong>bold</strong>.</p>
-
-<div class="figure" style="width:454px">
-<img src="{@docRoot}images/billing_check_supported.png" alt="" height="168" />
-<p class="img-caption">
- <strong>Figure 4.</strong> Message sequence for checking whether in-app billing is supported.
-</p>
-</div>
-
-<p>The synchronous response for a <code>CHECK_BILLING_SUPPORTED</code> request provides a Bundle
-with a server response code. A <code>RESULT_OK</code> response code indicates that in-app billing
-is supported; a <code>RESULT_BILLING_UNAVAILABLE</code> response code indicates that in-app billing
-is unavailable because the API version you specified is unrecognized or the user is not eligible to
-make in-app purchases (for example, the user resides in a country that does not allow in-app
-billing). A <code>SERVER_ERROR</code> can also be returned, indicating that there was a problem with
-the Google Play server.</p>
-<h3 id="billing-action-notify">Handling IN_APP_NOTIFY messages</h3>
-
-<p>Usually, your application receives an <code>IN_APP_NOTIFY</code> broadcast intent from Google
-Play in response to a <code>REQUEST_PURCHASE</code> message (see figure 2). The
-<code>IN_APP_NOTIFY</code> broadcast intent informs your application that the state of a requested
-purchase has changed. To retrieve the details of that purchase, your application sends a
-<code>GET_PURCHASE_INFORMATION</code> request. Google Play responds with a
-<code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the details of the purchase
-state change. Your application then sends a <code>CONFIRM_NOTIFICATIONS</code> message, informing
-Google Play that you have received the purchase state change information.</p>
-
-<p>In some special cases, you may receive multiple <code>IN_APP_NOTIFY</code> messages even though
-you have confirmed receipt of the purchase information, or you may receive
-<code>IN_APP_NOTIFY</code> messages for a purchase change even though you never initiated the
-purchase. Your application must handle both of these special cases.</p>
-
-<h4>Handling multiple IN_APP_NOTIFY messages</h4>
-
-<p>When Google Play receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given
-<code>PURCHASE_STATE_CHANGED</code> message, it usually stops sending <code>IN_APP_NOTIFY</code>
-intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Google
-Play may send repeated <code>IN_APP_NOTIFY</code> intents for a
-<code>PURCHASE_STATE_CHANGED</code> message even though your application has sent a
-<code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a device loses network connectivity
-while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Google Play
-might not receive your <code>CONFIRM_NOTIFICATIONS</code> message and it could send multiple
-<code>IN_APP_NOTIFY</code> messages until it receives acknowledgement that you received the
-transaction message. Therefore, your application must be able to recognize that the subsequent
-<code>IN_APP_NOTIFY</code> messages are for a previously processed transaction. You can do this by
-checking the <code>orderID</code> that's contained in the JSON string because every transaction has
-a unique <code>orderId</code>.</p>
-
-<h4>Handling refunds and other unsolicited IN_APP_NOTIFY messages</h4>
-
-<p>There are two cases where your application may receive <code>IN_APP_NOTIFY</code> broadcast
-intents even though your application has not sent a <code>REQUEST_PURCHASE</code> message. Figure 5
-shows the messaging sequence for both of these cases. Request types for each
-<code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents are
-shown in <em>italic</em>. For clarity, figure 5 does not show the <code>RESPONSE_CODE</code>
-broadcast intents that are sent for every request.</p>
-
-<div class="figure" style="width:481px">
-<img src="{@docRoot}images/billing_refund.png" alt="" height="189" />
-<p class="img-caption">
- <strong>Figure 5.</strong> Message sequence for refunds and other unsolicited
-IN_APP_NOTIFY messages.</p>
-</div>
-
-<p>In the first case, your application may receive an <code>IN_APP_NOTIFY</code> broadcast intent
-when a user has your application installed on two (or more) devices and the user makes an in-app
-purchase from one of the devices. In this case, Google Play sends an <code>IN_APP_NOTIFY</code>
-message to the second device, informing the application that there is a purchase state change. Your
-application can handle this message the same way it handles the response from an
-application-initiated <code>REQUEST_PURCHASE</code> message, so that ultimately your application
-receives a <code>PURCHASE_STATE_CHANGED</code> broadcast intent message that includes information
-about the item that has been purchased. This applies only to items that have their <a
-href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">purchase type</a> set
-to "managed per user account."</p>
-
-<p>In the second case, your application can receive an <code>IN_APP_NOTIFY</code> broadcast intent
-when Google Play receives a refund notification from Google Checkout. In this case, Google
-Play sends an <code>IN_APP_NOTIFY</code> message to your application. Your application can handle
-this message the same way it handles responses from an application-initiated
-<code>REQUEST_PURCHASE</code> message so that ultimately your application receives a
-<code>PURCHASE_STATE_CHANGED</code> message that includes information about the item that has been
-refunded. The refund information is included in the JSON string that accompanies the
-<code>PURCHASE_STATE_CHANGED</code> broadcast intent. Also, the <code>purchaseState</code> field in
-the JSON string is set to 2.</p>
-
-<p class="caution"><strong>Important:</strong> You cannot use the Google Checkout API to
-issue refunds or cancel in-app billing transactions. You must do this manually through your
-Google Checkout merchant account. However, you can use the Google Checkout API to retrieve order
-information.</p>
-
-<h2 id="billing-security">Security Controls</h2>
-
-<p>To help ensure the integrity of the transaction information that is sent to your application,
-Google Play signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code>
-broadcast intent. Google Play uses the private key that is associated with your publisher account
-to create this signature. The publisher site generates an RSA key pair for each publisher account.
-You can find the public key portion of this key pair on your account's profile page. It is the same
-public key that is used with Google Play licensing.</p>
-
-<p>When Google Play signs a billing response, it includes the signed JSON string (unencrypted)
-and the signature. When your application receives this signed response you can use the public key
-portion of your RSA key pair to verify the signature. By performing signature verification you can
-help detect responses that have been tampered with or that have been spoofed. You can perform this
-signature verification step in your application; however, if your application connects to a secure
-remote server then we recommend that you perform the signature verification on that server.</p>
-
-<p>In-app billing also uses nonces (a random number used once) to help verify the integrity of the
-purchase information that's returned from Google Play. Your application must generate a nonce and
-send it with a <code>GET_PURCHASE_INFORMATION</code> request and a <code>RESTORE_TRANSACTIONS</code>
-request. When Google Play receives the request, it adds the nonce to the JSON string that
-contains the transaction information. The JSON string is then signed and returned to your
-application. When your application receives the JSON string, you need to verify the nonce as well as
-the signature of the JSON string.</p>
-
-<p>For more information about best practices for security and design, see <a
-href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>.</p>
-
-<h2 id="billing-limitations">In-app Billing Requirements and Limitations</h2>
-
-<p>Before you get started with in-app billing, be sure to review the following requirements and
-limitations.</p>
-
-<ul>
- <li>In-app billing can be implemented only in applications that you publish through Google
- Play.</li>
- <li>You must have a Google Checkout Merchant account to use Google Play In-app Billing.</li>
- <li>In-app billing requires version 2.3.4 (or higher) of the Android Market application.
- To support subscriptions, version 3.5 or higher of the Google Play app is required. On devices
- running Android 3.0, version 5.0.12 (or higher) of the MyApps application is required.</li>
- <li>An application can use in-app billing only if the device is running Android 1.6 (API level 4)
- or higher.</li>
- <li>You can use in-app billing to sell only digital content. You cannot use in-app billing to sell
- physical goods, personal services, or anything that requires physical delivery.</li>
- <li>Google Play does not provide any form of content delivery. You are responsible for
- delivering the digital content that you sell in your applications.</li>
- <li>You cannot implement in-app billing on a device that never connects to the network. To
- complete in-app purchase requests, a device must be able to access the Google Play server over
- the network. </li>
-</ul>
-<p>For more information about in-app billing requirements, see <a
-href="https://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=1153481">In-App
-Billing Availability and Policies</a>.</p>
-page.title=In-app Billing Reference
+page.title=In-app Billing Reference <span style="font-size:16px;">(IAB Version 3)</span>
parent.title=In-app Billing
parent.link=index.html
@jd:body
<div id="qv">
<h2>In this document</h2>
<ol>
- <li><a href="#billing-codes">Server Response Codes for In-app Billing</a></li>
- <li><a href="#billing-interface">In-app Billing Service Interface</a></li>
- <li><a href="#billing-intents">In-app Billing Broadcast Intents</a></li>
- <li><a href="#other-intents">Other Broadcast Intents</a></li>
- <li><a href="#billing-versions">In-app Billing API Versions</a></li>
+ <li><a href="#billing-codes">Server Response Codes</a></li>
+ <li><a href="#billing-interface">API Reference</a>
+ <ol>
+ <li><a href="#getSkuDetails">getSkuDetails()</a></li>
+ <li><a href="#getBuyIntent">getBuyIntent()</a></li>
+ <li><a href="#getPurchases">getPurchases()</a></li>
+ </ol>
+ </li>
</ol>
<h2>Downloads</h2>
<ol>
<li><a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">Sample
- Application</a></li>
+ Application (V3)</a></li>
</ol>
<h2>See also</h2>
<ol>
- <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html">Implementing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
- Design</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app
- Billing</a></li>
+ <li><a href="{@docRoot}google/play/billing/api.html">In-app Billing Version 3</a></li>
+ <li><a href="{@docRoot}training/in-app-billing/index.html">Selling In-app Products</a></li>
</ol>
</div>
</div>
+<p>This documentation provides technical reference information for using the In-app Billing Version 3 API. </p>
-<p>The following document provides technical reference information for the following:</p>
-
-<ul>
- <li><a href="#billing-codes">Google Play Server Response Codes for In-app Billing</a></li>
- <li><a href="#billing-interface">In-app Billing Interface Parameters</a></li>
- <li><a href="#billing-intents">In-app Billing Broadcast Intents</a></li>
- <li><a href="#other-intents">Other Intents</a></li>
- <li><a href="#billing-versions">In-app Billing API Versions</a></li>
-</ul>
-
-<h2 id="billing-codes">Server Response Codes for In-app Billing</h2>
-
-<p>The following table lists all of the server response codes that are sent from Google Play to
-your application. Google Play sends these response codes asynchronously as
-<code>response_code</code> extras in the <code>com.android.vending.billing.RESPONSE_CODE</code>
-broadcast intent. Your application must handle all of these response codes.</p>
-
-<p class="table-caption" id="response-codes-table"><strong>Table 1.</strong> Summary of response
-codes returned by Google Play.</p>
+<h2 id="billing-codes">Server Response Codes</h2>
+<p>The following table lists all of the server response codes that are sent from Google Play to your application. Google Play sends the response code synchronously as an integer mapped to the {@code RESPONSE_CODE} key in the response {@code Bundle}. Your application must handle all of these response codes.</p>
+<p class="table-caption" id="response-codes-table">
+<strong>Table 1.</strong> Summary of response codes for In-app Billing Version 3 API calls.</p>
<table>
-
-<tr>
-<th>Response Code</th>
-<th>Value</th>
-<th>Description</th>
-</tr>
-<tr>
- <td><code>RESULT_OK</code></td>
- <td>0</td>
- <td>Indicates that the request was sent to the server successfully. When this code is returned in
- response to a <code>CHECK_BILLING_SUPPORTED</code> request, indicates that billing is
- supported.</td>
-</tr>
-<tr>
- <td><code>RESULT_USER_CANCELED</code></td>
- <td>1</td>
- <td>Indicates that the user pressed the back button on the checkout page instead of buying the
- item.</td>
-</tr>
-<tr>
- <td><code>RESULT_SERVICE_UNAVAILABLE</code></td>
- <td>2</td>
- <td>Indicates that the network connection is down.</td>
-</tr>
-<tr>
- <td><code>RESULT_BILLING_UNAVAILABLE</code></td>
- <td>3</td>
- <td>Indicates that in-app billing is not available because the <code>API_VERSION</code> that you
- specified is not recognized by the Google Play application or the user is ineligible for in-app
- billing (for example, the user resides in a country that prohibits in-app purchases).</td>
-</tr>
-<tr>
- <td><code>RESULT_ITEM_UNAVAILABLE</code></td>
- <td>4</td>
- <td>Indicates that Google Play cannot find the requested item in the application's product
- list. This can happen if the product ID is misspelled in your <code>REQUEST_PURCHASE</code>
- request or if an item is unpublished in the application's product list.</td>
-</tr>
-<tr>
- <td><code>RESULT_DEVELOPER_ERROR</code></td>
- <td>5</td>
- <td>Indicates that an application is trying to make an in-app billing request but the application
- has not declared the com.android.vending.BILLING permission in its manifest. Can also indicate
- that an application is not properly signed, or that you sent a malformed request, such as a
- request with missing Bundle keys or a request that uses an unrecognized request type.</td>
-</tr>
-<tr>
- <td><code>RESULT_ERROR</code></td>
- <td>6</td>
- <td>Indicates an unexpected server error. For example, this error is triggered if you try to
-purchase an item from yourself, which is not allowed by Google Checkout.</td>
-</tr>
+ <tr>
+ <th scope="col">Response Code</th>
+ <th scope="col">Value</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_OK}</td>
+ <td>0</td>
+ <td>Success</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_USER_CANCELED}</td>
+ <td>1</td>
+ <td>User pressed back or canceled a dialog</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_BILLING_UNAVAILABLE}</td>
+ <td>3</td>
+ <td>Billing API version is not supported for the type requested</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_ITEM_UNAVAILABLE}</td>
+ <td>4</td>
+ <td>Requested product is not available for purchase</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_DEVELOPER_ERROR}</td>
+ <td>5</td>
+ <td>Invalid arguments provided to the API. This error can also indicate that the application was not correctly signed or properly set up for In-app Billing in Google Play, or does not have the necessary permissions in its manifest</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_ERROR}</td>
+ <td>6</td>
+ <td>Fatal error during the API action</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_ITEM_ALREADY_OWNED}</td>
+ <td>7</td>
+ <td>Failure to purchase since item is already owned</td>
+ </tr>
+ <tr>
+ <td>{@code BILLING_RESPONSE_RESULT_ITEM_NOT_OWNED}</td>
+ <td>8</td>
+ <td>Failure to consume since item is not owned</td>
+ </tr>
</table>
-<h2 id="billing-interface">In-app Billing Service Interface</h2>
-
-<p>The following section describes the interface for Google Play's in-app billing service. The
-interface is defined in the <code>IMarketBillingService.aidl</code> file, which is included with the
-in-app billing <a
-href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">sample
-application</a>.</p>
-<p>The interface consists of a single request method <code>sendBillingRequest()</code>. This method
-takes a single {@link android.os.Bundle} parameter. The Bundle parameter includes several key-value
-pairs, which are summarized in table 2.</p>
+<h2 id="billing-interface">API Reference</h2>
+<p>The In-app Billing Version 3 API is defined in the {@code IInAppBillingService.aidl} file, which is included with the Version 3 <a href="{@docRoot}training/in-app-billing/preparing-iab-app.html#GetSample">sample application</a>.</p>
-<p class="table-caption"><strong>Table 2.</strong> Description of Bundle keys passed in a
-<code>sendBillingRequest()</code> request.</p>
+<h3 id="getSkuDetails">The getSkuDetails() method</h3>
+<p>This method returns product details for a list of product IDs. In the response {@code Bundle} sent by Google Play, the query results are stored in a String {@code ArrayList} mapped to the {@code DETAILS_LIST} key. Each String in the details list contains product details for a single product in JSON format. The fields in the JSON string with the product details are summarized in table 2.</p>
+<p class="table-caption" id="product-details-table">
+<strong>Table 2.</strong> Description of JSON fields with product item details returned from a {@code getSkuDetails} request.</p>
<table>
-
-<tr>
-<th>Key</th>
-<th>Type</th>
-<th>Possible Values</th>
-<th>Required?</th>
-<th>Description</th>
-</tr>
-<tr>
- <td><code>BILLING_REQUEST</code></td>
- <td><code>String</code></td>
- <td><code>CHECK_BILLING_SUPPORTED</code>, <code>REQUEST_PURCHASE</code>,
- <code>GET_PURCHASE_INFORMATION</code>, <code>CONFIRM_NOTIFICATIONS</code>, or
- <code>RESTORE_TRANSACTIONS</code></td>
- <td>Yes</td>
- <td>The type of billing request you are making with the <code>sendBillingRequest()</code> request.
- The possible values are discussed more below this table.</td>
-</tr>
-<tr>
- <td><code>API_VERSION</code></td>
- <td><code>int</code></td>
- <td> <ul>
- <li><code>"2"</code> [<a href="#version_2">details</a>]</li>
- <li><code>"1"</code> [<a href="#version_1">details</a>]</li>
- </ul></td>
- <td>Yes</td>
- <td>The version of Google Play's in-app billing service you want to use. The current version is
- 2.</td>
-</tr>
-<tr>
- <td><code>PACKAGE_NAME</code></td>
- <td><code>String</code></td>
- <td>A valid package name.</td>
- <td>Yes</td>
- <td>The name of the application that is making the request.</td>
-</tr>
-<tr>
- <td><code>ITEM_ID</code></td>
- <td><code>String</code></td>
- <td>Any valid product identifier.</td>
- <td>Required for <code>REQUEST_PURCHASE</code> requests.</td>
- <td>The product ID of the item you are making a billing request for. Every in-app item that you
- sell using Google Play's in-app billing service must have a unique product ID, which you
- specify on the Google Play publisher site.</td>
-</tr>
-<tr>
- <td><code>NONCE</code></td>
- <td><code>long</code></td>
- <td>Any valid <code>long</code> value.</td>
- <td>Required for <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code>
- requests.</td>
- <td>A number used once. Your application must generate and send a nonce with each
- <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is
- returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, so you can use this value
- to verify the integrity of transaction responses form Google Play.</td>
-</tr>
-<tr>
- <td><code>NOTIFY_IDS</code></td>
- <td>Array of <code>long</code> values</td>
- <td>Any valid array of <code>long</code> values</td>
- <td>Required for <code>GET_PURCHASE_INFORMATION</code> and <code>CONFIRM_NOTIFICATIONS</code>
- requests.</td>
- <td>An array of notification identifiers. A notification ID is sent to your application in an
- <code>IN_APP_NOTIFY</code> broadcast intent every time a purchase changes state. You use the
- notification to retrieve the details of the purchase state change.</td>
-</tr>
-<tr>
- <td><code>DEVELOPER_PAYLOAD</code></td>
- <td><code>String</code></td>
- <td>Any valid <code>String</code> less than 256 characters long.</td>
- <td>No</td>
- <td>A developer-specified string that can be specified when you make a
- <code>REQUEST_PURCHASE</code> request. This field is returned in the JSON string that contains
- transaction information for an order. You can use this key to send supplemental information with
- an order. For example, you can use this key to send index keys with an order, which is useful if
- you are using a database to store purchase information. We recommend that you do not use this key
- to send data or content.</td>
-</tr>
+ <tr>
+ <th scope="col">Key</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>{@code productId}</td>
+ <td>The product ID for the product.</td>
+ </tr>
+ <tr>
+ <td>{@code type}</td>
+ <td>Value must be “inapp” for an in-app purchase type.</td>
+ </tr>
+ <tr>
+ <td>{@code price}</td>
+ <td>Formatted price of the item, including its currency sign. The price does not include tax.</td>
+ </tr>
+ <tr>
+ <td>{@code title}</td>
+ <td>Title of the product.</td>
+ </tr>
+ <tr>
+ <td>{@code description}</td>
+ <td>Description of the product.</td>
+ </tr>
</table>
+</p>
-<p>The <code>BILLING_REQUEST</code> key can have the following values:</p>
-
-<ul>
- <li><code>CHECK_BILLING_SUPPORTED</code>
- <p>This request verifies that the Google Play application supports in-app billing. You
- usually send this request when your application first starts up. This request is useful if you
- want to enable or disable certain UI features that are relevant only to in-app billing.</p>
- </li>
- <li><code>REQUEST_PURCHASE</code>
- <p>This request sends a purchase message to the Google Play application and is the foundation
- of in-app billing. You send this request when a user indicates that he or she wants to purchase
- an item in your application. Google Play then handles the financial transaction by displaying
- the checkout user interface.</p>
- </li>
- <li><code>GET_PURCHASE_INFORMATION</code>
- <p>This request retrieves the details of a purchase state change. A purchase state change can
- occur when a purchase request is billed successfully or when a user cancels a transaction during
- checkout. It can also occur when a previous purchase is refunded. Google Play notifies your
- application when a purchase changes state, so you only need to send this request when there is
- transaction information to retrieve.</p>
- </li>
- <li><code>CONFIRM_NOTIFICATIONS</code>
- <p>This request acknowledges that your application received the details of a purchase state
- change. That is, this message confirms that you sent a <code>GET_PURCHASE_INFORMATION</code>
- request for a given notification and that you received the purchase information for the
- notification.</p>
- </li>
- <li><code>RESTORE_TRANSACTIONS</code>
- <p>This request retrieves a user's transaction status for managed purchases (see <a
- href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">Choosing a
- Purchase Type</a> for more information). You should send this message only when you need to
- retrieve a user's transaction status, which is usually only when your application is reinstalled
- or installed for the first time on a device.</p>
- </li>
-</ul>
-
-<p>Every in-app billing request generates a synchronous response. The response is a {@link
-android.os.Bundle} and can include one or more of the following keys:</p>
-
-<ul>
- <li><code>RESPONSE_CODE</code>
- <p>This key provides status information and error information about a request.</p>
- </li>
- <li><code>PURCHASE_INTENT</code>
- <p>This key provides a {@link android.app.PendingIntent}, which you use to launch the checkout
- activity.</p>
- </li>
- <li><code>REQUEST_ID</code>
- <p>This key provides you with a request identifier, which you can use to match asynchronous
- responses with requests.</p>
- </li>
-</ul>
-
-<p>Some of these keys are not relevant to certain types of requests. Table 3 shows which keys are
-returned for each request type.</p>
-
-<p class="table-caption"><strong>Table 3.</strong> Description of Bundle keys that are returned with
-each in-app billing request type.</p>
+<h3 id="getBuyIntent">The getBuyIntent() method</h3>
+<p>This method returns a response code integer mapped to the {@code RESPONSE_CODE} key, and a {@code PendingIntent} to launch the puchase flow for the in-app item mapped to the {@code BUY_INTENT} key. When it receives the {@code PendingIntent}, Google Play sends a response {@code Intent} with the data for that purchase order. The data that is returned in the response {@code Intent} is summarized in table 3.</p>
+<p class="table-caption" id="purchase-pendingintent-response-table">
+<strong>Table 3.</strong> Response data from an In-app Billing Version 3 purchase request.</p>
<table>
-
-<tr>
-<th>Request Type</th>
-<th>Keys Returned</th>
-<th>Possible Response Codes</th>
-</tr>
-<tr>
- <td><code>CHECK_BILLING_SUPPORTED</code></td>
- <td><code>RESPONSE_CODE</code></td>
- <td><code>RESULT_OK</code>, <code>RESULT_BILLING_UNAVAILABLE</code>, <code>RESULT_ERROR</code>,
- <code>RESULT_DEVELOPER_ERROR</code></td>
-</tr>
-<tr>
- <td><code>REQUEST_PURCHASE</code></td>
- <td><code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, <code>REQUEST_ID</code></td>
- <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
-</tr>
-<tr>
- <td><code>GET_PURCHASE_INFORMATION</code></td>
- <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td>
- <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
-</tr>
-<tr>
- <td><code>CONFIRM_NOTIFICATIONS</code></td>
- <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td>
- <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
-</tr>
-<tr>
- <td><code>RESTORE_TRANSACTIONS</code></td>
- <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td>
- <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
-</tr>
+ <tr>
+ <th scope="col">Key</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>{@code RESPONSE_CODE}</td>
+ <td>0 if the purchase was success, error otherwise.</td>
+ </tr>
+ <tr>
+ <td>{@code INAPP_PURCHASE_DATA}</td>
+ <td>
+ A String in JSON format that contains details about the purchase order. See table 4 for a description of the JSON fields.
+ </td>
+ </tr>
+ <tr>
+ <td>{@code INAPP_DATA_SIGNATURE}</td>
+ <td>String containing the signature of the purchase data that was signed with the private key of the developer.</td>
+ </tr>
</table>
+</p>
-<h2 id="billing-intents">In-app Billing Broadcast Intents</h2>
-
-<p>The following section describes the in-app billing broadcast intents that are sent by the Google
-Play application. These broadcast intents inform your application about in-app billing actions
-that have occurred. Your application must implement a {@link android.content.BroadcastReceiver} to
-receive these broadcast intents, such as the <code>BillingReceiver</code> that's shown in the in-app
-billing <a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">sample
-application</a>.</p>
-
-<h4>com.android.vending.billing.RESPONSE_CODE</h4>
-
-<p>This broadcast intent contains a Google Play response code, and is sent after you make an
-in-app billing request. A server response code can indicate that a billing request was successfully
-sent to Google Play or it can indicate that some error occurred during a billing request. This
-intent is not used to report any purchase state changes (such as refund or purchase information).
-For more information about the response codes that are sent with this response, see <a
-href="#billing-codes">Google Play Response Codes for In-app Billing</a>. The sample application
-assigns this broadcast intent to a constant named <code>ACTION_RESPONSE_CODE</code>.</p>
-
-<h5>Extras</h5>
-
-<ul type="none">
- <li><code>request_id</code>—a <code>long</code> representing a request ID. A request ID
- identifies a specific billing request and is returned by Google Play at the time a request is
- made.</li>
- <li><code>response_code</code>—an <code>int</code> representing the Google Play server
- response code.</li>
-</ul>
-
-<h4>com.android.vending.billing.IN_APP_NOTIFY</h4>
-
-<p>This response indicates that a purchase has changed state, which means a purchase succeeded, was
-canceled, or was refunded. This response contains one or more notification IDs. Each notification ID
-corresponds to a specific server-side message, and each messages contains information about one or
-more transactions. After your application receives an <code>IN_APP_NOTIFY</code> broadcast intent,
-you send a <code>GET_PURCHASE_INFORMATION</code> request with the notification IDs to retrieve the
-message details. The sample application assigns this broadcast intent to a constant named
-<code>ACTION_NOTIFY</code>.</p>
-
-<h5>Extras</h5>
-
-<ul type="none">
- <li><code>notification_id</code>—a <code>String</code> representing the notification ID for
- a given purchase state change. Google Play notifies you when there is a purchase state change
- and the notification includes a unique notification ID. To get the details of the purchase state
- change, you send the notification ID with the <code>GET_PURCHASE_INFORMATION</code> request.</li>
-</ul>
-
-<h4>com.android.vending.billing.PURCHASE_STATE_CHANGED</h4>
-
-<p>This broadcast intent contains detailed information about one or more transactions. The
-transaction information is contained in a JSON string. The JSON string is signed and the signature
-is sent to your application along with the JSON string (unencrypted). To help ensure the security of
-your in-app billing messages, your application can verify the signature of this JSON string. The
-sample application assigns this broadcast intent to a constant named
-<code>ACTION_PURCHASE_STATE_CHANGED</code>.</p>
-
-<h5>Extras</h5>
-
-<ul type="none">
- <li><code>inapp_signed_data</code>—a <code>String</code> representing the signed JSON
- string.</li>
- <li><code>inapp_signature</code>—a <code>String</code> representing the signature.</li>
-</ul>
-
-<p class="note"><strong>Note:</strong> Your application should map the broadcast intents and extras
-to constants that are unique to your application. See the <code>Consts.java</code> file in the
-sample application to see how this is done.</p>
-
-<p>The fields in the JSON string are described in the following table (see table 4):</p>
-
-<p class="table-caption"><strong>Table 4.</strong> Description of JSON fields that are returned with
-a <code>PURCHASE_STATE_CHANGED</code> intent.</p>
-
+<p>Table 4 describes the JSON fields that are returned in the response data for a purchase order.</p>
+<p class="table-caption" id="purchase-data-table">
+<strong>Table 4.</strong> Descriptions of the JSON fields for {@code INAPP_PURCHASE_DATA}.</p>
<table>
-
-<tr>
-<th>Field</th>
-<th>Description</th>
-</tr>
-<tr>
- <td>nonce</td>
- <td>A number used once. Your application generates the nonce and sends it with the
- <code>GET_PURCHASE_INFORMATION</code> request. Google Play sends the nonce back as part of the
- JSON string so you can verify the integrity of the message.</td>
-</tr>
-<tr>
- <td>notificationId</td>
- <td>A unique identifier that is sent with an <code>IN_APP_NOTIFY</code> broadcast intent. Each
- <code>notificationId</code> corresponds to a specify message that is waiting to be retrieved on
- the Google Play server. Your application sends back the <code>notificationId</code> with the
- <code>GET_PURCHASE_INFORMATION</code> message so Google Play can determine which messages you
- are retrieving.</td>
-</tr>
-<tr>
- <td>orderId</td>
- <td>A unique order identifier for the transaction. This corresponds to the transaction's Merchant
- Order Number. For transactions dated previous to 5 December 2012, the orderID correcponds to the transaction's
- Google Order Number. For more information, see <a href="{@docRoot}google/play/billing/billing_admin.html#orderId">Working
- with order numbers</a>.</td>
-</tr>
-<tr>
- <td>packageName</td>
- <td>The application package from which the purchase originated.</td>
-</tr>
-<tr>
- <td>productId</td>
- <td>The item's product identifier. Every item has a product ID, which you must specify in the
- application's product list on the Google Play publisher site.</td>
-</tr>
-<tr>
- <td>purchaseTime</td>
- <td>The time the product was purchased, in milliseconds since the epoch (Jan 1, 1970).</td>
-</tr>
-
-<tr>
- <td>purchaseState</td>
- <td>The purchase state of the order. Possible values are 0 (purchased), 1 (canceled), 2
- (refunded), or 3 (expired, for subscription purchases only).</td>
-</tr>
-<tr>
- <td>purchaseToken</td>
- <td>A token that uniquely identifies a subscription purchase for a given item and user pair.
- You can use the token to specify the subscription when querying for subscription validity.
-
- <p><br><em>Supported only in In-app Billing API version 2 and higher.</em></p></td>
-</tr>
-<tr>
- <td>developerPayload</td>
- <td>A developer-specified string that contains supplemental information about an order. You can
- specify a value for this field when you make a <code>REQUEST_PURCHASE</code> request.</td>
-</tr>
+ <tr>
+ <th scope="col">Field</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>{@code orderId}</td>
+ <td>A unique order identifier for the transaction. This corresponds to the Google Wallet Order ID.</td>
+ </tr>
+ <tr>
+ <td>{@code packageName}</td>
+ <td>The application package from which the purchase originated.</td>
+ </tr>
+ <tr>
+ <td>{@code productId}</td>
+ <td>The item's product identifier. Every item has a product ID, which you must specify in the application's product list on the Google Play publisher site.</td>
+ </tr>
+ <tr>
+ <td>{@code purchaseTime}</td>
+ <td>The time the product was purchased, in milliseconds since the epoch (Jan 1, 1970).</td>
+ </tr>
+ <tr>
+ <td>{@code purchaseState}</td>
+ <td>The purchase state of the order. Possible values are 0 (purchased), 1 (canceled), or 2 (refunded).</td>
+ </tr>
+ <tr>
+ <td>{@code developerPayload}</td>
+ <td>A developer-specified string that contains supplemental information about an order. You can specify a value for this field when you make a {@code getBuyIntent} request.</td>
+ </tr>
+ <tr>
+ <td>{@code purchaseToken}</td>
+ <td>A token that uniquely identifies a purchase for a given item and user pair. </td>
+ </tr>
</table>
+</p>
-<!--<h2 id="other-intents">Other Intents</h2>
-
-<p>The following Intents related to In-app Billing may be useful in your
-implemention. </p> -->
-
-<h2 id="http-api">HTTP API for verification and cancelation</h2>
-
-<p>Google Play offers an HTTP-based API that you can use to remotely query the
-validity of a specific subscription at any time or cancel a subscription. The
-API is designed to be used from your backend servers as a way of securely
-managing subscriptions, as well as extending and integrating subscriptions with
-other services. See <a
-href="{@docRoot}google/play/billing/billing_subscriptions.html#play-dev-api">
-Google Play Android Developer API</a> for more information.</p>
-
-<h2 id="billing-versions">In-app Billing API Versions</h2>
-
-<p>The In-app Billing API is versioned, with each version offering
-additional features to your app. At run time, your app can query the Google Play app to determine
-what version of the API it supports and what features are available. Typically, the Google Play app
-will be updated and will support the latest version of the API.
-
-<p>The sections below list the supported versions of the In-app Billing API.
-Versions are specified in the <code>API_VERSION</code> key of the Bundle object
-passed in the <code>sendBillingRequest()</code>, which is defined in the defined
-in the <code>IMarketBillingService.aidl</code> file, which is included with the
-in-app billing <a
-href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">
-sample application</a>. For more information, see <a
-href="#billing-interface">In-app Billing Service Interface</a>.</p>
-<h3 id="version_2">In-app Billing version 2</h3>
-
-<p><em>May 2012</em></p>
-
-<ul>
-<li>Adds support for subscriptions.
- <ul>
- <li>Adds a new supported string value, "2", for the <code>API_VERSION</code> key
- of the Bundle object passed in the <code>sendBillingRequest()</code>.</li>
- <li>Adds a new JSON field, <code>purchaseToken</code>, to the
- <code>orders</code> list returned in a <code>PURCHASE_STATE_CHANGED</code>
- intent. </li>
- <li>Adds a new <code>purchaseState</code> value, <code>3</code> (expired), to the
- <code>orders</code> list returned in a <code>PURCHASE_STATE_CHANGED</code>
- intent. The value indicates that a subscription has expired and is no longer valid.</li>
-<li>Requires Google Play (Play Store) version 3.5 or higher.</li>
-</ul>
-
-<h3 id="version_1">In-app Billing version 1</h3>
-
-<p><em>March 2011</em></p>
-
-<ul>
-<li>Initial release.</li>
-<li>Requires Google Play/Android Market 2.3.4 or higher.</li>
-</ul>
+<h3 id="getPurchases">The getPurchases() method</h3>
+<p>This method returns the current un-consumed products owned by the user. Table 5 lists the response data that is returned in the {@code Bundle}.</p>
+<p class="table-caption" id="getpurchases-response-table">
+<strong>Table 5.</strong> Response data from a {@code getPurchases} request.</p>
+<table>
+ <tr>
+ <th scope="col">Key</th>
+ <th scope="col">Description</th>
+ </tr>
+ <tr>
+ <td>{@code RESPONSE_CODE}</td>
+ <td>0 if the request was successful, error otherwise.</td>
+ </tr>
+ <tr>
+ <td>{@code INAPP_PURCHASE_ITEM_LIST}</td>
+ <td>{@code StringArrayList} containing the list of productIds of purchases from this app.</td>
+ </tr>
+ <tr>
+ <td>{@code INAPP_PURCHASE_DATA_LIST}</td>
+ <td>{@code StringArrayList} containing the details for purchases from this app. See table 4 for the list of detail information stored in each {@code INAPP_PURCHASE_DATA} item in the list.</td>
+ </tr>
+ <tr>
+ <td>{@code INAPP_DATA_SIGNATURE_LIST}</td>
+ <td>{@code StringArrayList} containing the signatures of purchases from this app.</td>
+ </tr>
+ <tr>
+ <td>{@code INAPP_CONTINUATION_TOKEN}</td>
+ <td>String containing a continuation token to retrieve the next set of in-app products owned by the user. This is only set by the Google Play service if the number of products owned by the user is very large. When a continuation token is present in the response, you must make another call to {@code getPurchases} and pass in the continuation token that you received. The subsequent {@code getPurchases} call returns more purchases and possibly another continuation token.</td>
+ </tr>
+</table>
+</p>
<ol>
<li><a href="#billing-testing-static">Testing in-app purchases with static responses</a></li>
<li><a href="#billing-testing-real">Testing in-app purchases using your own product IDs</a></li>
-
- </ol>
- <h2>Downloads</h2>
- <ol>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">Sample
- Application</a></li>
</ol>
<h2>See also</h2>
<ol>
<li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html">Implementing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
- Design</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
- Reference</a></li>
- </ol>
+ <ol>
</div>
</div>
-<p>The Google Play publisher site provides several tools that help you test your in-app billing
+<p>The Google Play publisher site provides several tools that help you test your In-app Billing
implementation before it is published. You can use these tools to create test accounts and purchase
special reserved items that send static billing responses to your application.</p>
-<p>To test in-app billing in an application you must install the application on an Android-powered
-device. You cannot use the Android emulator to test in-app billing. The device you use for testing
+<p>To test In-app Billing in an application you must install the application on an Android-powered
+device. You cannot use the Android emulator to test In-app Billing. The device you use for testing
must run a standard version of the Android 1.6 or later platform (API level 4 or higher), and have
the most current version of the 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
+most current Google Play application, your application won't be able to send In-app Billing
requests to Google Play. For general information about how to set up a device for use in
developing Android applications, see <a href="{@docRoot}tools/device.html">Using Hardware
Devices</a>.</p>
-<p>The following section shows you how to set up and use the in-app billing test tools.</p>
+<p>The following section shows you how to set up and use the In-app Billing test tools.</p>
<h2 id="billing-testing-static">Testing in-app purchases with static responses</h2>
-<p>We recommend that you first test your in-app billing implementation using static responses from
+<p>We recommend that you first test your In-app Billing implementation using static responses from
Google Play. This enables you to verify that your application is handling the primary Google
Play responses correctly and that your application is able to verify signatures correctly.</p>
-<p>To test your implementation with static responses, you make an in-app billing request using a
+<p>To test your implementation with static responses, you make an In-app Billing request using a
special item that has a reserved product ID. Each reserved product ID returns a specific static
-response from Google Play. No money is transferred when you make in-app billing requests with the
+response from Google Play. No money is transferred when you make In-app Billing requests with the
reserved product IDs. Also, you cannot specify the form of payment when you make a billing request
with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the
product ID android.test.purchased.</p>
install your application on a device, log into the device, and make billing requests using the
reserved product IDs.</p>
-<p>There are four reserved product IDs for testing static in-app billing responses:</p>
+<p>There are four reserved product IDs for testing static In-app Billing responses:</p>
<ul>
<li><strong>android.test.purchased</strong>
- <p>When you make an in-app billing request with this product ID, Google Play responds as
+ <p>When you make an In-app Billing request with this product ID, Google Play responds as
though you successfully purchased an item. The response includes a JSON string, which contains
fake purchase information (for example, a fake order ID). In some cases, the JSON string is
signed and the response includes the signature so you can test your signature verification
implementation using these responses.</p>
</li>
<li><strong>android.test.canceled</strong>
- <p>When you make an in-app billing request with this product ID Google Play responds as
+ <p>When you make an In-app Billing request with this product ID Google Play responds as
though the purchase was canceled. This can occur when an error is encountered in the order
process, such as an invalid credit card, or when you cancel a user's order before it is
charged.</p>
</li>
<li><strong>android.test.refunded</strong>
- <p>When you make an in-app billing request with this product ID, Google Play responds as
+ <p>When you make an In-app Billing request with this product ID, Google Play responds as
though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app
billing service. Refunds must be initiated by you (the merchant). After you process a refund
request through your Google Checkout account, a refund message is sent to your application by
Google Play. This occurs only when Google Play gets notification from Google Checkout that
- a refund has been made. For more information about refunds, see <a
- href="{@docRoot}google/play/billing/billing_overview.html#billing-action-notify">Handling
- IN_APP_NOTIFY messages</a> and <a
- href="http://www.google.com/support/androidmarket/bin/answer.py?answer=1153485">In-app Billing
- Pricing</a>.</p>
+ a refund has been made. For more information about refunds, see <a href="{@docRoot}google/play/billing/v2/api.html#billing-action-notify">Handling
+IN_APP_NOTIFY messages</a> and <a href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=1153485">In-app Billing
+Pricing</a>.</p>
</li>
<li><strong>android.test.item_unavailable</strong>
- <p>When you make an in-app billing request with this product ID, Google Play responds as
+ <p>When you make an In-app Billing request with this product ID, Google Play responds as
though the item being purchased was not listed in your application's product list.</p>
</li>
</ul>
</table>
-<p>To make an in-app billing request with a reserved product ID, you simply construct a normal
+<p>To make an In-app Billing request with a reserved product ID, you simply construct a normal
<code>REQUEST_PURCHASE</code> request, but instead of using a real product ID from your
application's product list you use one of the reserved product IDs.</p>
<ol>
<li><strong>Install your application on an Android-powered device.</strong>
- <p>You cannot use the emulator to test in-app billing; you must install your application on a
- device to test in-app billing.</p>
+ <p>You cannot use the emulator to test In-app Billing; you must install your application on a
+ device to test In-app Billing.</p>
<p>To learn how to install an application on a device, see <a
href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
device</a>.</p>
</li>
<li><strong>Verify that your device is running a supported version of the Google Play
application or the MyApps application.</strong>
- <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
- the MyApps application. If your device is running any other version of Android, in-app billing
+ <p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
+ the MyApps application. If your device is running any other version of Android, In-app Billing
requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
version of the Google Play application, see <a
href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
<li><strong>Run your application and purchase the reserved product IDs.</strong></li>
</ol>
-<p class="note"><strong>Note</strong>: Making in-app billing requests with the reserved product IDs
-overrides the usual Google Play production system. When you send an in-app billing request for a
+<p class="note"><strong>Note</strong>: Making In-app Billing requests with the reserved product IDs
+overrides the usual Google Play production system. When you send an In-app Billing request for a
reserved product ID, the quality of service will not be comparable to the production
environment.</p>
<h2 id="billing-testing-real">Testing In-app Purchases Using Your Own Product IDs</h2>
<p>After you finish your static response testing, and you verify that signature verification is
-working in your application, you can test your in-app billing implementation by making actual in-app
-purchases. Testing real in-app purchases enables you to test the end-to-end in-app billing
+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 Google Play and the actual checkout flow that
users will experience in your application.</p>
testing. You only need to upload your application as a draft application to perform end-to-end
testing.</p>
-<p>To test your in-app billing implementation with actual in-app purchases, you will need to
+<p>To test your In-app Billing implementation with actual in-app purchases, you will need to
register at least one test account on the Google Play publisher site. You cannot use your
developer account to test the complete in-app purchase process because Google Checkout does not let
you buy items from yourself. If you have not set up test accounts before, see <a
want to refund purchases that are made with test accounts, otherwise the purchases will show up as
actual payouts to your merchant account.</p>
-<p>To test your in-app billing implementation with actual purchases, follow these steps:</p>
+<p>To test your In-app Billing implementation with actual purchases, follow these steps:</p>
<ol>
<li><strong>Upload your application as a draft application to the publisher site.</strong>
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 Google Play, see
- <a href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading
+ <a href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=113469">Uploading
applications</a>.</p>
</li>
<li><strong>Add items to the application's product list.</strong>
list</a> to learn how to do this.</p>
</li>
<li><strong>Install your application on an Android-powered device.</strong>
- <p>You cannot use the emulator to test in-app billing; you must install your application on a
- device to test in-app billing.</p>
+ <p>You cannot use the emulator to test In-app Billing; you must install your application on a
+ device to test In-app Billing.</p>
<p>To learn how to install an application on a device, see <a
href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
device</a>.</p>
</li>
<li><strong>Make one of your test accounts the primary account on your device.</strong>
- <p>To perform end-to-end testing of in-app billing, the primary account on your device must be
+ <p>To perform end-to-end testing of In-app Billing, the primary account on your device must be
one of the <a
href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test accounts</a>
that you registered on the Google Play site. If the primary account on your device is not a
</li>
<li><strong>Verify that your device is running a supported version of the Google Play
application or the MyApps application.</strong>
- <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
- the MyApps application. If your device is running any other version of Android, in-app billing
+ <p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
+ the MyApps application. If your device is running any other version of Android, In-app Billing
requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
version of the Google Play application, see <a
href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
<p class="note"><strong>Note:</strong> The only way to change the primary account on a device is to
do a factory reset, making sure you log on with your primary account first.</p>
-<p>When you are finished testing your in-app billing implementation, you are ready to
+<p>When you are finished testing your In-app Billing implementation, you are ready to
publish your application on Google Play. You can follow the normal steps for <a
href="{@docRoot}tools/publishing/preparing.html">preparing</a>, <a
href="{@docRoot}tools/publishing/app-signing.html">signing</a>, and <a
<div class="sidebox">
<h2><strong>New in In-App Billing</strong></h2>
<ul>
- <li><strong>New order number format</strong>— Starting 5 December, orders are reported in Merchant Order Number format. See <a href="{@docRoot}google/play/billing/billing_admin.html#orderId">Working with Order Numbers</a> for an example.</li>
- <li><strong>Free trials</strong>—You can now offer users a configurable <a href="/google/play/billing/billing_subscriptions.html#trials">free trial period</a> for your in-app subscriptions. You can set up trials with a simple change in the Developer Console—no change to your app code is needed.</li>
+ <li><strong>In-app Billing Version 3</strong>—The <a href="{@docRoot}google/play/billing/api.html">latest version</a> of In-app Billing features a synchronous API that is easier to implement and lets you manage products and purchases more effectively.</li>
+ <li><strong>New order number format</strong>—Starting 5 December, orders are reported in Merchant Order Number format. See <a href="/google/play/billing/billing_admin.html#orderId">Working with Order Numbers</a> for an example.</li>
+ <li><strong>Free trials</strong>—You can now offer users a configurable <a href="/google/play/billing/v2/billing_subscriptions.html#trials">free trial period</a> for your in-app subscriptions. You can set up trials with a simple change in the Developer Console—no change to your app code is needed.</li>
</ul>
</div>
</div>
handles all checkout details so your application never has to directly process
any financial transactions. Google Play uses the same checkout backend service as
is used for application purchases, so your users experience a consistent and
-familiar purchase flow (see figure 1). Also, the transaction fee for in-app
-purchases is the same as the transaction fee for application purchases
-(30%).</p>
+familiar purchase flow.</p>
<p>Any application that you publish through Google Play can implement In-app Billing. No special
account or registration is required other than an Android Market publisher account and a Google
-Checkout merchant account. Also, because the service uses no dedicated framework APIs, you can add
-in-app billing to any application that uses a minimum API level of 4 or higher.</p>
+Checkout merchant account.</p>
<p>To help you integrate in-app billing into your application, the Android SDK
provides a sample application that demonstrates how to sell standard in-app
-products and subscriptions from inside an app. The sample contains examples of
-billing-related classes you can use to implement in-app billing in your
-application. It also contains examples of the database, user interface, and
-business logic you might use to implement in-app billing.</p>
+products and subscriptions from inside an app.</p>
-<p class="caution"><strong>Important</strong>: Although the sample application is a working example
-of how you can implement in-app billing, we <em>strongly recommend</em> that you modify and
-obfuscate the sample code before you use it in a production application. For more information, see
-<a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>.</p>
-
-<img src="{@docRoot}images/billing_checkout_flow.png" height="382" id="figure1" />
-<p class="img-caption">
- <strong>Figure 1.</strong> Applications initiate in-app billing requests through their own UI
- (first screen). Google Play responds to the request by providing the checkout user interface
- (middle screen). When checkout is complete, the application resumes.
-</p>
-
-<p>To learn more about Google Play's in-app billing service and start integrating it into your
-applications, read the following documents:</p>
+<p>To get started, read the documents below or take the <a href="{@docRoot}training/in-app-billing/index.html">Selling
+ In-app Products</a> training class.</p>
+</div>
+</div>
<dl>
- <dt><strong><a href="{@docRoot}google/play/billing/billing_overview.html">In-app
- Billing Overview</a></strong></dt>
- <dd>Learn how the service works and what a typical in-app billing implementation looks
- like.</dd>
- <dt><strong><a href="{@docRoot}google/play/billing/billing_integrate.html">Implementing
- In-app Billing</a></strong></dt>
- <dd>Use this step-by-step guide to start incorporating in-app billing into your
- application. The instructions apply to both one-time and subscription purchases.</dd>
-
- <dt><strong><a href="{@docRoot}google/play/billing/billing_subscriptions.html">Subscriptions</a></strong></dt>
- <dd>Learn how subscriptions work and how to implement support for them in your app.</dd>
+ <dt><strong><a href="{@docRoot}google/play/billing/billing_overview.html">Overview</a></strong></dt>
+ <dd>Read this document for a description of the underlying concepts in In-app Billing.</dd>
+ <dt><strong><a href="{@docRoot}google/play/billing/api.html">Version 3 API</a></strong></dt>
+ <dd>Read the documents in this section for an overview of the latest version of In-app Billing, as well as implementation details and API reference.</dd>
<dt><strong><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security
and Design</a></strong></dt>
- <dd>Review these best practices to help ensure that your in-app billing implementation is
+ <dd>Review these best practices to help ensure that your In-app Billing implementation is
secure and well designed.</dd>
<dt><strong><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app
Billing</a></strong></dt>
- <dd>Understand how the in-app billing test tools work and learn how to test your in-app billing
+ <dd>Understand how the In-app Billing test tools work and learn how to test your In-app Billing
implementation.</dd>
<dt><strong><a href="{@docRoot}google/play/billing/billing_admin.html">Administering
In-app Billing</a></strong></dt>
<dd>Learn how to set up your product list, register test accounts, and handle refunds.</dd>
- <dt><strong><a href="{@docRoot}google/play/billing/billing_reference.html">Reference</a></strong></dt>
- <dd>Get detailed information about Google Play response codes and the in-app billing
- interface.</dd>
</dl>
-
--- /dev/null
+page.title=In-app Billing Version 2
+@jd:body
+
+<div style="background-color:#fffdeb;width:100%;margin-bottom:1em;padding:.5em;">In-app Billing Version 2 is superseded. Please <a href="{@docRoot}google/play/billing/billing_overview.html#migration">migrate to Version 3</a> at your earliest convenience.</div>
+ <div id="qv-wrapper" style="margin-top:0;">
+<div id="qv">
+
+ <h2>In this document</h2>
+ <ol>
+ <li><a href="#billing-types">Product and Purchase Types</a></li>
+ <li><a href="#billing-arch">Service Architecture</a></li>
+ <li><a href="#billing-msgs">Service Messages</a></li>
+ <ol>
+ <li><a href="#billing-request">Request messages</a></li>
+ <li><a href="#billing-response">Broadcast intents</a></li>
+ <li><a href="#billing-message-sequence">Messaging sequence</a></li>
+ <li><a href="#billing-action-notify">Handling IN_APP_NOTIFY messages</a></li>
+ </ol>
+ <li><a href="#billing-security">Security Controls</a></li>
+ <li><a href="#billing-limitations">Requirements and Limitations</a></li>
+ </ol>
+</div>
+</div>
+
+<p>In-app Billing version 2 is the legacy version of the Google Play In-app
+Billing. Like Version 3, it lets you interact with the Google Play purchase flow
+and payments system indirectly, by means of IPC communication with the Play
+Store app installed on the device. </p>
+
+<p>Unlike Version 3, the Version 2 API is
+asynchronous and uses service messages sent as broadcast intents, so
+it is more complicated than Version 3. </p>
+
+<p>Version 2 supports both unmanaged and managed products, as well as supports
+subscriptions, where Version 3 does not yet offer support for subscriptions. If
+you want to sell subscriptions in your app, you should implement In-app Billing
+Version 2, rather than Version 3. </p>
+
+<p>If you do not need to sell subscriptions, you
+should implement In-app Billing Version 3 instead.</p>
+
+<div class="sidebox-wrapper">
+<div class="sidebox">
+ <h2>New in In-app Billing V2</h2>
+ <p><strong>Free trials</strong>—You can now offer users a configurable free trial period for
+ your in-app subscriptions. You can set up trials with a simple change in the Developer
+ Console—no change to your app code is needed.</p>
+</div>
+</div>
+
+<h2 id="billing-types">Product Types</h2>
+
+<p>In-app Billing Version supports three different product types
+to give you flexibility in how you monetize your app. In all cases, you define
+your products using the Google Play Developer Console, including product type,
+SKU, price, description, and so on. For more information, see <a
+href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app Billing</a>.</p>
+
+<ul>
+<li><em>Managed per user account</em> — Items that can be purchased only
+once per user account on Google Play. When a user purchases an item that uses
+the "managed per user account" product type, Google Play permanently stores the
+transaction information for each item on a per-user basis. This enables you to
+later query Google Play to 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, Google Play prevents the user from purchasing the item again and
+displays an "Item already purchased" error.
+
+<p>The "managed" product type is useful if you are selling
+items such as game levels or application features. These items are not transient
+and usually need to be restored whenever a user reinstalls your application,
+wipes the data on their device, or installs your application on a new
+device.</p>
+
+<li><em>Unmanaged</em> — Items that do not have their transaction
+information stored on Google Play. This means that you cannot later query Google
+Play to retrieve transaction information for those items. For "unmanaged"
+purchases, you are responsible for managing the transaction information. Also,
+Google Play does not attempt to prevent the user from purchasing an item
+multiple times if it uses the "unmanaged" product type. It's up to you to
+control how many times an unmanaged item can be purchased.</p>
+
+<p>The "unmanaged" product type is useful if you are selling consumable items,
+such as fuel or magic spells. These items are consumed within your application
+and are usually purchased multiple times.</p></li>
+
+<li><em>Subscriptions</em> — Items that are sold with a
+developer-specified, recurring billing interval. When a user purchases a
+subscription, Google Play and its payment processor automatically bill the
+user's account at the specified interval and price, charging the amount to the
+original payment method. Once the user purchases a subscription, Google Play
+continues billing the account indefinitely, without requiring approval or action
+from the user. The user can cancel the subscription at any time.
+
+<p>Subscriptions can only be sold using the "managed per user account" purchase
+type. As with in-app products, once the user has purchased an in-app product
+there is no refund window. Users desiring refunds must contact the developer
+directly. For more information about subscriptions and how to sell them in your
+apps, see the <a href="{@docRoot}google/play/billing/v2/billing_subscriptions.html">Subscriptions</a>
+document.</p></li>
+</ul>
+
+<h2 id="billing-arch">Service Architecture</h2>
+
+<p>Your app accesses the In-app Billing service using an API that is exposed by
+the Google Play app installed on the device. The Google Play app then uses an
+asynchronous message loop to convey billing requests and responses between your
+application and the Google Play server. In practice, your application never
+directly communicates with the Google Play server (see figure 1). Instead, your
+application sends billing requests to the Google Play application over
+interprocess communication (IPC) and receives purchase responses from the Google
+Play application in the form of asynchronous broadcast intents. Your application
+does not manage any network connections between itself and the Google Play
+server or use any special APIs from the Android platform.</p>
+
+<div class="figure" style="width:440px">
+<img src="/images/billing_arch.png" alt="" height="582" />
+<p class="img-caption">
+ <strong>Figure 1.</strong> Your application sends and receives billing messages through the
+ Google Play application, which handles all communication with the Google Play server.</p>
+</div>
+
+<p>Some in-app billing implementations may also use a private remote server to deliver content or
+validate transactions, but a remote server is not required to implement in-app billing. A remote
+server can be useful if you are selling digital content that needs to be delivered to a user's
+device, such as media files or photos. You might also use a remote server to store users'
+transaction history or perform various in-app billing security tasks, such as signature
+verification. Although you can handle all security-related tasks in your application, performing
+those tasks on a remote server is recommended because it helps make your application less vulnerable
+to security attacks.</p>
+
+<p>A typical in-app billing implementation relies on three components:</p>
+<ul>
+ <li>A {@link android.app.Service Service} (named <code>BillingService</code> in the sample application),
+ which processes purchase messages from the application and sends billing requests to the Google
+ Play in-app billing service.</li>
+ <li>A {@link android.content.BroadcastReceiver BroadcastReceiver} (named <code>BillingReceiver</code> in the sample
+ application), which receives all asynchronous billing responses from the Google Play
+ application.</li>
+ <li>A security component (named <code>Security</code> in the sample application), which performs
+ security-related tasks, such as signature verification and nonce generation. For more information
+ about in-app billing security, see <a href="#billing-security">Security controls</a> later in this
+ document.</li>
+</ul>
+
+<p>You may also want to incorporate two other components to support in-app billing:</p>
+<ul>
+ <li>A response {@link android.os.Handler Handler} (named <code>ResponseHandler</code> in the sample
+ application), which provides application-specific processing of purchase notifications, errors,
+ and other status messages.</li>
+ <li>An observer (named <code>PurchaseObserver</code> in the sample application), which is
+ responsible for sending callbacks to your application so you can update your user interface with
+ purchase information and status.</li>
+</ul>
+
+<p>In addition to these components, your application must provide a way to store information about
+users' purchases and some sort of user interface that lets users select items to purchase. You do
+not need to provide a checkout user interface. When a user initiates an in-app purchase, the Google
+Play application presents the checkout user interface to your user. When the user completes the
+checkout process, your application resumes.</p>
+
+<h2 id="billing-msgs">In-app Billing Messages</h2>
+
+<p>When the user initiates a purchase, your application sends billing messages to Google Play's
+in-app billing service (named <code>MarketBillingService</code>) using simple IPC method calls. The
+Google Play application responds to all billing requests synchronously, providing your
+application with status notifications and other information. The Google Play application also
+responds to some billing requests asynchronously, providing your application with error messages and
+detailed transaction information. The following section describes the basic request-response
+messaging that takes place between your application and the Google Play application.</p>
+
+<h3 id="billing-request">In-app billing requests</h3>
+
+<p>Your application sends in-app billing requests by invoking a single IPC method
+(<code>sendBillingRequest()</code>), which is exposed by the <code>MarketBillingService</code>
+interface. This interface is defined in an <a
+href="{@docRoot}guide/components/aidl.html">Android Interface Definition Language</a> file
+(<code>IMarketBillingService.aidl</code>). You can <a
+href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">download</a> this AIDL
+file with the in-app billing sample application.</p>
+
+<p>The <code>sendBillingRequest()</code> method has a single {@link android.os.Bundle Bundle} parameter.
+The Bundle that you deliver must include several key-value pairs that specify various parameters for
+the request, such as the type of billing request you are making, the item that is being purchased and
+its type, and the application that is making the request. For more information about the Bundle keys
+that are sent with a request, see <a
+href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-interface">In-app Billing
+Service Interface</a>.
+
+<p>One of the most important keys that every request Bundle must have is the
+<code>BILLING_REQUEST</code> key. This key lets you specify the type of billing request you are
+making. Google Play's in-app billing service supports the following five types of billing
+requests:</p>
+
+<ul>
+ <li><code>CHECK_BILLING_SUPPORTED</code>
+ <p>This request verifies that the Google Play application supports in-app billing. You
+ usually send this request when your application first starts up. This request is useful if you
+ want to enable or disable certain UI features that are relevant only to in-app billing.</p>
+ </li>
+ <li><code>REQUEST_PURCHASE</code>
+ <p>This request sends a purchase message to the Google Play application and is the foundation
+ of in-app billing. You send this request when a user indicates that he or she wants to purchase
+ an item in your application. Google Play then handles the financial transaction by displaying
+ the checkout user interface.</p>
+ </li>
+ <li><code>GET_PURCHASE_INFORMATION</code>
+ <p>This request retrieves the details of a purchase state change. A purchase changes state when
+ a requested purchase is billed successfully or when a user cancels a transaction during
+ checkout. It can also occur when a previous purchase is refunded. Google Play notifies your
+ application when a purchase changes state, so you only need to send this request when there is
+ transaction information to retrieve.</p>
+ </li>
+ <li><code>CONFIRM_NOTIFICATIONS</code>
+ <p>This request acknowledges that your application received the details of a purchase state
+ change. Google Play sends purchase state change notifications to your application until you
+ confirm that you received them.</p>
+ </li>
+ <li><code>RESTORE_TRANSACTIONS</code>
+ <p>This request retrieves a user's transaction status for <a
+ href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">managed
+ purchases</a> and <a
+ href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">subscriptions</a>.
+ You should send this request only when you need to retrieve a user's transaction
+ status, which is usually only when your application is reinstalled or installed for the first
+ time on a device.</p>
+ </li>
+</ul>
+
+<h3 id="billing-response">In-app Billing Responses</h3>
+
+<p>The Google Play application responds to in-app billing requests with both synchronous and
+asynchronous responses. The synchronous response is a {@link android.os.Bundle Bundle} with the following
+three keys:</p>
+
+<ul>
+ <li><code>RESPONSE_CODE</code>
+ <p>This key provides status information and error information about a request.</p>
+ </li>
+ <li><code>PURCHASE_INTENT</code>
+ <p>This key provides a {@link android.app.PendingIntent PendingIntent}, which you use to launch the checkout
+ activity.</p>
+ </li>
+ <li><code>REQUEST_ID</code>
+ <p>This key provides you with a request identifier, which you can use to match asynchronous
+ responses with requests.</p>
+ </li>
+</ul>
+<p>Some of these keys are not relevant to every request. For more information, see <a
+href="#billing-message-sequence">Messaging sequence</a> later in this document.</p>
+
+<p>The asynchronous response messages are sent in the form of individual broadcast intents and
+include the following:</p>
+
+<ul>
+ <li><code>com.android.vending.billing.RESPONSE_CODE</code>
+ <p>This response contains a Google Play server response code, and is sent after you make an
+ in-app billing request. A server response code can indicate that a billing request was
+ successfully sent to Google Play or it can indicate that some error occurred during a billing
+ request. This response is <em>not</em> used to report any purchase state changes (such as refund
+ or purchase information). For more information about the response codes that are sent with this
+ response, see <a
+ href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-codes">Server Response Codes
+ for In-app Billing</a>.</p>
+ </li>
+ <li><code>com.android.vending.billing.IN_APP_NOTIFY</code>
+ <p>This response indicates that a purchase has changed state, which means a purchase succeeded,
+ was canceled, or was refunded. This response contains one or more notification IDs. Each
+ notification ID corresponds to a specific server-side message, and each messages contains
+ information about one or more transactions. After your application receives an
+ <code>IN_APP_NOTIFY</code> broadcast intent, you send a <code>GET_PURCHASE_INFORMATION</code>
+ request with the notification IDs to retrieve message details.</p>
+ </li>
+ <li><code>com.android.vending.billing.PURCHASE_STATE_CHANGED</code>
+ <p>This response contains detailed information about one or more transactions. The transaction
+ information is contained in a JSON string. The JSON string is signed and the signature is sent
+ to your application along with the JSON string (unencrypted). To help ensure the security of
+ your in-app billing messages, your application can verify the signature of this JSON string.</p>
+ </li>
+</ul>
+
+<p>The JSON string that is returned with the <code>PURCHASE_STATE_CHANGED</code> intent provides
+your application with the details of one or more billing transactions. An example of this JSON
+string for a subscription item is shown below:</p>
+<pre class="no-pretty-print" style="color:black">{ "nonce" : 1836535032137741465,
+ "orders" :
+ [{ "notificationId" : "android.test.purchased",
+ "orderId" : "transactionId.android.test.purchased",
+ "packageName" : "com.example.dungeons",
+ "productId" : "android.test.purchased",
+ "developerPayload" : "bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ",
+ "purchaseTime" : 1290114783411,
+ "purchaseState" : 0,
+ "purchaseToken" : "rojeslcdyyiapnqcynkjyyjh" }]
+}
+</pre>
+
+<p>For more information about the fields in this JSON string, see <a
+href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-intents">In-app Billing
+Broadcast Intents</a>.</p>
+
+<h3 id="billing-message-sequence">Messaging sequence</h3>
+
+<p>The messaging sequence for a typical purchase request is shown in figure 2. Request types for
+each <code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents
+are shown in <em>italic</em>. For clarity, figure 2 does not show the <code>RESPONSE_CODE</code>
+broadcast intents that are sent for every request.</p>
+
+<p>The basic message sequence for an in-app purchase request is as follows:</p>
+
+<ol>
+ <li>Your application sends a purchase request (<code>REQUEST_PURCHASE</code> type), specifying a
+ product ID and other parameters.</li>
+ <li>The Google Play application sends your application a Bundle with the following keys:
+ <code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and <code>REQUEST_ID</code>. The
+ <code>PURCHASE_INTENT</code> key provides a {@link android.app.PendingIntent PendingIntent}, which your
+ application uses to start the checkout UI for the given product ID.</li>
+ <li>Your application launches the pending intent, which launches the checkout UI.
+ <p class="note"><strong>Note:</strong> You must launch the pending intent from an activity
+ context and not an application context.</p>
+ </li>
+ <li>When the checkout flow finishes (that is, the user successfully purchases the item or cancels
+ the purchase), Google Play sends your application a notification message (an
+ <code>IN_APP_NOTIFY</code> broadcast intent). The notification message includes a notification ID,
+ which references the transaction.</li>
+ <li>Your application requests the transaction information by sending a
+ <code>GET_PURCHASE_STATE_CHANGED</code> request, specifying the notification ID for the
+ transaction.</li>
+ <li>The Google Play application sends a Bundle with a <code>RESPONSE_CODE</code> key and a
+ <code>REQUEST_ID</code> key.
+ <li>Google Play sends the transaction information to your application in a
+ <code>PURCHASE_STATE_CHANGED</code> broadcast intent.</li>
+ <li>Your application confirms that you received the transaction information for the given
+ notification ID by sending a confirmation message (<code>CONFIRM_NOTIFICATIONS</code> type),
+ specifying the notification ID for which you received transaction information.</li>
+ <li>The Google Play application sends your application a Bundle with a
+ <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key.</li>
+</ol>
+
+<img src="/images/billing_request_purchase.png" height="231" id="figure2" />
+<p class="img-caption">
+ <strong>Figure 2.</strong> Message sequence for a purchase request.
+</p>
+
+<p>Keep in mind, you must send a confirmation when you receive transaction information from Google
+Play (step 8 in figure 2). If you don't send a confirmation message, Google Play will
+continue sending <code>IN_APP_NOTIFY</code> messages for the transactions you have not
+confirmed. As a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request for
+a purchased item until you have delivered the item to the user. This way, if your application
+crashes or something else prevents your application from delivering the product, your application
+will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating
+that you need to deliver the product. Also, as a best practice, your application must be able to
+handle <code>IN_APP_NOTIFY</code> messages that contain multiple orders.</p>
+
+<p>The messaging sequence for a restore transaction request is shown in figure 3. Request types for
+each <code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents
+are shown in <em>italic</em>. For clarity, figure 3 does not show the <code>RESPONSE_CODE</code>
+broadcast intents that are sent for every request.</p>
+
+<div class="figure" style="width:490px">
+<img src="/images/billing_restore_transactions.png" alt="" height="168" />
+<p class="img-caption">
+ <strong>Figure 3.</strong> Message sequence for a restore transactions request.
+</p>
+</div>
+
+<p>The request triggers three responses. The first is a {@link android.os.Bundle Bundle} with a
+<code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key. Next, the Google Play
+application sends a <code>RESPONSE_CODE</code> broadcast intent, which provides status information
+or error information about the request. As always, the <code>RESPONSE_CODE</code> message references
+a specific request ID, so you can determine which request a <code>RESPONSE_CODE</code> message
+pertains to.</p>
+
+<p>The <code>RESTORE_TRANSACTIONS</code> request type also triggers a
+<code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the same type of transaction
+information that is sent during a purchase request. Unlike with a purchase request, however, the transactions
+are given without any associated notification IDs, so you do not need to respond to this
+intent with a <code>CONFIRM_NOTIFICATIONS</code> message. </p>
+
+<p class="note"><strong>Note:</strong> You should use the <code>RESTORE_TRANSACTIONS</code> request
+type only when your application is installed for the first time on a device or when your
+application has been removed from a device and reinstalled.</p>
+
+<p>The messaging sequence for checking whether in-app billing is supported is shown in figure 4. The
+request type for the <code>sendBillingRequest()</code> method is shown in <strong>bold</strong>.</p>
+
+<div class="figure" style="width:454px">
+<img src="/images/billing_check_supported.png" alt="" height="168" />
+<p class="img-caption">
+ <strong>Figure 4.</strong> Message sequence for checking whether in-app billing is supported.
+</p>
+</div>
+
+<p>The synchronous response for a <code>CHECK_BILLING_SUPPORTED</code> request provides a Bundle
+with a server response code. A <code>RESULT_OK</code> response code indicates that in-app billing
+is supported; a <code>RESULT_BILLING_UNAVAILABLE</code> response code indicates that in-app billing
+is unavailable because the API version you specified is unrecognized or the user is not eligible to
+make in-app purchases (for example, the user resides in a country that does not allow in-app
+billing). A <code>SERVER_ERROR</code> can also be returned, indicating that there was a problem with
+the Google Play server.</p>
+
+<h3 id="billing-action-notify">Handling IN_APP_NOTIFY messages</h3>
+
+<p>Usually, your application receives an <code>IN_APP_NOTIFY</code> broadcast intent from Google
+Play in response to a <code>REQUEST_PURCHASE</code> message (see figure 2). The
+<code>IN_APP_NOTIFY</code> broadcast intent informs your application that the state of a requested
+purchase has changed. To retrieve the details of that purchase, your application sends a
+<code>GET_PURCHASE_INFORMATION</code> request. Google Play responds with a
+<code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the details of the purchase
+state change. Your application then sends a <code>CONFIRM_NOTIFICATIONS</code> message, informing
+Google Play that you have received the purchase state change information.</p>
+
+<p>In some special cases, you may receive multiple <code>IN_APP_NOTIFY</code> messages even though
+you have confirmed receipt of the purchase information, or you may receive
+<code>IN_APP_NOTIFY</code> messages for a purchase change even though you never initiated the
+purchase. Your application must handle both of these special cases.</p>
+
+<h4>Handling multiple IN_APP_NOTIFY messages</h4>
+
+<p>When Google Play receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given
+<code>PURCHASE_STATE_CHANGED</code> message, it usually stops sending <code>IN_APP_NOTIFY</code>
+intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Google
+Play may send repeated <code>IN_APP_NOTIFY</code> intents for a
+<code>PURCHASE_STATE_CHANGED</code> message even though your application has sent a
+<code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a device loses network connectivity
+while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Google Play
+might not receive your <code>CONFIRM_NOTIFICATIONS</code> message and it could send multiple
+<code>IN_APP_NOTIFY</code> messages until it receives acknowledgement that you received the
+transaction message. Therefore, your application must be able to recognize that the subsequent
+<code>IN_APP_NOTIFY</code> messages are for a previously processed transaction. You can do this by
+checking the <code>orderID</code> that's contained in the JSON string because every transaction has
+a unique <code>orderId</code>.</p>
+
+<h4>Handling refunds and other unsolicited IN_APP_NOTIFY messages</h4>
+
+<p>There are two cases where your application may receive <code>IN_APP_NOTIFY</code> broadcast
+intents even though your application has not sent a <code>REQUEST_PURCHASE</code> message. Figure 5
+shows the messaging sequence for both of these cases. Request types for each
+<code>sendBillingRequest()</code> method are shown in <strong>bold</strong>, broadcast intents are
+shown in <em>italic</em>. For clarity, figure 5 does not show the <code>RESPONSE_CODE</code>
+broadcast intents that are sent for every request.</p>
+
+<div class="figure" style="width:481px">
+<img src="/images/billing_refund.png" alt="" height="189" />
+<p class="img-caption">
+ <strong>Figure 5.</strong> Message sequence for refunds and other unsolicited
+IN_APP_NOTIFY messages.</p>
+</div>
+
+<p>In the first case, your application may receive an <code>IN_APP_NOTIFY</code> broadcast intent
+when a user has your application installed on two (or more) devices and the user makes an in-app
+purchase from one of the devices. In this case, Google Play sends an <code>IN_APP_NOTIFY</code>
+message to the second device, informing the application that there is a purchase state change. Your
+application can handle this message the same way it handles the response from an
+application-initiated <code>REQUEST_PURCHASE</code> message, so that ultimately your application
+receives a <code>PURCHASE_STATE_CHANGED</code> broadcast intent message that includes information
+about the item that has been purchased. This applies only to items that have their product type
+set to "managed per user account."</p>
+
+<p>In the second case, your application can receive an <code>IN_APP_NOTIFY</code> broadcast intent
+when Google Play receives a refund notification from Google Wallet. In this case, Google
+Play sends an <code>IN_APP_NOTIFY</code> message to your application. Your application can handle
+this message the same way it handles responses from an application-initiated
+<code>REQUEST_PURCHASE</code> message so that ultimately your application receives a
+<code>PURCHASE_STATE_CHANGED</code> message that includes information about the item that has been
+refunded. The refund information is included in the JSON string that accompanies the
+<code>PURCHASE_STATE_CHANGED</code> broadcast intent. Also, the <code>purchaseState</code> field in
+the JSON string is set to 2.</p>
+
+<p class="caution"><strong>Important:</strong> You cannot use the Google Wallet API to
+issue refunds or cancel in-app billing transactions. You must do this manually through your
+Google Wallet merchant account. However, you can use the Google Wallet API to retrieve order
+information.</p>
+
+<h2 id="billing-security">Security Controls</h2>
+
+<p>To help ensure the integrity of the transaction information that is sent to your application,
+Google Play signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code>
+broadcast intent. Google Play uses the private key that is associated with the app to create
+this signature. The Developer Console generates an RSA key pair for each app.
+You can find the public key portion of this key pair in the app's publishing details
+in the Developer Console, under <strong>Settings</strong>, in the License Key field.</p>
+
+<p>When Google Play signs a billing response, it includes the signed JSON string (unencrypted)
+and the signature. When your application receives this signed response you can use the public key
+portion of your RSA key pair to verify the signature. By performing signature verification you can
+help detect responses that have been tampered with or that have been spoofed. You can perform this
+signature verification step in your application; however, if your application connects to a secure
+remote server then we recommend that you perform the signature verification on that server.</p>
+
+<p>In-app billing also uses nonces (a random number used once) to help verify the integrity of the
+purchase information that's returned from Google Play. Your application must generate a nonce and
+send it with a <code>GET_PURCHASE_INFORMATION</code> request and a <code>RESTORE_TRANSACTIONS</code>
+request. When Google Play receives the request, it adds the nonce to the JSON string that
+contains the transaction information. The JSON string is then signed and returned to your
+application. When your application receives the JSON string, you need to verify the nonce as well as
+the signature of the JSON string.</p>
+
+<p>For more information about best practices for security and design, see <a
+href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>.</p>
+
+<h2 id="billing-limitations">In-app Billing Requirements and Limitations</h2>
+
+<p>Before you get started with in-app billing, be sure to review the following requirements and
+limitations.</p>
+
+<ul>
+ <li>In-app billing can be implemented only in applications that you publish through Google
+ Play.</li>
+ <li>You must have a Google Wallet Merchant account to use Google Play In-app Billing.</li>
+ <li>In-app billing requires version 2.3.4 (or higher) of the Android Market application.
+ To support subscriptions, version 3.5 or higher of the Google Play app is required. On devices
+ running Android 3.0, version 5.0.12 (or higher) of the MyApps application is required.</li>
+ <li>An application can use in-app billing only if the device is running Android 1.6 (API level 4)
+ or higher.</li>
+ <li>You can use in-app billing to sell only digital content. You cannot use in-app billing to sell
+ physical goods, personal services, or anything that requires physical delivery.</li>
+ <li>Google Play does not provide any form of content delivery. You are responsible for
+ delivering the digital content that you sell in your applications.</li>
+ <li>You cannot implement in-app billing on a device that never connects to the network. To
+ complete in-app purchase requests, a device must be able to access the Google Play server over
+ the network. </li>
+</ul>
--- /dev/null
+page.title=Implementing In-app Billing <span style="font-size:16px;">(IAB Version 2)</span>
+@jd:body
+
+<div style="background-color:#fffdeb;width:100%;margin-bottom:1em;padding:.5em;">In-app Billing Version 2 is superseded. Please <a href="{@docRoot}google/play/billing/billing_overview.html#migration">migrate to Version 3</a> at your earliest convenience.</div>
+ <div id="qv-wrapper" style="margin-top:0;">
+<div id="qv">
+ <h2>In this document</h2>
+ <ol>
+ <li><a href="#billing-download">Downloading the Sample</a></li>
+ <li><a href="#billing-add-aidl">Adding the AIDL file to your project</a></li>
+ <li><a href="#billing-permission">Updating Your Manifest</a></li>
+ <li><a href="#billing-service">Creating a Service</a></li>
+ <li><a href="#billing-broadcast-receiver">Creating a BroadcastReceiver</a></li>
+ <li><a href="#billing-security">Securing Your App</a></li>
+ <li><a href="#billing-implement">Modifying Your Application Code</a></li>
+ </ol>
+ <h2>Downloads</h2>
+ <ol>
+ <li><a href="#billing-download">Sample Application (V2)</a></li>
+ </ol>
+</div>
+</div>
+
+<p>This document helps you implement In-app Billing Version 2 by stepping through the primary
+implementation tasks, using the sample application as an example.</p>
+
+<p>Before you implement in-app billing in your own application, be sure that you read <a
+href="{@docRoot}google/play/billing/v2/api.html">Overview of In-app Billing Version 2</a> and <a
+href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>. These
+documents provide background information that will make it easier for you to implement in-app
+billing.</p>
+
+<p>To implement in-app billing in your application, you need to do the following:</p>
+<ol>
+ <li><a href="#billing-download">Download the in-app billing sample application</a>.</li>
+ <li><a href="#billing-add-aidl">Add the IMarketBillingService.aidl file</a> to your project.</li>
+ <li><a href="#billing-permission">Update your AndroidManifest.xml file</a>.</li>
+ <li><a href="#billing-service">Create a Service</a> and bind it to the
+ <code>MarketBillingService</code> so your application can send billing requests and receive
+ billing responses from Google Play.</li>
+ <li><a href="#billing-broadcast-receiver">Create a BroadcastReceiver</a> to handle broadcast
+ intents from Google Play.</li>
+ <li><a href="#billing-signatures">Create a security processing component</a> to verify the
+ integrity of the transaction messages that are sent by Google Play.</li>
+ <li><a href="#billing-implement">Modify your application code</a> to support in-app billing.</li>
+</ol>
+
+<h2 id="billing-download">Downloading the Sample Application</h2>
+
+<p>The in-app billing sample application shows you how to perform several tasks that are common to
+all in-app billing implementations, including:</p>
+
+<ul>
+ <li>Sending in-app billing requests to Google Play.</li>
+ <li>Handling synchronous responses from Google Play.</li>
+ <li>Handling broadcast intents (asynchronous responses) from Google Play.</li>
+ <li>Using in-app billing security mechanisms to verify the integrity of billing responses.</li>
+ <li>Creating a user interface that lets users select items for purchase.</li>
+</ul>
+
+<p>The sample application includes an application file (<code>Dungeons.java</code>), the AIDL file
+for the <code>MarketBillingService</code> (<code>IMarketBillingService.aidl</code>), and several
+classes that demonstrate in-app billing messaging. It also includes a class that demonstrates basic
+security tasks, such as signature verification.</p>
+
+<p>Table 1 lists the source files that are included with the sample application.</p>
+<p class="table-caption" id="source-files-table"><strong>Table 1.</strong> In-app billing sample
+application source files.</p>
+
+<table>
+<tr>
+<th>File</th>
+<th>Description</th>
+</tr>
+
+<tr>
+<td>IMarketBillingService.aidl</td>
+<td>Android Interface Definition Library (AIDL) file that defines the IPC interface to Google
+Play's in-app billing service (<code>MarketBillingService</code>).</td>
+</tr>
+
+<tr>
+<td>Dungeons.java</td>
+<td>Sample application file that provides a UI for making purchases and displaying purchase
+history.</td>
+</tr>
+
+<tr>
+<td>PurchaseDatabase.java</td>
+<td>A local database for storing purchase information.</td>
+</tr>
+
+<tr>
+ <td>BillingReceiver.java</td>
+ <td>A {@link android.content.BroadcastReceiver} that receives asynchronous response messages
+ (broadcast intents) from Google Play. Forwards all messages to the
+ <code>BillingService</code>.</td>
+</tr>
+<tr>
+ <td>BillingService.java</td>
+ <td>A {@link android.app.Service} that sends messages to Google Play on behalf of the
+ application by connecting (binding) to the <code>MarketBillingService</code>.</td>
+</tr>
+
+<tr>
+ <td>ResponseHandler.java</td>
+ <td>A {@link android.os.Handler} that contains methods for updating the purchases database and the
+ UI.</td>
+</tr>
+
+<tr>
+ <td>PurchaseObserver.java</td>
+ <td>An abstract class for observing changes related to purchases.</td>
+</tr>
+
+<tr>
+<td>Security.java</td>
+<td>Provides various security-related methods.</td>
+</tr>
+
+<tr>
+<td>Consts.java</td>
+<td>Defines various Google Play constants and sample application constants. All constants that
+are defined by Google Play must be defined the same way in your application.</td>
+</tr>
+
+<tr>
+<td>Base64.java and Base64DecoderException.java</td>
+<td>Provides conversion services from binary to Base64 encoding. The <code>Security</code> class
+relies on these utility classes.</td>
+</tr>
+
+</table>
+
+<p>The in-app billing sample application is available as a downloadable component of the Android
+SDK. To download the sample application component, launch the Android SDK Manager and then
+select the <strong>Google Market Billing package</strong> component (see figure 1), and click <strong>Install
+Selected</strong> to begin the download.</p>
+
+
+<img src="{@docRoot}images/billing_package.png" height="325" id="figure1" />
+<p class="img-caption">
+ <strong>Figure 1.</strong> The Google Market Billing package contains the sample application and
+ the AIDL file.
+</p>
+
+<p>When the download is complete, the Android SDK Manager saves the component into the
+following directory:</p>
+
+<p><code><sdk>/extras/google/market_billing/</code></p>
+
+<p>If you want to see an end-to-end demonstration of in-app billing before you integrate in-app
+billing into your own application, you can build and run the sample application. Building and
+running the sample application involves three tasks:</p>
+
+<ul>
+ <li>Configuring and building the sample application.</li>
+ <li>Uploading the sample application to Google Play.</li>
+ <li>Setting up test accounts and running the sample application.</li>
+</ul>
+
+<p class="note"><strong>Note:</strong> Building and running the sample application is necessary only
+if you want to see a demonstration of in-app billing. If you do not want to run the sample
+application, you can skip to the next section, <a href="#billing-add-aidl">Adding the AIDL file to
+your project</a>.</p>
+
+<h3>Configuring and building the sample application</h3>
+
+<p>Before you can run the sample application, you need to configure it and build it by doing the
+following:</p>
+
+<ol>
+ <li><strong>Add your Google Play public key to the sample application code.</strong>
+ <p>This enables the application to verify the signature of the transaction information that is
+ returned from Google Play. To add your public key to the sample application code, do the
+ following:</p>
+ <ol>
+ <li>Log in to your Google Play <a href="http://play.google.com/apps/publish">publisher
+ account</a>.</li>
+ <li>On the upper left part of the page, under your name, click <strong>Edit
+ Profile</strong>.</li>
+ <li>On the Edit Profile page, scroll down to the <strong>Licensing & In-app
+ Billing</strong> panel.</li>
+ <li>Copy your public key.</li>
+ <li>Open <code>src/com/example/dungeons/Security.java</code> in the editor of your choice.
+ <p>You can find this file in the sample application's project folder.</p>
+ </li>
+ <li>Add your public key to the following line of code:
+ <p><code>String base64EncodedPublicKey = "your public key here";</code></p>
+ </li>
+ <li>Save the file.</li>
+ </ol>
+ </li>
+ <li><strong>Change the package name of the sample application.</strong>
+ <p>The current package name is <code>com.example.dungeons</code>. Google Play does not let
+ you upload applications with package names that contain <code>com.example</code>, so you must
+ change the package name to something else.</p>
+ </li>
+ <li><strong>Build the sample application in release mode and sign it.</strong>
+ <p>To learn how to build and sign applications, see <a
+ href="{@docRoot}tools/building/index.html">Building and Running</a>.</p>
+ </li>
+</ol>
+
+<h3>Uploading the sample application</h3>
+
+<p>After you build a release version of the sample application and sign it, you need to upload it as
+a draft to the Google Play publisher site. You also need to create a product list for the in-app
+items that are available for purchase in the sample application. The following instructions show you
+how to do this.</p>
+<ol>
+ <li><strong>Upload the release version of the sample application to Google Play.</strong>
+ <p>Do not publish the sample application; leave it as an unpublished draft application. The
+ sample application is for demonstration purposes only and should not be made publicly available
+ on Google Play. To learn how to upload an application to Google Play, see <a
+ href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=113469">Uploading
+ applications</a>.</p>
+ </li>
+ <li><strong>Create a product list for the sample application.</strong>
+ <p>The sample application lets you purchase two items: a two-handed sword
+ (<code>sword_001</code>) and a potion (<code>potion_001</code>). We recommend that you set up
+ your product list so that <code>sword_001</code> has a purchase type of "Managed per user
+ account" and <code>potion_001</code> has a purchase type of "Unmanaged" so you can see how these
+ two purchase types behave. To learn how to set up a product list, see <a
+ href="{@docRoot}google/play/billing/billing_admin.html#billing-list-setup">Creating a Product
+ List</a>.</p>
+ <p class="note"><strong>Note:</strong> You must publish the items in your product
+ list (<code>sword_001</code> and <code>potion_001</code>) even though you are not publishing the
+ sample application. Also, you must have a Google Checkout Merchant account to add items to the
+ sample application's product list.</p>
+ </li>
+</ol>
+
+<h3>Running the sample application</h3>
+
+<p>You cannot run the sample application in the emulator. You must install the sample application
+onto a device to run it. To run the sample application, do the following:</p>
+
+<ol>
+ <li><strong>Make sure you have at least one test account registered under your Google Play
+ publisher account.</strong>
+ <p>You cannot purchase items from yourself (Google Checkout prohibits this), so you need to
+ create at least one test account that you can use to purchase items in the sample application.
+ To learn how to set up a test account, see <a
+ href="{@docRoot}google/play/billing/billing_testing.html#billing-testing-setup">Setting up Test
+ Accounts</a>.</p>
+ </li>
+ <li><strong>Verify that your device is running a supported version of the Google Play
+ application or the MyApps application.</strong>
+ <p>If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
+ the MyApps application. If your device is running any other version of Android, in-app billing
+ requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+ version of the Google Play application, see <a
+ href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
+ Play</a>.</p>
+ </li>
+ <li><strong>Install the application onto your device.</strong>
+ <p>Even though you uploaded the application to Google Play, the application is not published,
+ so you cannot download it from Google Play to a device. Instead, you must install the
+ application onto your device. To learn how to install an application onto a device, see <a
+ href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
+ device</a>.</p>
+ </li>
+ <li><strong>Make one of your test accounts the primary account on your device.</strong>
+ <p>The primary account on your device must be one of the <a
+ href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test accounts</a>
+ that you registered on the Google Play publisher site. If the primary account on your device is not a
+ test account, you must do a factory reset of the device and then sign in with one of your test
+ accounts. To perform a factory reset, do the following:</p>
+ <ol>
+ <li>Open Settings on your device.</li>
+ <li>Touch <strong>Privacy</strong>.</li>
+ <li>Touch <strong>Factory data reset</strong>.</li>
+ <li>Touch <strong>Reset phone</strong>.</li>
+ <li>After the phone resets, be sure to sign in with one of your test accounts during the
+ device setup process.</li>
+ </ol>
+ </li>
+ <li><strong>Run the application and purchase the sword or the potion.</strong>
+ <p>When you use a test account to purchase items, the test account is billed through Google
+ Wallet and your Google Checkout Merchant account receives a payout for the purchase.
+ Therefore, you may want to refund purchases that are made with test accounts, otherwise the
+ purchases will show up as actual payouts to your merchant account.</p>
+</ol>
+
+<p class="note"><strong>Note</strong>: Debug log messages are turned off by default in the
+sample application. You can turn them on by setting the variable <code>DEBUG</code>
+to <code>true</code> in the <code>Consts.java</code> file.</p>
+
+<h2 id="billing-add-aidl">Adding the AIDL file to your project</h2>
+
+<p>The sample application contains an Android Interface Definition Language (AIDL) file, which
+defines the interface to Google Play's in-app billing service
+(<code>MarketBillingService</code>). When you add this file to your project, the Android build
+environment creates an interface file (<code>IMarketBillingService.java</code>). You can then use
+this interface to make billing requests by invoking IPC method calls.</p>
+
+<p>If you are using the ADT plug-in with Eclipse, you can just add this file to your
+<code>/src</code> directory. Eclipse will automatically generate the interface file when you build
+your project (which should happen immediately). If you are not using the ADT plug-in, you can put
+the AIDL file into your project and use the Ant tool to build your project so that the
+<code>IMarketBillingService.java</code> file gets generated.</p>
+
+<p>To add the <code>IMarketBillingService.aidl</code> file to your project, do the following:</p>
+
+<ol>
+ <li>Create the following directory in your application's <code>/src</code> directory:
+ <p><code>com/android/vending/billing/</code></p>
+ </li>
+ <li>Copy the <code>IMarketBillingService.aidl</code> file into the
+ <code>sample/src/com/android/vending/billing/</code> directory.</li>
+ <li>Build your application.</li>
+</ol>
+
+<p>You should now find a generated interface file named <code>IMarketBillingService.java</code> in
+the <code>gen</code> folder of your project.</p>
+
+<h2 id="billing-permission">Updating Your Application's Manifest</h2>
+
+<p>In-app billing relies on the Google Play application, which handles all communication between
+your application and the Google Play server. To use the Google Play application, your
+application must request the proper permission. You can do this by adding the
+<code>com.android.vending.BILLING</code> permission to your AndroidManifest.xml file. If your
+application does not declare the in-app billing permission, but attempts to send billing requests,
+Google Play will refuse the requests and respond with a <code>RESULT_DEVELOPER_ERROR</code>
+response code.</p>
+
+<p>In addition to the billing permission, you need to declare the {@link
+android.content.BroadcastReceiver} that you will use to receive asynchronous response messages
+(broadcast intents) from Google Play, and you need to declare the {@link android.app.Service}
+that you will use to bind with the <code>IMarketBillingService</code> and send messages to Google
+Play. You must also declare <a
+href="{@docRoot}guide/topics/manifest/intent-filter-element.html">intent filters</a> for the {@link
+android.content.BroadcastReceiver} so that the Android system knows how to handle the broadcast
+intents that are sent from the Google Play application.</p>
+
+<p>For example, here is how the in-app billing sample application declares the billing permission,
+the {@link android.content.BroadcastReceiver}, the {@link android.app.Service}, and the intent
+filters. In the sample application, <code>BillingReceiver</code> is the {@link
+android.content.BroadcastReceiver} that handles broadcast intents from the Google Play
+application and <code>BillingService</code> is the {@link android.app.Service} that sends requests
+to the Google Play application.</p>
+
+<pre>
+<?xml version="1.0" encoding="utf-8"?>
+<manifest xmlns:android="http://schemas.android.com/apk/res/android"
+ package="com.example.dungeons"
+ android:versionCode="1"
+ android:versionName="1.0">
+
+ <uses-permission android:name="com.android.vending.BILLING" />
+
+ <application android:icon="@drawable/icon" android:label="@string/app_name">
+ <activity android:name=".Dungeons" android:label="@string/app_name">
+ <intent-filter>
+ <action android:name="android.intent.action.MAIN" />
+ <category android:name="android.intent.category.LAUNCHER" />
+ </intent-filter>
+ </activity>
+
+ <service android:name="BillingService" />
+
+ <receiver android:name="BillingReceiver">
+ <intent-filter>
+ <action android:name="com.android.vending.billing.IN_APP_NOTIFY" />
+ <action android:name="com.android.vending.billing.RESPONSE_CODE" />
+ <action android:name="com.android.vending.billing.PURCHASE_STATE_CHANGED" />
+ </intent-filter>
+ </receiver>
+
+ </application>
+</manifest>
+</pre>
+
+<h2 id="billing-service">Creating a Local Service</h2>
+
+<p>Your application must have a local {@link android.app.Service} to facilitate messaging between
+your application and Google Play. At a minimum, this service must do the following:</p>
+
+<ul>
+ <li>Bind to the <code>MarketBillingService</code>.
+ <li>Send billing requests (as IPC method calls) to the Google Play application. The five types
+ of billing requests include:
+ <ul>
+ <li><code>CHECK_BILLING_SUPPORTED</code> requests</li>
+ <li><code>REQUEST_PURCHASE</code> requests</li>
+ <li><code>GET_PURCHASE_INFORMATION</code> requests</li>
+ <li><code>CONFIRM_NOTIFICATIONS</code> requests</li>
+ <li><code>RESTORE_TRANSACTIONS</code> requests</li>
+ </ul>
+ </li>
+ <li>Handle the synchronous response messages that are returned with each billing request.</li>
+</ul>
+
+<h3>Binding to the MarketBillingService</h3>
+
+<p>Binding to the <code>MarketBillingService</code> is relatively easy if you've already added the
+<code>IMarketBillingService.aidl</code> file to your project. The following code sample shows how to
+use the {@link android.content.Context#bindService bindService()} method to bind a service to the
+<code>MarketBillingService</code>. You could put this code in your service's {@link
+android.app.Activity#onCreate onCreate()} method.</p>
+
+<pre>
+try {
+ boolean bindResult = mContext.bindService(
+ new Intent("com.android.vending.billing.MarketBillingService.BIND"), this,
+ Context.BIND_AUTO_CREATE);
+ if (bindResult) {
+ Log.i(TAG, "Service bind successful.");
+ } else {
+ Log.e(TAG, "Could not bind to the MarketBillingService.");
+ }
+} catch (SecurityException e) {
+ Log.e(TAG, "Security exception: " + e);
+}
+</pre>
+
+<p>After you bind to the service, you need to create a reference to the
+<code>IMarketBillingService</code> interface so you can make billing requests via IPC method calls.
+The following code shows you how to do this using the {@link
+android.content.ServiceConnection#onServiceConnected onServiceConnected()} callback method.</p>
+
+<pre>
+/**
+ * The Android system calls this when we are connected to the MarketBillingService.
+ */
+ public void onServiceConnected(ComponentName name, IBinder service) {
+ Log.i(TAG, "MarketBillingService connected.");
+ mService = IMarketBillingService.Stub.asInterface(service);
+ }
+</pre>
+
+<p>You can now use the <code>mService</code> reference to invoke the
+<code>sendBillingRequest()</code> method.</p>
+
+<p>For a complete implementation of a service that binds to the <code>MarketBillingService</code>,
+see the <code>BillingService</code> class in the sample application.</p>
+
+<h3>Sending billing requests to the MarketBillingService</h3>
+
+<p>Now that your {@link android.app.Service} has a reference to the
+<code>IMarketBillingService</code> interface, you can use that reference to send billing requests
+(via IPC method calls) to the <code>MarketBillingService</code>. The
+<code>MarketBillingService</code> IPC interface exposes a single public method
+(<code>sendBillingRequest()</code>), which takes a single {@link android.os.Bundle} parameter. The
+Bundle that you deliver with this method specifies the type of request you want to perform, using
+various key-value pairs. For instance, one key indicates the type of request you are making, another
+indicates the item being purchased, and another identifies your application. The
+<code>sendBillingRequest()</code> method immediately returns a Bundle containing an initial response
+code. However, this is not the complete purchase response; the complete response is delivered with
+an asynchronous broadcast intent. For more information about the various Bundle keys that are
+supported by the <code>MarketBillingService</code>, see <a
+href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-interface">In-app Billing
+Service Interface</a>.</p>
+
+<p>You can use the <code>sendBillingRequest()</code> method to send five types of billing requests.
+The five request types are specified using the <code>BILLING_REQUEST</code> Bundle key. This Bundle
+key can have the following five values:</p>
+
+<ul>
+ <li><code>CHECK_BILLING_SUPPORTED</code>—verifies that the Google Play application
+ supports in-app billing and the version of the In-app Billing API available.</li>
+ <li><code>REQUEST_PURCHASE</code>—sends a purchase request for an in-app item.</li>
+ <li><code>GET_PURCHASE_INFORMATION</code>—retrieves transaction information for a purchase
+ or refund.</li>
+ <li><code>CONFIRM_NOTIFICATIONS</code>—acknowledges that you received the transaction
+ information for a purchase or refund.</li>
+ <li><code>RESTORE_TRANSACTIONS</code>—retrieves a user's transaction history for <a
+ href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">managed
+ purchases</a>.</li>
+</ul>
+
+<p>To make any of these billing requests, you first need to build an initial {@link
+android.os.Bundle} that contains the three keys that are required for all requests:
+<code>BILLING_REQUEST</code>, <code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The following
+code sample shows you how to create a helper method named <code>makeRequestBundle()</code> that does
+this.</p>
+
+<pre>
+protected Bundle makeRequestBundle(String method) {
+ Bundle request = new Bundle();
+ request.putString(BILLING_REQUEST, method);
+ request.putInt(API_VERSION, 1);
+ request.putString(PACKAGE_NAME, getPackageName());
+ return request;
+</pre>
+
+<p>To use this helper method, you pass in a <code>String</code> that corresponds to one of the five
+types of billing requests. The method returns a Bundle that has the three required keys defined. The
+following sections show you how to use this helper method when you send a billing request.</p>
+
+<p class="caution"><strong>Important</strong>: You must make all in-app billing requests from your
+application's main thread.</p>
+
+<h4>Verifying that in-app billing is supported (CHECK_BILLING_SUPPPORTED)</h4>
+
+<p>The following code sample shows how to verify whether the Google Play application supports
+in-app billing and confirm what version of the API it supports. In the sample, <code>mService</code>
+is an instance of the <code>MarketBillingService</code> interface.</p>
+
+<pre>
+/**
+* Request type is CHECK_BILLING_SUPPORTED
+*/
+ Bundle request = makeRequestBundle("CHECK_BILLING_SUPPORTED");
+ Bundle response = mService.sendBillingRequest(request);
+ // Do something with this response.
+}
+</pre>
+
+<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
+three keys that are required for all requests: <code>BILLING_REQUEST</code>,
+<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. If you are offering subscriptions in
+your app, set the API_VERSION key to a value of "2", to confirm that In-app Billing v2 is
+available. For an examnple, see
+<a href="{@docRoot}google/play/billing/v2/billing_subscriptions.html#version">Subscriptions</a>.</p>
+
+<p>The <code>CHECK_BILLING_SUPPORTED</code> request returns a synchronous {@link
+android.os.Bundle} response, which contains only a single key: <code>RESPONSE_CODE</code>. The
+<code>RESPONSE_CODE</code> key can have the following values:</p>
+<ul>
+ <li><code>RESULT_OK</code>—the spedified version of in-app billing is supported.</li>
+ <li><code>RESULT_BILLING_UNAVAILABLE</code>—in-app billing is not available because the API
+ version you specified is not recognized or the user is not eligible to make in-app purchases (for
+ example, the user resides in a country that prohibits in-app purchases).</li>
+ <li><code>RESULT_ERROR</code>—there was an error connecting with the Google Play
+ application.</li>
+ <li><code>RESULT_DEVELOPER_ERROR</code>—the application is trying to make an in-app billing
+ request but the application has not declared the <code>com.android.vending.BILLING</code>
+ permission in its manifest. Can also indicate that an application is not properly signed, or that
+ you sent a malformed request.</li>
+</ul>
+
+<p>The <code>CHECK_BILLING_SUPPORTED</code> request does not trigger any asynchronous responses
+(broadcast intents).</p>
+
+<p>We recommend that you invoke the <code>CHECK_BILLING_SUPPORTED</code> request within a
+<code>RemoteException</code> block. When your code throws a <code>RemoteException</code> it
+indicates that the remote method call failed, which means that the Google Play application is out
+of date and needs to be updated. In this case, you can provide users with an error message that
+contains a link to the <a
+href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google Play</a>
+Help topic.</p>
+
+<p>The sample application demonstrates how you can handle this error condition (see
+<code>DIALOG_CANNOT_CONNECT_ID</code> in <code>Dungeons.java</code>).</p>
+
+<h4>Making a purchase request (REQUEST_PURCHASE)</h4>
+
+<p>To make a purchase request you must do the following:</p>
+
+<ul>
+ <li>Send the <code>REQUEST_PURCHASE</code> request.</li>
+ <li>Launch the {@link android.app.PendingIntent} that is returned from the Google Play
+ application.</li>
+ <li>Handle the broadcast intents that are sent by the Google Play application.</li>
+</ul>
+
+<h5>Making the request</h5>
+
+<p>You must specify four keys in the request {@link android.os.Bundle}. The following code sample
+shows how to set these keys and make a purchase request for a single in-app item. In the sample,
+<code>mProductId</code> is the Google Play product ID of an in-app item (which is listed in the
+application's <a href="{@docRoot}google/play/billing/billing_admin.html#billing-list-setup">product
+list</a>), and <code>mService</code> is an instance of the <code>MarketBillingService</code>
+interface.</p>
+
+<pre>
+/**
+* Request type is REQUEST_PURCHASE
+*/
+ Bundle request = makeRequestBundle("REQUEST_PURCHASE");
+ request.putString(ITEM_ID, mProductId);
+ // Request is for a standard in-app product
+ request.putString(ITEM_TYPE, "inapp");
+ // Note that the developer payload is optional.
+ if (mDeveloperPayload != null) {
+ request.putString(DEVELOPER_PAYLOAD, mDeveloperPayload);
+ }
+ Bundle response = mService.sendBillingRequest(request);
+ // Do something with this response.
+</pre>
+<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
+three keys that are required for all requests: <code>BILLING_REQUEST</code>,
+<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The <code>ITEM_ID</code> key is then added
+to the Bundle prior to invoking the <code>sendBillingRequest()</code> method.</p>
+
+<p>The request returns a synchronous {@link android.os.Bundle} response, which contains three keys:
+<code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and <code>REQUEST_ID</code>. The
+<code>RESPONSE_CODE</code> key provides you with the status of the request and the
+<code>REQUEST_ID</code> key provides you with a unique request identifier for the request. The
+<code>PURCHASE_INTENT</code> key provides you with a {@link android.app.PendingIntent}, which you
+can use to launch the checkout UI.</p>
+
+<h5>Using the pending intent</h5>
+
+<p>How you use the pending intent depends on which version of Android a device is running. On
+Android 1.6, you must use the pending intent to launch the checkout UI in its own separate task
+instead of your application's activity stack. On Android 2.0 and higher, you can use the pending
+intent to launch the checkout UI on your application's activity stack. The following code shows you
+how to do this. You can find this code in the <code>PurchaseObserver.java</code> file in the sample
+application.</p>
+
+<pre>
+void startBuyPageActivity(PendingIntent pendingIntent, Intent intent) {
+ if (mStartIntentSender != null) {
+ // This is on Android 2.0 and beyond. The in-app checkout page activity
+ // will be on the activity stack of the application.
+ try {
+ // This implements the method call:
+ // mActivity.startIntentSender(pendingIntent.getIntentSender(),
+ // intent, 0, 0, 0);
+ mStartIntentSenderArgs[0] = pendingIntent.getIntentSender();
+ mStartIntentSenderArgs[1] = intent;
+ mStartIntentSenderArgs[2] = Integer.valueOf(0);
+ mStartIntentSenderArgs[3] = Integer.valueOf(0);
+ mStartIntentSenderArgs[4] = Integer.valueOf(0);
+ mStartIntentSender.invoke(mActivity, mStartIntentSenderArgs);
+ } catch (Exception e) {
+ Log.e(TAG, "error starting activity", e);
+ }
+ } else {
+ // This is on Android 1.6. The in-app checkout page activity will be on its
+ // own separate activity stack instead of on the activity stack of
+ // the application.
+ try {
+ pendingIntent.send(mActivity, 0 /* code */, intent);
+ } catch (CanceledException e) {
+ Log.e(TAG, "error starting activity", e);
+ }
+ }
+}
+</pre>
+
+<p class="caution"><strong>Important:</strong> You must launch the pending intent from an activity
+context and not an application context. Also, you cannot use the <code>singleTop</code> <a
+href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">launch mode</a> to launch the
+pending intent. If you do either of these, the Android system will not attach the pending intent to
+your application process. Instead, it will bring Google Play to the foreground, disrupting your
+application.</p>
+
+<h5>Handling broadcast intents</h5>
+
+<p>A <code>REQUEST_PURCHASE</code> request also triggers two asynchronous responses (broadcast
+intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent,
+which provides error information about the request. If the request does not generate an
+error, the <code>RESPONSE_CODE</code> broadcast intent returns <code>RESULT_OK</code>, which
+indicates that the request was successfully sent. (To be clear, a <code>RESULT_OK</code> response
+does not indicate that the requested purchase was successful; it indicates that the request was sent
+successfully to Google Play.)</p>
+
+<p>Next, when the requested transaction changes state (for example, the purchase is successfully
+charged to a credit card or the user cancels the purchase), the Google Play application sends an
+<code>IN_APP_NOTIFY</code> broadcast intent. This message contains a notification ID, which you can
+use to retrieve the transaction details for the <code>REQUEST_PURCHASE</code> request.</p>
+
+<p class="note"><strong>Note:</strong> The Google Play application also sends
+an <code>IN_APP_NOTIFY</code> for refunds. For more information, see <a
+href="{@docRoot}google/play/billing/v2/api.html#billing-action-notify">Handling
+IN_APP_NOTIFY messages</a>.</p>
+
+<p>Because the purchase process is not instantaneous and can take several seconds (or more), you
+must assume that a purchase request is pending from the time you receive a <code>RESULT_OK</code>
+message until you receive an <code>IN_APP_NOTIFY</code> message for the transaction. While the
+transaction is pending, the Google Play checkout UI displays an "Authorizing purchase..."
+notification; however, this notification is dismissed after 60 seconds and you should not rely on
+this notification as your primary means of conveying transaction status to users. Instead, we
+recommend that you do the following:</p>
+
+<ul>
+ <li>Add an {@link android.app.Activity} to your application that shows users the status of pending
+and completed in-app purchases.</li>
+ <li>Use a <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html">status
+bar notification</a> to keep users informed about the progress of a purchase.</li>
+</ul>
+
+<p>To use these two UI elements, you could invoke a status bar notification with a ticker-text
+message that says "Purchase pending" when your application receives a <code>RESULT_OK</code>
+message. Then, when your application receives an <code>IN_APP_NOTIFY</code> message, you could
+update the notification with a new message that says "Purchase succeeded" or "Purchase failed." When
+a user touches the expanded status bar notification, you could launch the activity that shows the
+status of pending and completed in-app purchases.</p>
+
+<p>If you use some other UI technique to inform users about the state of a pending transaction,
+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 Google Play.</p>
+
+<p class="caution"><strong>Important:</strong> If a user purchases a managed item, you must prevent
+the user from purchasing the item again while the original transaction is pending. If a user
+attempts to purchase a managed item twice, and the first transaction is still pending, Google
+Play will display an error to the user; however, Google Play will not send an error to your
+application notifying you that the second purchase request was canceled. This might cause your
+application to get stuck in a pending state while it waits for an <code>IN_APP_NOTIFY</code> message
+for the second purchase request.</p>
+
+<h4>Retrieving transaction information for a purchase or refund (GET_PURCHASE_INFORMATION)</h4>
+
+<p>You retrieve transaction information in response to an <code>IN_APP_NOTIFY</code> broadcast
+intent. The <code>IN_APP_NOTIFY</code> message contains a notification ID, which you can use to
+retrieve transaction information.</p>
+
+<p>To retrieve transaction information for a purchase or refund you must specify five keys in the
+request {@link android.os.Bundle}. The following code sample shows how to set these keys and make
+the request. In the sample, <code>mService</code> is an instance of the
+<code>MarketBillingService</code> interface.</p>
+
+<pre>
+/**
+* Request type is GET_PURCHASE_INFORMATION
+*/
+ Bundle request = makeRequestBundle("GET_PURCHASE_INFORMATION");
+ request.putLong(REQUEST_NONCE, mNonce);
+ request.putStringArray(NOTIFY_IDS, mNotifyIds);
+ Bundle response = mService.sendBillingRequest(request);
+ // Do something with this response.
+}
+</pre>
+<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
+three keys that are required for all requests: <code>BILLING_REQUEST</code>,
+<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional keys are then added to the
+bundle prior to invoking the <code>sendBillingRequest()</code> method. The
+<code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you
+must generate. The Google Play application returns this nonce with the
+<code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the integrity of the
+transaction information. The <code>NOTIFY_IDS</code> key contains an array of notification IDs,
+which you received in the <code>IN_APP_NOTIFY</code> broadcast intent.</p>
+
+<p>The request returns a synchronous {@link android.os.Bundle} response, which contains two keys:
+<code>RESPONSE_CODE</code> and <code>REQUEST_ID</code>. The <code>RESPONSE_CODE</code> key provides
+you with the status of the request and the <code>REQUEST_ID</code> key provides you with a unique
+request identifier for the request.</p>
+
+<p>A <code>GET_PURCHASE_INFORMATION</code> request also triggers two asynchronous responses
+(broadcast intents). First, the Google Play application sends a <code>RESPONSE_CODE</code>
+broadcast intent, which provides status and error information about the request. Next, if the
+request was successful, the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code>
+broadcast intent. This message contains detailed transaction information. The transaction
+information is contained in a signed JSON string (unencrypted). The message includes the signature
+so you can verify the integrity of the signed string.</p>
+
+<h4>Acknowledging transaction information (CONFIRM_NOTIFICATIONS)</h4>
+
+<p>To acknowledge that you received transaction information you send a
+<code>CONFIRM_NOTIFICATIONS</code> 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 the request. In
+the sample, <code>mService</code> is an instance of the <code>MarketBillingService</code>
+interface.</p>
+
+<pre>
+/**
+* Request type is CONFIRM_NOTIFICATIONS
+*/
+ Bundle request = makeRequestBundle("CONFIRM_NOTIFICATIONS");
+ request.putStringArray(NOTIFY_IDS, mNotifyIds);
+ Bundle response = mService.sendBillingRequest(request);
+ // Do something with this response.
+}
+</pre>
+<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
+three keys that are required for all requests: <code>BILLING_REQUEST</code>,
+<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional <code>NOTIFY_IDS</code> key
+is then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The
+<code>NOTIFY_IDS</code> key contains an array of notification IDs, which you received in an
+<code>IN_APP_NOTIFY</code> broadcast intent and also used in a <code>GET_PURCHASE_INFORMATION</code>
+request.</p>
+
+<p>The request returns a synchronous {@link android.os.Bundle} response, which contains two keys:
+<code>RESPONSE_CODE</code> and <code>REQUEST_ID</code>. The <code>RESPONSE_CODE</code> key provides
+you with the status of the request and the <code>REQUEST_ID</code> key provides you with a unique
+request identifier for the request.</p>
+
+<p>A <code>CONFIRM_NOTIFICATIONS</code> request triggers a single asynchronous response—a
+<code>RESPONSE_CODE</code> broadcast intent. This broadcast intent provides status and error
+information about the request.</p>
+
+<p>You must send a confirmation when you receive transaction information from Google Play. If you
+don't send a confirmation message, Google Play will continue sending
+<code>IN_APP_NOTIFY</code> messages for the transactions you have not confirmed. Also,
+your application must be able to handle <code>IN_APP_NOTIFY</code> messages that contain multiple
+orders.</p>
+
+<p>In addition, as a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request
+for a purchased item until you have delivered the item to the user. This way, if your application
+crashes or something else prevents your application from delivering the product, your application
+will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Google Play indicating
+that you need to deliver the product.</p>
+
+<h4>Restoring transaction information (RESTORE_TRANSACTIONS)</h4>
+
+<p>To restore a user's transaction information, you send a <code>RESTORE_TRANSACTIONS</code>
+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 the request. In the sample, <code>mService</code> is an
+instance of the <code>MarketBillingService</code> interface.</p>
+
+<pre>
+/**
+* Request type is RESTORE_TRANSACTIONS
+*/
+ Bundle request = makeRequestBundle("RESTORE_TRANSACTIONS");
+ request.putLong(REQUEST_NONCE, mNonce);
+ Bundle response = mService.sendBillingRequest(request);
+ // Do something with this response.
+}
+</pre>
+<p>The <code>makeRequestBundle()</code> method constructs an initial Bundle, which contains the
+three keys that are required for all requests: <code>BILLING_REQUEST</code>,
+<code>API_VERSION</code>, and <code>PACKAGE_NAME</code>. The additional <code>REQUEST_NONCE</code>
+key is then added to the bundle prior to invoking the <code>sendBillingRequest()</code> method. The
+<code>REQUEST_NONCE</code> key contains a cryptographically secure nonce (number used once) that you
+must generate. The Google Play application returns this nonce with the transactions information
+contained in the <code>PURCHASE_STATE_CHANGED</code> broadcast intent so you can verify the
+integrity of the transaction information.</p>
+
+<p>The request returns a synchronous {@link android.os.Bundle} response, which contains two keys:
+<code>RESPONSE_CODE</code> and <code>REQUEST_ID</code>. The <code>RESPONSE_CODE</code> key provides
+you with the status of the request and the <code>REQUEST_ID</code> key provides you with a unique
+request identifier for the request.</p>
+
+<p>A <code>RESTORE_TRANSACTIONS</code> request also triggers two asynchronous responses (broadcast
+intents). First, the Google Play application sends a <code>RESPONSE_CODE</code> broadcast intent,
+which provides status and error information about the request. Next, if the request was successful,
+the Google Play application sends a <code>PURCHASE_STATE_CHANGED</code> broadcast intent. This
+message contains the detailed transaction information. The transaction information is contained in a
+signed JSON string (unencrypted). The message includes the signature so you can verify the integrity
+of the signed string.</p>
+
+<p class="note"><strong>Note:</strong> You should use the <code>RESTORE_TRANSACTIONS</code>
+request type only when your application is installed for the first time on a device or when your
+application has been removed from a device and reinstalled.</p>
+
+<h3>Other service tasks</h3>
+
+<p>You may also want your {@link android.app.Service} to receive intent messages from your {@link
+android.content.BroadcastReceiver}. You can use these intent messages to convey the information that
+was sent asynchronously from the Google Play application to your {@link
+android.content.BroadcastReceiver}. To see an example of how you can send and receive these intent
+messages, see the <code>BillingReceiver.java</code> and <code>BillingService.java</code> files in
+the sample application. You can use these samples as a basis for your own implementation. However,
+if you use any of the code from the sample application, be sure you follow the guidelines in <a
+href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>.</p>
+
+<h2 id="billing-broadcast-receiver">Creating a BroadcastReceiver</h2>
+
+<p>The Google Play application uses broadcast intents to send asynchronous billing responses to
+your application. To receive these intent messages, you need to create a {@link
+android.content.BroadcastReceiver} that can handle the following intents:</p>
+
+<ul>
+ <li>com.android.vending.billing.RESPONSE_CODE
+ <p>This broadcast intent contains a Google Play response code, and is sent after you make an
+ in-app billing request. For more information about the response codes that are sent with this
+ response, see <a
+ href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-codes">Google Play Response
+ Codes for In-app Billing</a>.</p>
+ </li>
+ <li>com.android.vending.billing.IN_APP_NOTIFY
+ <p>This response indicates that a purchase has changed state, which means a purchase succeeded,
+ was canceled, or was refunded. For more information about notification messages, see <a
+ href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-intents">In-app Billing
+ Broadcast Intents</a></p>
+ </li>
+ <li>com.android.vending.billing.PURCHASE_STATE_CHANGED
+ <p>This broadcast intent contains detailed information about one or more transactions. For more
+ information about purchase state messages, see <a
+ href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-intents">In-app Billing
+ Broadcast Intents</a></p>
+ </li>
+</ul>
+
+<p>Each of these broadcast intents provide intent extras, which your {@link
+android.content.BroadcastReceiver} must handle. The intent extras are listed in the following table
+(see table 1).</p>
+
+<p class="table-caption"><strong>Table 1.</strong> Description of broadcast intent extras that are
+sent in response to billing requests.</p>
+
+<table>
+
+<tr>
+<th>Intent</th>
+<th>Extra</th>
+<th>Description</th>
+</tr>
+<tr>
+ <td><code>com.android.vending.billing.RESPONSE_CODE</code></td>
+ <td><code>request_id</code></td>
+ <td>A <code>long</code> representing a request ID. A request ID identifies a specific billing
+ request and is returned by Google Play at the time a request is made.</td>
+</tr>
+<tr>
+ <td><code>com.android.vending.billing.RESPONSE_CODE</code></td>
+ <td><code>response_code</code></td>
+ <td>An <code>int</code> representing the actual Google Play server response code.</td>
+</tr>
+<tr>
+ <td><code>com.android.vending.billing.IN_APP_NOTIFY</code></td>
+ <td><code>notification_id</code></td>
+ <td>A <code>String</code> representing the notification ID for a given purchase state change.
+ Google Play notifies you when there is a purchase state change and the notification includes a
+ unique notification ID. To get the details of the purchase state change, you send the notification
+ ID with the <code>GET_PURCHASE_INFORMATION</code> request.</td>
+</tr>
+<tr>
+ <td><code>com.android.vending.billing.PURCHASE_STATE_CHANGED</code></td>
+ <td><code>inapp_signed_data</code></td>
+ <td>A <code>String</code> representing the signed JSON string. The JSON string contains
+ information about the billing transaction, such as order number, amount, and the item that was
+ purchased or refunded.</td>
+</tr>
+<tr>
+ <td><code>com.android.vending.billing.PURCHASE_STATE_CHANGED</code></td>
+ <td><code>inapp_signature</code></td>
+ <td>A <code>String</code> representing the signature of the JSON string.</td>
+</tr>
+</table>
+
+<p>The following code sample shows how to handle these broadcast intents and intent extras within a
+{@link android.content.BroadcastReceiver}. The BroadcastReceiver in this case is named
+<code>BillingReceiver</code>, just as it is in the sample application.</p>
+
+<pre>
+public class BillingReceiver extends BroadcastReceiver {
+
+ private static final String TAG = "BillingReceiver";
+
+ // 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 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";
+ public static final String INAPP_SIGNATURE = "inapp_signature";
+ public static final String INAPP_REQUEST_ID = "request_id";
+ public static final String INAPP_RESPONSE_CODE = "response_code";
+
+
+ @Override
+ public void onReceive(Context context, Intent intent) {
+ String action = intent.getAction();
+ if (ACTION_PURCHASE_STATE_CHANGED.equals(action)) {
+ String signedData = intent.getStringExtra(INAPP_SIGNED_DATA);
+ String signature = intent.getStringExtra(INAPP_SIGNATURE);
+ // Do something with the signedData and the signature.
+ } else if (ACTION_NOTIFY.equals(action)) {
+ String notifyId = intent.getStringExtra(NOTIFICATION_ID);
+ // Do something with the notifyId.
+ } else if (ACTION_RESPONSE_CODE.equals(action)) {
+ long requestId = intent.getLongExtra(INAPP_REQUEST_ID, -1);
+ int responseCodeIndex = intent.getIntExtra(INAPP_RESPONSE_CODE,
+ ResponseCode.RESULT_ERROR.ordinal());
+ // Do something with the requestId and the responseCodeIndex.
+ } else {
+ Log.w(TAG, "unexpected action: " + action);
+ }
+ }
+ // Perform other processing here, such as forwarding intent messages to your local service.
+}
+</pre>
+
+<p>In addition to receiving broadcast intents from the Google Play application, your {@link
+android.content.BroadcastReceiver} must handle the information it received in the broadcast intents.
+Usually, your {@link android.content.BroadcastReceiver} does this by sending the information to a
+local service (discussed in the next section). The <code>BillingReceiver.java</code> file in the
+sample application shows you how to do this. You can use this sample as a basis for your own {@link
+android.content.BroadcastReceiver}. However, if you use any of the code from the sample application,
+be sure you follow the guidelines that are discussed in <a
+href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design </a>.</p>
+
+<h2 id="billing-security">Securing Your Application</h2>
+
+<p>To help ensure the integrity of the transaction information that is sent to your application,
+Google Play signs the JSON string that is contained in the <code>PURCHASE_STATE_CHANGED</code>
+broadcast intent. Google Play uses the private key that is associated with your publisher account
+to create this signature. The publisher site generates an RSA key pair for each publisher account.
+You can find the public key portion of this key pair on your account's profile page. It is the same
+public key that is used with Google Play licensing.</p>
+
+<p>When Google Play signs a billing response, it includes the signed JSON string (unencrypted)
+and the signature. When your application receives this signed response you can use the public key
+portion of your RSA key pair to verify the signature. By performing signature verification you can
+help detect responses that have been tampered with or that have been spoofed. You can perform this
+signature verification step in your application; however, if your application connects to a secure
+remote server then we recommend that you perform the signature verification on that server.</p>
+
+<p>In-app billing also uses nonces (a random number used once) to help verify the integrity of the
+purchase information that's returned from Google Play. Your application must generate a nonce and
+send it with a <code>GET_PURCHASE_INFORMATION</code> request and a <code>RESTORE_TRANSACTIONS</code>
+request. When Google Play receives the request, it adds the nonce to the JSON string that
+contains the transaction information. The JSON string is then signed and returned to your
+application. When your application receives the JSON string, you need to verify the nonce as well as
+the signature of the JSON string.</p>
+
+<p>For more information about best practices for security and design, see <a
+href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a>.</p>
+
+<h3 id="billing-signatures">Verifying signatures and nonces</h3>
+
+<p>Google Play's in-app billing service uses two mechanisms to help verify the integrity of the
+transaction information you receive from Google Play: nonces and signatures. A nonce (number used
+once) is a cryptographically secure number that your application generates and sends with every
+<code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is
+returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, enabling you to verify that
+any given <code>PURCHASE_STATE_CHANGED</code> response corresponds to an actual request that you
+made. Every <code>PURCHASE_STATE_CHANGED</code> broadcast intent also includes a signed JSON string
+and a signature, which you can use to verify the integrity of the response.</p>
+
+<p>Your application must provide a way to generate, manage, and verify nonces. The following sample
+code shows some simple methods you can use to do this.</p>
+
+<pre>
+ private static final SecureRandom RANDOM = new SecureRandom();
+ private static HashSet<Long> sKnownNonces = new HashSet<Long>();
+
+ public static long generateNonce() {
+ long nonce = RANDOM.nextLong();
+ sKnownNonces.add(nonce);
+ return nonce;
+ }
+
+ public static void removeNonce(long nonce) {
+ sKnownNonces.remove(nonce);
+ }
+
+ public static boolean isNonceKnown(long nonce) {
+ return sKnownNonces.contains(nonce);
+ }
+</pre>
+
+<p>Your application must also provide a way to verify the signatures that accompany every
+<code>PURCHASE_STATE_CHANGED</code> broadcast intent. The <code>Security.java</code> file in the
+sample application shows you how to do this. If you use this file as a basis for your own security
+implementation, be sure to follow the guidelines in <a
+href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design</a> and
+obfuscate your code.</p>
+
+<p>You will need to use your Google Play public key to perform the signature verification. The
+following procedure shows you how to retrieve Base64-encoded public key from the Google Play
+publisher site.</p>
+
+<ol>
+ <li>Log in to your <a href="http://play.google.com/apps/publish">publisher account</a>.</li>
+ <li>On the upper left part of the page, under your name, click <strong>Edit profile</strong>.</li>
+ <li>On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure
+ 2).</li>
+ <li>Copy your public key.</li>
+</ol>
+
+<p class="caution"><strong>Important</strong>: To keep your public key safe from malicious users and
+hackers, do not embed your public key as an entire 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 information, but you do not want to make it easy for a
+hacker or malicious user to replace the public key with another key.</p>
+
+<img src="{@docRoot}images/billing_public_key.png" height="510" id="figure2" />
+<p class="img-caption">
+ <strong>Figure 2.</strong> The Licensing and In-app Billing panel of your account's Edit Profile
+ page lets you see your public key.
+</p>
+
+<h2 id="billing-implement">Modifying Your Application Code</h2>
+
+<p>After you finish adding in-app billing components to your project, you are ready to modify your
+application's code. For a typical implementation, like the one that is demonstrated in the sample
+application, this means you need to write code to do the following: </p>
+
+<ul>
+ <li>Create a storage mechanism for storing users' purchase information.</li>
+ <li>Create a user interface that lets users select items for purchase.</li>
+</ul>
+
+<p>The sample code in <code>Dungeons.java</code> shows you how to do both of these tasks.</p>
+
+<h3>Creating a storage mechanism for storing purchase information</h3>
+
+<p>You must set up a database or some other mechanism for storing users' purchase information. The
+sample application provides an example database (PurchaseDatabase.java); however, the example
+database has been simplified for clarity and does not exhibit the security best practices that we
+recommend. If you have a remote server, we recommend that you store purchase information on your
+server instead of in a local database on a device. For more information about security best
+practices, see <a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
+Design</a>.</p>
+
+<p class="note"><strong>Note</strong>: If you store any purchase information on a device, be sure to
+encrypt the data and use a device-specific encryption key. Also, if the purchase type for any of
+your items is "unmanaged," we recommend that you back up the purchase information for these items to
+a remote server or use Android's <a href="{@docRoot}guide/topics/data/backup.html">data
+backup</a> framework to back up the purchase information. Backing up purchase information for
+unmanaged items is important because unmanaged items cannot be restored by using the
+<code>RESTORE_TRANSACTIONS</code> request type.</p>
+
+<h3>Creating a user interface for selecting items</h3>
+
+<p>You must provide users with a means for selecting items that they want to purchase. Google
+Play provides the checkout user interface (which is where the user provides a form of payment and
+approves the purchase), but your application must provide a control (widget) that invokes the
+<code>sendBillingRequest()</code> method when a user selects an item for purchase.</p>
+
+<p>You can render the control and trigger the <code>sendBillingRequest()</code> method any way you
+want. The sample application uses a spinner widget and a button to present items to a user and
+trigger a billing request (see <code>Dungeons.java</code>). The user interface also shows a list of
+recently purchased items.</p>
+
--- /dev/null
+page.title=In-app Billing Reference <span style="font-size:16px;">(IAB Version 2)</span>
+@jd:body
+
+<div style="background-color:#fffdeb;width:100%;margin-bottom:1em;padding:.5em;">In-app Billing Version 2 is superseded. Please <a href="{@docRoot}google/play/billing/billing_overview.html#migration">migrate to Version 3</a> at your earliest convenience.</div>
+ <div id="qv-wrapper" style="margin-top:0;">
+<div id="qv">
+<h2>In this document</h2>
+ <ol>
+ <li><a href="#billing-codes">Server Response Codes</a></li>
+ <li><a href="#billing-interface">API Reference</a></li>
+ <li><a href="#billing-intents">Broadcast Intents</a></li>
+ <li><a href="#http-api">REST API for Subscriptions</a></li>
+ </ol>
+
+<h2>Related Samples</h2>
+ <ol>
+ <li><a href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">Sample
+ Application (V2)</a></li>
+ </ol>
+
+</div>
+</div>
+<p>This documentation provides technical reference information for using the In-app Billing Version 2 API. </p>
+
+<h2 id="billing-codes">Server Response Codes</h2>
+<p>The following table lists all of the server response codes that are sent from Google Play to
+your application. Google Play sends these response codes asynchronously as
+<code>response_code</code> extras in the <code>com.android.vending.billing.RESPONSE_CODE</code>
+broadcast intent. Your application must handle all of these response codes.</p>
+
+<p class="table-caption" id="response-codes-table"><strong>Table 6.</strong> Summary of response
+codes returned by Google Play.</p>
+
+<table>
+<tr>
+<th>Response Code</th>
+<th>Value</th>
+<th>Description</th>
+</tr>
+<tr>
+ <td><code>RESULT_OK</code></td>
+ <td>0</td>
+ <td>Indicates that the request was sent to the server successfully. When this code is returned in
+ response to a <code>CHECK_BILLING_SUPPORTED</code> request, indicates that billing is
+ supported.</td>
+</tr>
+<tr>
+ <td><code>RESULT_USER_CANCELED</code></td>
+ <td>1</td>
+ <td>Indicates that the user pressed the back button on the checkout page instead of buying the
+ item.</td>
+</tr>
+<tr>
+ <td><code>RESULT_SERVICE_UNAVAILABLE</code></td>
+ <td>2</td>
+ <td>Indicates that the network connection is down.</td>
+</tr>
+<tr>
+ <td><code>RESULT_BILLING_UNAVAILABLE</code></td>
+ <td>3</td>
+ <td>Indicates that In-app Billing is not available because the <code>API_VERSION</code> that you
+ specified is not recognized by the Google Play application or the user is ineligible for in-app
+ billing (for example, the user resides in a country that prohibits in-app purchases).</td>
+</tr>
+<tr>
+ <td><code>RESULT_ITEM_UNAVAILABLE</code></td>
+ <td>4</td>
+ <td>Indicates that Google Play cannot find the requested item in the application's product
+ list. This can happen if the product ID is misspelled in your <code>REQUEST_PURCHASE</code>
+ request or if an item is unpublished in the application's product list.</td>
+</tr>
+<tr>
+ <td><code>RESULT_DEVELOPER_ERROR</code></td>
+ <td>5</td>
+ <td>Indicates that an application is trying to make an In-app Billing request but the application
+ has not declared the com.android.vending.BILLING permission in its manifest. Can also indicate
+ that an application is not properly signed, or that you sent a malformed request, such as a
+ request with missing Bundle keys or a request that uses an unrecognized request type.</td>
+</tr>
+<tr>
+ <td><code>RESULT_ERROR</code></td>
+ <td>6</td>
+ <td>Indicates an unexpected server error. For example, this error is triggered if you try to
+purchase an item from yourself, which is not allowed by Google Wallet.</td>
+</tr>
+</table>
+</p>
+
+<h3 id="billing-interface">In-app billing Version 2 API reference</h3>
+
+<p>The following section describes the interface for Google Play's In-app Billing service. The
+interface is defined in the <code>IMarketBillingService.aidl</code> file, which is included with the
+In-app Billing <a
+href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">sample
+application</a>.</p>
+<p>The interface consists of a single request method <code>sendBillingRequest()</code>. This method
+takes a single {@link android.os.Bundle} parameter. The Bundle parameter includes several key-value
+pairs, which are summarized in table 7.</p>
+
+<p class="table-caption"><strong>Table 7.</strong> Description of Bundle keys passed in a
+<code>sendBillingRequest()</code> request.</p>
+
+<table>
+
+<tr>
+<th>Key</th>
+<th>Type</th>
+<th>Possible Values</th>
+<th>Required?</th>
+<th>Description</th>
+</tr>
+<tr>
+ <td><code>BILLING_REQUEST</code></td>
+ <td><code>String</code></td>
+ <td><code>CHECK_BILLING_SUPPORTED</code>, <code>REQUEST_PURCHASE</code>,
+ <code>GET_PURCHASE_INFORMATION</code>, <code>CONFIRM_NOTIFICATIONS</code>, or
+ <code>RESTORE_TRANSACTIONS</code></td>
+ <td>Yes</td>
+ <td>The type of billing request you are making with the <code>sendBillingRequest()</code> request.
+ The possible values are discussed more below this table.</td>
+</tr>
+<tr>
+ <td><code>API_VERSION</code></td>
+ <td><code>int</code></td>
+ <td> <ul>
+ <li><code>"2"</code> [<a href="#version_2">details</a>]</li>
+ <li><code>"1"</code> [<a href="#version_1">details</a>]</li>
+ </ul></td>
+ <td>Yes</td>
+ <td>The version of Google Play's In-app Billing service you want to use.</td>
+</tr>
+<tr>
+ <td><code>PACKAGE_NAME</code></td>
+ <td><code>String</code></td>
+ <td>A valid package name.</td>
+ <td>Yes</td>
+ <td>The name of the application that is making the request.</td>
+</tr>
+<tr>
+ <td><code>ITEM_ID</code></td>
+ <td><code>String</code></td>
+ <td>Any valid product identifier.</td>
+ <td>Required for <code>REQUEST_PURCHASE</code> requests.</td>
+ <td>The product ID of the item you are making a billing request for. Every in-app item that you
+ sell using Google Play's In-app Billing service must have a unique product ID, which you
+ specify on the Google Play publisher site.</td>
+</tr>
+<tr>
+ <td><code>NONCE</code></td>
+ <td><code>long</code></td>
+ <td>Any valid <code>long</code> value.</td>
+ <td>Required for <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code>
+ requests.</td>
+ <td>A number used once. Your application must generate and send a nonce with each
+ <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is
+ returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, so you can use this value
+ to verify the integrity of transaction responses form Google Play.</td>
+</tr>
+<tr>
+ <td><code>NOTIFY_IDS</code></td>
+ <td>Array of <code>long</code> values</td>
+ <td>Any valid array of <code>long</code> values</td>
+ <td>Required for <code>GET_PURCHASE_INFORMATION</code> and <code>CONFIRM_NOTIFICATIONS</code>
+ requests.</td>
+ <td>An array of notification identifiers. A notification ID is sent to your application in an
+ <code>IN_APP_NOTIFY</code> broadcast intent every time a purchase changes state. You use the
+ notification to retrieve the details of the purchase state change.</td>
+</tr>
+<tr>
+ <td><code>DEVELOPER_PAYLOAD</code></td>
+ <td><code>String</code></td>
+ <td>Any valid <code>String</code> less than 256 characters long.</td>
+ <td>No</td>
+ <td>A developer-specified string that can be specified when you make a
+ <code>REQUEST_PURCHASE</code> request. This field is returned in the JSON string that contains
+ transaction information for an order. You can use this key to send supplemental information with
+ an order. For example, you can use this key to send index keys with an order, which is useful if
+ you are using a database to store purchase information. We recommend that you do not use this key
+ to send data or content.</td>
+</tr>
+</table>
+
+<p>The <code>BILLING_REQUEST</code> key can have the following values:</p>
+
+<ul>
+ <li><code>CHECK_BILLING_SUPPORTED</code>
+ <p>This request verifies that the Google Play application supports In-app Billing. You
+ usually send this request when your application first starts up. This request is useful if you
+ want to enable or disable certain UI features that are relevant only to In-app Billing.</p>
+ </li>
+ <li><code>REQUEST_PURCHASE</code>
+ <p>This request sends a purchase message to the Google Play application and is the foundation
+ of In-app Billing. You send this request when a user indicates that he or she wants to purchase
+ an item in your application. Google Play then handles the financial transaction by displaying
+ the checkout user interface.</p>
+ </li>
+ <li><code>GET_PURCHASE_INFORMATION</code>
+ <p>This request retrieves the details of a purchase state change. A purchase state change can
+ occur when a purchase request is billed successfully or when a user cancels a transaction during
+ checkout. It can also occur when a previous purchase is refunded. Google Play notifies your
+ application when a purchase changes state, so you only need to send this request when there is
+ transaction information to retrieve.</p>
+ </li>
+ <li><code>CONFIRM_NOTIFICATIONS</code>
+ <p>This request acknowledges that your application received the details of a purchase state
+ change. That is, this message confirms that you sent a <code>GET_PURCHASE_INFORMATION</code>
+ request for a given notification and that you received the purchase information for the
+ notification.</p>
+ </li>
+ <li><code>RESTORE_TRANSACTIONS</code>
+ <p>This request retrieves a user's transaction status for managed purchases (see <a
+ href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">Choosing a
+ Purchase Type</a> for more information). You should send this message only when you need to
+ retrieve a user's transaction status, which is usually only when your application is reinstalled
+ or installed for the first time on a device.</p>
+ </li>
+</ul>
+
+<p>Every In-app Billing request generates a synchronous response. The response is a {@link
+android.os.Bundle} and can include one or more of the following keys:</p>
+
+<ul>
+ <li><code>RESPONSE_CODE</code>
+ <p>This key provides status information and error information about a request.</p>
+ </li>
+ <li><code>PURCHASE_INTENT</code>
+ <p>This key provides a {@link android.app.PendingIntent}, which you use to launch the checkout
+ activity.</p>
+ </li>
+ <li><code>REQUEST_ID</code>
+ <p>This key provides you with a request identifier, which you can use to match asynchronous
+ responses with requests.</p>
+ </li>
+</ul>
+
+<p>Some of these keys are not relevant to certain types of requests. Table 8 shows which keys are
+returned for each request type.</p>
+
+<p class="table-caption"><strong>Table 8.</strong> Description of Bundle keys that are returned with
+each In-app Billing request type.</p>
+
+<table>
+
+<tr>
+<th>Request Type</th>
+<th>Keys Returned</th>
+<th>Possible Response Codes</th>
+</tr>
+<tr>
+ <td><code>CHECK_BILLING_SUPPORTED</code></td>
+ <td><code>RESPONSE_CODE</code></td>
+ <td><code>RESULT_OK</code>, <code>RESULT_BILLING_UNAVAILABLE</code>, <code>RESULT_ERROR</code>,
+ <code>RESULT_DEVELOPER_ERROR</code></td>
+</tr>
+<tr>
+ <td><code>REQUEST_PURCHASE</code></td>
+ <td><code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, <code>REQUEST_ID</code></td>
+ <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
+</tr>
+<tr>
+ <td><code>GET_PURCHASE_INFORMATION</code></td>
+ <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td>
+ <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
+</tr>
+<tr>
+ <td><code>CONFIRM_NOTIFICATIONS</code></td>
+ <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td>
+ <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
+</tr>
+<tr>
+ <td><code>RESTORE_TRANSACTIONS</code></td>
+ <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td>
+ <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td>
+</tr>
+</table>
+
+<h3 id="billing-intents">In-app billing broadcast intents</h3>
+
+<p>The following section describes the In-app Billing broadcast intents that are sent by the Google
+Play application. These broadcast intents inform your application about In-app Billing actions
+that have occurred. Your application must implement a {@link android.content.BroadcastReceiver} to
+receive these broadcast intents, such as the <code>BillingReceiver</code> that's shown in the in-app
+billing <a href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">sample
+application</a>.</p>
+
+<h4>com.android.vending.billing.RESPONSE_CODE</h4>
+
+<p>This broadcast intent contains a Google Play response code, and is sent after you make an
+In-app Billing request. A server response code can indicate that a billing request was successfully
+sent to Google Play or it can indicate that some error occurred during a billing request. This
+intent is not used to report any purchase state changes (such as refund or purchase information).
+For more information about the response codes that are sent with this response, see <a
+href="#billing-codes">Google Play Response Codes for In-app Billing</a>. The sample application
+assigns this broadcast intent to a constant named <code>ACTION_RESPONSE_CODE</code>.</p>
+
+<h5>Extras</h5>
+
+<ul type="none">
+ <li><code>request_id</code>—a <code>long</code> representing a request ID. A request ID
+ identifies a specific billing request and is returned by Google Play at the time a request is
+ made.</li>
+ <li><code>response_code</code>—an <code>int</code> representing the Google Play server
+ response code.</li>
+</ul>
+
+<h4>com.android.vending.billing.IN_APP_NOTIFY</h4>
+
+<p>This response indicates that a purchase has changed state, which means a purchase succeeded, was
+canceled, or was refunded. This response contains one or more notification IDs. Each notification ID
+corresponds to a specific server-side message, and each messages contains information about one or
+more transactions. After your application receives an <code>IN_APP_NOTIFY</code> broadcast intent,
+you send a <code>GET_PURCHASE_INFORMATION</code> request with the notification IDs to retrieve the
+message details. The sample application assigns this broadcast intent to a constant named
+<code>ACTION_NOTIFY</code>.</p>
+
+<h5>Extras</h5>
+
+<ul type="none">
+ <li><code>notification_id</code>—a <code>String</code> representing the notification ID for
+ a given purchase state change. Google Play notifies you when there is a purchase state change
+ and the notification includes a unique notification ID. To get the details of the purchase state
+ change, you send the notification ID with the <code>GET_PURCHASE_INFORMATION</code> request.</li>
+</ul>
+
+<h4>com.android.vending.billing.PURCHASE_STATE_CHANGED</h4>
+
+<p>This broadcast intent contains detailed information about one or more transactions. The
+transaction information is contained in a JSON string. The JSON string is signed and the signature
+is sent to your application along with the JSON string (unencrypted). To help ensure the security of
+your In-app Billing messages, your application can verify the signature of this JSON string. The
+sample application assigns this broadcast intent to a constant named
+<code>ACTION_PURCHASE_STATE_CHANGED</code>.</p>
+
+<h5>Extras</h5>
+
+<ul type="none">
+ <li><code>inapp_signed_data</code>—a <code>String</code> representing the signed JSON
+ string.</li>
+ <li><code>inapp_signature</code>—a <code>String</code> representing the signature.</li>
+</ul>
+
+<p class="note"><strong>Note:</strong> Your application should map the broadcast intents and extras
+to constants that are unique to your application. See the <code>Consts.java</code> file in the
+sample application to see how this is done.</p>
+
+<p>The fields in the JSON string are described in the following table (see table 9):</p>
+
+<p class="table-caption"><strong>Table 9.</strong> Description of JSON fields that are returned with
+a <code>PURCHASE_STATE_CHANGED</code> intent.</p>
+
+<table>
+
+<tr>
+<th>Field</th>
+<th>Description</th>
+</tr>
+<tr>
+ <td>nonce</td>
+ <td>A number used once. Your application generates the nonce and sends it with the
+ <code>GET_PURCHASE_INFORMATION</code> request. Google Play sends the nonce back as part of the
+ JSON string so you can verify the integrity of the message.</td>
+</tr>
+<tr>
+ <td>notificationId</td>
+ <td>A unique identifier that is sent with an <code>IN_APP_NOTIFY</code> broadcast intent. Each
+ <code>notificationId</code> corresponds to a specify message that is waiting to be retrieved on
+ the Google Play server. Your application sends back the <code>notificationId</code> with the
+ <code>GET_PURCHASE_INFORMATION</code> message so Google Play can determine which messages you
+ are retrieving.</td>
+</tr>
+<tr>
+ <td>orderId</td>
+ <td>A unique order identifier for the transaction. This corresponds to the Google Wallet Order
+ ID.</td>
+</tr>
+<tr>
+ <td>packageName</td>
+ <td>The application package from which the purchase originated.</td>
+</tr>
+<tr>
+ <td>productId</td>
+ <td>The item's product identifier. Every item has a product ID, which you must specify in the
+ application's product list on the Google Play publisher site.</td>
+</tr>
+<tr>
+ <td>purchaseTime</td>
+ <td>The time the product was purchased, in milliseconds since the epoch (Jan 1, 1970).</td>
+</tr>
+
+<tr>
+ <td>purchaseState</td>
+ <td>The purchase state of the order. Possible values are 0 (purchased), 1 (canceled), 2
+ (refunded), or 3 (expired, for subscription purchases only).</td>
+</tr>
+<tr>
+ <td>purchaseToken</td>
+ <td>A token that uniquely identifies a subscription purchase for a given item and user pair.
+ You can use the token to specify the subscription when querying for subscription validity.
+
+ <p><br><em>Supported only in In-app Billing API Version 2 and higher.</em></p></td>
+</tr>
+<tr>
+ <td>developerPayload</td>
+ <td>A developer-specified string that contains supplemental information about an order. You can
+ specify a value for this field when you make a <code>REQUEST_PURCHASE</code> request.</td>
+</tr>
+</table>
+
+<!--<h2 id="other-intents">Other Intents</h2>
+
+<p>The following Intents related to In-app Billing may be useful in your
+implemention. </p> -->
+
+<h3 id="http-api">REST API for subscriptions</h3>
+<p>Google Play offers an HTTP-based API that you can use to remotely query the validity of a specific subscription at any time or cancel a subscription. The API is designed to be used from your backend servers as a way of securely managing subscriptions, as well as extending and integrating subscriptions with other services. See <a href="{@docRoot}google/play/billing/v2/billing_subscriptions.html#play-dev-api"> Google Play Android Developer API</a> for more information.</p>
-page.title=Subscriptions
-parent.title=In-app Billing
-parent.link=index.html
+page.title=Subscriptions <span style="font-size:16px;">(IAB Version 2)</span>
@jd:body
-<div id="qv-wrapper">
+<div style="background-color:#fffdeb;width:100%;margin-bottom:1em;padding:.5em;">In-app Billing Version 2 is superseded. Please <a href="{@docRoot}google/play/billing/billing_overview.html#migration">migrate to Version 3</a> at your earliest convenience.</div>
+ <div id="qv-wrapper" style="margin-top:0;">
<div id="qv">
<h2>In this document</h2>
<ol>
</ol> -->
</li>
</ol>
- <h2>Downloads</h2>
- <ol>
- <li><a href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">Sample Application</a></li>
- </ol>
- <h2>See also</h2>
- <ol>
- <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_best_practices.html">Security and
- Design</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_admin.html">Administering In-app
- Billing</a></li>
- <li><a href="{@docRoot}google/play/billing/billing_reference.html">In-app Billing
- Reference</a></li>
- </ol>
</div>
</div>
+<p class="note"><strong>Important:</strong> This documentation describes how to implement subscriptions with the Version 2 API. Subscription support for the in-app billing <a href="{@docRoot}google/play/billing/api.html">Version 3 API</a> is coming soon.</p></li>
+
<p>Subscriptions let you sell content, services, or features in your app with
automated, recurring billing. Adding support for subscriptions is
straightforward and you can easily adapt an existing In-app Billing
interactions as for other in-app products.subscriptions. Because the
implementation of subscriptions follows the same path as for other in-app
products, details are provided outside of this document, starting with the <a
-href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+href="{@docRoot}google/play/billing/v2/api.html">In-app Billing
Overview</a>. </p>
<p>This document is focused on highlighting implementation details that are
specific to subscriptions, along with some strategies for the associated billing
and business models.</p>
+<p class="note"><strong>Note:</strong> Subscriptions are supported in In-app Billing Version 2 only. Support for subscriptions will be added to Version 3 in the weeks ahead.</p>
+
<h2 id="overview">Overview of Subscriptions</h2>
<p>A <em>subscription</em> is a new product type offered in In-app Billing that lets you
<ul>
<li>Must run Android 2.2 or higher</li>
- <li>Google Play Store app, version 3.5 or higher, must be installed</li>
+ <li>Google Play Store app, Version 3.5 or higher, must be installed</li>
</ul>
<p>Google Play 3.5 and later versions include support for the In-app Billing
<p>The full implementation details for In-app Billing are provided outside of
this document, starting with the <a
-href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+href="{@docRoot}google/play/billing/v2/api.html">In-app Billing
Overview</a>. This document is focused on highlighting implementation details
that are specific to subscriptions, along with some strategies for the
associated billing and business models.</p>
<h3 id="sample">Sample application</h3>
<p>To help you get started with your In-app Billing implementation and
-subscriptions, an updated version of the In-app Billing sample app is available.
+subscriptions, an updated Version of the In-app Billing sample app is available.
You can download the sample app from the Android SDK repository using the
Android SDK Manager. For details, see <a
-href="{@docRoot}google/play/billing/billing_integrate.html#billing-download">
+href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">
Downloading the Sample Application</a>.</p>
<h3 id="model">Application model</h3>
errors, and status messages, and an observer for sending callbacks to your
application as needed. All of these components and their interactions are
described in full in the <a
-href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+href="{@docRoot}google/play/billing/v2/api.html">In-app Billing
Overview</a> and related documents.</p>
<p>To initiate different types of billing communication with Google Play, your
<p>Subscriptions support is available only in versions of Google Play that
support the In-app Billing v2 API (Google Play 3.5 and higher). For your app,
-an essential first step at launch is to check whether the version of Google Play
+an essential first step at launch is to check whether the Version of Google Play
installed on the device supports the In-app Billing v2 API and
subscriptions.</p>
<h3 id="purchase">Requesting a subscription purchase</h3>
-<p>Once you’ve checked the API version as described above and determined that
+<p>Once you’ve checked the API Version as described above and determined that
subscriptions are supported, you can present subscription products to the user
for purchase. When the user has selected a subscription product and initiated a
purchase, your app handles the purchase just as it would for other in-app
<p>The REQUEST_PURCHASE includes a Bundle containing the item details, as
described in the <a
-href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+href="{@docRoot}google/play/billing/v2/api.html">In-app Billing
Overview</a>. For a subscription, the Bundle must also specify:</p>
<ul>
<code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, and
<code>REQUEST_ID</code>. Your app uses the <code>PURCHASE_INTENT</code> to
launch the checkout UI and the message flow proceeds exactly as described in <a
-href="{@docRoot}google/play/billing/billing_overview.html#billing-message-
+href="{@docRoot}google/play/billing/v2/api.html#billing-message-
sequence">Messaging sequence</a>.</p>
<p>Here’s how the sample app initiates a purchase for a subscription, where
<p>The process for restoring subscriptions transactions is the same as described
in <a
-href="{@docRoot}google/play/billing/billing_overview.html#billing-message-
+href="{@docRoot}google/play/billing/v2/api.html#billing-message-
sequence">Messaging sequence</a>. Your app sends a
<code>RESTORE_TRANSACTIONS</code> request to Google Play. Google Play sends two
broadcast intents as asynchronous responses — a <code>RESPONSE_CODE</code>
<p>For subscriptions, you make the same types of modifications to your app as
are described in <a
-href="{@docRoot}google/play/billing/billing_integrate.html#billing-implement">
+href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-implement">
Modifying your Application Code</a>.</p>
<p>Note that, in your UI that lets users view and select subscriptions for
--- /dev/null
+page.title=In-app Billing Version Notes
+@jd:body
+
+<p>The In-app Billing API is versioned, with each version offering additional features to your app. API support is provided by the Google Play Store app. On most devices, the Google Play Store app is updated automatically to support newer versions of the API.
+
+<p>The sections below list the supported versions of the In-app Billing API.</p>
+
+<p id="api_check"><strong><em>How to check for In-app Billing version</em></strong></p>
+
+<p>At run time, your app can query the Google Play Store app to determine what version of the API it supports and what features are available. </p>
+
+<ul>
+<li>If you are using in-app billing version 3, the version information is not directly returned the Google Play. Instead, you can check if Google Play supports the version of the In-app Billing API that you are using by sending a {@code isBillingSupported} request.</li>
+<li>If the In-app Billing API version that you are using is earlier than version 3, the version information is returned in the <code>API_VERSION</code> key of the Bundle object passed in the {@code sendBillingRequest} method. For more information, see <a href="{@docRoot}google/play/billing/v2/billing_reference.html#billing-interface-v2">In-app Billing Service Interface</a>.</li>
+</ul>
+
+<h3 id="version_3">In-app Billing version 3</h3>
+<p><em>December 2012</em></p>
+<ul>
+<li>Requires Google Play client version 3.9.16 or higher.
+<li>Provides a new Android Interface Definition Language (AIDL) file named {@code IInAppBillingService.aidl}. The new interface offers these features:
+<ul>
+<li>Provides a new API to get details of in-app items published for the app including price, type, title and description.</li>
+<li>The purchase flow is synchronous and purchase information is available immediately after it completes.</li>
+<li>Purchase information of in-app purchases is maintained within the Google Play system till the purchase is consumed.</li>
+<li>An API to consume a purchase of an inapp item. All purchases of one-time in-app items are consumable and thereafter can be purchased again.</li>
+<li>An API to get current purchases of the user immediately. This list will not contain any consumed purchases.</li>
+</ul>
+</li>
+<li>Subscriptions are not yet supported in this version of the API.</li>
+</ul>
+
+<h3 id="version_2">In-app Billing version 2</h3>
+<p><em>May 2012</em></p>
+<ul>
+ <li>Adds support for subscriptions, including free trial period.</li>
+ <li>Adds a new supported string value, "2", for the <code>API_VERSION</code> key of the Bundle object passed in the <code>sendBillingRequest()</code>.</li>
+ <li>Adds a new JSON field, <code>purchaseToken</code>, to the <code>orders</code> list returned in a <code>PURCHASE_STATE_CHANGED</code> intent. </li>
+ <li>Adds a new <code>purchaseState</code> value, <code>3</code> (expired), to the <code>orders</code> list returned in a <code>PURCHASE_STATE_CHANGED</code> intent. The value indicates that a subscription has expired and is no longer valid.</li>
+<li>Requires Google Play (Play Store) version 3.5 or higher.</li>
+</ul>
+
+<h3 id="version_1">In-app Billing version 1</h3>
+<p><em>March 2011</em></p>
+<ul>
+<li>Initial release.</li>
+<li>Requires Google Play/Android Market 2.3.4 or higher.</li>
+</ul>
+
+
--- /dev/null
+page.title=Selling In-app Products
+
+trainingnavtop=true
+startpage=true
+next.title=Preparing Your In-app Billing Application
+next.link=preparing-iab-app.html
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<!-- Required platform, tools, add-ons, devices, knowledge, etc. -->
+<h2>Dependencies and prerequisites</h2>
+<ul>
+ <li>Android 2.2 or higher</li>
+</ul>
+
+<h2>You Should Also Read</h2>
+<ul>
+<li><a href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+ Overview</a></li>
+</ul>
+
+</div>
+</div>
+<p>In this class, you'll learn how to perform common In-app Billing operations from Android applications.</p>
+<p>In-app billing is a service hosted on Google Play that lets you charge for digital content or for upgrades in your app. The In-app Billing API makes it easy for you to integrate In-app Billing into your applications. You can request product details from Google Play, issue orders for in-app products, and quickly retrieve ownership information based on users' purchase history. You can also query the Google Play service for details about in-app products, such as local pricing and availability. Google Play provides a checkout interface that makes user interactions with the In-app Billing service seamless, and provides a more intuitive experience to your users.</p>
+<p>This class describes how to get started with the Version 3 API. To learn how to use the version 2 API, see <a href="{@docRoot}google/play/billing/v2/billing_integrate.html">Implementing In-App Billing (V2)</a>.</p>
+
+<h2>Lessons</h2>
+
+<!-- Create a list of the lessons in this class along with a short description of each lesson.
+These should be short and to the point. It should be clear from reading the summary whether someone
+will want to jump to a lesson or not.-->
+
+<dl>
+ <dt><b><a href="preparing-iab-app.html">Preparing Your In-app Billing Application</a></b></dt>
+ <dd>In this lesson, you will learn how to prepare your application to use the In-app Billing API and communicate with Google Play. You will also learn how to establish a connection to communicate with Google Play and verify that the In-app Billing API version that you are using is supported.</dd>
+ <dt><b><a href="list-iab-products.html">Establishing In-app Billing Products for Sale</a></b></dt>
+ <dd>In this lesson, you will learn how to specify the In-app Billing products for your app in Google Play and query the product details.</dd>
+ <dt><b><a href="purchase-iab-products.html">Purchase In-app Billing Products</a></b></dt>
+ <dd>In this lesson, you will learn how to purchase In-app Billing products, track consumption of purchased items, and query for details of purchased items.</dd>
+ <dt><b><a href="test-iab-app.html">Testing Your In-app Billing Application</a></b></dt>
+ <dd>In this lesson, you will learn how to test your application to ensure that In-app Billing is functioning correctly.</dd>
+</dl>
--- /dev/null
+page.title=Establishing In-app Billing Products for Sale
+parent.title=Selling In-app Products
+parent.link=index.html
+
+trainingnavtop=true
+previous.title=Preparing Your In-app Billing Application
+previous.link=preparing-iab-app.html
+next.title=Purchasing In-app Billing Products
+next.link=purchase-iab-products.html
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<h2>This lesson teaches you to</h2>
+<ol>
+ <li><a href="#DefineProducts">Specify In-app Products in Google Play</a></li>
+ <li><a href="#QueryDetails">Query In-app Product Details</a></li>
+</ol>
+
+<h2>You should also read</h2>
+<ul>
+<li><a href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+ Overview</a></li>
+</ul>
+
+
+</div>
+</div>
+
+<p>Before publishing your In-app Billing application, you'll need to define the product list of digital goods available for purchase in the <a href="https://play.google.com/apps/publish/">Google Play Developer Console</a>. </p>
+
+<h2 id="DefineProducts">Specify In-app Products in Google Play</h2>
+<p>From the Developer Console, you can define product information for in-app products and associate the product list with your application.</p>
+
+<p>To add new in-app products to your product list:</p>
+<ol>
+<li>Build a signed APK file for your In-app Billing application. To learn how to build and sign your APK, see <a href="{@docRoot}tools/publishing/preparing.html#publishing-build">Building Your Application for Release</a>. Make sure that you are using your final (not debug) certificate and private key to sign your application.
+</li>
+<li>In the Developer Console, open the application entry that you created earlier.</li>
+<li>Click on the APK tab then click on Upload new APK. Upload the signed APK file to the Developer Console. Don’t publish the app yet!</li>
+<li>Navigate to the uploaded app listing, and click on <strong>In-app Products</strong>.
+<li>Click on the option to add a new product, then complete the form to specify the product information such as the item’s unique product ID (also called its <em>SKU</em>), description, price, and country availability. Note down the product ID since you might need this information to query purchase details in your application later. <p class="note"><strong>Important:</strong> The In-app Billing Version 3 service only supports managed in-app products, so make sure that you specify that the purchase type is 'Managed' when you add new items to your product list in the Developer Console.</p></li>
+<li>Once you have completed the form, activate the product so that your application can purchase it. <p class="note"><strong>Warning:</strong> It may take up to 2-3 hours after uploading the APK for Google Play to recognize your updated APK version. If you try to test your application before your uploaded APK is recognized by Google Play, your application will receive a ‘purchase cancelled’ response with an error message “This version of the application is not enabled for In-app Billing.”</p></li>
+</ol>
+
+<h2 id="QueryDetails">Query Items Available for Purchase</h2>
+<p>You can query Google Play to programmatically retrieve details of the in-app products that are associated with your application (such as the product’s price, title, description, and type). This is useful, for example, when you want to display a listing of unowned items that are still available for purchase to users.</p>
+<p class="note"><strong>Note:</strong> When making the query, you will need to specify the product IDs for the products explicitly. You can manually find the product IDs from the Developer Console by opening the <strong>In-app Products</strong> tab for your application. The product IDs are listed under the column labeled <strong>Name/ID</strong>.</p>
+<p>To retrieve the product details, call {@code queryInventoryAsync(boolean, List, QueryInventoryFinishedListener)} on your IabHelper instance.
+<ul>
+<li>The first input argument indicates whether product details should be retrieved (should be set to {@code true}).</li>
+<li>The {@code List} argument consists of one or more product IDs (also called SKUs) for the products that you want to query.</li>
+<li>Finally, the {@code QueryInventoryFinishedListener} argument specifies a listener is notified when the query operation has completed and handles the query response.</li>
+</ul>
+If you use the the convenience classes provided in the sample, the classes will handle background thread management for In-app Billing requests, so you can safely make queries from the main thread of your application.
+</p>
+<p>The following code shows how you can retrieve the details for two products with IDs {@code SKU_APPLE} and {@code SKU_BANANA} that you previously defined in the Developer Console.</p>
+
+<pre>
+List<String> additionalSkuList = new List<String>();
+additionalSkuList.add(SKU_APPLE);
+additionalSkuList.add(SKU_BANANA);
+mHelper.queryInventoryAsync(true, additionalSkuList,
+ mQueryFinishedListener);
+</pre>
+
+<p>If the query is successful, the query results are stored in an {@code Inventory} object that is passed back to the listener.</p>
+<p>The following code shows how you can retrieve the item prices from the result set.</p>
+
+<pre>
+IabHelper.QueryInventoryFinishedListener
+ mQueryFinishedListener = new IabHelper.QueryInventoryFinishedListener() {
+ public void onQueryInventoryFinished(IabResult result, Inventory inventory)
+ {
+ if (result.isFailure()) {
+ // handle error
+ return;
+ }
+
+ String applePrice =
+ inventory.getSkuDetails(SKU_APPLE).getPrice();
+ String bananaPrice =
+ inventory.getSkuDetails(SKU_BANANA).getPrice();
+
+ // update the UI
+ }
+}
+</pre>
+
--- /dev/null
+page.title=Preparing Your In-app Billing Application
+parent.title=Selling In-app Products
+parent.link=index.html
+
+trainingnavtop=true
+next.title=Establishing In-app Billing Products for Sale
+next.link=list-iab-products.html
+
+@jd:body
+
+<!-- This is the training bar -->
+<div id="tb-wrapper">
+<div id="tb">
+
+<h2>This lesson teaches you to</h2>
+<ol>
+ <li><a href="#GetSample">Download the Sample App</a></li>
+ <li><a href="#AddToDevConsole">Add Your App to the Developer Console</a></li>
+ <li><a href="#AddLibrary">Add the In-app Billing Library</a></li>
+ <li><a href="#SetPermission">Set the Billing Permission</a></li>
+ <li><a href="#Connect">Initiate a Connection with Google Play</a></li>
+</ol>
+
+<h2>You should also read</h2>
+<ul>
+<li><a href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+ Overview</a></li>
+</ul>
+
+</div>
+</div>
+
+<p>Before you can start using the In-app Billing service, you'll need to add the library that contains the In-app Billing Version 3 API to your Android project. You also need to setting the permissions for your application to communicate with Google Play. In addition, you'll need to establish a connection between your application and Google Play. You should also verify that the In-app Billing API version that you are using in your application is supported by Google Play.</p>
+
+<h2 id="GetSample">Download the Sample Application</h2>
+<p>In this training class, you will use a reference implementation for the In-app Billing Version 3 API called the {@code TrivialDrive} sample application. The sample includes convenience classes to quickly set up the In-app Billing service, marshal and unmarshal data types, and handle In-app Billing requests from the main thread of your application. </p>
+<p>To download the sample application:</p>
+<ol>
+<li>Open the <a href="{@docRoot}tools/help/sdk-manager.html">Android SDK Manager</a>.</li>
+<li>In the SDK Manager, expand the {@code Extras} section.</li>
+<li>Select <strong>Google Play Billing Library</strong>. Make sure to select the download for In-app Billing Version 3 or above.</li>
+<li>Click <strong>Install</strong> to complete the download.</li>
+</ol>
+<p>The sample files will be installed to {@code /your/sdk/location/extras/google/play_billing/in-app-billing-v03}.</p>
+
+<h2 id="AddToDevConsole">Add Your Application to the Developer Console</h2>
+<p>The Google Play Developer Console is where you publish your In-app Billing application and manage the various digital goods that are available for purchase from your application. When you create a new application entry in the Developer Console, it automatically generates a public license key for your application. You will need this key to establish a trusted connection from your application to the Google Play servers. You only need to generate this key once per application, and don’t need to repeat these steps when you update the APK file for your application.</p>
+<p>To add your application to the Developer Console:</p>
+<ol>
+<li>Go to the <a href="http://play.google.com/apps/publish">Google Play Developer Console</a> site and log in. You will need to register for a new developer account, if you have not registered previously. To sell in-app items, you also need to have a <a href="http://www.google.com/wallet/merchants.html">Google Checkout Merchant</a> account.</li>
+<li>Click on <strong>Try the new design</strong> to access the preview version of the Developer Console, if you are not already logged on to that version. </li>
+<li>In the <strong>All Applications</strong> tab, add a new application entry.
+<ol type="a">
+<li>Click <strong>Add new application</strong>.</li>
+<li>Enter a name for your new In-app Billing application.</li>
+<li>Click <strong>Prepare Store Listing</strong>.</li>
+</ol>
+</li>
+<li>In the <strong>Services & APIs</strong> tab, find and make a note of the public license key that Google Play generated for your application. This is a Base64 string that you will need to include in your application code later.</li>
+</ol>
+<p>Your application should now appear in the list of applications in Developer Console.</p>
+
+<h2 id="AddLibrary">Add the In-app Billing Library</h2>
+<p>To use the In-app Billing Version 3 features, you must add the {@code IInAppBillingService.aidl} file to your Android project. This Android Interface Definition Language (AIDL) file defines the interface to the Google Play service.</p>
+<p>You can find the {@code IInAppBillingService.aidl} file in the provided sample app. Depending on whether you are creating a new application or modifying an existing application, follow the instructions below to add the In-app Billing Library to your project.</p>
+<h3>New Project</h3>
+<p>To add the In-app Billing Version 3 library to your new In-app Billing project:</p>
+<ol>
+<li>Copy the {@code TrivialDrive} sample files into your Android project.</li>
+<li>Modify the package name in the files you copied to use the package name for your project. In Eclipse, you can use this shortcut: right-click the package name, then select <strong>Refactor</strong> > <strong>Rename</strong>.</li>
+<li>Open the {@code AndroidManifest.xml} file and update the package attribute value to use the package name for your project.</li>
+<li>Fix import statements as needed so that your project compiles correctly. In Eclipse, you can use this shortcut: press <strong>Ctrl+Shift+O</strong> in each file showing errors.</li>
+<li>Modify the sample to create your own application. Remember to copy the Base64 public license key for your application from the Developer Console over to your {@code MainActivity.java}.</li>
+</ol>
+
+<h3>Existing Project</h3>
+<p>To add the In-app Billing Version 3 library to your existing In-app Billing project:</p>
+<ol>
+<li>Copy the {@code IInAppBillingService.aidl} file to your Android project.
+ <ul>
+ <li>If you are using Eclipse: Import the {@code IInAppBillingService.aidl} file into your {@code /src} directory.</li>
+ <li>If you are developing in a non-Eclipse environment: Create the following directory {@code /src/com/android/vending/billing} and copy the {@code IInAppBillingService.aidl} file into this directory.</li>
+ </ul>
+</li>
+<li>Build your application. You should see a generated file named {@code IInAppBillingService.java} in the {@code /gen} directory of your project.</li>
+<li>Add the helper classes from the {@code /util} directory of the {@code TrivialDrive} sample to your project. Remember to change the package name declarations in those files accordingly so that your project compiles correctly.</li>
+</ol>
+
+<p>Your project should now contain the In-app Billing Version 3 library.</p>
+
+<h2 id="SetPermission">Set the Billing Permission</h2>
+<p>Your app needs to have permission to communicate request and response messages to the Google Play’s billing service. To give your app the necessary permission, add this line in your {@code AndroidManifest.xml} manifest file:</p>
+<pre>
+<uses-permission android:name="com.android.vending.BILLING" />
+</pre>
+
+<h2 id="Connect">Initiate a Connection with Google Play</h2>
+<p>You must bind your Activity to Google Play’s In-app Billing service to send In-app Billing requests to Google Play from your application. The convenience classes provided in the sample handles the binding to the In-app Billing service, so you don’t have to manage the network connection directly.</p>
+<p>To set up synchronous communication with Google Play, create an {@code IabHelper} instance in your activity's {@code onCreate} method. In the constructor, pass in the {@code Context} for the activity, along with a string containing the public license key that was generated earlier by the Google Play Developer Console. </p>
+<p class="note"><strong>Security Recommendation:</strong> It is highly recommended that you do not hard-code the exact public license key string value as provided by Google Play. Instead, you can construct the whole public license key string at runtime from substrings, or retrieve it from an encrypted store, before passing it to the constructor. This approach makes it more difficult for malicious third-parties to modify the public license key string in your APK file.</p>
+
+<pre>
+IabHelper mHelper;
+
+@Override
+public void onCreate(Bundle savedInstanceState) {
+ // ...
+ String base64EncodedPublicKey;
+
+ // compute your public key and store it in base64EncodedPublicKey
+ mHelper = new IabHelper(this, base64EncodedPublicKey);
+}
+</pre>
+
+<p>Next, perform the service binding by calling the {@code startSetup} method on the {@code IabHelper} instance that you created. Pass the method an {@code OnIabSetupFinishedListener} instance, which is called once the {@code IabHelper} completes the asynchronous setup operation. As part of the setup process, the {@code IabHelper} also checks if the In-app Billing Version 3 API is supported by Google Play. If the API version is not supported, or if an error occured while establishing the service binding, the listener is notified and passed an {@code IabResult} object with the error message.</p>
+
+<pre>
+mHelper.startSetup(new IabHelper.OnIabSetupFinishedListener() {
+ public void onIabSetupFinished(IabResult result) {
+ if (!result.isSuccess()) {
+ // Oh noes, there was a problem.
+ Log.d(TAG, "Problem setting up In-app Billing: " + result);
+ }
+ // Hooray, IAB is fully set up!
+ }
+});
+</pre>
+
+<p>If the setup completed successfully, you can now use the {@code mHelper} reference to communicate with the Google Play service. When your application is launched, it is a good practice to query Google Play to find out what in-app items are owned by a user. This is covered further in the <a href="{@docRoot}training/in-app-billing/purchase-iab-products.html#QueryPurchases">Query Purchased Items</a> section.</p>
+
+<p class="note"><strong>Important:</strong> Remember to unbind from the In-app Billing service when you are done with your activity. If you don’t unbind, the open service connection could cause your device’s performance to degrade. To unbind and free your system resources, call the {@code IabHelper}'s {@code dispose} method when your {@code Activity} gets destroyed.</p>
+
+<pre>
+@Override
+public void onDestroy() {
+ if (mHelper != null) mHelper.dispose();
+ mHelper = null;
+}
+</pre>
+
+
+
+
+
--- /dev/null
+page.title=Purchasing In-app Billing Products
+parent.title=Selling In-app Products
+parent.link=index.html
+
+trainingnavtop=true
+previous.title=Establishing In-app Billing Products for Sale
+previous.link=list-iab-products.html
+next.title=Testing Your In-app Billing Application
+next.link=test-iab-app.html
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<h2>This lesson teaches you to</h2>
+<ol>
+ <li><a href="#Purchase">Purchase an Item</a></li>
+ <li><a href="#QueryPurchases">Query Purchased Items</a></li>
+ <li><a href="#Consume">Consume a Purchase</a></li>
+</ol>
+
+<h2>You should also read</h2>
+<ul>
+<li><a href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+ Overview</a></li>
+</ul>
+</div>
+</div>
+
+<p>Once your application is connected to Google Play, you can initiate purchase requests for in-app products. Google Play provides a checkout interface for users to enter their payment method, so your application does not need to handle payment transactions directly.</p>
+<p>When an item is purchased, Google Play recognizes that the user has ownership of that item and prevents the user from purchasing another item with the same product ID until it is consumed. You can control how the item is consumed in your application, and notify Google Play to make the item available for purchase again.</p>
+<p>You can also query Google Play to quickly retrieve the list of purchases that were made by the user. This is useful, for example, when you want to restore the user's purchases when your user launches your app.</p>
+
+<h2 id="Purchase">Purchase an Item</h2>
+
+<p>To start a purchase request from your app, call {@code launchPurchaseFlow(Activity, String, int, OnIabPurchaseFinishedListener, String)} on your {@code IabHelper} instance. You must make this call from the main thread of your {@code Activity}. Here’s an explaination of the {@code launchPurchaseFlow} method parameters:</p>
+<ul>
+<li>The first argument is the calling {@code Activity}.</li>
+<li>The second argument is the product ID (also called its SKU) of the item to purchase. Make sure that you are providing the ID and not the product name. You must have previously defined and activated the item in the Developer Console, otherwise it won’t be recognized. </li>
+<li>The third argument is a request code value. This value can be any positive integer. Google Play reurns this request code to the calling {@code Activity}’s {@code onActivityResult} along with the purchase response.</li>
+<li>The fourth argument is a listener that is notified when the purchase operation has completed and handles the purchase response from Google Play.</li>
+<li>The fifth argument contains a ‘developer payload’ string that you can use to send supplemental information about an order (it can be an empty string). Typically, this is used to pass in a string token that uniquely identifies this purchase request. If you specify a string value, Google Play returns this string along with the purchase response. Subsequently, when you make queries about this purchase, Google Play returns this string together with the purchase details. <p class="note"><strong>Security Recommendation:</strong> It’s good practice to pass in a string that helps your application to identify the user who made the purchase, so that you can later verify that this is a legitimate purchase by that user. For consumable items, you can use a randomly generated string, but for non-consumable items you should use a string that uniquely identifies the user.</p></li>
+</ul>
+<p>The following example shows how you can make a purchase request for a product with ID {@code SKU_GAS}, using an arbitrary value of 10001 for the request code, and an encoded developer payload string.</p>
+
+<pre>
+mHelper.launchPurchaseFlow(this, SKU_GAS, 10001,
+ mPurchaseFinishedListener, "bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ");
+</pre>
+
+<p>If the purchase order is successful, the response data from Google Play is stored in an {@code Purchase} object that is passed back to the listener.</p>
+
+<p>The following example shows how you can handle the purchase response in the listener, depending on whether the purchase order was completed successfully, and whether the user purchased gas or a premium upgrade. In this example, gas is an in-app product that can be purchased multiple times, so you should consume the purchase to allow the user to buy it again. To learn how to consume purchases, see the <a href="{@docRoot}training/in-app-billing/purchase-iab-products.html#Consume">Consuming Products</a> section. The premium upgrade is a one-time purchase so you don’t need to consume it. It is good practice to update the UI immediately so that your users can see their newly purchased items.</p>
+
+<pre>
+IabHelper.OnIabPurchaseFinishedListener mPurchaseFinishedListener
+ = new IabHelper.OnIabPurchaseFinishedListener() {
+ public void onIabPurchaseFinished(IabResult result, Purchase purchase)
+ {
+ if (result.isFailure()) {
+ Log.d(TAG, "Error purchasing: " + result);
+ return;
+ }
+ else if (purchase.getSku().equals(SKU_GAS)) {
+ // consume the gas and update the UI
+ }
+ else (purchase.getSku().equals(SKU_PREMIUM)) {
+ // give user access to premium content and update the UI
+ }
+ }
+};
+</pre>
+
+<p class="note"><strong>Security Recommendation:</strong> When you receive the purchase response from Google Play, make sure to check the returned data signature, the {@code orderId}, and the {@code developerPayload} string in the {@code Purchase} object to make sure that you are getting the expected values. You should verify that the {@code orderId} is a unique value that you have not previously processed, and the {@code developerPayload} string matches the token that you sent previously with the purchase request. As a further security precaution, you should perform the verification on your own secure server. </p>
+
+<h2 id="QueryPurchases">Query Purchased Items</h2>
+<p>Upon a successful purchase, the user’s purchase data is cached locally by Google Play’s In-app Billing service. It is good practice to frequently query the In-app Billing service for the user’s purchases, for example whenever the app starts up or resumes, so that the user’s current in-app product ownership information is always reflected in your app.</p>
+
+<p>To retrieve the user’s purchases from your app, call {@code queryInventoryAsync(QueryInventoryFinishedListener)} on your {@code IabHelper} instance. The {@code QueryInventoryFinishedListener} argument specifies a listener that is notified when the query operation has completed and handles the query response. It is safe to make this call fom your main thread.</p>
+
+<pre>
+mHelper.queryInventoryAsync(mGotInventoryListener);
+</pre>
+
+<p>If the query is successful, the query results are stored in an {@code Inventory} object that is passed back to the listener. The In-app Billing service returns only the purchases made by the user account that is currently logged in to the device.</p>
+
+<pre>
+IabHelper.QueryInventoryFinishedListener mGotInventoryListener
+ = new IabHelper.QueryInventoryFinishedListener() {
+ public void onQueryInventoryFinished(IabResult result,
+ Inventory inventory) {
+
+ if (result.isFailure()) {
+ // handle error here
+ }
+ else {
+ // does the user have the premium upgrade?
+ mIsPremium = inventory.hasPurchase(SKU_PREMIUM);
+ // update UI accordingly
+ }
+ }
+};
+</pre>
+
+<h2 id="Consume">Consume a Purchase</h2>
+<p>You can use the In-app Billing Version 3 API to track the ownership of purchased items in Google Play. Once an item is purchased, it is considered to be "owned" and cannot be purchased again from Google Play while in that state. You must send a consumption request for the item before Google Play makes it available for purchase again. All managed in-app products are consumable. How you use the consumption mechanism in your app is up to you. Typically, you would implement consumption for products with temporary benefits that users may want to purchase multiple times (for example, in-game currency or replensihable game tokens). You would typically not want to implement consumption for products that are purchased once and provide a permanent effect (for example, a premium upgrade).</p>
+<p>It's your responsibility to control and track how the in-app product is provisioned to the user. For example, if the user purchased in-game currency, you should update the player's inventory with the amount of currency purchased.</p>
+<p class="note"><strong>Security Recommendation:</strong> You must send a consumption request before provisioning the benefit of the consumable in-app purchase to the user. Make sure that you have received a successful consumption response from Google Play before you provision the item.</p>
+<p>To record a purchase consumption, call {@code consumeAsync(Purchase, OnConsumeFinishedListener)} on your {@code IabHelper} instance. The first argument that the method takes is the {@code Purchase} object representing the item to consume. The second argument is a {@code OnConsumeFinishedListener} that is notified when the consumption operation has completed and handles the consumption response from Google Play. It is safe to make this call fom your main thread.</p>
+<p>In this example, you want to consume the gas item that the user has previously purchased in your app.</p>
+
+<pre>
+mHelper.consumeAsync(inventory.getPurchase(SKU_GAS),
+ mConsumeFinishedListener);
+</pre>
+
+<p>The following example shows how to implement the {@code OnConsumeFinishedListener}.</p>
+
+<pre>
+IabHelper.OnConsumeFinishedListener mConsumeFinishedListener =
+ new IabHelper.OnConsumeFinishedListener() {
+ public void onConsumeFinished(Purchase purchase, IabResult result) {
+ if (result.isSuccess()) {
+ // provision the in-app purchase to the user
+ // (for example, credit 50 gold coins to player's character)
+ }
+ else {
+ // handle error
+ }
+ }
+};
+</pre>
+
+<h3>Check for Consumable Items on Startup</h3>
+<p>It’s important to check for consumable items when the user starts up your application. Typically, you would first query the In-app Billing service for the items purchased by the user (via {@code queryInventoryAsync}), then get the consumable {@code Purchase} objects from the Inventory. If your application detects that are any consumable items that are owned by the user, you should send a consumption request to Google Play immediately and provision the item to the user. See the {@code TrivialDrive} sample for an example of how to implement this checking at startup.</p>
+
+
--- /dev/null
+page.title=Testing Your In-app Billing Application
+parent.title=Selling In-app Products
+parent.link=index.html
+
+trainingnavtop=true
+previous.title=Purchasing In-app Billing Products
+previous.link=purchase-iab-products.html
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<h2>This lesson teaches you to</h2>
+<ol>
+ <li><a href="#StaticTest">Test with Static Responses</a></li>
+ <li><a href="#PlayItemTest">Test with Your Own Product IDs</a></li>
+</ol>
+
+<h2>You should also read</h2>
+<ul>
+<li><a href="{@docRoot}google/play/billing/billing_overview.html">In-app Billing
+ Overview</a></li>
+</ul>
+
+</div>
+</div>
+
+<p>To ensure that In-app Billing is functioning correctly in your application, you should test the test the application before you publish it on Google Play. Early testing also helps to ensure that the user flow for purchasing in-app items is not confusing or slow, and that users can see their newly purchased items in a timely way.</p>
+
+<h2 id="StaticTest">Test with Static Responses</h2>
+Test your In-app Billing application with static responses by using Google Play’s reserved product IDs.By using reserved product IDs instead of actual product IDs, you can test the purchase flow without specifying an actual payment method or transferring money. To learn more about the reserved product IDs, see <a href="{@docRoot}google/play/billing/billing_testing.html">Testing In-app Billing</a>.
+
+<h2 id="PlayItemTest">Test with Your Own Product IDs</h2>
+<p>Because Google Play does not allow you to use your developer account to directly purchase in-app products that you have created yourself, you'll need to create test acccounts under your developer account profile. To create a test account, simply enter a valid Google email address. Users with these test accounts will then be able to make in-app-billing purchases from uploaded, unpublished applications that you manage.</p>
+<p>To test your In-app Billing Version 3 application using your own product IDs:
+<ol>
+<li>In the Developer Console, add one or more tester accounts to the developer account that you are using to publish your application.
+ <ol type="a">
+ <li>Login to the <a href="https://play.google.com/apps/publish/" target="_blank">Developer Console</a> with your developer account.</li>
+ <li>Click <strong>Settings</strong> > <strong>Account</strong> details, then in the <strong>License Testing</strong> section, add the Google email addresses for your tester accounts.</li>
+</ol>
+<li>Build a signed APK file for your In-app Billing application. To learn how to build and sign your APK, see <a href="{@docRoot}tools/publishing/preparing.html#publishing-build">Building Your Application for Release</a>. Make sure that you are using your final (not debug) certificate and private key to sign your application.
+</li>
+<li>Make sure that you have uploaded the signed APK for your application to the Developer Console, and associated one or more in-app products with your application. You don't need to publish the application on Google Play to test it. <p class="note"><strong>Warning:</strong> It may take up to 2-3 hours after uploading the APK for Google Play to recognize your updated APK version. If you try to test your application before your uploaded APK is recognized by Google Play, your application will receive a ‘purchase cancelled’ response with an error message “This version of the application is not enabled for In-app Billing.”</p></li>
+<li>Install the APK file to your physical test device by using the {@code adb} tool. To learn how to install the application, see <a href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a Device</a>. Make sure that:
+ <ul>
+ <li>Your test device is running on Android SDK Version 2.2 (API level 8) or higher, and is installed with Google Play client Version 3.9.16 or higher.</li>
+ <li>The {@code android:versionCode} and {@code android:versionName} attributes values in the {@code AndroidManifest.xml} of the application that you are installing matches the values of your APK in the Developer Console.</li>
+ <li>Your application is signed with the same certificate that you used for the APK that you uploaded to the Developer Console, before installing it on your device.</li>
+ </ul>
+</li>
+<li>Login to the test device by using a tester account. Test your In-app Billing application by purchasing a few items, and fix any issues that you encounter. Remember to refund the purchases if you don’t want your testers to be actually charged!</li>
+</ol>
+</p>
+
</a>
</div>
<ul>
+ <li class="nav-section">
+ <div class="nav-section-header"><a href="<?cs var:toroot ?>training/in-app-billing/index.html"
+ description="How to sell in-app products from your application using In-app Billing.">
+ Selling In-app Products
+ </a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>training/in-app-billing/preparing-iab-app.html">
+ <span class="en">Preparing Your App</span>
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/in-app-billing/list-iab-products.html">
+ <span class="en">Establishing Products for Sale</span>
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/in-app-billing/purchase-iab-products.html">
+ <span class="en">Purchasing Products</span>
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/in-app-billing/test-iab-app.html">
+ <span class="en">Testing Your App</span>
+ </a>
+ </li>
+ </ul>
+ </li>
<li class="nav-section">
<div class="nav-section-header">
--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+ <key>ActiveLayerIndex</key>
+ <integer>0</integer>
+ <key>ApplicationVersion</key>
+ <array>
+ <string>com.omnigroup.OmniGrafflePro</string>
+ <string>139.16.0.171715</string>
+ </array>
+ <key>AutoAdjust</key>
+ <true/>
+ <key>BackgroundGraphic</key>
+ <dict>
+ <key>Bounds</key>
+ <string>{{0, 0}, {576, 733}}</string>
+ <key>Class</key>
+ <string>SolidGraphic</string>
+ <key>ID</key>
+ <integer>2</integer>
+ <key>Style</key>
+ <dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ </dict>
+ <key>BaseZoom</key>
+ <integer>0</integer>
+ <key>CanvasOrigin</key>
+ <string>{0, 0}</string>
+ <key>ColumnAlign</key>
+ <integer>1</integer>
+ <key>ColumnSpacing</key>
+ <real>36</real>
+ <key>CreationDate</key>
+ <string>2012-10-22 20:20:34 +0000</string>
+ <key>Creator</key>
+ <string>Quddus Chong</string>
+ <key>DisplayScale</key>
+ <string>1 0/72 in = 1.0000 in</string>
+ <key>GraphDocumentVersion</key>
+ <integer>8</integer>
+ <key>GraphicsList</key>
+ <array>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>232</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{473.50000023841858, 333}</string>
+ <string>{342.75000023841858, 333}</string>
+ <string>{99.750000238418579, 333}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>231</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{101, 289}</string>
+ <string>{472, 288}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>230</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{102.5, 144.00001525878906}</string>
+ <string>{473.5, 143.00001525878906}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>217</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{472.875, 218}</string>
+ <string>{342.125, 218}</string>
+ <string>{99.125, 218}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{136.25, 264}, {305.5, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>220</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKxFjb25zdW1lUHVyY2hhc2UoKYaEAmlJARGS
+ hISEDE5TRGljdGlvbmFyeQCUhAFpBJKElpYQTlNQYXJh
+ Z3JhcGhTdHlsZYaShISEEE5TUGFyYWdyYXBoU3R5bGUA
+ lIQEQ0NAUwIAhISEB05TQXJyYXkAlJkMkoSEhAlOU1Rl
+ eHRUYWIAlIQCQ2YAHIaShJ+eADiGkoSfngBUhpKEn54A
+ cIaShJ+eAIGMAIaShJ+eAIGoAIaShJ+eAIHEAIaShJ+e
+ AIHgAIaShJ+eAIH8AIaShJ+eAIEYAYaShJ+eAIE0AYaS
+ hJ+eAIFQAYaGgQAIhARbMWZdg83MTD2GkoSWlgdOU0Nv
+ bG9yhpKEhIQHTlNDb2xvcgCUhAFjA4QCZmYAg2ZmJj+G
+ koSWlgZOU0ZvbnSGkoSEhAZOU0ZvbnQelJkohAVbNDBj
+ XQYAAAAeAAAA//5IAGUAbAB2AGUAdABpAGMAYQAtAEIA
+ bwBsAGQAAACEAWYMoQChAaEAoQCGkoSWlg5OU09yaWdp
+ bmFsRm9udIaSr4aG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 consumePurchase()}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>17</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{123.25, 309}, {331.5, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>218</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKw9TVUNDRVNTL0ZBSUxVUkWGhAJpSQEPkoSE
+ hAxOU0RpY3Rpb25hcnkAlIQBaQOShJaWB05TQ29sb3KG
+ koSEhAdOU0NvbG9yAJSEAWMDhAJmZgCDZmYmP4aShJaW
+ EE5TUGFyYWdyYXBoU3R5bGWGkoSEhBBOU1BhcmFncmFw
+ aFN0eWxlAJSEBENDQFMCAISEhAdOU0FycmF5AJSZDJKE
+ hIQJTlNUZXh0VGFiAJSEAkNmAByGkoSioQA4hpKEoqEA
+ VIaShKKhAHCGkoSioQCBjACGkoSioQCBqACGkoSioQCB
+ xACGkoSioQCB4ACGkoSioQCB/ACGkoSioQCBGAGGkoSi
+ oQCBNAGGkoSioQCBUAGGhoEACIQEWzFmXYPNzEw9hpKE
+ lpYGTlNGb250hpKEhIQGTlNGb250HpSZHIQFWzI4Y10G
+ AAAAFAAAAP/+SABlAGwAdgBlAHQAaQBjAGEAhAFmDJsA
+ mwGbAJsAhoaG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 SUCCESS/FAILURE}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>15</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{99.75, 153}, {373.75, 66}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>203</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBK35CdW5kbGUoUkVTUE9OU0VfQ09ERSwgSU5B
+ UFBfUFVSQ0hBU0VfSVRFTV9MSVNULCBJTkFQUF9QVVJD
+ SEFTRV9EQVRBX0xJU1QsIElOQVBQX0RBVEFfU0lHTkFU
+ VVJFX0xJU1QsIElOQVBQX0NPTlRJTlVBVElPTl9UT0tF
+ TimGhAJpSQF+koSEhAxOU0RpY3Rpb25hcnkAlIQBaQOS
+ hJaWB05TQ29sb3KGkoSEhAdOU0NvbG9yAJSEAWMDhAJm
+ ZgCDZmYmP4aShJaWEE5TUGFyYWdyYXBoU3R5bGWGkoSE
+ hBBOU1BhcmFncmFwaFN0eWxlAJSEBENDQFMCAISEhAdO
+ U0FycmF5AJSZDJKEhIQJTlNUZXh0VGFiAJSEAkNmAByG
+ koSioQA4hpKEoqEAVIaShKKhAHCGkoSioQCBjACGkoSi
+ oQCBqACGkoSioQCBxACGkoSioQCB4ACGkoSioQCB/ACG
+ koSioQCBGAGGkoSioQCBNAGGkoSioQCBUAGGhoEACIQE
+ WzFmXYPNzEw9hpKElpYGTlNGb250hpKEhIQGTlNGb250
+ HpSZHIQFWzI4Y10GAAAAFAAAAP/+SABlAGwAdgBlAHQA
+ aQBjAGEAhAFmDJsAmwGbAJsAhoaG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 Bundle(RESPONSE_CODE, INAPP_PURCHASE_ITEM_LIST, INAPP_PURCHASE_DATA_LIST, INAPP_DATA_SIGNATURE_LIST, INAPP_CONTINUATION_TOKEN)}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>126</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{238.00002503395081, 119.00001525878906}, {97, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>YES</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>199</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKw5nZXRQdXJjaGFzZXMoKYaEAmlJAQ6ShISE
+ DE5TRGljdGlvbmFyeQCUhAFpBJKElpYQTlNQYXJhZ3Jh
+ cGhTdHlsZYaShISEEE5TUGFyYWdyYXBoU3R5bGUAlIQE
+ Q0NAUwIAhISEB05TQXJyYXkAlJkMkoSEhAlOU1RleHRU
+ YWIAlIQCQ2YAHIaShJ+eADiGkoSfngBUhpKEn54AcIaS
+ hJ+eAIGMAIaShJ+eAIGoAIaShJ+eAIHEAIaShJ+eAIHg
+ AIaShJ+eAIH8AIaShJ+eAIEYAYaShJ+eAIE0AYaShJ+e
+ AIFQAYaGgQAIhARbMWZdg83MTD2GkoSWlgdOU0NvbG9y
+ hpKEhIQHTlNDb2xvcgCUhAFjA4QCZmYAg2ZmJj+GkoSW
+ lgZOU0ZvbnSGkoSEhAZOU0ZvbnQelJkohAVbNDBjXQYA
+ AAAeAAAA//5IAGUAbAB2AGUAdABpAGMAYQAtAEIAbwBs
+ AGQAAACEAWYMoQChAaEAoQCGkoSWlg5OU09yaWdpbmFs
+ Rm9udIaSr4aG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 getPurchases()}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>14</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ <key>Wrap</key>
+ <string>NO</string>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{472.875, 103}, {80.185199999999995, 284}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans-Bold</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>200</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{1, 1}</string>
+ <string>{1, -1}</string>
+ <string>{-1, -1}</string>
+ <string>{-1, 1}</string>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ <string>{-0.5, -0.233518}</string>
+ <string>{-0.49144199999999999, 0.26006299999999999}</string>
+ <string>{0.50711799999999996, -0.22408600000000001}</string>
+ <string>{0.50711799999999996, 0.267179}</string>
+ <string>{-0.27431, -0.474028}</string>
+ <string>{0.27977999999999997, -0.47847800000000001}</string>
+ <string>{0.29393799999999998, 0.54304399999999997}</string>
+ <string>{-0.28623199999999999, 0.55380399999999996}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.874135</string>
+ <key>r</key>
+ <string>0.71718</string>
+ </dict>
+ <key>FillType</key>
+ <integer>2</integer>
+ <key>GradientAngle</key>
+ <real>90</real>
+ <key>GradientColor</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.662438</string>
+ <key>r</key>
+ <string>0.464468</string>
+ </dict>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.35</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Fuzziness</key>
+ <real>2.3972222805023193</real>
+ <key>ShadowVector</key>
+ <string>{0, 1}</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0.93512</string>
+ <key>g</key>
+ <string>0.472602</string>
+ <key>r</key>
+ <string>0.333854</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>3</real>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc
+
+\f0\b\fs24 \cf0 Google\
+Play App}</string>
+ <key>VerticalPad</key>
+ <integer>0</integer>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{20.814800000000005, 103}, {80.185199999999995, 284}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans-Bold</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>157</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{1, 1}</string>
+ <string>{1, -1}</string>
+ <string>{-1, -1}</string>
+ <string>{-1, 1}</string>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ <string>{-0.5, -0.233518}</string>
+ <string>{-0.49144199999999999, 0.26006299999999999}</string>
+ <string>{0.50711799999999996, -0.22408600000000001}</string>
+ <string>{0.50711799999999996, 0.267179}</string>
+ <string>{-0.27431, -0.474028}</string>
+ <string>{0.27977999999999997, -0.47847800000000001}</string>
+ <string>{0.29393799999999998, 0.54304399999999997}</string>
+ <string>{-0.28623199999999999, 0.55380399999999996}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.874135</string>
+ <key>r</key>
+ <string>0.71718</string>
+ </dict>
+ <key>FillType</key>
+ <integer>2</integer>
+ <key>GradientAngle</key>
+ <real>90</real>
+ <key>GradientColor</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.662438</string>
+ <key>r</key>
+ <string>0.464468</string>
+ </dict>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.35</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Fuzziness</key>
+ <real>2.3972222805023193</real>
+ <key>ShadowVector</key>
+ <string>{0, 1}</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0.93512</string>
+ <key>g</key>
+ <string>0.472602</string>
+ <key>r</key>
+ <string>0.333854</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>3</real>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc
+
+\f0\b\fs24 \cf0 Your In-app\
+Billing Application}</string>
+ <key>VerticalPad</key>
+ <integer>0</integer>
+ </dict>
+ </dict>
+ </array>
+ <key>GridInfo</key>
+ <dict>
+ <key>ShowsGrid</key>
+ <string>YES</string>
+ </dict>
+ <key>GuidesLocked</key>
+ <string>NO</string>
+ <key>GuidesVisible</key>
+ <string>YES</string>
+ <key>HPages</key>
+ <integer>1</integer>
+ <key>ImageCounter</key>
+ <integer>1</integer>
+ <key>KeepToScale</key>
+ <false/>
+ <key>Layers</key>
+ <array>
+ <dict>
+ <key>Lock</key>
+ <string>NO</string>
+ <key>Name</key>
+ <string>Layer 1</string>
+ <key>Print</key>
+ <string>YES</string>
+ <key>View</key>
+ <string>YES</string>
+ </dict>
+ </array>
+ <key>LayoutInfo</key>
+ <dict>
+ <key>Animate</key>
+ <string>NO</string>
+ <key>circoMinDist</key>
+ <real>18</real>
+ <key>circoSeparation</key>
+ <real>0.0</real>
+ <key>layoutEngine</key>
+ <string>dot</string>
+ <key>neatoSeparation</key>
+ <real>0.0</real>
+ <key>twopiSeparation</key>
+ <real>0.0</real>
+ </dict>
+ <key>LinksVisible</key>
+ <string>NO</string>
+ <key>MagnetsVisible</key>
+ <string>NO</string>
+ <key>MasterSheets</key>
+ <array/>
+ <key>ModificationDate</key>
+ <string>2012-11-16 02:03:40 +0000</string>
+ <key>Modifier</key>
+ <string>Quddus Chong</string>
+ <key>NotesVisible</key>
+ <string>NO</string>
+ <key>Orientation</key>
+ <integer>2</integer>
+ <key>OriginVisible</key>
+ <string>NO</string>
+ <key>PageBreaks</key>
+ <string>YES</string>
+ <key>PrintInfo</key>
+ <dict>
+ <key>NSBottomMargin</key>
+ <array>
+ <string>float</string>
+ <string>41</string>
+ </array>
+ <key>NSHorizonalPagination</key>
+ <array>
+ <string>coded</string>
+ <string>BAtzdHJlYW10eXBlZIHoA4QBQISEhAhOU051bWJlcgCEhAdOU1ZhbHVlAISECE5TT2JqZWN0AIWEASqEhAFxlwCG</string>
+ </array>
+ <key>NSLeftMargin</key>
+ <array>
+ <string>float</string>
+ <string>18</string>
+ </array>
+ <key>NSPaperSize</key>
+ <array>
+ <string>size</string>
+ <string>{612, 792}</string>
+ </array>
+ <key>NSPrintReverseOrientation</key>
+ <array>
+ <string>int</string>
+ <string>0</string>
+ </array>
+ <key>NSRightMargin</key>
+ <array>
+ <string>float</string>
+ <string>18</string>
+ </array>
+ <key>NSTopMargin</key>
+ <array>
+ <string>float</string>
+ <string>18</string>
+ </array>
+ </dict>
+ <key>PrintOnePage</key>
+ <false/>
+ <key>ReadOnly</key>
+ <string>NO</string>
+ <key>RowAlign</key>
+ <integer>1</integer>
+ <key>RowSpacing</key>
+ <real>36</real>
+ <key>SheetTitle</key>
+ <string>Canvas 1</string>
+ <key>SmartAlignmentGuidesActive</key>
+ <string>YES</string>
+ <key>SmartDistanceGuidesActive</key>
+ <string>YES</string>
+ <key>UniqueID</key>
+ <integer>1</integer>
+ <key>UseEntirePage</key>
+ <false/>
+ <key>VPages</key>
+ <integer>1</integer>
+ <key>WindowInfo</key>
+ <dict>
+ <key>CurrentSheet</key>
+ <integer>0</integer>
+ <key>ExpandedCanvases</key>
+ <array>
+ <dict>
+ <key>name</key>
+ <string>Canvas 1</string>
+ </dict>
+ </array>
+ <key>Frame</key>
+ <string>{{301, 4}, {1093, 874}}</string>
+ <key>ListView</key>
+ <true/>
+ <key>OutlineWidth</key>
+ <integer>142</integer>
+ <key>RightSidebar</key>
+ <false/>
+ <key>ShowRuler</key>
+ <true/>
+ <key>Sidebar</key>
+ <true/>
+ <key>SidebarWidth</key>
+ <integer>120</integer>
+ <key>VisibleRegion</key>
+ <string>{{-184, 14}, {944, 719}}</string>
+ <key>Zoom</key>
+ <real>1</real>
+ <key>ZoomValues</key>
+ <array>
+ <array>
+ <string>Canvas 1</string>
+ <real>1</real>
+ <real>1</real>
+ </array>
+ </array>
+ </dict>
+</dict>
+</plist>
--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+ <key>ActiveLayerIndex</key>
+ <integer>0</integer>
+ <key>ApplicationVersion</key>
+ <array>
+ <string>com.omnigroup.OmniGrafflePro</string>
+ <string>139.16.0.171715</string>
+ </array>
+ <key>AutoAdjust</key>
+ <true/>
+ <key>BackgroundGraphic</key>
+ <dict>
+ <key>Bounds</key>
+ <string>{{0, 0}, {576, 733}}</string>
+ <key>Class</key>
+ <string>SolidGraphic</string>
+ <key>ID</key>
+ <integer>2</integer>
+ <key>Style</key>
+ <dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ </dict>
+ <key>BaseZoom</key>
+ <integer>0</integer>
+ <key>CanvasOrigin</key>
+ <string>{0, 0}</string>
+ <key>ColumnAlign</key>
+ <integer>1</integer>
+ <key>ColumnSpacing</key>
+ <real>36</real>
+ <key>CreationDate</key>
+ <string>2012-10-22 20:20:34 +0000</string>
+ <key>Creator</key>
+ <string>Quddus Chong</string>
+ <key>DisplayScale</key>
+ <string>1 0/72 in = 1.0000 in</string>
+ <key>GraphDocumentVersion</key>
+ <integer>8</integer>
+ <key>GraphicsList</key>
+ <array>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>233</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{103.6875, 163.71327209472656}</string>
+ <string>{474.6875, 162.71327209472656}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>232</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{474.0625, 237.7132568359375}</string>
+ <string>{343.3125, 237.7132568359375}</string>
+ <string>{100.3125, 237.7132568359375}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{100.9375, 172.7132568359375}, {373.75, 66}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>203</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBK35CdW5kbGUoUkVTUE9OU0VfQ09ERSwgSU5B
+ UFBfUFVSQ0hBU0VfSVRFTV9MSVNULCBJTkFQUF9QVVJD
+ SEFTRV9EQVRBX0xJU1QsIElOQVBQX0RBVEFfU0lHTkFU
+ VVJFX0xJU1QsIElOQVBQX0NPTlRJTlVBVElPTl9UT0tF
+ TimGhAJpSQF+koSEhAxOU0RpY3Rpb25hcnkAlIQBaQOS
+ hJaWB05TQ29sb3KGkoSEhAdOU0NvbG9yAJSEAWMDhAJm
+ ZgCDZmYmP4aShJaWEE5TUGFyYWdyYXBoU3R5bGWGkoSE
+ hBBOU1BhcmFncmFwaFN0eWxlAJSEBENDQFMCAISEhAdO
+ U0FycmF5AJSZDJKEhIQJTlNUZXh0VGFiAJSEAkNmAByG
+ koSioQA4hpKEoqEAVIaShKKhAHCGkoSioQCBjACGkoSi
+ oQCBqACGkoSioQCBxACGkoSioQCB4ACGkoSioQCB/ACG
+ koSioQCBGAGGkoSioQCBNAGGkoSioQCBUAGGhoEACIQE
+ WzFmXYPNzEw9hpKElpYGTlNGb250hpKEhIQGTlNGb250
+ HpSZHIQFWzI4Y10GAAAAFAAAAP/+SABlAGwAdgBlAHQA
+ aQBjAGEAhAFmDJsAmwGbAJsAhoaG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 Bundle(RESPONSE_CODE, INAPP_PURCHASE_ITEM_LIST, INAPP_PURCHASE_DATA_LIST, INAPP_DATA_SIGNATURE_LIST, INAPP_CONTINUATION_TOKEN)}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>126</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{239.18752503395081, 138.71327209472656}, {97, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>YES</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>199</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKw5nZXRQdXJjaGFzZXMoKYaEAmlJAQ6ShISE
+ DE5TRGljdGlvbmFyeQCUhAFpA5KElpYHTlNDb2xvcoaS
+ hISEB05TQ29sb3IAlIQBYwOEAmZmAINmZiY/hpKElpYQ
+ TlNQYXJhZ3JhcGhTdHlsZYaShISEEE5TUGFyYWdyYXBo
+ U3R5bGUAlIQEQ0NAUwIAhISEB05TQXJyYXkAlJkMkoSE
+ hAlOU1RleHRUYWIAlIQCQ2YAHIaShKKhADiGkoSioQBU
+ hpKEoqEAcIaShKKhAIGMAIaShKKhAIGoAIaShKKhAIHE
+ AIaShKKhAIHgAIaShKKhAIH8AIaShKKhAIEYAYaShKKh
+ AIE0AYaShKKhAIFQAYaGgQAIhARbMWZdg83MTD2GkoSW
+ lgZOU0ZvbnSGkoSEhAZOU0ZvbnQelJkohAVbNDBjXQYA
+ AAAeAAAA//5IAGUAbAB2AGUAdABpAGMAYQAtAEIAbwBs
+ AGQAAACEAWYMmwCbAZsAmwCGhoY=
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 getPurchases()}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>14</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ <key>Wrap</key>
+ <string>NO</string>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>231</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{103, 504}</string>
+ <string>{474, 503}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>230</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{103, 76.2867431640625}</string>
+ <string>{474, 75.2867431640625}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>229</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{471.0000031888485, 112}</string>
+ <string>{341.9117077589035, 112}</string>
+ <string>{102, 112}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>228</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{472.0000031888485, 326.77316284179688}</string>
+ <string>{342.9117077589035, 326.77316284179688}</string>
+ <string>{103, 326.77316284179688}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>227</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{474.75, 428.573486328125}</string>
+ <string>{344, 428.573486328125}</string>
+ <string>{101, 428.573486328125}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{193, 89}, {195, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>YES</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>224</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKxdTVVBQT1JURUQvTk9UX1NVUFBPUlRFRIaE
+ AmlJAReShISEDE5TRGljdGlvbmFyeQCUhAFpA5KElpYH
+ TlNDb2xvcoaShISEB05TQ29sb3IAlIQBYwOEAmZmAINm
+ ZiY/hpKElpYQTlNQYXJhZ3JhcGhTdHlsZYaShISEEE5T
+ UGFyYWdyYXBoU3R5bGUAlIQEQ0NAUwIAhISEB05TQXJy
+ YXkAlJkMkoSEhAlOU1RleHRUYWIAlIQCQ2YAHIaShKKh
+ ADiGkoSioQBUhpKEoqEAcIaShKKhAIGMAIaShKKhAIGo
+ AIaShKKhAIHEAIaShKKhAIHgAIaShKKhAIH8AIaShKKh
+ AIEYAYaShKKhAIE0AYaShKKhAIFQAYaGgQAIhARbMWZd
+ g83MTD2GkoSWlgZOU0ZvbnSGkoSEhAZOU0ZvbnQelJkc
+ hAVbMjhjXQYAAAAUAAAA//5IAGUAbAB2AGUAdABpAGMA
+ YQCEAWYMmwCbAZsAmwCGhoY=
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 SUPPORTED/NOT_SUPPORTED}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>23</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ <key>Wrap</key>
+ <string>NO</string>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{117.6875, 51.2867431640625}, {339, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>222</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKxRpc0JpbGxpbmdTdXBwb3J0ZWQoKYaEAmlJ
+ ARSShISEDE5TRGljdGlvbmFyeQCUhAFpBJKElpYQTlNQ
+ YXJhZ3JhcGhTdHlsZYaShISEEE5TUGFyYWdyYXBoU3R5
+ bGUAlIQEQ0NAUwIAhISEB05TQXJyYXkAlJkMkoSEhAlO
+ U1RleHRUYWIAlIQCQ2YAHIaShJ+eADiGkoSfngBUhpKE
+ n54AcIaShJ+eAIGMAIaShJ+eAIGoAIaShJ+eAIHEAIaS
+ hJ+eAIHgAIaShJ+eAIH8AIaShJ+eAIEYAYaShJ+eAIE0
+ AYaShJ+eAIFQAYaGgQAIhARbMWZdg83MTD2GkoSWlgdO
+ U0NvbG9yhpKEhIQHTlNDb2xvcgCUhAFjA4QCZmYAg2Zm
+ Jj+GkoSWlgZOU0ZvbnSGkoSEhAZOU0ZvbnQelJkohAVb
+ NDBjXQYAAAAeAAAA//5IAGUAbAB2AGUAdABpAGMAYQAt
+ AEIAbwBsAGQAAACEAWYMoQChAaEAoQCGkoSWlg5OU09y
+ aWdpbmFsRm9udIaSr4aG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 isBillingSupported()}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>20</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>217</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{476.125, 548.6573486328125}</string>
+ <string>{345.375, 548.6573486328125}</string>
+ <string>{102.375, 548.6573486328125}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>Pattern</key>
+ <integer>1</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{202.25, 480}, {174, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>YES</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>216</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKxxzdGFydEludGVudFNlbmRlckZvclJlc3Vs
+ dCgphoQCaUkBG5KEhIQMTlNEaWN0aW9uYXJ5AJSEAWkE
+ koSWlhBOU1BhcmFncmFwaFN0eWxlhpKEhIQQTlNQYXJh
+ Z3JhcGhTdHlsZQCUhARDQ0BTAgCEhIQHTlNBcnJheQCU
+ mQyShISECU5TVGV4dFRhYgCUhAJDZgAchpKEn54AOIaS
+ hJ+eAFSGkoSfngBwhpKEn54AgYwAhpKEn54AgagAhpKE
+ n54AgcQAhpKEn54AgeAAhpKEn54AgfwAhpKEn54AgRgB
+ hpKEn54AgTQBhpKEn54AgVABhoaBAAiEBFsxZl2DzcxM
+ PYaShJaWB05TQ29sb3KGkoSEhAdOU0NvbG9yAJSEAWMD
+ hAJmZgCDZmYmP4aShJaWBk5TRm9udIaShISEBk5TRm9u
+ dB6UmSiEBVs0MGNdBgAAAB4AAAD//kgAZQBsAHYAZQB0
+ AGkAYwBhAC0AQgBvAGwAZAAAAIQBZgyhAKEBoQChAIaS
+ hJaWDk5TT3JpZ2luYWxGb250hpKvhpcCAZKEmJkDkquS
+ rJKZkpqSrpKEsJkchAVbMjhjXQYAAAAUAAAA//5IAGUA
+ bAB2AGUAdABpAGMAYQClDKEAoQGhAKEAhoaG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 startIntentSenderForResult(
+\b0 )}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>27</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ <array>
+ <integer>27</integer>
+ <integer>1</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ <key>Wrap</key>
+ <string>NO</string>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{111.75, 510.6573486328125}, {352.25, 38}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>214</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBK0BCdW5kbGUoUkVTUE9OU0VfQ09ERSwgSU5B
+ UFBfUFVSQ0hBU0VfREFUQSwgSU5BUFBfREFUQV9TSUdO
+ QVRVUkUphoQCaUkBQJKEhIQMTlNEaWN0aW9uYXJ5AJSE
+ AWkDkoSWlgdOU0NvbG9yhpKEhIQHTlNDb2xvcgCUhAFj
+ A4QCZmYAg2ZmJj+GkoSWlhBOU1BhcmFncmFwaFN0eWxl
+ hpKEhIQQTlNQYXJhZ3JhcGhTdHlsZQCUhARDQ0BTAgCE
+ hIQHTlNBcnJheQCUmQyShISECU5TVGV4dFRhYgCUhAJD
+ ZgAchpKEoqEAOIaShKKhAFSGkoSioQBwhpKEoqEAgYwA
+ hpKEoqEAgagAhpKEoqEAgcQAhpKEoqEAgeAAhpKEoqEA
+ gfwAhpKEoqEAgRgBhpKEoqEAgTQBhpKEoqEAgVABhoaB
+ AAiEBFsxZl2DzcxMPYaShJaWBk5TRm9udIaShISEBk5T
+ Rm9udB6UmRyEBVsyOGNdBgAAABQAAAD//kgAZQBsAHYA
+ ZQB0AGkAYwBhAIQBZgybAJsBmwCbAIaGhg==
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 Bundle(RESPONSE_CODE, INAPP_PURCHASE_DATA, INAPP_DATA_SIGNATURE)}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>64</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{120.75, 405.57347106933594}, {331.5, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>212</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKyFCdW5kbGUoUkVTUE9OU0VfQ09ERSwgQlVZ
+ X0lOVEVOVCmGhAJpSQEhkoSEhAxOU0RpY3Rpb25hcnkA
+ lIQBaQOShJaWB05TQ29sb3KGkoSEhAdOU0NvbG9yAJSE
+ AWMDhAJmZgCDZmYmP4aShJaWEE5TUGFyYWdyYXBoU3R5
+ bGWGkoSEhBBOU1BhcmFncmFwaFN0eWxlAJSEBENDQFMC
+ AISEhAdOU0FycmF5AJSZDJKEhIQJTlNUZXh0VGFiAJSE
+ AkNmAByGkoSioQA4hpKEoqEAVIaShKKhAHCGkoSioQCB
+ jACGkoSioQCBqACGkoSioQCBxACGkoSioQCB4ACGkoSi
+ oQCB/ACGkoSioQCBGAGGkoSioQCBNAGGkoSioQCBUAGG
+ hoEACIQEWzFmXYPNzEw9hpKElpYGTlNGb250hpKEhIQG
+ TlNGb250HpSZHIQFWzI4Y10GAAAAFAAAAP/+SABlAGwA
+ dgBlAHQAaQBjAGEAhAFmDJsAmwGbAJsAhoaG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 Bundle(RESPONSE_CODE, BUY_INTENT)}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>33</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>211</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{102.5, 386.685302734375}</string>
+ <string>{473.5, 385.685302734375}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{169.75, 362.685302734375}, {239, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>210</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKw5nZXRCdXlJbnRlbnQoKYaEAmlJAQ6ShISE
+ DE5TRGljdGlvbmFyeQCUhAFpBJKElpYQTlNQYXJhZ3Jh
+ cGhTdHlsZYaShISEEE5TUGFyYWdyYXBoU3R5bGUAlIQE
+ Q0NAUwIAhISEB05TQXJyYXkAlJkMkoSEhAlOU1RleHRU
+ YWIAlIQCQ2YAHIaShJ+eADiGkoSfngBUhpKEn54AcIaS
+ hJ+eAIGMAIaShJ+eAIGoAIaShJ+eAIHEAIaShJ+eAIHg
+ AIaShJ+eAIH8AIaShJ+eAIEYAYaShJ+eAIE0AYaShJ+e
+ AIFQAYaGgQAIhARbMWZdg83MTD2GkoSWlgdOU0NvbG9y
+ hpKEhIQHTlNDb2xvcgCUhAFjA4QCZmYAg2ZmJj+GkoSW
+ lgZOU0ZvbnSGkoSEhAZOU0ZvbnQelJkohAVbNDBjXQYA
+ AAAeAAAA//5IAGUAbAB2AGUAdABpAGMAYQAtAEIAbwBs
+ AGQAAACEAWYMoQChAaEAoQCGkoSWlg5OU09yaWdpbmFs
+ Rm9udIaSr4aG
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 getBuyIntent()}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>14</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{161.5, 307.5}, {252, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>YES</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>208</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKyNCdW5kbGUoUkVTUE9OU0VfQ09ERSwgREVU
+ QUlMU19MSVNUKYaEAmlJASOShISEDE5TRGljdGlvbmFy
+ eQCUhAFpA5KElpYHTlNDb2xvcoaShISEB05TQ29sb3IA
+ lIQBYwOEAmZmAINmZiY/hpKElpYQTlNQYXJhZ3JhcGhT
+ dHlsZYaShISEEE5TUGFyYWdyYXBoU3R5bGUAlIQEQ0NA
+ UwIAhISEB05TQXJyYXkAlJkMkoSEhAlOU1RleHRUYWIA
+ lIQCQ2YAHIaShKKhADiGkoSioQBUhpKEoqEAcIaShKKh
+ AIGMAIaShKKhAIGoAIaShKKhAIHEAIaShKKhAIHgAIaS
+ hKKhAIH8AIaShKKhAIEYAYaShKKhAIE0AYaShKKhAIFQ
+ AYaGgQAIhARbMWZdg83MTD2GkoSWlgZOU0ZvbnSGkoSE
+ hAZOU0ZvbnQelJkchAVbMjhjXQYAAAAUAAAA//5IAGUA
+ bAB2AGUAdABpAGMAYQCEAWYMmwCbAZsAmwCGhoY=
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\fs24 \cf2 Bundle(RESPONSE_CODE, DETAILS_LIST)}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>35</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ <key>Wrap</key>
+ <string>NO</string>
+ </dict>
+ <dict>
+ <key>Class</key>
+ <string>LineGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>11</real>
+ </dict>
+ <key>ID</key>
+ <integer>206</integer>
+ <key>OrthogonalBarAutomatic</key>
+ <true/>
+ <key>OrthogonalBarPoint</key>
+ <string>{0, 0}</string>
+ <key>OrthogonalBarPosition</key>
+ <real>-1</real>
+ <key>Points</key>
+ <array>
+ <string>{103, 289.64337158203125}</string>
+ <string>{474, 288.64337158203125}</string>
+ </array>
+ <key>Style</key>
+ <dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.7</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>4</real>
+ <key>HeadArrow</key>
+ <string>FilledArrow</string>
+ <key>Legacy</key>
+ <true/>
+ <key>LineType</key>
+ <integer>2</integer>
+ <key>TailArrow</key>
+ <string>0</string>
+ </dict>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{117.6875, 267.86102294921875}, {339, 24}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FitText</key>
+ <string>Vertical</string>
+ <key>Flow</key>
+ <string>Resize</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.65</string>
+ <key>w</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>205</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Draws</key>
+ <string>NO</string>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>RTFD</key>
+ <data>
+ BAtzdHJlYW10eXBlZIHoA4QBQISEhBJOU0F0dHJpYnV0
+ ZWRTdHJpbmcAhIQITlNPYmplY3QAhZKEhIQITlNTdHJp
+ bmcBlIQBKw9nZXRTa3VEZXRhaWxzKCmGhAJpSQEPkoSE
+ hAxOU0RpY3Rpb25hcnkAlIQBaQSShJaWEE5TUGFyYWdy
+ YXBoU3R5bGWGkoSEhBBOU1BhcmFncmFwaFN0eWxlAJSE
+ BENDQFMCAISEhAdOU0FycmF5AJSZDJKEhIQJTlNUZXh0
+ VGFiAJSEAkNmAByGkoSfngA4hpKEn54AVIaShJ+eAHCG
+ koSfngCBjACGkoSfngCBqACGkoSfngCBxACGkoSfngCB
+ 4ACGkoSfngCB/ACGkoSfngCBGAGGkoSfngCBNAGGkoSf
+ ngCBUAGGhoEACIQEWzFmXYPNzEw9hpKElpYHTlNDb2xv
+ coaShISEB05TQ29sb3IAlIQBYwOEAmZmAINmZiY/hpKE
+ lpYGTlNGb250hpKEhIQGTlNGb250HpSZKIQFWzQwY10G
+ AAAAHgAAAP/+SABlAGwAdgBlAHQAaQBjAGEALQBCAG8A
+ bABkAAAAhAFmDKEAoQGhAKEAhpKElpYOTlNPcmlnaW5h
+ bEZvbnSGkq+Ghg==
+ </data>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc
+
+\f0\b\fs24 \cf2 getSkuDetails()}</string>
+ <key>alpha</key>
+ <array>
+ <array>
+ <integer>0</integer>
+ <integer>15</integer>
+ <real>0.64999997615814209</real>
+ </array>
+ </array>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{475.49999999999994, 47}, {80.185199999999995, 530}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans-Bold</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>200</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{1, 1}</string>
+ <string>{1, -1}</string>
+ <string>{-1, -1}</string>
+ <string>{-1, 1}</string>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ <string>{-0.5, -0.233518}</string>
+ <string>{-0.49144199999999999, 0.26006299999999999}</string>
+ <string>{0.50711799999999996, -0.22408600000000001}</string>
+ <string>{0.50711799999999996, 0.267179}</string>
+ <string>{-0.27431, -0.474028}</string>
+ <string>{0.27977999999999997, -0.47847800000000001}</string>
+ <string>{0.29393799999999998, 0.54304399999999997}</string>
+ <string>{-0.28623199999999999, 0.55380399999999996}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.874135</string>
+ <key>r</key>
+ <string>0.71718</string>
+ </dict>
+ <key>FillType</key>
+ <integer>2</integer>
+ <key>GradientAngle</key>
+ <real>90</real>
+ <key>GradientColor</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.662438</string>
+ <key>r</key>
+ <string>0.464468</string>
+ </dict>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.35</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Fuzziness</key>
+ <real>2.3972222805023193</real>
+ <key>ShadowVector</key>
+ <string>{0, 1}</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0.93512</string>
+ <key>g</key>
+ <string>0.472602</string>
+ <key>r</key>
+ <string>0.333854</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>3</real>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc
+
+\f0\b\fs24 \cf0 Google\
+Play App}</string>
+ <key>VerticalPad</key>
+ <integer>0</integer>
+ </dict>
+ </dict>
+ <dict>
+ <key>Bounds</key>
+ <string>{{22.814800000000005, 47}, {80.185199999999995, 530}}</string>
+ <key>Class</key>
+ <string>ShapedGraphic</string>
+ <key>FontInfo</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Font</key>
+ <string>DroidSans-Bold</string>
+ <key>Size</key>
+ <real>10</real>
+ </dict>
+ <key>ID</key>
+ <integer>157</integer>
+ <key>Magnets</key>
+ <array>
+ <string>{1, 1}</string>
+ <string>{1, -1}</string>
+ <string>{-1, -1}</string>
+ <string>{-1, 1}</string>
+ <string>{0, 1}</string>
+ <string>{0, -1}</string>
+ <string>{1, 0}</string>
+ <string>{-1, 0}</string>
+ <string>{-0.5, -0.233518}</string>
+ <string>{-0.49144199999999999, 0.26006299999999999}</string>
+ <string>{0.50711799999999996, -0.22408600000000001}</string>
+ <string>{0.50711799999999996, 0.267179}</string>
+ <string>{-0.27431, -0.474028}</string>
+ <string>{0.27977999999999997, -0.47847800000000001}</string>
+ <string>{0.29393799999999998, 0.54304399999999997}</string>
+ <string>{-0.28623199999999999, 0.55380399999999996}</string>
+ </array>
+ <key>Shape</key>
+ <string>Rectangle</string>
+ <key>Style</key>
+ <dict>
+ <key>fill</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.874135</string>
+ <key>r</key>
+ <string>0.71718</string>
+ </dict>
+ <key>FillType</key>
+ <integer>2</integer>
+ <key>GradientAngle</key>
+ <real>90</real>
+ <key>GradientColor</key>
+ <dict>
+ <key>b</key>
+ <string>1</string>
+ <key>g</key>
+ <string>0.662438</string>
+ <key>r</key>
+ <string>0.464468</string>
+ </dict>
+ </dict>
+ <key>shadow</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>a</key>
+ <string>0.35</string>
+ <key>b</key>
+ <string>0</string>
+ <key>g</key>
+ <string>0</string>
+ <key>r</key>
+ <string>0</string>
+ </dict>
+ <key>Fuzziness</key>
+ <real>2.3972222805023193</real>
+ <key>ShadowVector</key>
+ <string>{0, 1}</string>
+ </dict>
+ <key>stroke</key>
+ <dict>
+ <key>Color</key>
+ <dict>
+ <key>b</key>
+ <string>0.93512</string>
+ <key>g</key>
+ <string>0.472602</string>
+ <key>r</key>
+ <string>0.333854</string>
+ </dict>
+ <key>CornerRadius</key>
+ <real>3</real>
+ </dict>
+ </dict>
+ <key>Text</key>
+ <dict>
+ <key>Text</key>
+ <string>{\rtf1\ansi\ansicpg1252\cocoartf1187\cocoasubrtf340
+\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;}
+\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc
+
+\f0\b\fs24 \cf0 Your \
+In-app Billing\
+Application}</string>
+ <key>VerticalPad</key>
+ <integer>0</integer>
+ </dict>
+ </dict>
+ </array>
+ <key>GridInfo</key>
+ <dict>
+ <key>ShowsGrid</key>
+ <string>YES</string>
+ </dict>
+ <key>GuidesLocked</key>
+ <string>NO</string>
+ <key>GuidesVisible</key>
+ <string>YES</string>
+ <key>HPages</key>
+ <integer>1</integer>
+ <key>ImageCounter</key>
+ <integer>1</integer>
+ <key>KeepToScale</key>
+ <false/>
+ <key>Layers</key>
+ <array>
+ <dict>
+ <key>Lock</key>
+ <string>NO</string>
+ <key>Name</key>
+ <string>Layer 1</string>
+ <key>Print</key>
+ <string>YES</string>
+ <key>View</key>
+ <string>YES</string>
+ </dict>
+ </array>
+ <key>LayoutInfo</key>
+ <dict>
+ <key>Animate</key>
+ <string>NO</string>
+ <key>circoMinDist</key>
+ <real>18</real>
+ <key>circoSeparation</key>
+ <real>0.0</real>
+ <key>layoutEngine</key>
+ <string>dot</string>
+ <key>neatoSeparation</key>
+ <real>0.0</real>
+ <key>twopiSeparation</key>
+ <real>0.0</real>
+ </dict>
+ <key>LinksVisible</key>
+ <string>NO</string>
+ <key>MagnetsVisible</key>
+ <string>NO</string>
+ <key>MasterSheets</key>
+ <array/>
+ <key>ModificationDate</key>
+ <string>2012-11-16 02:31:19 +0000</string>
+ <key>Modifier</key>
+ <string>Quddus Chong</string>
+ <key>NotesVisible</key>
+ <string>NO</string>
+ <key>Orientation</key>
+ <integer>2</integer>
+ <key>OriginVisible</key>
+ <string>NO</string>
+ <key>PageBreaks</key>
+ <string>YES</string>
+ <key>PrintInfo</key>
+ <dict>
+ <key>NSBottomMargin</key>
+ <array>
+ <string>float</string>
+ <string>41</string>
+ </array>
+ <key>NSHorizonalPagination</key>
+ <array>
+ <string>coded</string>
+ <string>BAtzdHJlYW10eXBlZIHoA4QBQISEhAhOU051bWJlcgCEhAdOU1ZhbHVlAISECE5TT2JqZWN0AIWEASqEhAFxlwCG</string>
+ </array>
+ <key>NSLeftMargin</key>
+ <array>
+ <string>float</string>
+ <string>18</string>
+ </array>
+ <key>NSPaperSize</key>
+ <array>
+ <string>size</string>
+ <string>{612, 792}</string>
+ </array>
+ <key>NSPrintReverseOrientation</key>
+ <array>
+ <string>int</string>
+ <string>0</string>
+ </array>
+ <key>NSRightMargin</key>
+ <array>
+ <string>float</string>
+ <string>18</string>
+ </array>
+ <key>NSTopMargin</key>
+ <array>
+ <string>float</string>
+ <string>18</string>
+ </array>
+ </dict>
+ <key>PrintOnePage</key>
+ <false/>
+ <key>ReadOnly</key>
+ <string>NO</string>
+ <key>RowAlign</key>
+ <integer>1</integer>
+ <key>RowSpacing</key>
+ <real>36</real>
+ <key>SheetTitle</key>
+ <string>Canvas 1</string>
+ <key>SmartAlignmentGuidesActive</key>
+ <string>YES</string>
+ <key>SmartDistanceGuidesActive</key>
+ <string>YES</string>
+ <key>UniqueID</key>
+ <integer>1</integer>
+ <key>UseEntirePage</key>
+ <false/>
+ <key>VPages</key>
+ <integer>1</integer>
+ <key>WindowInfo</key>
+ <dict>
+ <key>CurrentSheet</key>
+ <integer>0</integer>
+ <key>ExpandedCanvases</key>
+ <array>
+ <dict>
+ <key>name</key>
+ <string>Canvas 1</string>
+ </dict>
+ </array>
+ <key>Frame</key>
+ <string>{{122, 4}, {1093, 874}}</string>
+ <key>ListView</key>
+ <true/>
+ <key>OutlineWidth</key>
+ <integer>142</integer>
+ <key>RightSidebar</key>
+ <false/>
+ <key>ShowRuler</key>
+ <true/>
+ <key>Sidebar</key>
+ <true/>
+ <key>SidebarWidth</key>
+ <integer>120</integer>
+ <key>VisibleRegion</key>
+ <string>{{-184, 14}, {944, 719}}</string>
+ <key>Zoom</key>
+ <real>1</real>
+ <key>ZoomValues</key>
+ <array>
+ <array>
+ <string>Canvas 1</string>
+ <real>1</real>
+ <real>1</real>
+ </array>
+ </array>
+ </dict>
+</dict>
+</plist>
OSDN Git Service
