Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add special backup action for adaptive brightness data #839

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

buttercookie42
Copy link

@buttercookie42 buttercookie42 commented Jan 21, 2024

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.

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. 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).
@buttercookie42
Copy link
Author

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 buttercookie42 marked this pull request as draft January 22, 2024 10:56
@buttercookie42
Copy link
Author

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
Copy link
Collaborator

hg42 commented Apr 10, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants