I have 4 signed release build apks of different architectures (35.MB on average is size) and had submitted for Alpha and Beta testing. While as a tester I downloaded the app from Google Play Store, but it was showing up 111 MB file while I was downloading it.
I thought it was how it worked for Alpha and Beta, but while I move the same release to production I faced the same issue. Now the app is on production but I am worried the users may not panic for 111 MB app which was earlier as 35.40 MB on average for all devices. Refer screens below.
Earlier I never posted the builds for Alpha and Beta testing, but this time there was a requirement for Upgrade activity.
This one shows up in one of the apk release details:
Info for the the same build:
This SO post could be the answer.
If that is a paid application, you may implement the Google Play licensing service, else (if free), implement your own copy protection scheme.
You may check this github post for more related issue.
Hope this helps.
Related
The situation
An app is released to Google Play as apk. First release back in 2018, several apk updates since. Now as is required from Google (pr. August / November 2021), the format needs to be app-bundle instead of apk when updating the app.
I successfully build the app-bundle and uploaded to Google Play Console. I released the build on 'internal test' track. All seems to be just fine.
The problem
However, no matter what I do, I keep seeing and downloading the latest apk-version instead of the new app-bundle version.
The latest apk version-code is "400126/200126" (x64/x86).
The latest app-bundle version-code is "131".
I first thought it could be a problem that 131 < 400126 (obviously), so I created a new release on the 'internal test' track without any artifact - in the hope that could sort of 'reset' the state - and then creating a new release with the "131" app-bundle again. However no luck in getting the app-bundle version on my devices.
Besides I tried these things with no luck
Unsubscribing and re-subscribing the 'internal track' a dozens of times.
Removed and re-added my Google-id email from the set of 'testers' on Google Play a dozens of times.
Cleared the Google Play cache on my devices.
Installing from Web a dozens of times. Always ending up getting the latest apk-version installed. But actually, when entering my App on Google Play Web, it still shows the latest apk-version, even though it tells me (correctly) that this is a beta-version (indicating that I, indeed, is registered as internal tester). This, at least, is consistent with the fact that I keep download and finding only the latest apk in Google Play app on my phone-device, and not the app-bundle.
BUT! How do I get my new app-bundle available on the 'internal test'? All suggestions are more than welcome. Thanks!
I ended up creating a ticket at Google Support. They quickly replied that I simply needed to increase the build-number to > 400126. That makes a lot of sense.
However, we had another app where this was not needed - but that might be because the app had not yet been promoted to production at the time?
I am aware how to upload multiple apks in Google Play Console as described in this youtube video.
This approach works so far.
However, I have my doubts it won't work anymore after August 1st, since Google Play Console won't accept 32 bit apk anymore and the current process as described in the above link is as follow:
Create Release
Upload 32 bit APK
Save, Review and finally
Start Rollout to Production - I suspect this step won't pass for 32 APK after August 1st
Create Release
Press Retain to keep 32 bit APK
Start, Review and Start Rollout to Production
So my question is - if I would like to keep releasing 32 & 64 APK as alternative of apk bundle (which is Google Play Console preferable but not yet mandatory option), how shall I proceed so I can release 32 APK along with 64 one?
You can upload two APKs in the same release as long as the APK targeting 64-bit has a higher version code than the APK targeting 32-bit (Google Play will complain if you don't do that). All the documentation on this topic can be found at: https://developer.android.com/google/play/publishing/multiple-apks
A simpler alternative is to upload a single Android App Bundle in place of an APK, and Google Play will take care of generating the APKs for each of the native architecture your app supports. The documentation can be found at: https://developer.android.com/platform/technology/app-bundle
I'm trying to beta test an sdk that I uploaded to the developer console 2 days ago.
I have an apk currently published on production and a newer apk published in beta.
I followed all the steps (created google+ group, added testers, etc) but when I get to the https://play.google.com/apps/testing/***** page, it send me to the production app to download with an older version number.
So basically, I cannot download the beta apk from the play store, it makes me download the production version.
Has anyone ever had a similar experience? I'm trying to test out in-app purchases, but this is really putting a damper on my progress... any help is greatly appreciated!
Thanks!
In case anyone has the same question I did, the answer was simply to wait.
I have a production app on the Google Play store. I have also released a beta version to a limited group using the Google Play beta feature. However, if I make changes to the production app, I then need to re-build and re-release the beta app because it gets overwritten by the new production version. This is very frustrating when I want to make some bug fixes on production without changing the beta. Is there any way to release a new production app without invalidating the current beta?
The basic problem is that Google Play updates based on build number (versionCode), and doesn't care which channel the .apk comes from.
Your only option is to not pickup sequential build numbers, but instead leave gaps. For example if your prod is versionCode="10", make the beta build versionCode="20" which will give you the chance to publish nine more minor prod releases before you hit the issue of invalidating the beta build.
Though there are two problems with this approach:
- Obviously it does not scale very well.
- It makes it hard to manage the build numbers, as now you have to keep a record of what build has reached which build number.
- If you don't invalidate the beta build, your beta users will still have the bugs you just fixed in the new prod build until you upgrade them.
Note that if you don't have permission changes that prevent auto-upgrade, invalidating the beta build and publishing a new one is not that much of an issue; most users won't even notice that they were upgraded (unless your app tells them explicitly).
I believe the reason google requires that your new production version of the application override the beta is due to the basic development cycle. Typically applications start in the Alpha stage, then beta, and finally end in production.
The beta version is overwritten due to the fact that the next logical step in the cycle from beta is release. When you re-submit the beta version, it would be the current code revision as the production version, alongside bug fixes that are being tested.
The scheme is very simple:
Google Play uses versionCode to indicate the apk currently available to a user. It doesn't matter if it is a production or a beta release. Also it is not allowed to upload a build with versionCode lower than it was in some previous build.
So in your case you need to upload a production version and then upload a beta release (even if its only change is versionCode). Occasionally some of your beta users may download a production release, but they will get the beta release a bit later anyway.
I've been distributing beta APKs to my testers with the LVL checking enabled, and I'm getting many reports of the app behaving as if it is not licensed.
This is not a problem in the current version that is in the Play Store, and the LVL checking code hasn't changed since my last release.
I'm wondering: will the LVL library return 'unlicensed' or behave unpredictably on APKs that have not yet been uploaded to the Android Developer Console? Is it possibly these problems will go away when this update is downloaded from the Play Store?
I ended up pushing my update live, and I've not had any reports of the licensing failing with this code.
As was suggested in this thread, commenting out the versionCode/mVersionCode check in LicenseValidator was likely the reason my beta APK was failing. Hope that helps someone.