Another way to ask the question: how to make inapp billing working with all versions of my app?
I have got an app with inapp billing. I want to update it.
My active apk on the developer console is in version 1. My problem is the following:
when I install my updated app (signed package) in version 2 on my device using adb, I get the following message: "This version of the application package is not configured for Market billing"
when I install my updated app (always signed package) in version 1 (same version as the one on the console) on my device (what I can't do on the console...I have to increase the version number !) using adb, verything works...
Consequently, it seems that inapp billing works only with one version of the app: the one which is active in the console. I imagine that my users will have the same issue: only the users with the last update of the app will be able to perform inapp billing...the others will get the error.
Anybody knows how to solve this issue ? How can I do so that all my apps already installed in the world will be able to do inapp billing whatever the version number is ??
Thanks !!!
By "console" do you mean your publisher's account?
I think this isn't a bug but a feature by design. If you attempt to make a purchase that doesn't have one of the 4 android.test.* item ids, and it is running a debug version or even a release version that is newer than the one you have published, you will receive this error:
For example, if you're running on your device a Release mode that's one version higher than what's in the Market and you try to purchase a real item (not an android.test.* one), you will get the aforementioned error.
To further clarify: If you run an application of a higher versionCode than the one in the AndroidMarket (with the same package name, of course) it will succeed in "making the purchase" if you use one of the 4 android.test.* item ids.
Please note that this is based on my own experience and observation as full documentation on this leaves something to be desired.
Here is what I have observed while using In-App-Billing.
When you upload your release apk (regardless of Alpha/Beta/Production), IAB will not work right away, you will have to wait for a few hours before it can work
Uploading a new version of the apk (higher version) will also be the same. You will have to wait for a few hours for it to eventually work. The older version with IAB will still work though. What I usually do is to upload my release apk as Beta, wait a few hours, then when it is already working, promote the apk to production.
i face this error. solution:please upload sign apk and test with your Product id:com.test.purchased and set as a in-app product.
(1)run on your mobile using export with sign apk .
(2)if error is occur then wait 1-2 hours because sometime google take response late.
Related
My company has an app published in the google play store/android marketplace. One of the issues that we're fixing in the next version of the app is adding back xlargeScreen = true (it was somehow set to false in the previous version, so now the app isn't showing up on larger tablets). We're trying to get the alpha/beta testing setup so we can make sure we have all our problems fixed before we push the apk to live.
I've uploaded an apk to alpha and published it. I made a google+ community, added it to the accepted testers and sent out the link for the app. But, when we go out to the link and get set as testers nothing happens. If I go to the google play store, it shows the date for the newest upload to the account but the 'install' button attempts to install the previous live version (which is incompatible with the test device, yay!). Also someone else used their device and all the install did was install the old version to their device.
I've considered the "wait up to 24 hours for the publish to go through" being the problem, but the first alpha was uploaded Friday at lunch and would not work at lunch today, on Monday. I moved the old apk to beta and put a new one in alpha (more bug fixes yay) at lunch today. I checked all the settings and everything looks correct, but I can't see how I'm suppose to actually download the beta or the alpha at this point. And if I'm suppose to download the production version 1) How am I suppose to do that on the device that's incompatible with the production version and 2) how do I choose between the beta and the alpha version?
Ok, so it takes about 2 hours to be published for alpha/beta and it will be availible in the google play store in place of the live app if you opt in.
My specific problem was the the new alpha/beta apk was still incompatible with the device. I wish there was some notice on the page to show that you are viewing a test version (or better yet, a way to select alpha/beta/production on the google play page after you opt-in).
Turns out that <uses-permission> will in some cases make a device incompatible if it's missing the feature. Adding <uses-feature android:name="problem feature" android:required="false" /> for the offending permissions fixed my issue.
Say I have an application that users have installed from the Play Store, if one of my users reports a bug and I want to send them a patched version of the app to test, they can install it to their phone just fine. But if I then update the app on the Play Store, will the user get the update? My testing seems to indicate this is the case, but is there any gotchas?
The way my build process works is that each time I build, it gets a higher version code, so the patched version will have a higher version code that the one currently in the Play Store and then the version I upload to the Play Store after sending my user the patch will have a higher version code again.
I'm taking a decently wild guess here, but it should work, provided the following are met:
The version code of the apk on Google Play is higher than that of the hotfix
The user originally installed the app from Google Play to begin with, and only updated it via side loading.
The hotfix and the Google Play update are both signed with the same key.
I'm decently sure this will work, as I recall a long discussion about this on one of the android google groups that ended with success. I unfortunately cannot find it right now.
If you do try it out, please post back with the results.
I don't see any issue with this workflow. As long as you increment the version number at each build.
So I'm having trouble uploading a new APK to the play store with billing enabled.
Currently I have a published app that is paid and I want to change it to a subscription app such that the users get a yearly subscription and hence latest data to the app.
Now my issue is that the developer console will not let me upload a draft APK with the permissions for billing enabled. I log into the dev console, go to APK, change from simple to advanced mode, save my new APK as a draft and once uploaded I get the following error:
This configuration cannot be published for the following reason(s):
All devices that might receive version 1 would receive version 2.
Some devices are eligible to run multiple APKs. In such a scenario, the device will receive the APK with the higher version code.
I updated the Version code and the version number to be one higher than the current as well as different combinations of upping only one of the two values with still no success.
The app is being signed with the same keystore.
Thanks,
DMan
Figured out what this actually means now. Basically it was just telling me that I need to archive the current apk in order to actually publish the new apk. The new apk was successfully added as a draft. This message was just worded a little awkwardly and actually means that in order to publish version 2 version 1 must be archived NOT that there was anything wrong with the saved draft I performed.
Thanks,
Dman
Yes, all you have to do is to disable the old aplication, after that a the Publish botton will be available to push on the top left area so your new APK will be published
Did you disable your first version? By default, after uploading in advanced mode, both your first and 2nd version are activated. Looks to me like it's just saying that you've got 2 APKs active, that will reach the same devices thus one of the 2 is useless.
We have an Application which utilizes In App Billing. The problem that we're seeing is as follows:
When the versionCode of the App on the device is the same as the version code of the Application published in the Play Developer Console, Billing works fine.
When a build with a higher versionCode is uploaded to the Play Developer Console, In App Billing stops working on the App on the device (with a lower versionCode) saying that "The Application is not configured for Billing".
This is fine, when testing, but the question is - what is the behavior when the App is in the Google Play Store? When you replace the Application (to perform an update) does the Application that's in the wild (with a lower versionCode) stop working with In App Billing?
If so, what approach do people use to performing updates? Do you force the user to update before purchasing? Or is this problem only true prior to publishing?
Any advice would be greatly appreciated!
Thanks!
As long as the "newer" apk that you upload is signed using the same key as the existing one then you shouldn't run into any problems.
I have just tested running my app with a previous version (version code is lower) and in app billing still works.
The caveat is that you must not delete the apk from the market, simply deactivate it.
But what you say about forcing updates, I do prompt the user to update when they open the app regardless.
You may have already read it, but here is the official info on multiple apks.
I am working on learning in-app billing but I am having a problem with the google's in-app billing example, the Dungeon one.
I have already set up the application, added my public key, and changed the API_VERSION to 1 in the makeRequestBundle().
I have already exported and signed the application and uploaded it onto Google Play and saved it as a draft with a few pictures and activated the apk. I also added both the sword_001 and potion_001 as published in-app purchases!
Next I installed the signed app onto my phone but when I try to purchase either the sword or the potion I get an Item unavailable error
The item you requested is not available for purchase.
I even tried on a different device to make sure it wasn't because developer's can't purchase their own products, and I get the same message on both devices.
What have I missed?
Check your versionCode. It can't be higher than the last published/unpublished version in any of your distribution channels (prod/beta/alpha).
In app billing seems fraught with pitfalls, but this is what I found that affected availability of items for purchase and also suitability of application:
My code for what it was worth was strongly based on the Google Android demo, but I stripped out a lot of the complexity. I have a feeling that having got it to work a better result would be produced by writing it all again from scratch.
I got the static test product ids going first.
Despite what the documentation says, it seemed to me that the purchase item(s) must be published, even when using a test account. Mine didn't work when they weren't, anyway, and I waited quite a long time to see if they would start to work as others have suggested - they still didn't.
You (I anyway) can't publish a purchase item without publishing the app, so what I did was upload and publish the app, create the purchase items, publish them (big button at the bottom of the page), then unpublish the app again. This seems to leave the items published.
The app must be signed in the usual way (I did this by exporting from Eclipse) before uploading, but what isn't so obvious is that the app you load to the mobile MUST also be signed in the same way - ie a (debug signed) version loaded to the device by Eclipse - run or debug - isn't going to work.
They also both need the same version number, I think. Not 100% sure. If so that would unfortunately kind of imply that customers with old versions installed can't purchase anything without upgrading.
When the app is uploaded to Google, it can take several hours before it becomes available and you get all the right responses for the in-app billing. I find 1-2 hours typically.
I suspect the other comments on this subject about whether you use a gmail or googlemail test account might be red herrings, but for what it is worth, my test account is gmail.
I did come across a useful little note on the internet somewhere about how to change your primary account on the mobile without having to do a hard reset (and consequently losing everything), but unfortunately I haven't managed to find it again.
What I did find though is that one can have several google accounts on the mobile, and then select the one to be used by Google Play.
Hope this helps somebody. I have to say its a pretty complicated system, with not many switten down answers, and I nearly gave up on it.
If your app are on closed alpha testing, you have to sign in with your test account to Opt-in URL; https://play.google.com/apps/testing/{your.app.namespace}
My experience on this error is:
Make sure to upload the signed APK to developer console.
Make sure to install the signed APK on your device not launch the app in the debugger.
Make sure to create a test account in your developer console.
Make sure to sign in your device with your test account.
Make sure to create in app billing in your developer console and finally activate the item from the console!!! (this is the one that got me after fully following google's tutorial)
It's no longer sufficient to just upload an unpublished draft apk to test in-app billing. What you need to do is upload an apk to the alpha or beta apk section on the Developer Console. Then, you need to publish it. If you also have a draft apk in the Production APK section, be sure to delete it before you publish. Otherwise it will be available to everyone.
Publishing an alpha or beta apk makes that apk available to only those testers that you specify/allow.
Here is Google's documentation on this:
https://support.google.com/googleplay/android-developer/answer/6062777?rd=1
Well I found a solution to my problem. I wasn't able to get Google's in app purchasing example to work but I was able to get this InApp Billing Tutorial to work using the steps I mentioned in my original post.
If nothing else this may be helpful to someone to see all of the steps that need to be done to test one of the in-app billing examples.
Also had this problem for a couple of days and searched around a lot. I found this guy who said deleting the app and then reuploading fixed his problem, and that actually worked for me aswell.
Try that, delete your app from the developer console entirely. And reuppload a new signed apk and set it up all over again
Publishing the app did the trick for me(and leaving it published (!)). I had to wait a bit for Google to update their database as well, as mentioned elsewhere, changes on Google Play are not immediate.
Anecdotal Supplement: If you have an existing app in the portal already and you want to test a signed version, but not upload it into the portal for distribution. Do the normal steps to build a signed version BUT use your latest version code that is uploaded into the portal. You will will be able to do a quick and dirty test of purchasing (you can't upload this version on the Google Play portal, but it's a means to an end for a localized test (or even as a way to allow side loaded distributed versions/flavors that use Google Play for billing legitimately.)
3:)
Check if your device have more than one account then remove other accounts and keep the account you have entered in play console then it will be solved.