I'm the OP and thank you for thinking along with me here. As stated in numerous replies already then I totally agree that I could have done better in terms of testing things out - of course, there's always room for improvement in that regard. There was a deadline set by Google (again, first time I heard about it was at 18th of August, not before), change seemed trivial at time and since app worked on an old Android version as it was before then I didn't expect it to fail so miserably. Again, I'm not a seasoned Android dev, but have 15+ years of experience in software development in general so I have some expectations how things will work or not and what to expect and be afraid of. I really didn't know that "best practice" is to do a staged roll-out of "99.99999999%" to have a way of partial "yank" possibility of the latest release. To find out that there's no way to cancel/delete a latest release to fall back to previous working version was just something I did not expect in my wildest dreams (I guess this is something you only learn during situations like these). Yes, everyone can blame me for not testing every functionality with every Android version and I do the same, but please open your eyes and understand that the way releases are currently handled by Play Store is not a sane person would do outside of Play Store. Everyone will have a problem like this at one point and I do hope that this article will and thread in here will lower the number of developers experiencing situation similar to this.

> What if it worked on the latest version but not others? At what point do you draw the line?

This is a poor excuse. Even if it were a web app, you would still need to test on multiple browsers.

Doing a smoke test on a new release is just basic professionalism.

And having a phase roll out with a rollback is also not a new concept.

but bugs slip testing all the time, that why even “the pros” have to use staged deployment trick, which takes us to the root problem: releasing on android is like running through a minefield.

there are a million “shoulds”. just because you know most of them or can afford to account for them on every release doesn’t excuse google for the maintenance nightmare that the android ecosystem is.

I mean yes there are a million “shoulds”. But logging into your app to see if login works is kind of basic. It was the definition of amateur hour.

> And having a phase roll out with a rollback is also not a new concept.

Having a quick revert is also "not a new concept". Most modern devops practices focus not just on Mean Time to Failure, but Mean Time to Recovery, and a quick revert is a critical part of that. Even Google's own SRE best practices encourage that.

>At what point do you draw the line?

It is inexcusable that for a task to port an app to Android 13 (targetSdkVersion 33) that the app is not tested with Android 13.