I tried to use Google In-App Updates library in my application that already in the Playstore. But i have some problems about how to test it. I am not gonna use FakeAppUpdateManager since there are no UI is being shown and no update is really performed
First, I cannot test it with debug build even if i set the versionCode lower than Playstore version code because of different keystore.
Second, According some tutorials said that i must using release build and signed with same keystore that i use to upload on Playstore. but when i did that, i still didn't get any in-app update. My guess is: because i used Google App Signing so the fingerprint is different and it is not recognized as same application (let me know if i am wrong about this).
Is there any elegant way to test this out?
Related
My contractor is working on my Android Apps Google API in-app purchase feature and I dont want to send them the actual distribution keystore. Can I have them sign it with the debug keystore somehow and upload to Alpha? (its not obvious how to do this in AS or in Google's documentation - and if thats even going to work for Alpha distribution)
Id like to avoid compiling and testing each version the build myself because the contractor and I have a 12hr time difference and I work my main job during the day.
Alternatively maybe there are other ways of dealing with this all together when working in AndroidStudio/GooglePlay with foreign contractors?
Thanks
I'm developing an open-source app for Android using Phonegap. The development reached the stage at which it's usable enough to release it to public (something like a beta version). I just want to put my current APK on Github. Is there any reason why I would not want to uploading the APK signed with debug key and signing it with release instead (and going through the hassle of making one etc.)?
A debug key isn't any different from a normal key. So there's no reason it would harm anything. If you ever want to upgrade it, the upgrades will need to be signed with the same key or the user will have to uninstall first. And if you ever upload to Google Play, the same key has to be used for all uploads there. So make sure whatever key you release under is saved somewhere.
The only possible problem I see is that debug keys may have a short expiration date and need to be recreated (ADT used to expire them in 1 year). So if you plan on maintaining it you may want to create a key with a longer expiration.
You should create a key as there may be people who will be helping you in your current project and they will also be signing app, but with a different key and if they later upload apk to the GitHub, the user's will get different signature warning which will result of having to reinstall the app and thus losing any persisted data.
As long as you don't want anyone helping you out, it's fine the way it is.
You can use the one Android created for you if you are too lazy to create a new one. It is stored in C:\Users\<your_user_name>\.android assuming that you are using Windows as your OS.
No problem, you can just upload the release apk while making a new repo release on GitHub. I also do it, that way people who visit my repo can try the app then and there and it will be really helpful than uploading or hosting the apk somehwere else.
Also to make it easier to update the apk in future repo releases, I made a library which detects new repo release and downloads the latest apk. You can check out my library here. Hope this will be useful to you as well.
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.
I want to publish a beta version of some app of mine on the android market and face the problem that I cannot upload an app with the same package-name twice - not even with a different certificate. But having 2 package-names for release and beta version makes a lot of trouble ( e.g. having to change references to the different location of R every time )
Is there a best-practice/good workaround for that problem?
Yes call your package
com.you.app.beta
Fix all the bugs in this app. Then when you go live just copy the project refactor your package name (Eclipse CTRL+ALT+R on the item) update your manifest and re-release. The beta package is then not supported by you any more and you can even click unpublish, or release an update that shows an upgrade screen linking to the new package (i.e. new market url)
com.you.app
What's the problem?
since IO 2013 there is now one option to do beta-testing:
https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
We upload but do not publish beta versions of our apps. Once uploaded, the market will assume that any incoming license check is being done from a legitimate installation that was side loaded and will respond "licensed". So our beta testers can test a full implementation, including the licensing code. (Test account responses are also honored for uploaded but unpublished apps.)
When the testing is complete, we upload the release version using the same package (and signing cert), and publish.
I came across this blog which discuss Android Beta Testing and feels like that the better way. So just sharing with you guys. Hopefully it will be helpful for all . http://zubhium.posterous.com/android-app-beta-testing
Pushing app with com.packagename.beta is not a very good idea. It creates unnecessary confusion and secondly you don't want to get unstable version in market to get bad ratings for your brand.
Why can't you just use the same package name for the release version? Doing so would also let your beta users get notified of an "application upgrade" (that is, the release of the final version).
If you do want to use different package names, one way is to make an ant script that you can run that changes all the imports, and the manifest.xml, to use the new name. So you have your code that you develop in, then you can just run your ant script whenever you're ready to upload to the Market; say "ant beta". This would rename all your packages from com.company.app to com.company.app_beta, and you could release it on the Market.
It is good practice not to upload a beta version to the Market. You should only upload production ready applications to the Market, as this is what the users expect.
If you want to beta test your application, it is better to use a private distribution channel.
If you use the same certificate, then an application with the same package name will be considered as an update to a previous one. Users will be able to update easily.
I have an app on the Android Market, and recently I was made aware that another publisher had uploaded it under a different name, and was giving it away for free.
I've never uploaded an apk that wasn't signed correctly in the official Google manner. What I'd like to know is, is code signing intended to prevent this kind of thing happening?
Can someone remove the license and add their own? Is this easy to do?
They'd have to do more than just take your APK and upload it under their account. The namespace which you create is unique to your application. So, at a minimum they've reverse engineered some of your code.
As long as somebody is able to pull your apk off of their device and re-package it, nothing can really stop them from uploading it to the market on their own. Report it to Google and you may want to look into using the licensing service.
There is nothing preventing someone from doing this. All code signing does is ensure your application has not been modified from the version you published. i.e. a modified version cannot be installed on top of an unmodified version. If your app has simply been republished without modification, it is no different from your own version. Only the distribution source has changed.
You will need to implement some kind of licensing to prevent piracy. Android code signing is not like iOS code signing (where apps on the store as actually signed by Apple, not just you).