I have this problem that I was wondering about for a really long time, but quite surprisingly I was not able to google out anything on the topic. I say "surprisingly" because this has to be a very common scenario.
The question is more about the idea how google play application release notes are supposed to work.
Say I publish updates of my app on Internal track, or Alpha track quite often, but most of the updates do not make it to production because, obviously, bugs are found, fixed, and then new update is published and only after it all works OK, does the app get to the production channel.
Now for each of the testing releases there are release notes of course that contain only a a few things, but then the accumulated changes for production contain a lot of changes. However, when I finally promote a release to production, only the changes of that specific version are pre-filled in the release notes field. So it contains the changes against the latest testing release, but not all the changes that happened in all testing versions since the last production update.
There's this "Copy from previous release" button, but quite surprisingly, it only lets you select one version and not multiple versions (I would use it to pick all the testing releases since latest production and expect the tool to merge all of the release notes in one list) so that doesn't really help. Now I understand that this is not a universal solution as changes may come and go, and you could also be just fixing bugs that were introduced in between the testing versions, so it would not make sense to list such bug fixes in production release notes. But you could still merge those and then go over and review the changes manually.
But again, I am not really asking for a technical solution on how to accumulate the changes, but more about the philosophy of how should I tackle this kind of problem in general. How is this problem usually solved?
Thanks!
Related
I implemented in-app updating in Android, and to do so I added an internal testing track to make sure the update process worked as intented. All worked.
I set this internal release version number to be really high to distinguish it from production. For example, production version is 1.X.X, internal testing is 104.
I no longer need this internal testing track so I made it inactive and removed the testers (i.e. me).
However, the in-app update information still shows availableVersionCode=104. If I accept the update in-app, nothing actually downloads whereas it did when active.
How can I either remove this version entirely from internal testing, or stop in-app updates fetching this version?
I understand a last resort is to up production version to > 104 but I really do not want that.
Edit: It seems after a few days, the app no longer pulled in this testing track (but it did not stop immediately). I would still like to know how to delete internal releases.
After removing a testing track, the build actually disappearing from Play Store can take some time (up to 3 days in my experience). This is an undocumented behaviour and caused a lot of confusion for me the first time I encountered this issue as well. I generally follow a few self-made guidelines to lessen the confusion among the development and testing teams.
Try to keep just one testing track for all teams. But if you still want to have multiple testing tracks open, then I would suggest to have each tester added to just one of each track.
Release a new build on Production Track with an updated version code when you are done testing the in-app update feature.
Use Internal App Sharing to test in-app updates instead of using any of the testing tracks like described here.
Is it possible to end an app in beta (also known as open track or early access)? I currently have my app in internal app sharing, and decided to release it to Alpha - but noticed no differences, so tried to release it to Beta. But after reading supporting documentation which explains the difference between Alpha and Beta, I discovered I don't actually want to be in Beta yet.
There's no clear indications anywhere to say I can remove it, I've removed testers on the Beta release and even done a new release with no APK. But it's still accessible on the Google Play Store.
Am I doing something wrong, or is this genuinely by design?
It is by design, what you can do is, go to Manage country availability and uncheck all countries, then it won't be available to
Turns out after playing around with settings, it was literally down to my expectations for things to happen almost instantly similar to TestFlight on iOS. Google can take up to 3 hours to process an update, and I wasn't aware of this.
If anyone else has a similar issue - wait. But the conversation with Abubakar are useful ways to hide the app, but it won't be instant, so be patient.
There is option to remove testers in the Beta Manage page. Just Expand manage testers and click on Remove testers button.
I've been developing my first app for work and am having trouble removing an earlier version from the Google Play Console.
My first release was version 2, which I released on the Internal Test track, as much as an experiment to understand the working of things. I have subsequently release the app up to version 8, always targeting Alpha/Closed Track and had no problems with them.
However my first release, the one in Internal test track, simply refuses to go away. All the others I have found I can click MANAGE then RELEASE TO BETA then DISCARD (at the bottom) and they go away, but not this one.
Can anyone help me with this please. I have to say that the websites for releasing to both Android and to Apple do leave much to be desired - a bit of a baptism of fire to get your first app out there, even just to testers.
It is possible to discard the release by creating a new release without a bundle or APK, inserting a release name, which is required, and completing the process.
We found that while there is no remove, we had to add an empty version which replaced the test version. This was a huge problem for us as the test version was in violation of permissions rules and our production code was not, but the production app was pulled from the Play store... Yikes. Adding a remove or delete would be soooo much more intuitive.
Sign in Play Console
Choose your app
Click Release Overview (Left pane)
Select the release version that you want to stop
View track
Pause track (Right upper hand corner)
I would upload your next alpha to the internal test track and promote it to the alpha/closed track. You will still have a build in the internal test track, but at least it is a relevant build.
Tried and worked.
Unfortunately, there is no straightforward way to delete or make a version inactive. The simplest thing you can do is as follows:
If not done already, create a version of your apk/aab you want to really release and upload it.
Go to test tracks where old versions are used. Create a new release in that test track.
Instead of uploading a new apk/aab, just pick the latest one from the 'Add from library' option.
Roll out the test track release.
It will simply mark old versions (which were used in test tracks) as inactive and only the latest one you uploaded will remain active. You can verify it on the 'App bundle explorer' page.
Now you can submit the app for approval.
End a test
To remove users from your app's test:
Sign in to your Play Console.
Select an app.
On the left menu, select Release management > App releases.
Next to the test that you want to end, select Manage.
Expand the "Manage testers" card.
After ending a test, testers won't receive updates but the app will remain installed on their device.
To remove a closed test track that you created, select Deactivate track. You can access deactivated tracks on the App releases page in the "Closed tracks" section.
To end an open, closed alpha, or internal test, select Remove testers.
Go to manage internal test
Manage testers
Remove all testers
This is the safest way
Haven't found how to delete a build - as been said, we just upload a newer version of the app with higher build number into the Internal track and propagate it through Alpha to Production. So just overwrite the unwanted build.
You can mark them inactive after pausing it.
I believe that what most are saying is that Google needs better way to disable or continue testing an obsolete or bad build when the developer knows it's a waste of time. It seems that there are ways we can force it, but it's not the ideal way. I agree. I don't want people to waste their time or bad-mouth my app because of unclear definitions on our side. We are in the 21st century, but everyone makes mistakes. If Google path is ideal, then make the documentation reflect that.
You don't need to discard it. Testers will always get the highest version code they are eligible for.
Is there a possibility to release an app on Google Play without it being 'officialy released', advertised etc.?
Let me explain. I would like to release my application to some (quite large) audience in order to build a database. To these users I would like it to be available without the need to join any beta testers group. In the same time, to average user the app is not going to be very useable. So, at first I would like to narrow average users installing my app as much as possible. It would be great if I could postpone Google Play featuring it on any lists.
I hope I made myself clear. Any ideas?
You can release your app as a Beta release. It will be limited to a certain audience that you define in Google Play (there is a Users administration feature dedicated to that). This sounds like a normal process for what you are willing to achieve.
Before that, you can also release your app as an Alpha. The principle is the same but the group is different. Alpha is perfect to get rid of most of the bugs your application may have.
So, to summarize, the process is:
1- You build your app, and test it on your own
2- Then you release it as an Alpha to a very small group
3- Reiterate 1- and 2- as long as you have bugs reported by the Alpha testers
4- You promote your app as a Beta to another group, usually larger. Data is created and more bugs, less obvious, are reported
5- Reiterate fixing and 4- as long as you have bugs reported by the Beta testers
6- You promote your app as a Production release. Now everybody can use it.
You may also, once all this done, release your app with the words "(PUBLIC) BETA" in its name and description. Once the public beta testing done you'll just have to remove these words to let the users know this is no longer a Beta but a Stable version.
Caveat: by doing this way, you'll have to expect your app to receive negative comments and rating from users who didn't get this is a beta, or what a beta is.
We're moving to another Google Play developer account, so I faced the following problem.
App with LVL transferred to this new account returned LICENSE_ALLOW, until I've uploaded a new version with a new public key from our new Google Play account. Now it returns ERROR_NOT_MARKET_MANAGED.
I hope it's because Google Play didn't register a new uploaded apk yet (while in Developer console I see a new version) - according to Android Market Doesn't Show My New Version, but usually you must only upload an apk, even not publish, to get rid of this ERROR_NOT_MARKET_MANAGED error.
Any suggestions are welcome!
Relax people, after approx. 30 minutes after I uploaded it, app finally started to answer LICENSE_ALLOW!
So if you face the same problem, don't worry, just wait for a while.
I've been dealing with the same issue; I'm not sure it's quite a safe as "relax" though :)
Two concerns I'm investigating:
1) It seems wrong to me that LVL reports this an application error rather than a license violation. So be careful how you treat this in your policy, google's sample code implies that an app error is a developer error and is something your should either fix, or at least not penalize the user for. However if you ignore this in production builds it may provide a way for a hacker to disable your licensing by altering the app version to > the released version. (I don't know how feasible this hack is, but I have run into all kinds of crazy hacks already in CN so it wouldn't surprise me)
2) As pointed out some other threads e.g. Android "Not_Market_Managed" error this creates a problem when publishing new builds. I have not yet been able to make this turn off by saving a draft apk into gplay, so if I actually have to publish to turn this off that would be bad news as there's no way to test this without releasing.
The strange thing is I do not always get this error with new dev builds. Another post speculated that LVL has some rule like you can be +1 over the published version code without triggering it. I hit this error when I had done two released quite close to each other; maybe they are right?
but usually you must only upload an apk, even not publish
From my experience, for LVL to work, you absolutely have to publish the app, even if it's with as much as a single alpha build. (Even though the documentation says uploading a draft should suffice -- idk maybe I was unlucky and it was a temporary malfunction)
Considering #mvk's point 2)
bad news as there's no way to test this without releasing.
This can be remedied by publishing the app with no Production build -- this way the application doesn't go public but you can still test all the Play Store-bound stuff.