diff options
author | Bill Gruber <billg@google.com> | 2011-06-29 10:17:19 -0700 |
---|---|---|
committer | Bill Gruber <billg@google.com> | 2011-07-27 09:50:26 -0700 |
commit | 32db3fc25b1067accff8d4671d7a0a1428d4b546 (patch) | |
tree | 2257675043db6ec49db5a24880c2f727a75000cf /docs | |
parent | a94b9ad23ac1f281c9d2dac02d01aa07ca5e1682 (diff) | |
download | frameworks_base-32db3fc25b1067accff8d4671d7a0a1428d4b546.zip frameworks_base-32db3fc25b1067accff8d4671d7a0a1428d4b546.tar.gz frameworks_base-32db3fc25b1067accff8d4671d7a0a1428d4b546.tar.bz2 |
Cherry pick from Honeycomb-mr2 Change ID I6ba2dca8606cdd4608d42f219b115536facf099f
IAB docs: fixes and updates
Change-Id: I0a9d782a83ca16b27c3e90f7bfc19bb9bca5e908
Diffstat (limited to 'docs')
-rw-r--r-- | docs/html/guide/guide_toc.cs | 3 | ||||
-rw-r--r-- | docs/html/guide/market/billing/billing_about.html | 12 | ||||
-rwxr-xr-x | docs/html/guide/market/billing/billing_about.jd | 30 | ||||
-rwxr-xr-x | docs/html/guide/market/billing/billing_admin.jd | 5 | ||||
-rwxr-xr-x | docs/html/guide/market/billing/billing_integrate.jd | 27 | ||||
-rwxr-xr-x | docs/html/guide/market/billing/billing_overview.jd | 74 | ||||
-rwxr-xr-x | docs/html/guide/market/billing/billing_testing.jd | 10 |
7 files changed, 97 insertions, 64 deletions
diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index f7dbe30..ddfeb61 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -383,9 +383,6 @@ <span class="en">In-app Billing</span></a> </div> <ul> - <li><a href="<?cs var:toroot?>guide/market/billing/billing_about.html"> - <span class="en">About this Release</span></a> - </li> <li><a href="<?cs var:toroot?>guide/market/billing/billing_overview.html"> <span class="en">In-app Billing Overview</span></a> </li> diff --git a/docs/html/guide/market/billing/billing_about.html b/docs/html/guide/market/billing/billing_about.html new file mode 100644 index 0000000..d8395df --- /dev/null +++ b/docs/html/guide/market/billing/billing_about.html @@ -0,0 +1,12 @@ +<html> +<head> +<meta http-equiv="refresh" +content="0;url=http://developer.android.com/guide/market/billing/index.html"> +<title>Redirecting...</title> +</head> +<body> +<p>You should be redirected. Please <a +href="http://developer.android.com/guide/market/billing/index.html">click +here</a>.</p> +</body> +</html>
\ No newline at end of file diff --git a/docs/html/guide/market/billing/billing_about.jd b/docs/html/guide/market/billing/billing_about.jd deleted file mode 100755 index 5924170..0000000 --- a/docs/html/guide/market/billing/billing_about.jd +++ /dev/null @@ -1,30 +0,0 @@ -page.title=About this Release -parent.title=In-app Billing -parent.link=index.html -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - <h2>In this document</h2> - <ol> - <li><a href="#billing-about">About this Release</a></li> - </ol> - <h2>Downloads</h2> - <ol> - <li><a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">Sample Application</a></li> - </ol> - <h2>See also</h2> - <ol> - <li><a href="{@docRoot}guide/market/billing/billing_overview.html">Overview of In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_integrate.html">Implementing In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and Design</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_testing.html">Testing In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_admin.html">Administering In-app Billing</a></li> - <li><a href="{@docRoot}guide/market/billing/billing_reference.html">In-app Billing Reference</a></li> - </ol> -</div> -</div> - -<p>Android Market In-app Billing has reached the final launch milestone and is now available to developers and users. You can now publish applications that use Android Market's in-app billing service, and users can make in-app purchases. To find out how to implement in-app billing in your applications, see the <a href="{@docRoot}guide/market/billing/index.html">documentation</a> and the <a href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample application</a>.</p> - - diff --git a/docs/html/guide/market/billing/billing_admin.jd b/docs/html/guide/market/billing/billing_admin.jd index 939bbaa..cbb4b29 100755 --- a/docs/html/guide/market/billing/billing_admin.jd +++ b/docs/html/guide/market/billing/billing_admin.jd @@ -202,6 +202,11 @@ 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> +<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-testing-setup">Setting Up Test Accounts</h2> <p>The Android Market publisher site lets you set up one or more test accounts. A test account is a diff --git a/docs/html/guide/market/billing/billing_integrate.jd b/docs/html/guide/market/billing/billing_integrate.jd index 1a1f02a..3eebd59 100755 --- a/docs/html/guide/market/billing/billing_integrate.jd +++ b/docs/html/guide/market/billing/billing_integrate.jd @@ -783,11 +783,17 @@ request identifier for the request.</p> <code>RESPONSE_CODE</code> broadcast intent. This broadcast intent provides status and error information about the request.</p> -<p class="note"><strong>Note:</strong> As a best practice, you should not send a -<code>CONFIRM_NOTIFICATIONS</code> request for a purchased item until you have delivered the item to -the user. This way, if your application crashes or something else prevents your application from -delivering the product, your application will still receive an <code>IN_APP_NOTIFY</code> broadcast -intent from Android Market indicating that you need to deliver the product.</p> +<p>You must send a confirmation when you receive transaction information from Android Market. If you +don't send a confirmation message, Android Market will continue sending +<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 Android Market indicating +that you need to deliver the product.</p> <h4>Restoring transaction information (RESTORE_TRANSACTIONS)</h4> @@ -828,6 +834,10 @@ message contains the detailed transaction information. The transaction informati 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 @@ -1061,7 +1071,12 @@ practices, see <a href="{@docRoot}guide/market/billing/billing_best_practices.ht 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.</p> +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> diff --git a/docs/html/guide/market/billing/billing_overview.jd b/docs/html/guide/market/billing/billing_overview.jd index a42b772..8f9fd4c 100755 --- a/docs/html/guide/market/billing/billing_overview.jd +++ b/docs/html/guide/market/billing/billing_overview.jd @@ -257,7 +257,10 @@ broadcast intents that are sent for every request.</p> <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.</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), Android Market sends your application a notification message (an <code>IN_APP_NOTIFY</code> broadcast intent). The notification message includes a notification ID, @@ -276,14 +279,21 @@ broadcast intents that are sent for every request.</p> <code>RESPONSE_CODE</code> key and a <code>REQUEST_ID</code> key.</li> </ol> -<p class="note"><strong>Note:</strong> You must launch the pending intent from an activity context -and not an application context.</p> - <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 Android +Market (step 8 in figure 2). If you don't send a confirmation message, Android Market will +continue sending <code>IN_APP_NOTIFY</code> messages for the transactions you have not +confirmed. As a best practice, you should not send a <code>CONFIRM_NOTIFICATIONS</code> request for +a purchased item until you have delivered the item to the user. This way, if your application +crashes or something else prevents your application from delivering the product, your application +will still receive an <code>IN_APP_NOTIFY</code> broadcast intent from Android Market indicating +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> @@ -308,6 +318,10 @@ pertains to.</p> information that is sent during a purchase request, although 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> @@ -335,21 +349,32 @@ purchase has changed. To retrieve the details of that purchase, your application <code>GET_PURCHASE_INFORMATION</code> request. Android Market responds with a <code>PURCHASE_STATE_CHANGED</code> broadcast intent, which contains the details of the purchase state change. Your application then sends a <code>CONFIRM_NOTIFICATIONS</code> message, informing -Android Market that you've received the purchase state change information.</p> - -<p>When Android Market receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given message, it -usually stops sending <code>IN_APP_NOTIFY</code> intents for that message. However, there are some -cases where Android Market may send repeated <code>IN_APP_NOTIFY</code> intents for a message even -though your application has sent a <code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a -device loses network connectivity while you are sending the <code>CONFIRM_NOTIFICATIONS</code> -message. In this case, Android Market 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 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> - -<p>There are two cases where your application may also receive <code>IN_APP_NOTIFY</code> broadcast +Android Market 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 Android Market receives a <code>CONFIRM_NOTIFICATIONS</code> message for a given +<code>PURCHASE_STATE_CHANGED</code> message, it usually stops sending <code>IN_APP_NOTIFY</code> +intents for that <code>PURCHASE_STATE_CHANGED</code> message. Sometimes, however, Android +Market may send repeated <code>IN_APP_NOTIFY</code> intents for a +<code>PURCHASE_STATE_CHANGED</code> message even though your application has sent a +<code>CONFIRM_NOTIFICATIONS</code> message. This can occur if a device loses network connectivity +while you are sending the <code>CONFIRM_NOTIFICATIONS</code> message. In this case, Android Market +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 @@ -359,11 +384,11 @@ 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> + <strong>Figure 5.</strong> Message sequence for refunds and other unsolicited +IN_APP_NOTIFY messages.</p> </div> -<p>In the first case, your application can receive an <code>IN_APP_NOTIFY</code> broadcast intent +<p>In the first case, your application may receive an <code>IN_APP_NOTIFY</code> broadcast intent when a user has your application installed on two (or more) devices and the user makes an in-app purchase from one of the devices. In this case, Android Market sends an <code>IN_APP_NOTIFY</code> message to the second device, informing the application that there is a purchase state change. Your @@ -384,6 +409,11 @@ refunded. The refund information is included in the JSON string that accompanies <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, diff --git a/docs/html/guide/market/billing/billing_testing.jd b/docs/html/guide/market/billing/billing_testing.jd index 84d25b2..5453047 100755 --- a/docs/html/guide/market/billing/billing_testing.jd +++ b/docs/html/guide/market/billing/billing_testing.jd @@ -211,7 +211,8 @@ experience, including the actual responses from Android Market and the actual ch users will experience in your application.</p> <p class="note"><strong>Note</strong>: You do not need to publish your application to do end-to-end -testing. You only need to upload your draft application to perform end-to-end testing.</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 register at least one test account on the Android Market publisher site. You cannot use your @@ -233,8 +234,11 @@ actual payouts to your merchant account.</p> <ol> <li><strong>Upload your application as a draft application to the publisher site.</strong> <p>You do not need to publish your application to perform end-to-end testing with real product - IDs. To learn how to upload an application to Android Market, see <a - href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading + IDs; you only need to upload your application as a draft application. However, you must sign + your application with your release key before you upload it as a draft application. Also, the + version number of the uploaded application must match the version number of the application you + load to your device for testing. To learn how to upload an application to Android Market, see + <a href="http://market.android.com/support/bin/answer.py?answer=113469">Uploading applications</a>.</p> </li> <li><strong>Add items to the application's product list.</strong> |