[mnstngr]

Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy.

This is well-known to anyone who has been doing Android development for a while.

[jarm0]

Totally understand that a roll-back is more complex, but it doesn't explain why pulling back/pausing/deleting/yanking a release is not possible either - customers who got the newest faulty release can uninstall & install to get the previous version back (no need to worry about incompatibilities here) and the ones who did not get the updated version yet can stay using the old one until a new fixed version will be released.

[mnstngr]

This is exactly what staged rollouts are for. The author ignored that best practice. You can halt any release as long as it is in progress. Once you mark it complete (defined as rolled out to 100%), you can’t roll it back.

Each track in Google Play (alpha, beta, canary, prod) can hold up to one release at a time. It would get really confusing if it allowed more than one. And with the other rollout safeguards provided decelopers, it’s quite possible and very easy to do exactly what you’re asking for.

[eviks]

"may" is the reason why not supporting rollbacks at the OS level is baddesign