Testing Titanium's In-App Billing module for Android - android

Does anyone know how to properly test live android in app purchases in titanium debug mode?
Previously, I was successfully able to test live in-app purchases and create real transactions when debugging from Titanium Studio. That was because previously, I had incorrectly created my Google Play store listing using the development .apk as per:
http://developer.appcelerator.com/question/123704/what-keystore-does-titanium-studio-use-to-build-android-app-during-development
and therefore, Google play had associated my dev_keystore with my in-app purchase codes.
However, when I then tried to build and upload my production release using a generated keypair/certificate as per:
wiki.appcelerator.org/display/guides/Distributing+Android+apps
the Google Play store then (correctly) rejected my production candidate complaining that my APK had been signed with a different certificate to the one that was used in the original upload:
You uploaded an APK that is signed with a different certificate to your previous APKs.
You must use the same certificate. Your existing APKs are signed with the certificate(s)
with fingerprint(s): [ SHA1: ...:9D:47:9F ] and the certificate(s) used to sign the APK
you uploaded have fingerprint(s): [ SHA1: ...:5D:E2:4E ]
As such, I had to delete my google play store listing and recreate it from scratch using the signed APK as described by the appcelerator guide referenced above.
This has now resulted in my in-app purchases becoming associated with the signed APK which means that now when I am testing a development build of the app and attempt to make an in-app purchase, I am greeted with:
This version of the application is not configured for billing through Google Play
It is not a timing issue (I have waited 24 hours) as suggested by:
stackoverflow.com/questions/11068686/this-version-of-the-application-is-not-configured-for-billing-through-google-pla
It is occurring because the dev_keystore in my development build doesn't match the certificate associated with the in-app purchase codes.
I imagine I might be able to get around this if Titanium studio allowed me to specify my apps certificate certificate when debugging as per:
http://jira.appcelerator.org/browse/TISTUD-1214
In the interim, a testing workaround to debug purchases is that I have created an additional and separate 'test' duplicate google play application with identical in app purchases and associated it with my development .apk (instead of my signed apk). During testing, I then just need to change:
require('ti.inappbilling').setPublicKey(...)
to point to the test project instead of the real one. Then, when i'm comfortable with the payments, I will build using the real key.
This is a really sub-standard workaround and i'm hoping someone has a better way of doing things.

TISTUD-3669 adds the capability to specify the keystore used for non-production builds. Using this, you won't need the workaround you came up with.

Related

Is it possible to sign App Center APK's with the same key as Play Store AAB?

This is actually being done in Xamarin but thats technically not specific to the question.
I've been running a build CI/CD that currently was signing (with my own custom key) an APK and deploying it to App Center (its actually building an AAB and then making a fat APK from it fyi).
This has all been working fine for months for internal, daily builds of the app.
Now I'm deploying release candidates to Google Play Console and I have my CI/CD deploying AAB bundles.
The first bundle was signed with this same key and as I understand it that key is now the 'upload key' for google play, but because I'm deploying AAB (and I believe, by August we HAVE to), Google insists on signing the AAB for me.
This now means, if someone in our team installs the Internal track AAB, they then can't install an updated test build from AppCenter over the top as they are signed differently.
Is there anyway around this? Can I get the key google signed the build with and use that when uploading to AppCenter (I realise our team will need to at least uninstall an older signed build form AppCenter to then get updates but will be fine from that point out).
Ideally I want to be able to install updates from AppCenter and Google Play over the top of each other as long as their versions are incrementing.
There is unfortunately no way of requesting the signing key from Google. If you didn't provide Google with the signing key when you initially enrolled in Play Signing, then you will likely never have access to the signing key.
What you can do however is download the universal APK signed by Google (from the Bundle Explorer in the Play Console), then upload it to AppCenter. But I'm not sure if there is a download API available today to automate this operation on your CI.
With the thanks of Pierre's answer I didn't realise there was an option to create the Play signing key from an existing key using the pepk.jar
I redid the app this way and its working installing builds from AppCenter and Google Play on top of each other!

Android application distribution after Google App Signing

