You should be redirected. Please click +here.
+ + \ 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 5924170bb8339..0000000000000 --- 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 - -In this document
- -Downloads
- -See also
- -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 documentation and the sample application.
- - diff --git a/docs/html/guide/market/billing/billing_admin.jd b/docs/html/guide/market/billing/billing_admin.jd index 939bbaa03e680..cbb4b29cfc475 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 and In-app Billing Pricing. +Important: 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.
+Setting Up Test Accounts
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 1a1f02a346887..3eebd595a492d 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.
RESPONSE_CODE broadcast intent. This broadcast intent provides status and error
information about the request.
-Note: As a best practice, you should not send a
-CONFIRM_NOTIFICATIONS request for a purchased item until you have delivered the item to
-the user. This way, if your application crashes or something else prevents your application from
-delivering the product, your application will still receive an IN_APP_NOTIFY broadcast
-intent from Android Market indicating that you need to deliver the product.
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
+IN_APP_NOTIFY messages for the transactions you have not confirmed. Also,
+your application must be able to handle IN_APP_NOTIFY messages that contain multiple
+orders.
In addition, as a best practice, you should not send a CONFIRM_NOTIFICATIONS request
+for a purchased item until you have delivered the item to the user. This way, if your application
+crashes or something else prevents your application from delivering the product, your application
+will still receive an IN_APP_NOTIFY broadcast intent from Android Market indicating
+that you need to deliver the product.
Restoring transaction information (RESTORE_TRANSACTIONS)
@@ -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. +Note: You should use the RESTORE_TRANSACTIONS
+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.
Other service tasks
You may also want your {@link android.app.Service} to receive intent messages from your {@link @@ -1061,7 +1071,12 @@ practices, see Note: If you store any purchase information on a device, be sure to -encrypt the data and use a device-specific encryption key.
+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 data +backup 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 +RESTORE_TRANSACTIONS request type.
Creating a user interface for selecting items
diff --git a/docs/html/guide/market/billing/billing_overview.jd b/docs/html/guide/market/billing/billing_overview.jd index a42b772a2d57c..8f9fd4c616ccb 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.RESPONSE_CODE, PURCHASE_INTENT, and REQUEST_ID. The
PURCHASE_INTENT key provides a {@link android.app.PendingIntent}, which your
application uses to start the checkout UI for the given product ID.
- Note: You must launch the pending intent from an activity + context and not an application context.
+IN_APP_NOTIFY broadcast intent). The notification message includes a notification ID,
@@ -276,14 +279,21 @@ broadcast intents that are sent for every request.
RESPONSE_CODE key and a REQUEST_ID key.Note: You must launch the pending intent from an activity context -and not an application context.
-
Figure 2. Message sequence for a purchase request.
+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 IN_APP_NOTIFY messages for the transactions you have not
+confirmed. As a best practice, you should not send a CONFIRM_NOTIFICATIONS request for
+a purchased item until you have delivered the item to the user. This way, if your application
+crashes or something else prevents your application from delivering the product, your application
+will still receive an IN_APP_NOTIFY broadcast intent from Android Market indicating
+that you need to deliver the product. Also, as a best practice, your application must be able to
+handle IN_APP_NOTIFY messages that contain multiple orders.
The messaging sequence for a restore transaction request is shown in figure 3. Request types for
each sendBillingRequest() method are shown in bold, broadcast intents
are shown in italic. For clarity, figure 3 does not show the RESPONSE_CODE
@@ -308,6 +318,10 @@ pertains to.
CONFIRM_NOTIFICATIONS message.
+Note: You should use the RESTORE_TRANSACTIONS 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.
The messaging sequence for checking whether in-app billing is supported is shown in figure 4. The
request type for the sendBillingRequest() method is shown in bold.
GET_PURCHASE_INFORMATION request. Android Market responds with a
PURCHASE_STATE_CHANGED broadcast intent, which contains the details of the purchase
state change. Your application then sends a CONFIRM_NOTIFICATIONS message, informing
-Android Market that you've received the purchase state change information.
+Android Market that you have received the purchase state change information.
-When Android Market receives a CONFIRM_NOTIFICATIONS message for a given message, it
-usually stops sending IN_APP_NOTIFY intents for that message. However, there are some
-cases where Android Market may send repeated IN_APP_NOTIFY intents for a message even
-though your application has sent a CONFIRM_NOTIFICATIONS message. This can occur if a
-device loses network connectivity while you are sending the CONFIRM_NOTIFICATIONS
-message. In this case, Android Market might not receive your CONFIRM_NOTIFICATIONS
-message and it could send multiple IN_APP_NOTIFY messages until it receives
-acknowledgement that you received the message. Therefore, your application must be able to recognize
-that the subsequent IN_APP_NOTIFY messages are for a previously processed transaction.
-You can do this by checking the orderID that's contained in the JSON string because
-every transaction has a unique orderId.
In some special cases, you may receive multiple IN_APP_NOTIFY messages even though
+you have confirmed receipt of the purchase information, or you may receive
+IN_APP_NOTIFY messages for a purchase change even though you never initiated the
+purchase. Your application must handle both of these special cases.
There are two cases where your application may also receive IN_APP_NOTIFY broadcast
+
Handling multiple IN_APP_NOTIFY messages
+ +When Android Market receives a CONFIRM_NOTIFICATIONS message for a given
+PURCHASE_STATE_CHANGED message, it usually stops sending IN_APP_NOTIFY
+intents for that PURCHASE_STATE_CHANGED message. Sometimes, however, Android
+Market may send repeated IN_APP_NOTIFY intents for a
+PURCHASE_STATE_CHANGED message even though your application has sent a
+CONFIRM_NOTIFICATIONS message. This can occur if a device loses network connectivity
+while you are sending the CONFIRM_NOTIFICATIONS message. In this case, Android Market
+might not receive your CONFIRM_NOTIFICATIONS message and it could send multiple
+IN_APP_NOTIFY messages until it receives acknowledgement that you received the
+transaction message. Therefore, your application must be able to recognize that the subsequent
+IN_APP_NOTIFY messages are for a previously processed transaction. You can do this by
+checking the orderID that's contained in the JSON string because every transaction has
+a unique orderId.
Handling refunds and other unsolicited IN_APP_NOTIFY messages
+ +There are two cases where your application may receive IN_APP_NOTIFY broadcast
intents even though your application has not sent a REQUEST_PURCHASE message. Figure 5
shows the messaging sequence for both of these cases. Request types for each
sendBillingRequest() method are shown in bold, broadcast intents are
@@ -359,11 +384,11 @@ broadcast intents that are sent for every request.
- Figure 5. Message sequence for refunds and other unsolicited IN_APP_NOTIFY messages. -
+ Figure 5. Message sequence for refunds and other unsolicited +IN_APP_NOTIFY messages.In the first case, your application can receive an IN_APP_NOTIFY broadcast intent
+
In the first case, your application may receive an IN_APP_NOTIFY 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 IN_APP_NOTIFY
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
PURCHASE_STATE_CHANGED broadcast intent. Also, the purchaseState field in
the JSON string is set to 2.
Important: 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.
+Security Controls
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 84d25b2eb1dfd..5453047d96a83 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.
Note: 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.
+testing. You only need to upload your application as a draft application to perform end-to-end +testing.To test your in-app billing implementation with actual in-app purchases, you will need to register at least one test account on the Android Market publisher site. You cannot use your @@ -233,8 +234,11 @@ actual payouts to your merchant account.
- Upload your application as a draft application to the publisher site.
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 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 + Uploading applications.
- Add items to the application's product list.