[Survey] OS & App Rollback - part 2

I think i stated all already in step 1 but didn’t consider rollback there.

A rollback would be nice to have as some issues pop up only in large scale even you tested carefully before. But this would then mean, after talking about the version pinning before, if i change the pinned version to a lower one, it would mean a rollback.

Regarding app rolllback:
Keeping app data can be important but maybe should be an option to do so or not.
Means, i would expect an option to say “keep app data yes/no” when doing rollback as you might need to clean app data on rollback because the new version might corrupted the stored data but in other cases you don’t want/need it to keep app logins and so on.

Regarding OS rollback:
I fear a bit this might cause the device to unenroll/wipe. This shouldn’t happen otherwise, this is most likely not an option for us at least.

During an app rollback, local data should be kept by default, or the administrator should be able to specify an action. Ideally, the relevant data of apps is stored/synced on servers, but even manual registration processes for apps can lead to operational interruptions. Apps for knowledge workers are less of a problem in this regard. The issue rather occurs when accounts need to be set up by administrators or activation codes need to be generated for an app. If the app does encounter errors after the rollback, you could still use dialog boxes to guide the user through deleting the local app data. An app rollback would definitely be extremely helpful, even if it means deleting local data. Right now, it doesn't really matter whether the app is public or private; what matters is how quickly the developer can or is willing to provide a solution.

When it comes to rolling back system updates, I'm not sure how willing some OEMs are to go along with it. Samsung is very strict on this for security reasons and does its best to prevent it. Whenever we needed to roll back, it was usually for major releases or to test update mechanisms on a device multiple times. And Especially when rolling back system components without a factory reset, device administrators face a significant challenge in thoroughly testing everything for potential issues.

Survey done. Thanks Lizzie!

Survey answered!

We’ve routinely had to roll back app upgrades of even well tested business apps because of what Moombas has mentioned. Large scale broader rollouts often reveal new behaviors that were otherwise not accounted for in the controlled smaller testing groups. We’re constantly readjusting testing strategies to try and account for this but it’s never perfect. 1 superuser testing an app manually in a conference room is not simulating real world usage out on the floor or in the field where new issues are often discovered. 

Historically Roll back has only been an option for apps that we “sideload” via direct APK installs via Custom DPC EMMs. This generally meant force uninstalling the app and then installing the lower version as there really isn’t a concept of app downgrading on Android. In these situations app cache /data is deleted but we’re generally okay with that side effect over the alternative of not being able to roll back to an older version. In many cases our apps our stateless anyway so the only thing that might be lost is anything that was manually configured as well, but that can be restored as well. 

While I would like app storage /cache to be optionally included in an official rollback I can certainly understand why that might not be an option. For one the internal storage structure / db of an app is likely to change over time. If you upgrade an app to a new version that could result in a new internal db schema change to correlate with new features or behaviors of the updated version.  It becomes difficult to then downgrade / rollback the app while keeping the updated app cache/data because now that internal storage structure might now align with the old app version which could lead to instability. Most EMM admins are not going to have visibility into the internal data structural changes of the app to know whether it’s a good idea to include the app data or not in the rollback (if given the option) and I could see most option to try to keep that data without realizing they’re potentially creating hidden app instability issues that would be difficult to diagnose. For example a device that went through an upgrade and rollback could have version N-1 of an app with an internal data structure of N leading potentially unusual behavior of that app,. A device that was configured fresh after a rollback event would install N-1 directly and would have an internal N-1 data structure for that app and it would inherently be more stable given that it’s app database schema matches the app version. Diagnosing issues with the rolled back app versions would be hard because on the surface they would look identical to working versions of the same app.  App developers would need to update their own design paradigms to account for scenarios of downgrading whereby the internal app DB schema would need to be reverted to a prior schema. I know they are thinking about this in terms of app upgrades but no one is currently really thinking about handling app downgrades as they’re not an officially supported concept. 

There also are the natural security concerns of being able to roll back to a previously “insecure” version of an app while bringing newer app version back with you to the old version that I’m sure also play a role in this. 

With all that said I can completely understand why we might not be able to get the option to bring app cache / storage backwards during a rollback if an official rollback mechanism is otherwise introduced.

Thanks everyone for your feedback on this survey and part 1 - today will be the last day to complete the survey as it’s been up for a couple of weeks. Feel free to add any additional thoughts in the comments though, if you wish to continue the conversation. 

We will post a recap shortly.

Thanks,

Lizzie