Now we can use "App Signing by Google play" to sign our apps and will not have to manage keystores. But we use Jenkins for build creation and then share it with customers for testing via HockeyApp.
How can we integrate Google's App Signing along with Jenkins and HockeyApp for testing before actual release?
If you use Google App Signing, then the actual key to sign your app is only known by Google. That doesn't prevent you from signing it with another key and distributing it elsewhere, but it does mean that if you do, your users won't be able to update that copy via Google Play. If they're in a beta and supposed to be getting all the builds from a beta site, that's ok.
By the way Google Play also has beta functionality, it may be easier just to do the beta through them.

After App Signing - IAP not working

As per latest Google Play Store, we have enroll our applications into App Signing.
After this enrollment our IAP product is not working and showing error as :
"This version of the application is not configured for billing through Google Play".
WE HAVE ALREADY UPLOADED NEW BUILDS FOR ALPHA RELEASE.
Still, we are getting this error.
Also we have checked that if we sign an APK with older keystore.
We are able to see the IAP dialog correctly.
Please suggest.
I have found this,
If you create sign APK from new keystore.
And tried installing new APK rather than Play Store.
Then IAP will not work.
Previously this is working as expected.
Also installing new APK from anywhere else. You are not able to test Application upgrade scenarios.
That means if you have previously released app from old Sign APK then you enroll into App Signing and test upgrade scenarios from APK which has been uploaded on your private server, then your application will not install on the device.
The solution for this is to each time you want to test above scenarios, you should have to upload sign APKs to Play Store (Alpha).

apk with different certificate

I'm facing a problem with the certificates, two weeks ago I made a backup of my pc, I save the project and the key.jks now in a different computer I'm trying to upgrade my app but It says this:
Upload failed
You uploaded an APK that is signed with a different certificate to your previous APKs. You must use the same certificate.
Your existing APKs are signed with the certificate(s) with fingerprint(s):
[ SHA1: 90:F7:82:F9:C0:52:98:D7:EA:F9:9C:79:B9:00:1D:61:7E:5B:C5:06 ]
and the certificate(s) used to sign the APK you uploaded have fingerprint(s):
[ SHA1: 7B:67:D7:7B:C6:EB:53:49:94:41:86:89:C0:7A:2B:89:5B:0B:AC:A8 ]
Is there a way that I can fix this problem, the app has active users and I don't want to loose them
You cannot update your Apps, if you lost your APK Key. That is said also on Google's official Guide, to why it is soo important to save your API Keys.
You could try and contact Google Play service, but I doubt you'd get a positive respond or any respond at all. Best is to delete the App and re-create it and post it.
Otherwise, you can leave it there and you won't be able to update it without the original Key.
Here from official site Signing Your Application:
Warning: Keep your keystore and private key in a safe and secure
place, and ensure that you have secure backups of them. If you publish
an app to Google Play and then lose the key with which you signed your
app, you will not be able to publish any updates to your app, since
you must always sign all versions of your app with the same key.

Can not upload updated APK to Google for game made with Unity

We have recently purchased a game from another company and have done some updates to it with all the information converted over to our side.
The game is made and updated using Unity and is for the Android platform.
After doing all of these updates in Unity and using the Keystore that they supplied us (along with the passwords for the Keystore and the Key), we built the APK with no errors.
When I go into the Google Developer account and try to upload the new APK for testing, I get an error at the end of the upload that tells me that the certificate used in the APK is different than the one originally used on the other APKs so it can not upload the APK.
I have searched everywhere and people are saying that it is the Keystore and the key but I have the correct Keystore and Key because Unity would not allow me to build outside of debug testing without it (I tested this by putting a wrong password in for the Key and Unity gave me errors saying I had the wrong password).
I am using
- Macbook Pro with OSX 10.8.3
- Unity Version 4.1.3
I have all the correct SDKs for Android and the manifest package name matches the Bundle Identifier for the project. (The Bundle Identifier also matches the correct one attached to the Google Dev site.
Please help.
Unity will not stop you from building out an APK signed with a keystore that is different that what a previously built APK was signed with. So the unfortunate truth is that the version currently on Google Play was indeed signed with a different keystore. I've run into this problem myself in the past.
If you don't find the keystore that the app was originally signed with, you will need to pull down the current app and upload a new app.
I try to follow the practice of making the sure the production keystore is stored within the project's repository in an easy-to-find location.

Categories

Resources