Add special backup action for adaptive brightness data

[buttercookie42]

Searching through the code in frameworks/base/services/core/java/com/android/server/display/, these two files are the relevant ones.

Adaptive brightness in its current form was introduced for Android 9, and as per https://cs.android.com/android/_/android/platform/frameworks/base/+/3d9c19f2fd34cccac6fe09877ae9a6b4563a063e the storage directory moved from /data/system_de to /data/system for Android 14.

Restoring this data will likely be a bit tricky, because it seems the files are only read on startup, and afterwards the BrightnessTracker will always write back its in-memory values, overwriting any other data that might be present on disk.

Since the BrightnessTracker also writes its state during a regular reboot, it seems the only thing that could possibly work (other than an offline-restore through recovery or whatever) would be an immediate abrupt reboot through the reboot command (or possibly a "warm" reboot by only restarting zygote). I haven't tested this, though, because I didn't want to mess with my phone's adaptive brightness data (which currently works very nicely). Plus how to then fit the reboot into the UX flow would also be a good question.

At least it seems that other than on shutdown, the BrightnessTracker only writes via an Idle job that is executed once daily when the phone is charging, so the abrupt rebooting after restoration isn't super time-critical.

[buttercookie42]

I've done a little experiment and a reboot via calling reboot or setprop ctl.restart zygote indeed doesn't cause those files to be rewritten because the last-modified date doesn't change (so a restored backup would have been preserved), whereas rebooting regularly via the normal power menu does change the last modified date, so a restored backup would have been overwritten by stale data.

[buttercookie42]

Okay, after some more poking around I think that /data/system/display-manager-state.xml can be added to the list, too, because that's where the current actual brightness curve is being kept, but also that for completeness the "Device Health Services" app (com.google.android.apps.turbo) needs to be backed up, too, because it seems that that app does the actual job of turning these brightness events and ambient light stats into an actual auto brightness configuration.

[hg42]

While I appreciate that someone is investigating such things, I tend to hold the results back until we have at least rudimentary plugins...

I think, we need a better solutions for handling

• Android versions
• different locations for different manufacturers
• data moving around between versions
• alternate files
• alternate directories with the same files
• missing files or directories
  • flag for mandatory files -> error
  • flag for optional files -> ignored

It seems many files have a complicated dependency graph, not sure how to express this best.
However, it helps to see what kinds of dependencies are found in such data.
We actually need more of this.

I see this as a parallel effort:

• investigating what is necessary
• construct a plugin framework that can handle this