PURCHASE_STATE_CHANGED intent with no signature app version doesn't match uploaded APK

[GoogleCodeExporter]

What steps will reproduce the problem?

2. Install an APK on the device with a certain version number
1. Upload a APK to the Android Market with a newer version number
3. Attempt to restore transactions or purchase something on the device with the 
older app version

What is the expected output? What do you see instead?

When the APK versions match I get PURCHASE_STATE_CHANGED with a valid signature 
and signed data.

When they do not match, the user upon attempting to restore transactions gets 
PURCHASE_STATE_CHANGED with null signature and signed data. The request returns 
with the result RESULT_DEVELOPER_ERROR. If a purchase is attempted, the user 
gets the message "This version of the application is not configured for market 
billing." 

What version of the product are you using? On what operating system?

Android 2.2.2 on Galaxy S (Samsung Vibrant)
Using Dungeon example code.
APK is signed with release certificate.

Please provide any additional information below.

This is unexpected but would be bad if updates to the Market APK break the 
ability for older versions of the app to engage in Billing activities.

Original issue reported on code.google.com by seh...@gmail.com on 13 Apr 2011 at 9:40

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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