Loading
Refresh in-memory SharedPreferences instances after restore
Existing instances don't know that the file has changed out from under them, so they continue to return stale values from reads, and risk overwriting restored data with stale content if writes are performed. We now tell the backing cache system to induce a reload after restore (i.e. after we might have written a relevant file out from under it). Along the way we shook out an irregularity in the way we were setting up the context topology of non-lifecycle instances of the metadata-handling BackupAgent subclass, so that's fixed now too. Bug 12061817 Test: cts-tradefed run cts -m CtsBackupHostTestCases Change-Id: I401fe9297235b55d8a8f041e430d122dc6e24129