Open GoogleCodeExporter opened 9 years ago
FWIW - we're uploading the APK as draft (we haven't yet published a version
which includes billing) but using live, published in-app product IDs.
Original comment by seh...@gmail.com
on 13 Apr 2011 at 10:20
Does the published (non-draft) version of you app have the billing permission?
I ran into this same issue where I was getting the RESULT_DEVELOPER_ERROR and I
couldn't figure out what I was doing wrong. I finally realized that the
application I was testing with had a versionCode the same as my published app
version which did _not_ have the billing permission. When I changed it to the
versionCode of my draft APK that _does_ have the billing permission, it worked.
I don't think the issue is with the older vs newer versionCode, I believe it's
just that you have to test your in-app billing with a versionCode equivalent to
one with the billing permission (whether draft or published).
Original comment by ashug...@gmail.com
on 20 Apr 2011 at 11:59
The issue with ours was that it was one rev higher, both had the billing
permission.
So the test case is: if I upload build 189 and run build 189, billing is fine.
Then, I upgrade my phone to build 190, but neglect to upload build 190 as a
draft. We get RESULT_DEVELOPER_ERROR.
And the real issue, if I update the draft on the publisher site to 191, and
leave the phone at 190, I get RESULT_DEVELOPER_ERROR (i.e., the test upgrade
case is broken).
It's possible that this is a quirk in testing and of no consequence, but our
fear in testing was that the upgrade case would be broken in production. if we
did the same in the production case, we'd have users on 1.0 with in-app billing
that, after we upgraded to 1.1, would not be able to purchase without upgrading
their version of the app to 1.1.
Original comment by jenhar...@gmail.com
on 21 Apr 2011 at 2:30
any further information developments here? i notice some applications in the
store (robotek, most recently) seem top be able to upgrade and have both the
old apk and the new apk use the billing service.
Original comment by a...@brooklynpacket.com
on 31 May 2011 at 9:03
It seems that if your running a differently signed version than the one
published (or draft), then it returns a null signature.
If you run a signed .apk locally, it returns with a signature. It kinda makes
sense since the signatures don't match otherwise. Make debugging hard, though,
since you need to sign the debug version each time you want to debug.
Original comment by sdk...@gmail.com
on 2 Jun 2011 at 3:20
Hi ! So, what is the conclusion of this discussion? How to update an app which
uses inapp billing? How to avoid that users who do not have updated to the last
version get the "This version of the application is not configured for market
billing" message ? Since April 2011, somebody found the answer? Thanks guys!!!!!
Original comment by regis.an...@audioguidia.com
on 12 Nov 2011 at 12:07
Almost a year later and this is still marked as a new defect? I'm having this
same issue as well.
Original comment by rooster...@gmail.com
on 26 Sep 2012 at 7:37
I am experiencing the same issue with the same description as explained in this
Issue.
I have tried it on device using Android 2.3.4 and 2.3.5 same result error
message with dialog box.
Can you please make the In-App Billing feature more robust and friendlier to
developers?
Original comment by sjocelyn...@gmail.com
on 4 Oct 2012 at 11:12
This is a especially a problem for developers that use a build plugin to
increment their Android VersionCode on each full build or each source control
commit. Ie when you have a new version of the app on your phone you also need
to push a (not necessarily published) version to the Developer Console.
Further exacerbating the problem is that even when you do push the new version
to the DC you have about a 40 minute wait before that is visible to the Google
Play app on the device. Just enough time to have a coffee and feed and compose
this message.
This slows development .. lower the barriers please
Original comment by william....@xandar.com.au
on 21 Oct 2012 at 10:28
Could the original poster please update the title so that it is clear that the
real problem here is that purchasing cannot be tested unless the APK version
that has been delpoyed to the Google Play is EXACTLY the same as that running
on the device.
So that small iterations on the client can then cause large delays in testing
as you wait for the updated APK to get rolled out to all the Google Play
servers.
Original comment by william....@xandar.com.au
on 29 Oct 2012 at 9:29
Original issue reported on code.google.com by
seh...@gmail.com
on 13 Apr 2011 at 9:40