Re: [android-developers] In App Billing - Signature Verification failed.
On Thursday, August 14, 2014 4:25:30 PM UTC-7, Kostya Vasilyev wrote: Or with the just updated Google Play app. Very likely. I have few a people telling me the version of Android Market on their phone doesn't support in app billing. Nathan -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] In App Billing - Signature Verification failed.
On Wednesday, August 13, 2014 9:14:29 PM UTC-7, Nikolay Elenkov wrote: On Thu, Aug 14, 2014 at 9:41 AM, Nathan nathan@gmail.com javascript: wrote: So why would Google Play send me a bogus signature? Its not the first Google glitch, but what can I or the customer do about it? Build a backup license restore method (using randomly generated license codes that your *own* server verifies, etc.). If a customer is having problems, send them a license code. Alternatively, if there is major breakage, modify your server to temporarily ignore signature verification failures. IAP breaks from time to time, has been that way for years. Not much you can do about it but add workarounds in your code. Unfortunately, I think you are right. Nathan -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] In App Billing - Signature Verification failed.
In addition, I wonder if it has anything to do with this spec: Kernel version: 3.4.0-cyanogenmod-g433243c build02@cyanogenmod ) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] In App Billing - Signature Verification failed.
Or with the just updated Google Play app. 15 авг. 2014 г. 3:11 пользователь Nathan nathan.d.mel...@gmail.com написал: In addition, I wonder if it has anything to do with this spec: Kernel version: 3.4.0-cyanogenmod-g433243c build02@cyanogenmod ) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] In App Billing - Signature Verification failed.
On Thu, Aug 14, 2014 at 9:41 AM, Nathan nathan.d.mel...@gmail.com wrote: So why would Google Play send me a bogus signature? Its not the first Google glitch, but what can I or the customer do about it? Build a backup license restore method (using randomly generated license codes that your *own* server verifies, etc.). If a customer is having problems, send them a license code. Alternatively, if there is major breakage, modify your server to temporarily ignore signature verification failures. IAP breaks from time to time, has been that way for years. Not much you can do about it but add workarounds in your code. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] In App Billing v3 questions
On Thu, Feb 28, 2013 at 1:34 PM, LostDev byron.k...@gmail.com wrote: Is there any easy way to maintain separation between the application and our billing library? Require the client activity to implement some interface and pass it as a parameter to your library's method's as needed. It doesn't really matter where you launch stuff from as long as it is using the right thread (UI thread) and context (the activity's). Additionally, you don't really need to use IabHelper at all, you can see what it does (basically connect to a remote service and call its methods, sometimes in a worker thread) and implement something similar. You can't skip the onActivityResult() part though. -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] In App Billing v3 questions
Nikolay, Thanks for your reply. Concerning running launchPurchaseFlow from the UI thread. The library we developed for IAB Version 2 runs in a separate thread as it handles numerous server connections before the purchase request is sent to Google, and after purchase results are received. Rather than change the architecture of the library, is it possible to run launchPurchaseFlow on the UI thread (from the library thread)? I recently discovered runOnUiThread() but am unsure if it is appropriate in this case. On Thursday, February 28, 2013 2:18:05 PM UTC+9, Nikolay Elenkov wrote: On Thu, Feb 28, 2013 at 1:34 PM, LostDev byron...@gmail.com javascript: wrote: Is there any easy way to maintain separation between the application and our billing library? Require the client activity to implement some interface and pass it as a parameter to your library's method's as needed. It doesn't really matter where you launch stuff from as long as it is using the right thread (UI thread) and context (the activity's). Additionally, you don't really need to use IabHelper at all, you can see what it does (basically connect to a remote service and call its methods, sometimes in a worker thread) and implement something similar. You can't skip the onActivityResult() part though. -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] In App Billing v3 questions
On Thu, Feb 28, 2013 at 3:26 PM, LostDev byron.k...@gmail.com wrote: The library we developed for IAB Version 2 runs in a separate thread as it handles numerous server connections before the purchase request is sent to Google, and after purchase results are received. Rather than change the architecture of the library, is it possible to run launchPurchaseFlow on the UI thread (from the library thread)? I recently discovered runOnUiThread() but am unsure if it is appropriate in this case. I haven't tried it, but probably. You can also use a Handler created on the UI thread to achieve the same thing. -- -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] In-App billing draft apk not appearing in Developer Console
On Fri, Dec 7, 2012 at 7:55 AM, jb cona...@gmail.com wrote: Hi, I'm trying to test In-App billing on my app. I registered a test account in my Google Play account. I uploaded a new, signed apk as an unpublish draft (I uploaded and saved, but did not publish) The VersionCode is greater than the published apk (49 vs 48) The VersionName is different than the published apk (1.1.20 vs 1.1.19) The new apk contains: com.android.vending.BILLING When I go back to the Developer Console screen, the draft apk does not appear, only the published apks are present. Am I missing a step? No, there is no special entry for draft APK and it cannot be downloaded via the Play Store. It just needs to be there so you can test the IAB flow. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App billing draft apk not appearing in Developer Console
Don't I need the draft present to add the IAP entry. Or do I add that to the existing published apk? On Thursday, December 6, 2012 5:22:10 PM UTC-8, Nikolay Elenkov wrote: On Fri, Dec 7, 2012 at 7:55 AM, jb con...@gmail.com javascript: wrote: Hi, I'm trying to test In-App billing on my app. I registered a test account in my Google Play account. I uploaded a new, signed apk as an unpublish draft (I uploaded and saved, but did not publish) The VersionCode is greater than the published apk (49 vs 48) The VersionName is different than the published apk (1.1.20 vs 1.1.19) The new apk contains: com.android.vending.BILLING When I go back to the Developer Console screen, the draft apk does not appear, only the published apks are present. Am I missing a step? No, there is no special entry for draft APK and it cannot be downloaded via the Play Store. It just needs to be there so you can test the IAB flow. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App billing draft apk not appearing in Developer Console
On Fri, Dec 7, 2012 at 10:29 AM, jb cona...@gmail.com wrote: Don't I need the draft present to add the IAP entry. Or do I add that to the existing published apk? Not sure what you mean? The draft APK needs to be there, it just won't show up on the main screen. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App billing draft apk not appearing in Developer Console
OK, I think I got it working. All I needed to do was to add my In-App Products to my published apk, and now I can get the information for the In-App Product, using my draft apk version. On Thursday, December 6, 2012 5:34:45 PM UTC-8, Nikolay Elenkov wrote: On Fri, Dec 7, 2012 at 10:29 AM, jb con...@gmail.com javascript: wrote: Don't I need the draft present to add the IAP entry. Or do I add that to the existing published apk? Not sure what you mean? The draft APK needs to be there, it just won't show up on the main screen. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing for canadian
Am 13.10.12 18:31, schrieb MathieuB: to look at implementing in-app billing, when I faced the fact that canadian CANNOT open google merchant account... I was a bit shocked. are you sure? In-app billing is available to developers in supported locations for merchants. https://support.google.com/googleplay/android-developer/bin/answer.py?hl=enanswer=1153481 Supported locations for merchants Currently, developers in the below countries may register as Google Checkout merchants and sell paid applications: Argentina* Australia Austria Belgium Brazil Canada ... https://support.google.com/googleplay/android-developer/bin/answer.py?hl=enanswer=150324 Ralph -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing for canadian
Thought the same thing when I read it, they said it clear. But when it's time to open a google checkout account so I can receive money, it says only available to US and UK... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing for canadian
Am 14.10.12 19:41, schrieb MathieuB: Thought the same thing when I read it, they said it clear. But when it's time to open a google checkout account so I can receive money, it says only available to US and UK... I have a account in Germany, I think there is something else wrong :-( Ralph -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing for canadian
You mean you have a google checkout merchant account? And you register for in-app billing? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App Billing Example (Dungeons) does not increment purchases.
You will probably want to implement your own purchase tracking mechanism, for security / obfuscation if nothing else. -- K 2012/10/4 Escape Radius i...@escaperadius.com I've successfully tested the in-app billing example, Dungeons, and have observed an apparent error in its implementation (or in the documentation). In PurchaseDatabase.java the insertOrder method does not insert multiple rows in the table as the documentation points out: * Inserts a purchased product into the database. There may be multiple * rows in the table for the same product if it was purchased multiple times * or if it was refunded. I expected the purchase counter to increment every time I made a test purchase, but because the HISTORY_ORDER_ID_COL is defined as the primary key, multiple purchases of the same test product will NOT add a row, it simply updates the current row's information. In order to keep track of purchases, the primary key should be unique, ideally an auto-incremented integer. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing
I have tried the checkout API and that's working for my in app billing purchase. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing
Nope. The receipt has to be sent by the device Sent from my Nexus S On Jun 13, 2012 12:13 AM, John jo-d...@hotmail.com wrote: We are going to use in app billing to set up a system where content is delivered from our server, once the user purchases an in app feature. Does anyone know if there is an official way, that our server can contact Google's server to get a receipt of purchase, rather than trusting the user's device? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing
What about through Google Checkout? Do inapp Purchases go through Google Checkout? I notice that there is an API to get purchase information thereon. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing
Couldnt you send the signed/returned JSON data string object to a remote database and keep/use that as a record of purchase? I seem to recall something like this being suggested in the developer guide or a tutorial. On Tuesday, June 12, 2012 4:18:01 PM UTC-4, John wrote: What about through Google Checkout? Do inapp Purchases go through Google Checkout? I notice that there is an API to get purchase information thereon. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing
Yes. I am keeping the data in a database. But the question here is what happens if my private key gets hacked. Then I cannot trust the data from the client. Also, the Google Checkout has more data, such as purchase price, that the client doesn't provide to me. On Tuesday, June 12, 2012 3:10:09 PM UTC-6, kadmos wrote: Couldnt you send the signed/returned JSON data string object to a remote database and keep/use that as a record of purchase? I seem to recall something like this being suggested in the developer guide or a tutorial. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing
On Wed, Jun 13, 2012 at 7:05 AM, John jo-d...@hotmail.com wrote: Yes. I am keeping the data in a database. But the question here is what happens if my private key gets hacked. Then I cannot trust the data from the client. Your private key is kept on Google Checkout servers, so the chance of it being 'hacked' is very small. Also, the Google Checkout has more data, such as purchase price, that the client doesn't provide to me. The Checkout API is not available everywhere, but if you can get a merchant key (IIRC the name) you could probably use it. Try it out and report back here :) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App Billing Tracking By Android Market
On Tue, Jan 31, 2012 at 8:49 AM, beachboy jfma...@gmail.com wrote: how does the market know that I have unlocked these features and that the Lite version is really now the Paid version? It doesn't - *your app* would check if the user bought the unlock item and react accordingly. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing: Creating coupons ?
In-app billing does not allow free (of charge) items. You can refund a purchase once it's been completely processed (i.e. the money actually changed hands) and keep activation (it's up to the application code to treat refunded items as active: Dungeons does this). There is no expiration date either, although you could try unpublishing the item in the Dev Console - don't know if this affects existing transactions; it might. This assumes that the app does a restore transactions once in a while (which is subject to throttling on Google's side). Some similar requests for enhancements have been filed: http://code.google.com/p/marketbilling/issues/detail?id=12 http://code.google.com/p/marketbilling/issues/detail?id=3 ... but not specifically for coupon type functionality. You are welcome to do so (but I wonder if it makes any difference). At this time, I'd go with some other solution, perhaps an activator type application that could be installed alongside the main one, and would talk to your own server. -- Kostya 08.11.2011 0:38, androidmediadeveloper пишет: We want the ability to setup a beta program for our pro app, which uses in-app billing. I am exploring the possibility of giving our beta testers access to the pro features on the app for free for a limited amount of time, i.e., until we ship it in public. Was wondering if there is a way to generate and issue something like a coupon which can be redeemed by the beta tester to access the pro features. And, for us as developers to have a way to put an expiry on the access acquired via the coupon. Thanks! -- Kostya Vasilyev -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app Billing - not working on 1.6 2.1
2011/10/5 Sheado chad...@gmail.com Hello, In-app billing doesn't seem to be working on 1.6 2.1. I'm testing with the Dungeons sample app and purchasing android.test.purchased. Same issue in my own app. I just ran a quick test on a 2.0.1 device, and it worked - for an app that's in production, with an already purchased item (so this test confirmed restore transactions, not a new order). Is billing unstable for those versions? Should I remove billing for 1.6 2.1 devices? Thanks! -Chad -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app Billing - not working on 1.6 2.1
Thanks for double-checking. For me, some of the transactions are working, such as the purchase request. The purchase confirmation is never completing though. I don't want to take any chances with our users, so I'm going to remove the feature for =2.1 for now. -Chad On Wed, Oct 5, 2011 at 2:19 AM, Kostya Vasilyev kmans...@gmail.com wrote: 2011/10/5 Sheado chad...@gmail.com Hello, In-app billing doesn't seem to be working on 1.6 2.1. I'm testing with the Dungeons sample app and purchasing android.test.purchased. Same issue in my own app. I just ran a quick test on a 2.0.1 device, and it worked - for an app that's in production, with an already purchased item (so this test confirmed restore transactions, not a new order). Is billing unstable for those versions? Should I remove billing for 1.6 2.1 devices? Thanks! -Chad -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App Billing forces screen orientation change
On Thu, Aug 25, 2011 at 5:37 PM, groob krzysztof.grobe...@gmail.com wrote: Does anyone ever met similar behaviour? Yes, this is how Android works. Anyone knows the solution? Solution to what? You didn't state a problem. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing. How to store information about transactions of unmanaged products?
On Thu, Jul 14, 2011 at 10:59 PM, Mc Bell mobidevpublis...@gmail.com wrote: The problem is that I can have different additional information for similar products. So if something went wrong with the purchasing process (for example network connetion was down) and I have queued some orders on Market, I need to know exactly what order associated with additional information. Use REQUEST_ID to link orders to your custom information? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App billing, just 3 lines and integrate your app
On Sun, Jun 26, 2011 at 12:41 PM, MCON Dev mcon...@gmail.com wrote: I hope google makes it a bit easier to integrate in app billing in the future. It took me sometime to get this working. And with this blog I hope to make it easier for folks out there. You missed the link :) While some people may find this helpful, it's just a bunch of steps without any real explanation of what and why is being done. So even if someone gets it work by some chance, they will have no idea how to fix it when it breaks or change it to suit their needs. And then we get the 'plz hlp is URGENT' mails in here... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App Billing
Yeah, that link is broken for me as well, but your second link is actually the same help content, just linked differently. The Droid Incredible is about a year old, there is no way it could have Market 2.3 in its original firmware, as that only started to show up in February (IIRC) of this year. Have you tried the procedure explained in Google's help document, to let Market update? -- Kostya 2011/6/20 Ryan Mattison rmattis...@gmail.com Hello, I'm currently looking at using the in-app billing process, and a few things worry me. On - http://developer.android.com/guide/market/billing/billing_overview.html If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of the MyApps application. If your device is running any other version of Android, in-app billing requires version 2.3.4 (or higher) of the Android Market application. I'm running a relatively new Droid Incredible -- version of the Market Place (2.2.6). This doesn't appear to meet the requirements for In- App billing. On - https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=190860 Selecting the upgrade Android Market link, it leads me to Page Not Available. ... This looks like a huge issue for people that are attempting to use the InApp billing process. It says that my Market is supposed to be automatically keeping itself up-to-date - https://market.android.com/support/bin/answer.py?answer=190860 My question being, what percent of Android Phones actually support the InApp billing process? Thanks, Ryan -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing - REQUEST_ITEM_UNAVAILABLE
Have you published the item in your dev console?
*Thanks and Regards,
Kumar Bibek*
*
http://techdroid.kbeanie.com
http://www.kbeanie.com*
On Sat, Jun 18, 2011 at 11:25 PM, MCON Dev mcon...@gmail.com wrote:
I think I have things setup correctly, but I keep getting
REQUEST_ITEM_UNAVAILABLE.
DDMS reports the following
06-18 21:09:27.714: DEBUG/iDHaysbert(5449): ItemName : Hello(a)
SettingRingToneUri :
android.resource://com.haysbertv2/raw/hello3timescomeonpickupthephone2.mp3
PurchaseUri : hello3timescomeonpickupthephone2
06-18 21:09:27.714: DEBUG/iDHaysbert(5449): Sending Request id
hello3timescomeonpickupthephone2
06-18 21:09:27.722: DEBUG/iDHaysbert(5449): RequestPurchase
06-18 21:09:27.730: DEBUG/iDHaysbert(5449): request id: 7697028544955964412
06-18 21:09:30.323: INFO/iDHaysbert(5449): handleCommand() action:
com.android.vending.billing.RESPONSE_CODE
06-18 21:09:30.323: DEBUG/iDHaysbert(5449): Check response code
RequestPurchase: RESULT_ITEM_UNAVAILABLE
06-18 21:09:30.323: DEBUG/iDHaysbert(5449): product id :
hello3timescomeonpickupthephone2: RESULT_ITEM_UNAVAILABLE
06-18 21:09:30.323: INFO/iDHaysbert(5449): purchase failed
06-18 21:09:30.339: DEBUG/iDHaysbert(5449):
hello3timescomeonpickupthephone2: request purchase returned
RESULT_ITEM_UNAVAILABLE
I have 2 email accounts (gmail). Account A is my primary account on my
device and my test account on my market account. Account B is owner
account on market.
I have a in app product hello3timescomeonpickupthephone2 with product id.
All checkout file is under com.mcondev.test package and not
com.example. (from the sample).
Changed the package of some Consts variables
// Intent actions that we send from the BillingReceiver to the
// BillingService. Defined by this application.
public static final String ACTION_CONFIRM_NOTIFICATION =
com.mcondev.test.CONFIRM_NOTIFICATION;
public static final String ACTION_GET_PURCHASE_INFORMATION =
com.mcondev.test.GET_PURCHASE_INFORMATION;
public static final String ACTION_RESTORE_TRANSACTIONS =
com.mcondev.test.RESTORE_TRANSACTIONS;
Android Manifest has
uses-permission android:name=android.permission.INTERNET /
!-- Required permission to use in-app billing. --
uses-permission android:name=com.android.vending.BILLING /
service android:name=com.mcondev.test.BillingService /
receiver android:name=com.mcondev.test.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
AIDL
package com.android.vending.billing;
import android.os.Bundle;
interface IMarketBillingService {
/** Given the arguments in bundle form, returns a bundle for results. */
Bundle sendBillingRequest(in Bundle bundle);
}
Const.java changes
public static final String MARKET_BILLING_SERVICE_ACTION =
com.android.vending.billing.MarketBillingService.BIND;
public static final String ACTION_CONFIRM_NOTIFICATION =
com.mcondev.test.CONFIRM_NOTIFICATION;
public static final String ACTION_GET_PURCHASE_INFORMATION =
com.mcondev.test.GET_PURCHASE_INFORMATION;
public static final String ACTION_RESTORE_TRANSACTIONS =
com.mcondev.test.RESTORE_TRANSACTIONS;
Refactored and merged Dungeons to CheckoutPurchaseObserver. Removed
CATALOG code. Here are pieces of code.
public CheckoutPurchaseObserver(Activity newActivity, Handler newHandler) {
super(newActivity, newHandler);
context = newActivity.getApplicationContext() ;
mHandler = newHandler ;
mPurchaseDatabase = new PurchaseDatabase(context);
mBillingService = new BillingService();
mBillingService.setContext(context);
// Check if billing is supported.
ResponseHandler.register(this);
if (!mBillingService.checkBillingSupported()) {
showDialog(DIALOG_CANNOT_CONNECT_ID);
}
}
public void sendCheckoutRequest(String itemId, String quantity) {
if (Consts.DEBUG)
Log.d(TAG, Sending Request id +itemId) ;
if (!mBillingService.requestPurchase(itemId, quantity)) {
showDialog(DIALOG_BILLING_NOT_SUPPORTED_ID);
}
}
. all checkoutpurchaseobserver code
}
Is there anything wrong with this refactor ?
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received
Re: [android-developers] in- app billing
On Tue, May 24, 2011 at 4:59 AM, Mithun mithunsmur...@gmail.com wrote: 1. is it possible for me to control the pricing using 'in-app billing' ? No. 2. once i publish the app, is it possible to change the price? Yes. Don't make it free though - then there's no going back. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing and Google Checkout setup
Jeremy, Your screenshot doesn't have the lower part with timestamps, so I can't be sure, but... This is the initial state of new orders, which then changes automatically to something like: *Charge order:* Amount charged: $1.75 | Refund some money... *Shipment:* Confirmation sent on May 3, 2011 The bottom of the page, at this time, starts looking like this: *Order history* May 3 5:18 AM Order shipped You shipped this order. May 3 5:18 AM Order charged The customer's credit card was successfully charged for $1.75. May 3 5:18 AM Charge initiated You initiated a charge of $1.75 to the customer's credit card. May 3 2:38 AM Authorization successful The customer's credit card was authorized for $1.75, and passed all risk checks. (Expires May 10, 2011 2:38:26 AM GMT+01:00) May 3 2:38 AM Order received You received a new order. Google has sent the customer an order confirmation email. Note the amount of time that passes. -- Kostya 03.05.2011 23:02, JeremyChase ?: Hi - I've published an app that uses in-app billing and am having problems with Google Checkout. For one thing, I have it setup to send me an email when a purchase happens, but I am not receiving an email notification. Also, the 'Charge order' button is grayed out and the orders are showing as Not yet shipped. Do I have Checkout configured wrong? How do you have this setup? This is what I'm seeing in Google Checkout: https://img.skitch.com/20110503-p23k8uy5thqcfmdewyx2tty15k.png Thank you! Jeremy -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=eninline: checkmark.gif
Re: [android-developers] In-App Billing example service lifecycle
Mark, The calls to startService in BillingService are matched by stopSelf(), so that's not the cause. I believe this long-running service is caused by how the purchase activity starts the billing service: Dungeons.java mBillingService = new BillingService(); mBillingService.setContext(this); I don't see anything in the documentation to support that this is a proper way to start a service. Bug report: http://code.google.com/p/marketbilling/issues/detail?id=8 The call to unbindService in Dungeons.onDestroy is a bit of a red herring: The this in unbindService(this) is BillingService.this as a ServiceConnection. Therefore, the code unbinds the Vending service (inside Market) from the Billing service (inside the application), releasing the former, but does nothing to stop the latter. -- Kostya 19.04.2011 22:30, markusn82 пишет: Hi, I recently implemented In-App billing for an application and I used the Dungeons example as a starting point. I noticed that after leaving my application (onDestroy is called in the base stack activity), the BillingService service is still running on the phone and stays running long after. I made sure that I was unbinding from the BillingService service during onDestroy of my base activity. As I understand it, a service that is started with startService needs to be stopped with stopService/stopSelf, even if components bind/ unbind to it during its lifecycle (See http://developer.android.com/guide/topics/fundamentals/bound-services.html#Lifecycle). Does this mean that stopSelf should be called manually after calling unbindService() or should the service stop itself automatically? I looked further into the example code and saw that the BillingService service was being started with startService, but stopService/stopSelf was not being called ever. The call to stopSelf does exist in code but it is never executed during the lifecycle of the application. Does this indicate a bug in the example code or perhaps a bug in my usage. I noticed that the Dungeon example app itself also experiences the same problem (service still running after application exited). Any help would be appreciated. Thanks, Mark -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing refunds
Following up on in-app purchase refunds. The link to Refund some money... pointed out by TreKing becomes available after the order's financial transaction is completely settled. Make sense actually, because until then the money just isn't in the seller's account yet. -- Kostya 11.04.2011 20:20, Kostya Vasilyev ?: 11.04.2011 19:53, TreKing ?: On Mon, Apr 11, 2011 at 10:30 AM, Kostya Vasilyev kmans...@gmail.com mailto:kmans...@gmail.com wrote: Am I missing something? Anyone know where the Refund an order button is? I don't know if in-app billed stuff works different, but normally there's a Refund some money... option link to the left of that Cancel entire order button. Though it's poorly named as you can't refund some - it's all or nothing. There is - but it's grayed out. Also, with normal purchases, canceling and refunding is essentially the same. The documentation treats them differently, and so does the Dungeons sample. I was actually going to use that to issue a refund to a couple of people who helped me (with artwork and testing), seeing how the code treats Refunded as Purchased. The idea being that they would buy the in-app product, I would refund the purchase, and the app would keep working for them. The checkout window that the users see on the device tells them contact the developer for refunds. Canceling an order would refund the money, so at least that works, but keeping the app working would be a nice touch. Anyway. Filed a bug about this in the billing tracker. http://code.google.com/p/marketbilling/issues/detail?id=11 -- Kostya Vasilyev --http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing as a method of activating a trial feature?
I thought products with 0.00 were not allowed. The same for free products. Honestly, your best bet is probably using your own server. On Tue, Apr 12, 2011 at 6:05 PM, Zsolt Vasvari zvasv...@gmail.com wrote: I was thinking that I would allow my free app user's to have access to some portions of my app on a limited time trial basis. The biggest problem with this is that if the user uninstalls/ reinstalls, there doesn't seem to be a way of preventing them from restarting the trial period. I know I could put some file on the SD card and check for that, but that's trivial to defeat. The only way I could think of this is running a server side check, but that a) requires a server, b) requires the INTERNET permission. The in-app billing seems perfect for this. I could set up the trial as an item to purchase and Google will maintain for me the owners list. Does anybody have any opinion on this? What I need is to be able to set the price of item to $0.00 and have access to the purchase date. Is this doable? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- ~ Jeremiah:9:23-24 Android 2D MMORPG: http://solrpg.com/, http://www.youtube.com/user/revoltingx -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing refunds
On Mon, Apr 11, 2011 at 10:30 AM, Kostya Vasilyev kmans...@gmail.comwrote: Am I missing something? Anyone know where the Refund an order button is? I don't know if in-app billed stuff works different, but normally there's a Refund some money... option link to the left of that Cancel entire order button. Though it's poorly named as you can't refund some - it's all or nothing. Also, with normal purchases, canceling and refunding is essentially the same. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing refunds
11.04.2011 19:53, TreKing ?: On Mon, Apr 11, 2011 at 10:30 AM, Kostya Vasilyev kmans...@gmail.com mailto:kmans...@gmail.com wrote: Am I missing something? Anyone know where the Refund an order button is? I don't know if in-app billed stuff works different, but normally there's a Refund some money... option link to the left of that Cancel entire order button. Though it's poorly named as you can't refund some - it's all or nothing. There is - but it's grayed out. Also, with normal purchases, canceling and refunding is essentially the same. The documentation treats them differently, and so does the Dungeons sample. I was actually going to use that to issue a refund to a couple of people who helped me (with artwork and testing), seeing how the code treats Refunded as Purchased. The idea being that they would buy the in-app product, I would refund the purchase, and the app would keep working for them. The checkout window that the users see on the device tells them contact the developer for refunds. Canceling an order would refund the money, so at least that works, but keeping the app working would be a nice touch. Anyway. Filed a bug about this in the billing tracker. http://code.google.com/p/marketbilling/issues/detail?id=11 -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing problem
FWIW, It's still not working for me - although it worked fine two or three days ago. Same phone, same account, same modified Dungeons sample. In fact, I made no changes at all. Now purchases for android.test.* are sent to Market, but never get any response. This is as if I was running the unsigned debug build on my test phone, but I'm running a signed release build. I even tried removing and adding back the test account in Market profile, no change. They are presently rolling out per-country pricing for in-app billing, perhaps it's related. PS - I don't see a way to set country-specific prices in my console. All I see is USD with no way to choose another currency. Their email said available immediately. -- Kostya 09.04.2011 4:23, Seba ?: Hi Ivan/Kostya, I am having the exact same problem, and I am also seeing the same output regarding the GTalkService. Seba -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing problem
Ivan,
I have same exact setup, also Milestone 2.1.1, and the rest is the same.
Buying test items worked yesterday, but is not working now, same as for
you: the transaction never completes.
Looks like something in billing is just broken right now. I wonder how
well it's going to work in production.
BTW, when this happens, I also see logcat messages from GTalkService:
W/GTalkService( 1364): [DataMsgMgr] broadcast intent callback:
result=CANCELLED forIntent { act=android.intent.action.REMOTE_INTENT
cat=[*com.android.vending.billing.IN_APP_NOTIFY*] (has extras) }
W/GTalkService( 1364): TODO: implement reportNoReceiverError!
Are you seeing this too? I wonder why GTalkService gets billing
broadcasts, whether this is normal, and whether it aborts the broadcast
causing it to not be seen by the Dungeon's billing receiver.
-- Kostya
08.04.2011 13:14, Ivan ?:
Hi guys,
I'm trying to integrate in-app billing in an app but for some reason I
can't get the Dungeons sample app to work, even with static responses.
What I've done is:
- i've setup a publisher and merchant accounts
- copied my public key from publisher profile in
base64EncodedPublicKey in Security.java in Dungeons
- uploaded a signed apk and installed the same on my phone -
Motorola Milestone 2.1 with Market app 2.3.4
- using my developer's account and License Test Response is set to
Licensed on the phone
When I start the sample and select one of the static items - e.g.
android.test.purchased, the payment screen with a VISA xxx-FAKE opens,
but afterwards only shows Authorizing purchase and doesn't complete
and nothing shows up in Items you own.
Am I forgetting a step or my phone is the problem maybe? Do you have
any idea before I start debugging the issue?
Cheers,
Ivan
--
Kostya Vasilyev -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing problem
Hi Ivan/Kostya, I am having the exact same problem, and I am also seeing the same output regarding the GTalkService. Seba -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing problem
Hi Ivan/Kostya, I am having the exact same problem, and yes I am seeing the same output regarding the GTalkService. I will keep looking into it and see what happens. Good luck Seba -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In App Billing enhancement request
On 25 March 2011 02:41, Marcus Watkins mar...@versatilemonkey.com wrote: Would it be possible to allow the in-app billing to check the purchase status of an app? I want to switch a paid app to a freemium model, but it's not possible to switch and allow existing paid users to keep access to the app. My thought as well. Maybe you shall fill a bug/feature request? Regards, Marcin Orlowski *Tray Agenda http://bit.ly/trayagenda* - keep you daily schedule handy... WebnetMobile on *Facebook http://webnetmobile.com/fb/* and *Twitterhttp://webnetmobile.com/twitter/ * -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing does not work - although everything has been checked
I am also getting ITEM_UNAVAILABLE for my own product item with both a
test account and my developer's account. The application is uploaded but
not published, and so it the item.
In addition, purchasing authorization for android.test* items under
the test account never completes.
FWIW, the product list editing page says this:
An in-app product will appear UNPUBLISHED until the owning application
is PUBLISHED, at which point the in-app product's publishing state
applies. Please use the application editor to modify the application's
publishing state.
Not sure what this means for testing. Also, the License Test Response
field in the profile page (where you set up test accounts) doesn't
appear to have any codes specific to in-app billing, just codes for LVL.
-- Kostya
26.03.2011 14:32, Marc Reichelt пишет:
Hi!
I am including In-app billing in a new Android application I am
currently working on. The project is nearly finished and it should go
live as soon as in-app billing goes live.
In this project I want that users can donate to support the
application. However, I can not get In-app billing to work, although I
think I did everything right. Every time it is showing me that the
product is unavailable. Here is the logcat shortly after clicking the
button to purchase the item (product ID donate_1) and after closing
the Android Market dialog:
03-26 12:07:42.440: DEBUG/More(12297): buying: donate_1
03-26 12:07:42.440: DEBUG/BillingService(12297): RequestPurchase
03-26 12:07:42.450: DEBUG/BillingService(12297): request id:
8723043450188864909
03-26 12:07:42.450: INFO/ActivityManager(96): Starting: Intent
{ act=android.intent.action.VIEW
cmp=com.android.vending/.billing.InAppBuyPageActivity (has extras) }
from pid -1
03-26 12:07:42.770: INFO/ActivityManager(96): Displayed
com.android.vending/.billing.InAppBuyPageActivity: +313ms
device shows market dialog that product is unavailable.
03-26 12:12:28.500: INFO/BillingService(12297): handleCommand()
action: com.android.vending.billing.RESPONSE_CODE
03-26 12:12:28.500: DEBUG/BillingService(12297): RequestPurchase:
RESULT_ITEM_UNAVAILABLE
03-26 12:12:28.500: DEBUG/More(12297): donate_1:
RESULT_ITEM_UNAVAILABLE
03-26 12:12:28.500: INFO/More(12297): purchase failed
This is what I checked:
1) I correctly signed and uploaded my APK file to the developer
console and saved it as draft, and I installed it on my real device.
2) I ensured that my test account, e.g. example_t...@googlemail.com,
is listed as test account (the developer account is a different one,
let's say example_...@googlemail.com) and is the primary account on my
device.
3) The product donate_1 (unmanaged because multiple donations should
be possible) is listed as published and has a price of 0.79 €.
4) All static responses triggered by android.test.purchased etc.
have been tested and work.
5) Of course the Android Market is checked to have the latest version
(2.3.4).
So I believe I checked all points from
http://developer.android.com/guide/market/billing/billing_testing.html#billing-testing-real
- and I have no idea why it still does not work. Maybe a bug? It
wouldn't be the first time that...@googlemail.com addresses make
problems, but...@gmail.com do not. But that is just my guess.
Thanks in advance regards
Marc Reichelt || http://www.marcreichelt.de/
--
Kostya Vasilyev -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing sample is not working
Billing requires Market application 2.3, which has not been released yet. -- Kostya Vasilyev -- http://kmansoft.wordpress.com 15.02.2011 10:23 пользователь muhammad mahmood muhammad.rash...@gmail.com написал: Hi i would like to say that i want to implement in-app billing in my application. Before it i downloaded the sample billing app. But when i click on Buy button, it throws exception 01-06 05:01:26.608: ERROR/Bundle(966): readBundle: bad magic number 01-06 05:01:26.608: ERROR/Bundle(966): readBundle: trace = java.lang.RuntimeException 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Bundle.readFromParcelInner(Bundle.java:1580) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Bundle.init(Bundle.java:82) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Parcel.readBundle(Parcel.java:1381) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Parcel.readBundle(Parcel.java:1366) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Bundle $1.createFromParcel(Bundle.java:1517) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Bundle $1.createFromParcel(Bundle.java:1520) 01-06 05:01:26.608: ERROR/Bundle(966): at com.android.vending.billing.IMarketBillingService$Stub $Proxy.sendBillingRequest(IMarketBillingService.java:102) 01-06 05:01:26.608: ERROR/Bundle(966): at com.example.dungeons.BillingService $RequestPurchase.run(BillingService.java:231) 01-06 05:01:26.608: ERROR/Bundle(966): at com.example.dungeons.BillingService $BillingRequest.runIfConnected(BillingService.java:120) 01-06 05:01:26.608: ERROR/Bundle(966): at com.example.dungeons.BillingService $BillingRequest.runRequest(BillingService.java:97) 01-06 05:01:26.608: ERROR/Bundle(966): at com.example.dungeons.BillingService.requestPurchase(BillingService.java: 438) 01-06 05:01:26.608: ERROR/Bundle(966): at com.example.dungeons.Dungeons.onClick(Dungeons.java:464) 01-06 05:01:26.608: ERROR/Bundle(966): at android.view.View.performClick(View.java:2408) 01-06 05:01:26.608: ERROR/Bundle(966): at android.view.View $PerformClick.run(View.java:8816) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Handler.handleCallback(Handler.java:587) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Handler.dispatchMessage(Handler.java:92) 01-06 05:01:26.608: ERROR/Bundle(966): at android.os.Looper.loop(Looper.java:123) 01-06 05:01:26.608: ERROR/Bundle(966): at android.app.ActivityThread.main(ActivityThread.java:4627) 01-06 05:01:26.608: ERROR/Bundle(966): at java.lang.reflect.Method.invokeNative(Native Method) 01-06 05:01:26.608: ERROR/Bundle(966): at java.lang.reflect.Method.invoke(Method.java:521) 01-06 05:01:26.608: ERROR/Bundle(966): at com.android.internal.os.ZygoteInit $MethodAndArgsCaller.run(ZygoteInit.java:858) 01-06 05:01:26.608: ERROR/Bundle(966): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) 01-06 05:01:26.608: ERROR/Bundle(966): at dalvik.system.NativeStart.main(Native Method) 01-06 05:01:26.608: ERROR/BillingService(966): Error with requestPurchase Kind Regards Muhammad Rashid -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing - ITEM_ID limitations
Only just saw your reply, thanks Trevor. It looks like this will support just what I need. In my case, I'm going to have a small number of item classes, but each item the user buys will be unique. The uniquifying data will be small - just a couple of dozen bytes at most and acts as a natural key for any further item data. It looks like the In-app Billing API provides everything I need :) Tom. On 4 February 2011 02:41, Trevor Johns trevorjo...@google.com wrote: The primary problem is that the developer payload field is limited in size. Whatever data you put there has to travel through our entire billing system. Save the content to a datastore somewhere (either on-device or on a third-party server), then put the record ID in the developer payload field and you'll be fine. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com On Wed, Feb 2, 2011 at 2:11 PM, tomgibara tomgib...@gmail.com wrote: I've just finished reading the preliminary documentation for in-app billing. If I've understood correctly, as part of the billing request you can supply: * ITEM_ID which is limited to a small number of pre-registered product ids * DEVELOPER_PAYLOAD unconstrained - but with caveats? and these are the only two pieces of data you can send to identify the product being purchased. But even the DEVELOPER_PAYLOAD appears to be off-limits; the documentation contains the following (rather cryptic) advice: We recommend that you do not use this field to send data or content. I take this to mean product data/content, but that's no more than a guess, and if that's the correct interpretation, why? The result seems to be that you can't sell individuated items. I was hoping to use the in-app billing system to allow purchases of dynamically generated designs from my forthcoming Metaglow application, but this doesn't appear to be possible without operating some sort of 'credits purchase' system which I think would provide a very poor user experience and which isn't what I want to give users. Can anyone shed light on this? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
I believe being able to provide refunds is important. When you go to a real-world store, you can touch, look at, try on items before paying, and yet stores typically let you bring purchases back and get a refund. This is so that the customer knows that if something - unexpected and unforeseen - goes wrong, he can get his money back. That's psychology, not technology. Secondly, as a user, I prefer the situation where the pro version offers additional features compared to the lite version, and not where the lite version has the same features, and is deliberately made annoying in some way (nag screens, start-up delays, etc.) The user hopefully goes to buy the pro version to get those extra features, hoping that they work as advertised, but he has no ways to verify that before paying. Third, putting info about refunds in the application's UI would directly contradict what the user sees in the purchase window. And since the former is part of the application, and the latter comes from Google, which one do you think he's going to believe? Finally, providing information to the user about refunds in one place, the purchase window, would seem to me like valuable thing. Probably not too difficult to provide a boolean flag in the API so that the purchase window can say Refunds for this item are provided by the developer. -- Kostya 05.02.2011 1:56, Dianne Hackborn ?: On Fri, Feb 4, 2011 at 12:17 PM, Kostya Vasilyev kmans...@gmail.com mailto:kmans...@gmail.com wrote: I'm just concerned that it might deter purchases for lite to pro conversions. For buying in-game gems or potions it shouldn't really matter, those are impulse purchases and for smaller amounts too. Why would it deter payments? Here's the main value I see in the refund period: there is something you are purchasing, that you haven't actually been able yet to even try to download and install, so really have no idea what you are getting. Being able to get a refund if it is not what you want, buggy, or has other issues is important to have any confidence in buying in that situation. Using in-app purchases within an app is entirely different though. Consider the same situation with a lite vs. pro version: you downloaded the app for free, have been using it for however long you want (or however long the developer will let you), and have no decided it is worth spending $X to purchase it (or unlock a certain feature etc). What benefit does a refund period really give you here? Or look at this another way: the beauty of using in-app purchases for all of this is that *you* are in complete control of the user experience through this thing. All you need to do is get the user to download and run your free app, and after that you get to decide exactly how you want to interact with the user towards paying for the app. All in-app billing provides is the final point where the user has decided yes it is worth the money, I am paying. So you can do all kinds of things: - Have the full app running as a limited time trial, after which the user must purchase to continue using. - Have the full app running with ads, and the user able to pay to get rid of the ads. - Have limited features available in the free app, with a payment to unlock the full features (or even multiple payment options to unlock different features). - Allow the user to try out for-pay features for a limited amount of time. - Show a nag message every now and then encouraging the user to pay for your app to encourage further development. - And on and on! And in all of these cases, it is clear that the interactions here are directly between you as the app developer and your users, with Market now just being the point where the user hands over some cash. -- Dianne Hackborn Android framework engineer hack...@android.com mailto:hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
On Friday, February 4, 2011 1:03:26 AM UTC, Mark Carter wrote: I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? I'm not sure it does, actually. Consider your existing Pro users, most of whom presumably don't have the Lite version installed. When you convert Pro into (in your words) just a marker app, all these users will lose the functionality until they go download the app formerly know as Lite. They'll also end up with both items in their app list unless you go through some shenanigans with hiding the Pro token app; I say shenanigans because you can't afford to hide it for users who *don't* have Lite installed. That's a PITA, I know, I've done that kind of thing. And in any case, you're likely to annoy and confuse a good percentage of your existing paid users. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
In this lite/pro conversion scenario, can the user cancel his purchase of Pro key to revert back to the Lite version (for whatever reason)? There is a 15 minute window for refunds with the current scheme (separate Lite / Pro applications) - is there one for in-app purchases? The middle screenshot here says This in-app purchase cannot be refunded, is that always the case for in-app items? http://developer.android.com/guide/market/billing/index.html -- Kostya 04.02.2011 11:17, String ?: On Friday, February 4, 2011 1:03:26 AM UTC, Mark Carter wrote: I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? I'm not sure it does, actually. Consider your existing Pro users, most of whom presumably don't have the Lite version installed. When you convert Pro into (in your words) just a marker app, all these users will lose the functionality until they go download the app formerly know as Lite. They'll also end up with both items in their app list unless you go through some shenanigans with hiding the Pro token app; I say shenanigans because you can't afford to hide it for users who /don't/ have Lite installed. That's a PITA, I know, I've done that kind of thing. And in any case, you're likely to annoy and confuse a good percentage of your existing paid users. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Yeah, I wasn't thinking of killing all the functionality (in the Pro) straight away - rather when, say, 95% of users had already installed the Lite version. Anyway, it's all way too messy to seriously consider. Ideally, I would rather the Pro version becomes free (supporting in-app upgrades), and Lite users gradually move over to that. And that somehow, the licensing system can know which category the user falls into: 1. Paid for the app (i.e. got it *before* it became free) (LICENSED) 2. Did not pay for the app (i.e. got it *after* it became free), but purchased the in-app-upgrade (LICENSED) 3. Neither paid for the app nor purchased the in-app-upgrade (NOT_LICENSED) On 4 February 2011 15:17, String sterling.ud...@googlemail.com wrote: On Friday, February 4, 2011 1:03:26 AM UTC, Mark Carter wrote: I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? I'm not sure it does, actually. Consider your existing Pro users, most of whom presumably don't have the Lite version installed. When you convert Pro into (in your words) just a marker app, all these users will lose the functionality until they go download the app formerly know as Lite. They'll also end up with both items in their app list unless you go through some shenanigans with hiding the Pro token app; I say shenanigans because you can't afford to hide it for users who *don't* have Lite installed. That's a PITA, I know, I've done that kind of thing. And in any case, you're likely to annoy and confuse a good percentage of your existing paid users. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
In-app purchases have no refund window. (The developer can still manually issue a refund via their Checkout merchant console, but the user would need to manually email you.) -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com On Fri, Feb 4, 2011 at 12:33 AM, Kostya Vasilyev kmans...@gmail.com wrote: In this lite/pro conversion scenario, can the user cancel his purchase of Pro key to revert back to the Lite version (for whatever reason)? There is a 15 minute window for refunds with the current scheme (separate Lite / Pro applications) - is there one for in-app purchases? The middle screenshot here says This in-app purchase cannot be refunded, is that always the case for in-app items? http://developer.android.com/guide/market/billing/index.html -- Kostya 04.02.2011 11:17, String пишет: On Friday, February 4, 2011 1:03:26 AM UTC, Mark Carter wrote: I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? I'm not sure it does, actually. Consider your existing Pro users, most of whom presumably don't have the Lite version installed. When you convert Pro into (in your words) just a marker app, all these users will lose the functionality until they go download the app formerly know as Lite. They'll also end up with both items in their app list unless you go through some shenanigans with hiding the Pro token app; I say shenanigans because you can't afford to hide it for users who *don't* have Lite installed. That's a PITA, I know, I've done that kind of thing. And in any case, you're likely to annoy and confuse a good percentage of your existing paid users. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Thanks. Is that somehow explained to the user during the checkout process? -- Kostya 04.02.2011 21:07, Trevor Johns пишет: In-app purchases have no refund window. (The developer can still manually issue a refund via their Checkout merchant console, but the user would need to manually email you.) -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com On Fri, Feb 4, 2011 at 12:33 AM, Kostya Vasilyev kmans...@gmail.com mailto:kmans...@gmail.com wrote: In this lite/pro conversion scenario, can the user cancel his purchase of Pro key to revert back to the Lite version (for whatever reason)? There is a 15 minute window for refunds with the current scheme (separate Lite / Pro applications) - is there one for in-app purchases? The middle screenshot here says This in-app purchase cannot be refunded, is that always the case for in-app items? http://developer.android.com/guide/market/billing/index.html -- Kostya 04.02.2011 11:17, String пишет: On Friday, February 4, 2011 1:03:26 AM UTC, Mark Carter wrote: I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? I'm not sure it does, actually. Consider your existing Pro users, most of whom presumably don't have the Lite version installed. When you convert Pro into (in your words) just a marker app, all these users will lose the functionality until they go download the app formerly know as Lite. They'll also end up with both items in their app list unless you go through some shenanigans with hiding the Pro token app; I say shenanigans because you can't afford to hide it for users who /don't/ have Lite installed. That's a PITA, I know, I've done that kind of thing. And in any case, you're likely to annoy and confuse a good percentage of your existing paid users. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com mailto:android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com mailto:android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com mailto:android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com mailto:android-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
On Fri, Feb 4, 2011 at 10:40 AM, Kostya Vasilyev kmans...@gmail.com wrote: Thanks. Is that somehow explained to the user during the checkout process? -- Kostya Yes. See the bold text in the middle screenshot here: http://developer.android.com/images/billing_checkout_flow.png -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
No, that says that the purchase can't be refunded. Is it somehow made clear to the user that the purchase can be refunded by contacting the developer? -- Kostya 04.02.2011 22:24, Trevor Johns ?: On Fri, Feb 4, 2011 at 10:40 AM, Kostya Vasilyev kmans...@gmail.com mailto:kmans...@gmail.com wrote: Thanks. Is that somehow explained to the user during the checkout process? -- Kostya Yes. See the bold text in the middle screenshot here: http://developer.android.com/images/billing_checkout_flow.png -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
No. That's a policy issue for app developers. (Developers might decide that, depending on the nature of whatever's being purchased, that they don't want to issue refunds, even over email.) It's something you'd have to explain in your UI. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
That's too bad. The message very unambiguously says that there no refunds, and that window is the main thing the user deals with for purchases, and trusts as a source of information about how the process works (it being a Google thing). I'm just concerned that it might deter purchases for lite to pro conversions. For buying in-game gems or potions it shouldn't really matter, those are impulse purchases and for smaller amounts too. At least there could be something there explaining that refunds can only be issued by the developer only, and you might want to contact the developer at xxx@zzz for further info. -- Kostya 04.02.2011 22:57, Trevor Johns пишет: No. That's a policy issue for app developers. (Developers might decide that, depending on the nature of whatever's being purchased, that they don't want to issue refunds, even over email.) It's something you'd have to explain in your UI. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
On Fri, Feb 4, 2011 at 12:17 PM, Kostya Vasilyev kmans...@gmail.com wrote: I'm just concerned that it might deter purchases for lite to pro conversions. For buying in-game gems or potions it shouldn't really matter, those are impulse purchases and for smaller amounts too. Why would it deter payments? Here's the main value I see in the refund period: there is something you are purchasing, that you haven't actually been able yet to even try to download and install, so really have no idea what you are getting. Being able to get a refund if it is not what you want, buggy, or has other issues is important to have any confidence in buying in that situation. Using in-app purchases within an app is entirely different though. Consider the same situation with a lite vs. pro version: you downloaded the app for free, have been using it for however long you want (or however long the developer will let you), and have no decided it is worth spending $X to purchase it (or unlock a certain feature etc). What benefit does a refund period really give you here? Or look at this another way: the beauty of using in-app purchases for all of this is that *you* are in complete control of the user experience through this thing. All you need to do is get the user to download and run your free app, and after that you get to decide exactly how you want to interact with the user towards paying for the app. All in-app billing provides is the final point where the user has decided yes it is worth the money, I am paying. So you can do all kinds of things: - Have the full app running as a limited time trial, after which the user must purchase to continue using. - Have the full app running with ads, and the user able to pay to get rid of the ads. - Have limited features available in the free app, with a payment to unlock the full features (or even multiple payment options to unlock different features). - Allow the user to try out for-pay features for a limited amount of time. - Show a nag message every now and then encouraging the user to pay for your app to encourage further development. - And on and on! And in all of these cases, it is clear that the interactions here are directly between you as the app developer and your users, with Market now just being the point where the user hands over some cash. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Dianne, Your Have the full app running with ads, and the user able to pay to get rid of the ads comment really resonated with me :). Are you sure this is an approved use of the In App Billing? If it is, it solves most of the what I need right now. I've read most (not all) of the documentation, but haven't clarified that point yet. Hah... can I quote your email if I try it and am told it's not in the Terms of Service ? :). Sincerely, Brad Gies --- Bistro Bot - Bistro Blurb http://bgies.comhttp://nocrappyapps.com http://bistroblurb.com http://forcethetruth.com http://ihottonight.com --- Everything in moderation, including abstinence (paraphrased) Every person is born with a brain... Those who use it well are the successful happy ones - Brad Gies Adversity can make or break you... It's your choice... Choose wisely - Brad Gies Never doubt that a small group of thoughtful, committed people can change the world. Indeed. It is the only thing that ever has - Margaret Mead On 04/02/2011 2:56 PM, Dianne Hackborn wrote: On Fri, Feb 4, 2011 at 12:17 PM, Kostya Vasilyev kmans...@gmail.com mailto:kmans...@gmail.com wrote: I'm just concerned that it might deter purchases for lite to pro conversions. For buying in-game gems or potions it shouldn't really matter, those are impulse purchases and for smaller amounts too. Why would it deter payments? Here's the main value I see in the refund period: there is something you are purchasing, that you haven't actually been able yet to even try to download and install, so really have no idea what you are getting. Being able to get a refund if it is not what you want, buggy, or has other issues is important to have any confidence in buying in that situation. Using in-app purchases within an app is entirely different though. Consider the same situation with a lite vs. pro version: you downloaded the app for free, have been using it for however long you want (or however long the developer will let you), and have no decided it is worth spending $X to purchase it (or unlock a certain feature etc). What benefit does a refund period really give you here? Or look at this another way: the beauty of using in-app purchases for all of this is that *you* are in complete control of the user experience through this thing. All you need to do is get the user to download and run your free app, and after that you get to decide exactly how you want to interact with the user towards paying for the app. All in-app billing provides is the final point where the user has decided yes it is worth the money, I am paying. So you can do all kinds of things: - Have the full app running as a limited time trial, after which the user must purchase to continue using. - Have the full app running with ads, and the user able to pay to get rid of the ads. - Have limited features available in the free app, with a payment to unlock the full features (or even multiple payment options to unlock different features). - Allow the user to try out for-pay features for a limited amount of time. - Show a nag message every now and then encouraging the user to pay for your app to encourage further development. - And on and on! And in all of these cases, it is clear that the interactions here are directly between you as the app developer and your users, with Market now just being the point where the user hands over some cash. -- Dianne Hackborn Android framework engineer hack...@android.com mailto:hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Yikes. Okay let me be clear: I don't work on Market, I am not responsible for Market, I probably know less about this than you because I haven't read through the documentation. I am just giving my personal opinion. If it conflicts with anything in the TOS, I am wrong. But personally, I think this has the potential to be a way way better approach to dealing with paid apps than up-front payments, for both users and developers. Hopefully it is all kosher with Market. On Fri, Feb 4, 2011 at 3:08 PM, Brad Gies rbg...@gmail.com wrote: Dianne, Your Have the full app running with ads, and the user able to pay to get rid of the ads comment really resonated with me :). Are you sure this is an approved use of the In App Billing? If it is, it solves most of the what I need right now. I've read most (not all) of the documentation, but haven't clarified that point yet. Hah... can I quote your email if I try it and am told it's not in the Terms of Service ? :). Sincerely, Brad Gies --- Bistro Bot - Bistro Blurb http://bgies.comhttp://nocrappyapps.com http://bistroblurb.com http://forcethetruth.com http://ihottonight.com --- Everything in moderation, including abstinence (paraphrased) Every person is born with a brain... Those who use it well are the successful happy ones - Brad Gies Adversity can make or break you... It's your choice... Choose wisely - Brad Gies Never doubt that a small group of thoughtful, committed people can change the world. Indeed. It is the only thing that ever has - Margaret Mead On 04/02/2011 2:56 PM, Dianne Hackborn wrote: On Fri, Feb 4, 2011 at 12:17 PM, Kostya Vasilyev kmans...@gmail.commailto: kmans...@gmail.com wrote: I'm just concerned that it might deter purchases for lite to pro conversions. For buying in-game gems or potions it shouldn't really matter, those are impulse purchases and for smaller amounts too. Why would it deter payments? Here's the main value I see in the refund period: there is something you are purchasing, that you haven't actually been able yet to even try to download and install, so really have no idea what you are getting. Being able to get a refund if it is not what you want, buggy, or has other issues is important to have any confidence in buying in that situation. Using in-app purchases within an app is entirely different though. Consider the same situation with a lite vs. pro version: you downloaded the app for free, have been using it for however long you want (or however long the developer will let you), and have no decided it is worth spending $X to purchase it (or unlock a certain feature etc). What benefit does a refund period really give you here? Or look at this another way: the beauty of using in-app purchases for all of this is that *you* are in complete control of the user experience through this thing. All you need to do is get the user to download and run your free app, and after that you get to decide exactly how you want to interact with the user towards paying for the app. All in-app billing provides is the final point where the user has decided yes it is worth the money, I am paying. So you can do all kinds of things: - Have the full app running as a limited time trial, after which the user must purchase to continue using. - Have the full app running with ads, and the user able to pay to get rid of the ads. - Have limited features available in the free app, with a payment to unlock the full features (or even multiple payment options to unlock different features). - Allow the user to try out for-pay features for a limited amount of time. - Show a nag message every now and then encouraging the user to pay for your app to encourage further development. - And on and on! And in all of these cases, it is clear that the interactions here are directly between you as the app developer and your users, with Market now just being the point where the user hands over some cash. -- Dianne Hackborn Android framework engineer hack...@android.com mailto:hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups
Re: [android-developers] In app billing...
On Wed, Feb 2, 2011 at 8:25 PM, Dianne Hackborn hack...@android.com wrote: How about using it to be able to put your app up on market as a free trial version, using in-app billing to unlock the full version? That's exactly what I was thinking of when I heard the announcement. It would chop my GitHub repo in half! Just some questions about this...sure, the user can unlock the full version inside the trial version, but, how is this tracked for the user? As it currently stands, it looks as if only purchased apps are saved for the user (ie: they can uninstall and reinstall without paying again). What if the user installs the free trial, uses in-app billing to unlock the full version, then later decides to uninstall the app for space? Would the market/app, upon reinstalling, recognize that the user already has paid to unlock the full version? How is this managed? Is it left to the developer to manage these things on their own servers? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Is this the info you are looking for: http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type ? On 3 February 2011 21:25, Justin Giles jtgi...@gmail.com wrote: That's exactly what I was thinking of when I heard the announcement. It would chop my GitHub repo in half! Just some questions about this...sure, the user can unlock the full version inside the trial version, but, how is this tracked for the user? As it currently stands, it looks as if only purchased apps are saved for the user (ie: they can uninstall and reinstall without paying again). What if the user installs the free trial, uses in-app billing to unlock the full version, then later decides to uninstall the app for space? Would the market/app, upon reinstalling, recognize that the user already has paid to unlock the full version? How is this managed? Is it left to the developer to manage these things on their own servers? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Yep. Looks like that answers my question. Thanks! On Thu, Feb 3, 2011 at 8:49 AM, Mark Carter mjc1...@googlemail.com wrote: Is this the info you are looking for: http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type ? On 3 February 2011 21:25, Justin Giles jtgi...@gmail.com wrote: That's exactly what I was thinking of when I heard the announcement. It would chop my GitHub repo in half! Just some questions about this...sure, the user can unlock the full version inside the trial version, but, how is this tracked for the user? As it currently stands, it looks as if only purchased apps are saved for the user (ie: they can uninstall and reinstall without paying again). What if the user installs the free trial, uses in-app billing to unlock the full version, then later decides to uninstall the app for space? Would the market/app, upon reinstalling, recognize that the user already has paid to unlock the full version? How is this managed? Is it left to the developer to manage these things on their own servers? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
On Thursday, February 3, 2011 2:25:29 AM UTC, hackbod wrote: How about using it to be able to put your app up on market as a free trial version, using in-app billing to unlock the full version? I've been thinking about this since the announcement yesterday. I used to think this was a good use for in-app billing, but now I'm not so sure. My issue is with how to present the app. That's *app,* singular, because you'll only have one, as opposed to the lite/pro or trial/unlock pairs which are common now. With this current approach, especially lite/pro, users understand what they're getting with the free aspect. They see Lite in the title, and they immediately know they're not getting the whole enchilada. Expectations are managed. If the app is all-in-one (unlocked through in-app billing), I'm betting many users won't realize that they need to pay until AFTER they install it. It's well established that a large percentage don't read the Market description. So then they'll be annoyed that they didn't get the full version, with crappy 1* Market comments following soon after. Not a recipe for success. OTOH, I've had good results with separate lite/pro apps. My top-selling app was fed by a Lite version which rose in the Free rankings of its category, then more recently has fallen back down. But not before the Pro version rose high enough to gain decent visibility on the Paid side, and it's now doing well enough that it doesn't need the support of Lite any more. Moral: with two apps, you get two shots at success. I'm not saying that in-app billing to unlock a trial may not be right for some apps, some devs. Just that I, for one, am not convinced. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Interesting points, String. I was recently thinking about how to change an existing Lite/Pro combo to use in-app-upgrade instead. I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? On 4 February 2011 03:53:38 UTC+7, String sterling.ud...@googlemail.comwrote: On Thursday, February 3, 2011 2:25:29 AM UTC, hackbod wrote: How about using it to be able to put your app up on market as a free trial version, using in-app billing to unlock the full version? I've been thinking about this since the announcement yesterday. I used to think this was a good use for in-app billing, but now I'm not so sure. My issue is with how to present the app. That's *app,* singular, because you'll only have one, as opposed to the lite/pro or trial/unlock pairs which are common now. With this current approach, especially lite/pro, users understand what they're getting with the free aspect. They see Lite in the title, and they immediately know they're not getting the whole enchilada. Expectations are managed. If the app is all-in-one (unlocked through in-app billing), I'm betting many users won't realize that they need to pay until AFTER they install it. It's well established that a large percentage don't read the Market description. So then they'll be annoyed that they didn't get the full version, with crappy 1* Market comments following soon after. Not a recipe for success. OTOH, I've had good results with separate lite/pro apps. My top-selling app was fed by a Lite version which rose in the Free rankings of its category, then more recently has fallen back down. But not before the Pro version rose high enough to gain decent visibility on the Paid side, and it's now doing well enough that it doesn't need the support of Lite any more. Moral: with two apps, you get two shots at success. I'm not saying that in-app billing to unlock a trial may not be right for some apps, some devs. Just that I, for one, am not convinced. String -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
On Thu, Feb 3, 2011 at 5:03 PM, Mark Carter mjc1...@googlemail.com wrote: I was recently thinking about how to change an existing Lite/Pro combo to use in-app-upgrade instead. I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? Yes, that would work. There are apps that already use pro keys. You'd just be adding a second check with the in-app billing service for a license that's been purchased in the past. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-App billing: Can it be used for Donation?
Answers inline below... On Wed, Feb 2, 2011 at 3:30 PM, Prateek prateekandr...@gmail.com wrote: 1. Can In-app billing be used for accepting money as donation? Please note that this is NOT a donation given to a registered charity but its like money we give to fellow freelance developers if we appreciate their work. Don't know if there is anything in Google's Terms Conditions that stops developers from accepting money in the way as mentioned above. Any ideas? If yes, my guess is that it will be implemented as unmanaged purchase type. IANAL, so I can't interpret the terms and conditions for you. Sorry. 2. Is In-app billing only for Paid apps? No, it will be available for all apps published in Market. I cannot find the Product list under my currently published Free app listing as mentioned on http://d.android.com/guide/market/billing/billing_admin.html#billing-list-setup May be it's not activated for my account yet. Just wanted to verify. This is correct, it has not been enabled yet. (Once it is enabled, keep in mind you'll need to associate a Checkout account with your account for this to appear.) 3. What is the refund time window? Is it 15 mins for In-App billing also? There is no end-user refund period. If you want to issue a refund, it has to be done manually by the application publisher through their Checkout merchant console. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Thanks Trevor. After updating the Pro version (to be just a marker app), I would want to unpublish it (to avoid confusion) but would existing users see the update after unpublishing? Also, would existing users who buy a new phone automatically get that unpublished app? On 4 February 2011 09:25, Trevor Johns trevorjo...@google.com wrote: On Thu, Feb 3, 2011 at 5:03 PM, Mark Carter mjc1...@googlemail.comwrote: I was recently thinking about how to change an existing Lite/Pro combo to use in-app-upgrade instead. I can't see a nice way to do it. The best way I can think of is to introduce in-app billing to the Lite version and convert the Pro version into some kind of pro key token app. The Lite version would check for existence of this pro key app (and validate) if the in-app-upgrade had not been purchased. Does that work? Yes, that would work. There are apps that already use pro keys. You'd just be adding a second check with the in-app billing service for a license that's been purchased in the past. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In-app billing - ITEM_ID limitations
The primary problem is that the developer payload field is limited in size. Whatever data you put there has to travel through our entire billing system. Save the content to a datastore somewhere (either on-device or on a third-party server), then put the record ID in the developer payload field and you'll be fine. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com On Wed, Feb 2, 2011 at 2:11 PM, tomgibara tomgib...@gmail.com wrote: I've just finished reading the preliminary documentation for in-app billing. If I've understood correctly, as part of the billing request you can supply: * ITEM_ID which is limited to a small number of pre-registered product ids * DEVELOPER_PAYLOAD unconstrained - but with caveats? and these are the only two pieces of data you can send to identify the product being purchased. But even the DEVELOPER_PAYLOAD appears to be off-limits; the documentation contains the following (rather cryptic) advice: We recommend that you do not use this field to send data or content. I take this to mean product data/content, but that's no more than a guess, and if that's the correct interpretation, why? The result seems to be that you can't sell individuated items. I was hoping to use the in-app billing system to allow purchases of dynamically generated designs from my forthcoming Metaglow application, but this doesn't appear to be possible without operating some sort of 'credits purchase' system which I think would provide a very poor user experience and which isn't what I want to give users. Can anyone shed light on this? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
On Thu, Feb 3, 2011 at 6:34 PM, Mark Carter mjc1...@googlemail.com wrote: After updating the Pro version (to be just a marker app), I would want to unpublish it (to avoid confusion) but would existing users see the update after unpublishing? Yes, because they already have a license for the application. They'll continue to see it in their list of purchased items (and presumably get updates too) as long as the app is compatible with their device. Also, would existing users who buy a new phone automatically get that unpublished app? Assuming the system restore works properly, then yes. However, if the user disabled the backup service or doesn't sign into their phone during the setup wizard (i.e. they skip signing into their account until later), then we can't restore. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Thanks for the clarification. I do wish the licensing/in-app-payments data could be accessed in a more standardized way to make all this easier. What I would like to be able to do is query some API to find out all the purchases (whether for apps or in-app-payments) for any of my products. I can understand why you don't want an app querying for other apps from other publishers, but what about for other apps from the same publisher? This would also be a simple way to share in-app purchases across all of my apps (something I see which is not allowed in the new in-app system). One application of this might be a donate in-app purchase which could, say, remove ads (whoops!) from all apps from the developer. It would also be a simpler way to facilitate migration from the cumbersome Lite/Pro model to in-app unlocking (which feels neater, though is not perfect as mentioned earlier). On 4 February 2011 09:52:16 UTC+7, Trevor Johns trevorjo...@google.comwrote: On Thu, Feb 3, 2011 at 6:34 PM, Mark Carter mjc1...@googlemail.comwrote: After updating the Pro version (to be just a marker app), I would want to unpublish it (to avoid confusion) but would existing users see the update after unpublishing? Yes, because they already have a license for the application. They'll continue to see it in their list of purchased items (and presumably get updates too) as long as the app is compatible with their device. Also, would existing users who buy a new phone automatically get that unpublished app? Assuming the system restore works properly, then yes. However, if the user disabled the backup service or doesn't sign into their phone during the setup wizard (i.e. they skip signing into their account until later), then we can't restore. -- Trevor Johns Developer Programs Engineer, Android http://developer.android.com -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
Mainly for apps where buying extra services makes sense. Like a magazine application that allows you to buy and download magazine subscriptions or editions within the app. Damien sent from my HTC Desire On 03/02/2011 11:39 AM, sblantipodi perini.dav...@dpsoftware.org wrote: Hi, I just received a mail from google that informs me that In-App Billing will be available soon. Can you explain me please what is the in app billing and what is used for? We can create buy now button now without any additional apis that redirect customers to the market, why use in app billing on android? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] In app billing...
How about using it to be able to put your app up on market as a free trial version, using in-app billing to unlock the full version? On Wed, Feb 2, 2011 at 5:54 PM, Damien Cooke cooke.dam...@gmail.com wrote: Mainly for apps where buying extra services makes sense. Like a magazine application that allows you to buy and download magazine subscriptions or editions within the app. Damien sent from my HTC Desire On 03/02/2011 11:39 AM, sblantipodi perini.dav...@dpsoftware.org wrote: Hi, I just received a mail from google that informs me that In-App Billing will be available soon. Can you explain me please what is the in app billing and what is used for? We can create buy now button now without any additional apis that redirect customers to the market, why use in app billing on android? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
