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
Related
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?
I want to use the new in App billing, but I am using the multiple APK feature in the play console, so the new console which is where you go to get that key doesn't yet support my apps.
So how do I get such a key? Has anyone figured this out? Question was also asked here:
https://plus.google.com/+AndroidDevelopers/posts/R8DKwZDsz5m
Deactivate the APK on the old console, then switch to the new, copy the license key, and then switch again to old design and activate the APK again.
It sucks doesn't it? There is currently no way to get the key if you are using multiple APKs. I was told it should be fixed 'soon' on G+, not much to do but wait...
v3 feels unfinished and we still don't know how well it works in practice. I would evaluate it in a new (test) app for now, but hold off upgrading existing apps for a while. Although the inventory/get local price is nice to have and it does work synchronously (you don't have to wait for a GCM notification for purchase success, and those tend to get lost), which should bring up your success rate a bit.
BTW, the key is automatically generated, so it's there, you just cannot get to it. Another thing to watch out for is that v2 requires Android 2.2, so if you want to support 2.1 (or 1.6, but that's less relevant) you have to keep one APK version with v2.
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.
Amazon's documentation is surprising lacking in information about the submitting binary process. From what I can tell, you submit an unsigned binary and they wrap it in their own code and produce a signed apk?
This leaves several questions:
Does the Amazon App Store perform a zipalign for you?
If you have your app in the Android Market (Google's) already, is it recommended to use the same package name or a different one? Does it make any difference?
I also saw elsewhere, that they offer the option to download the apk they prepare and sign it with your own key. Is it recommended to take this and then sign it with the same key you are using in the Android Market? Does it make any difference?
Are there any other considerations or pitfalls that one should know before diving into this process?
Yes. Amazon wraps your binary with code specific to their appstore that allows them to collect analytics data and enforce DRM. The app will be repackaged after that.
You should use the same package name. The Amazon distribution agreement currently has a number of provisos; e.g., that your app is not priced lower on another app store. They also do occasional checks to see whether the version of your app on the market is up to date. These checks are primarily done using the package name; changing the package name of your app could easily be viewed by them as a means to evade the terms of the agreement.
No. There may be good reasons why one would want to do this, but none that I can think of. By default, Amazon signs your apk with a signature that is specific to your Amazon developer account.
Other:
Read this. In particular, ensure that the app links correctly to the Amazon app store and not the Android market, or others. I don't have inside data, but I'd wager a fair amount that the vast majority of submissions that Amazon turn down fall afoul of that requirement.
Edit: Point 2 is no longer correct; see comment below.
Here is the reply I received from the amazon mobile app distribution team for a question concerning whether to submit signed or unsigned apk's:
"You can submit signed, or unsigned binaries to the store - we will then apply our signature to your app in either case. If you need to sign your app with a known signature (if you are using Facebook authorization for example) you can choose to upload your app using our self signing process (you will need to ask us for this to be enabled for you)."
The most straight forward way to submit an app is to export your signed apk from Eclipse (all zip aligned are ready to go), then upload via the Distribution Portal using our DRM and signature.
For the latest update of my app I just took the same signed apk I previously released to google play, and it worked well.
I have only published two little applications that sell almost nothing, but both got aproved and I followed exactly the same procedure I follow for publishing on the Android Market: I just exported the signed .apk from eclipse and also used the same package name. So far I have no problems, so I guess it's ok.
You should zipalign during every build, as a matter of practice.
I use the same exact build process for Amazon as I do before publishing to Google. Only difference is an Interface's variable to determine the market link (at build time, if/else is compiled out).
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).