Apply restore to repositories
This CL also changes the source of truth of the list of tiles: * Tiles are read once from Settings and kept in memory. * After tiles change, the new value is applied to memory. * Changes to the list are posted to a shared flow and applied to the current list sequentially. * If a change occurs in Settings that makes the list different from what we have, we overwrite it with our value. The same thing is done to AutoAddRepository. The restore is used to trigger a change in the repositories. It's important to note that the restores are tracked starting at the point where we check the setting for the value there (on start of the user). This means that if the restore happens before we get the tiles for the first time, the setting would have the restored values. This is probably the best scenario: restore happening before SystemUI starts interfering. Given that now we don't listen to Settings, a new shell command has been added to StatusBarShellCommands to modify the set of tiles. Fixes: 289502851 Test: atest com.android.systemui.qs.pipeline Test: atest CtsTileServiceTestCases android.host.systemui Test: quicksettings PlatformScenarioTests Test: manual restore using LocalTransport Change-Id: I287bb3c47c3a4181f29f942bcb18bd81c129273c
Loading
Please register or sign in to comment