CMSettings: don't trample user metrics setting on upgrade
During an upgrade, we try to migrate values which are considered to be LEGACY settings to the new provider, however because of a bad upgrade path, we need to check if the key exists in the new database AND the old database, and then we can skip it in that case. Ticket: CYNGNOS-2740 Change-Id: I5d6bc8399ccc328f4190ed7508c27bd9d5de1b9d Signed-off-by: Roman Birg <roman@cyngn.com>
This commit is contained in:
parent
8c8601b9f3
commit
256a7350ce
@ -208,6 +208,14 @@ public class CMSettingsProvider extends ContentProvider {
|
|||||||
else if (tableName.equals(CMDatabaseHelper.CMTableNames.TABLE_SECURE)) {
|
else if (tableName.equals(CMDatabaseHelper.CMTableNames.TABLE_SECURE)) {
|
||||||
settingsValue = Settings.Secure.getStringForUser(contentResolver, settingsKey,
|
settingsValue = Settings.Secure.getStringForUser(contentResolver, settingsKey,
|
||||||
userId);
|
userId);
|
||||||
|
if (settingsValue != null && settingsKey.equals(CMSettings.Secure.STATS_COLLECTION)
|
||||||
|
&& CMSettings.Secure.getStringForUser(contentResolver, settingsKey, userId)
|
||||||
|
!= null) {
|
||||||
|
// incorrect migration from YOG4P -> YOG7D failed to remove
|
||||||
|
// Settings.Secure.STATS_COLLECTION after migration; so it may exist in both
|
||||||
|
// providers; so if it exists in the new database, prefer it.
|
||||||
|
continue;
|
||||||
|
}
|
||||||
|
|
||||||
// insert dnd, edit tiles for upgrade from 12.1 -> 13.0
|
// insert dnd, edit tiles for upgrade from 12.1 -> 13.0
|
||||||
if (CMSettings.Secure.QS_TILES.equals(settingsKey) && (settingsValue != null
|
if (CMSettings.Secure.QS_TILES.equals(settingsKey) && (settingsValue != null
|
||||||
|
Loading…
Reference in New Issue
Block a user