Description
Recently i had to restore backups of a work profile on a different device.
The original source of backup had the work profile id of 11 while target device had the work profile installed on id 10
The restoration process kept failing due to this, without any hints.
I dont know if this is a supported flow, but atleast, the app should give hints at the subtle difference.
Although this is very rare on base profile with id 0, since it would always match, but for work profile, this can occur
much frequently, if the work profiles are destroyed and re instantiated a few times, which would always install the latest profile
on an incremented id like 11,12 etc. And this would certainly create issues while restoration , but without giving the user any hints about this.
After figuring this subtle difference myself, the work around was to manually modify the backups with the following two commands:
find . -name '*user_11*' -exec bash -c ' mv $0 ${0/-user_11/-user_10}' {} \;sed -i 's/\"profileId\": 11,/\"profileId\": 10,/g' ./*/*.properties
These commands converted the backup to make it compatible with 10 profile, and all apps got restored successfully.
Although this is an edge case, it would be nice to have the app give hints about this, and may be give the user an option to make the backup compatible to the target profile id like above commands did for me to remove the manual intervention.
Steps To Reproduce
Create backup of a work profile on a device which had atleast one work profile destruction and reinstantiation, so that the work profile sits in some profile id other than 10
factory reset a device ,and create a fresh work profile [gets id 10]
restore the backups from step 1 to target device.
Restoration fails without giving any hints about the root cause.
Expected behavior
App should give this profile mismatch as a hint, and probably give option to make the backup compatible to the target profile.This conversion can be a part of the advanced features of the app.
Screenshots
I faced this issue quite sometime back.. so dont have any screenshots of the failures the app shows in this scenario.
Description Recently i had to restore backups of a work profile on a different device. The original source of backup had the work profile id of 11 while target device had the work profile installed on id 10 The restoration process kept failing due to this, without any hints. I dont know if this is a supported flow, but atleast, the app should give hints at the subtle difference. Although this is very rare on base profile with id 0, since it would always match, but for work profile, this can occur much frequently, if the work profiles are destroyed and re instantiated a few times, which would always install the latest profile on an incremented id like 11,12 etc. And this would certainly create issues while restoration , but without giving the user any hints about this.
After figuring this subtle difference myself, the work around was to manually modify the backups with the following two commands:
find . -name '*user_11*' -exec bash -c ' mv $0 ${0/-user_11/-user_10}' {} \;sed -i 's/\"profileId\": 11,/\"profileId\": 10,/g' ./*/*.propertiesThese commands converted the backup to make it compatible with 10 profile, and all apps got restored successfully.
Although this is an edge case, it would be nice to have the app give hints about this, and may be give the user an option to make the backup compatible to the target profile id like above commands did for me to remove the manual intervention.
Steps To Reproduce
Expected behavior App should give this profile mismatch as a hint, and probably give option to make the backup compatible to the target profile.This conversion can be a part of the advanced features of the app.
Screenshots I faced this issue quite sometime back.. so dont have any screenshots of the failures the app shows in this scenario.