I saw a very interesting report this week — from the reliable XDA Developers.com site — that the upcoming Android OS, Android Q, will let IT shops downgrade apps. That means that if a third-party app or even Android native app update presents problems, such as conflicting with other apps or opening a security hole or doing something else headache-inducing, IT can simply click and go back to the version from an hour or two earlier. This is massive.
IT shop managers are discovering in many ways that not owning and/or controlling key applications and environments that they used to control — think of the days before mobile apps and when the cloud was just something that periodically poured water on you — can be severely problematic at times.
On the iOS side, we’ve talked about how Apple loves to torment IT by periodically removing an app that the enterprise is using and not saying when it will be replaced. But like all mobile environments, Android also suffers from the app upgrade glitch conundrum. If a user upgrades a mobile app and it exhibits non-desired behavior, the only response today is to uninstall it and hope the matter is resolved soon. IT can always broadcast an email asking that the app not be updated, but that is only so effective. And what about the users who have already upgraded the app?
“There’s no way to downgrade an app unless you have a rooted device with an app like TitaniumBackup because Android’s package manager blocks you from installing older versions of apps,” noted XDA-Developers.com. “There’s a good reason for doing so because installing an older version of an app could lead to breakage if the app’s data isn’t cleared, or it could expose the user to danger if the older version is vulnerable to a security flaw. While we don’t know for sure if Google will allow users to rollback apps to an older version, we did find several permissions and commands in Android Q that suggest it’ll be possible. First, the new ‘PACKAGE_ROLLBACK_AGENT’ and ‘MANAGE_ROLLBACKS’ permissions suggest that the pre-installed market app can act as an agent to manage the rollback of application versions. The former permission is ‘signature’ while the latter is ‘installer’ on top of ‘signature,’ so this means only a platform-signed app with the ability to install apps — typically only the package manager, Google Play Store, or other first-party app stores, depending on the device — can use these permissions. Two new protected broadcast intents have been added: ‘PACKAGE_ENABLE_ROLLBACK’ and ‘PACKAGE_ROLLBACK EXECUTED.’ These broadcasts cannot be sent by third-party apps, and are likely intended to allow the affected app to know when it has been downgraded, much like how apps are told when they’ve been updated, giving them a chance to display some message on the next start. Lastly, a new flag has been added to the ‘pm install’ shell command. The flag, called ‘–enable-rollback,’ may let you rollback an application to an earlier version.”
First, the legally required disclaimer: All OS companies experiment with different options in pre-release versions, so there is no guarantee that what XDA-Developers found will make it to the final published version of the app. That disclaimer out of the way, the fact that someone at Google is seriously thinking about this is a remarkably good sign.
It would give IT just a little more control over its environment, while allowing more productivity. I saw more productivity because the reality today is that a problematic app must be shut down for however long it takes the app maker to issue a fix.
Little by little, IT is losing control of its data, its apps and its environments as the move to mobile, cloud and distributed data advances. Some shops are complaining of compliance problems caused by cloud staffs making tiny changes to apps — might be as seemingly innocuous as a firewall setting — that causes problems for companies that had thought they were fully compliant before the change, a change that no one on the cloud bothered to mention to them, let alone ask them.