By default, Android Pay refuses to work in debug builds, which makes testing tricky. What we've done so far is to actually merge new code into a develop or hotfix branch so our build environment will make a signed APK which can be tested. This is not ideal.
https://developers.google.com/android-pay/get-started states
"Note: Our test environment will not return live, chargeable tokens in the FullWallet response, but will allow us to test your pre-purchase flow. You will see an Unrecognized App error on the Android Pay chooser until your app has production access."
which isn't too promising.
https://developer.android.com/google/play/billing/billing_testing.html suggests testing with specially configured static responses for "reserved product IDs", which would be a nuisance to set up and not a true test. The other option they offer is to publish the app to an alpha or beta channel, which would, of course, be a signed APK.
https://stripe.com/docs/mobile/android has a suggestion about "TEST_GATEWAY_TOKEN" but isn't really helpful in learning how to use Android Pay in test.
We even talked to a Google Developer Advocate, who did nothing but cut and paste some of the same documentation.
Is there any way to do a good test using an unsigned build? It would be wonderful to test Android Pay functionality successfully on a local developer machine.
No, there is not a debug mode option to that per docs:
https://developer.android.com/google/play/billing/billing_testing.html
set a separate machine with a CI server and have it do the alpha and beta builds for testing Google Play.
It is a pity but you have only one way to test IAP:
Grant testing permission to your google accout used at your device
Build .apk file.
Upload it to your account at GoolePlay as beta version
Wait until uploaded .apk processed
Try do to actions you need and check it.
If any issues - fix them and start from p. 2
Related
I recently came across a free mobile app security testing tool based on proguard called AppSweep. I uploaded an android debug apk for security scanning/testing to see any potential vulnerabilities.
It provides a way to upload an apk without signing up or needing an api key and it worked perfectly and I was able to address most of the severe issues.
However, I want to remove an already uploaded app-debug.apk build and I am unable to find an edit or remove functionality. Is this provided and is there a hard limit on the total number of apk uploads?
You can add your existing builds to a project or also delete them after creating an account. Then it will look like this:
Apart from that, there is no limit on how many APKs you can upload, some users even integrate AppSweep into their CI/CD pipeline and create a new scan for each commit.
I have been trying to test the purchasing of Play store subscriptions on my device, but I have not succeeded despite following several step-by-step guides[1][2][3].
My ultmate aim is to test subscriptions on my USB connected device by building and installing the app with Android Studio. Unfortunately, it seems my only option right now is to to publish the app to the Alpha track on the Play Store, wait a few hours and download it every time I make a change.
The subscription products are queried successfully using BillingClient.querySkuDetailsAsync, but when I launch the billing flow (via BillingClient.launchBillingFlow) I see the following alert on the screen:
Error
This version of the application is not configured for billing through Google Play. Check the help centre for more information.
OK
I also see the following in the console:
W/ProxyBillingActivity: Activity finished with resultCode 0 and billing's responseCode: 5
W/BillingHelper: Couldn't find purchase lists, trying to find single data.
W/BillingHelper: Received a bad purchase data.
Couldn't find single purchase data as well.
The response code 5 indicates a developer error:
Invalid arguments provided to the API. This error can also indicate that the application was not correctly signed or properly set up for In-app Billing in Google Play, or does not have the necessary permissions in its manifest.
My app is published to Internal, Alpha and Beta release tracks with the same version name and version code as the locally built APK. In the Play console, I have created a License Tester and added it to the Alpha track's testers, then opted the tester in to the Alpha track via a link. On my device, I am logged in with the tester's Google account.
I have tried building an APK signed with the release certificate, with a matching version name & code to the APK published in the store. I was at first using the "Run" and "Debug" buttons in Android Studio, but discovered that they built an unsigned[7] APK no matter how I configured the signing configs. Instead, I build using the Build->Make Project menu item, and install the resulting signed APK using ADB[5]. The "Active Build Variant" is set to "Release".
It occurred to me that it may be impossible to sign a locally built APK with the same key as the APK distributed by the Play store, as my app has "Play App Signing" enabled (which causes Google to re-sign the APK using a different key, which is inaccessible to me). However, there is a thread on StackOverflow which suggests other have had success even when using Play App Signing[6].
I have also tried waiting several days between publishing a new build to the Alpha track and trying to purchase a subscription, as I read that the Play Store sometimes takes up to 24 hours to process builds.
I am using Android Studio 4.2 on MacOS 10.15.7, with a Samsung A5 phone for testing.
[1] Selling subscriptions
[2] Testing in-app purchases on Android
[3] Checklist on Stack overflow
[4] "Run" with signed APK
[5] Install an APK via ADB
[6] Testing In-App payments with Play App Signing enabled
[7] Verifying an APK is signed
Update 2022
I never found workaround for this on my Samsung A5 running Android 8. However, I purchased a Samsung A52 (running Android 12) and it does not exhibit this problem.
you need to increase the version and upload that version as beta publish.
mostly duplication
please check This version of the application is not configured for billing through Google Play
If two apps differ in the signing key or in the package, then Google Play considers them different applications
Both debug & release versions should use the same signing key, I can make test purchases while debugging via USB on Android Studio with no problemas
something like this on the app build.gradle :
buildTypes {
release {
signingConfig signingConfigs.mykey
debuggable false;
....
}
debug {
debuggable true
signingConfig signingConfigs.mykey
....
}
}
There's a utility called "lucky patcher" which modifies app code in order to allow for bypassing in app purchases (yes, it's used for piracy, but I'm pretty sure it's not piracy to bypass your own app). You could try using it to test your app.
And in case you haven't already, once you're done, protect against it by following this: Lucky patcher, how can I protect from it?
I need to deploy apps to app store for each branch. I have DEV, PROD, Staging and UAT environments. Each has a separate branch. What i need to build and deploy each branch to separate app in app store.
The problem is I can only add a single app in app store connect. If i try to add again, it says 'already connected'.
Anyone knows any solution for branch based deployment to store??
I couldn't find any articles mentioning these kind of scenarios.
Scenario
Single Repo
Dev Branch ---> Dev_App
Staging branch ---> Staging_App
I have separate apps in app store for each environment.
I would think it is normally discouraged to have multiple versions on the AppStore. I would think you would run DEV locally, STAGING on devices that download a release build from AppCenter, and PROD on the AppStore.
If you really wanted different versions on the AppStore, you would probably need to change the BundleIdentifier per release. You can find this in the Info.plist file.
Hi I see that Android Studio allows to build different APK for instant and installed app.
Does Google Play Developer console allows to upload different APK for instant and installed app there ? How does it manage ?
Does Google Play Developer console allows to upload different APK for instant and installed app there ? How does it manage ?
Yep. You need to upload different APK for instant and installed application. Google Play Developer Console has new menu Release management > Android Instant Apps to release instant app in addition to installed app.
You should go through this link to understand more Distribute your instant app
Yes, Play console allows you to add two different APK for the installable and instant app.
a picture is worth a thousand words
The developer console now separates your uploads by 'App Releases' vs 'Android Instant Apps', as illustrated by Pinkesh's answer. Better labeling would have been 'Installable Apps' instead of 'App Releases' in my opinion, as the later implies all versions. You are forced to use a different versionCode numbers for each type, even for otherwise identical APKs. The installable versionCode must be higher so the installable version will be an 'upgrade' from the instant version.
As to whether you would want to use the same codebase for both APKs ('bundles' now), like I do for my game app, the process has gotten better for arguing to do so. You used to have to do a 20+ step very code invasive process to break your app into three parts, installed, instant, and base modules here https://codelabs.developers.google.com/codelabs/android-multi-feature-instant-app/#0. For me, separate codebases would have been easier and less risky than this, but I still wasted a lot of time practicing with Google Codelab's example Topeka app before finding out it's all been depreciated. Now you can just add a separate module to store large resources and assets, flaging the module for just 'install-time' delivery, keeping the rest of your app under the 10G instant limit. You can include an 'isInstantapp' flag in your code to branch between instant and installable implementations.
This question already has answers here:
Difference between eng and user-debug build in Android
(2 answers)
Closed 4 years ago.
In Android, what is the difference between debug build and production build ? Also are there any other kinds of builds ?
Thanks.
I'm not sure if you are asking about the debug/production app or debug/product framework. So I will cover framework.
There are two different types of android framework build (the entire system image) user (aka production) and userdebug.
All standard device maker release their device with "user" build. Userdebug is meant for development and typically only built for in-house use.
Getting root:
In userdebug build you can simply do "adb root" to switch your adb shell to root mode. In addition, you can also do "adb remount" to remount the system partition to writeable mode for further control.
In user build, you can gain root access by installing special su binary and corresponding controlling app (like supersu). This way, while in adb shell, you can use "su" to gain a privileged shell. It is not as convenient as userdebug build.
In AOSP, you can choose the build type via the lunch command. For example
lunch aosp_hammerhead-userdebug
vs
lunch aosp_hammerhead-user
Well, the three little pigs had 3 types of builds but most of those didn't work out so well.
Anyway, you should see the docs here. When you build your app in the IDE you get a debug key and this is different than a production key. Having a debug build keeps you from needing to enter credentials each time but you obviously would want this prompt when you are ready to release a production build.
I guess this is what you are talking about but if you have something else in mind then please elaborate.
There is no difference between the two builds. The production build will run the same as the debug build with some limited exceptions. The limited exceptions relate to features that are signature dependent, i.e. they require you to register either the debug or production key to work properly. This would include most API's, like GoogleMaps or Facebook, and anything else that uses your build key to generate a unique identifier (think most OAuth2 products).
Your question is confusing/vague because in reality there is no difference in the two builds. Both will run exactly the same code. The difference is in who can run them and how you can run them. All android applications are signed when they are built by a unique key. This key identifies the app creator and is useful, in production, to ensure that the developer is not sending crap malware to those on the Google Play Store (or at least if they are we know where to find them).
Builds created in debug mode are signed with a debug key that is localized to a specific machine. This means if I build an app in debug mode to install to my phone, and another developer sitting right next to me builds the exact same code base to run on his phone our two applications will be signed with different debug keys. Why does this matter? Well, going back to the API registration process mentioned above, if I create our company wide Google Maps API registration using my debug key (bad idea) when my friend sitting next to me builds the app in debug mode on his machine he will encounter an error. The problem is that access to the Google Maps API is dependent on having an app installed that is registered with the right key. Because our two keys are different his app will not load properly.
Release/production mode allows you to sign the app is one universal key, not tied to a specific machine. This avoids the problem mentioned above. By using one key for all instals, every app will be able to access the same API's, so long as you register for them with your production key. This production key is not machine specific. You can send it to your friends (please don't) so they can sign apps as you.
That's pretty much it. You can read more about building and running apps here. If you have a more specific question please clarify.