做Android系统定制这几年，屏幕亮度调校是几乎每个项目都躲不开的硬骨头。手机体验上最直观的，除了流畅度和续航，就是屏幕亮度默认值是不是合理、自动背光跟不跟手。这篇文章就围绕Android 10展开，从framework层的亮度默认值改起，再聊到自动背光曲线怎么调才能真正常用。无论你是做ROM定制、平板方案，还是纯粹对系统源码好奇的开发者，这套思路都值得收藏一份。
1. 屏幕亮度在Android 10里的管理脉络
1.1 手动亮度与自动背光的开关逻辑
屏幕亮度在Android里并不是一个简单的“设置一个数”就能全覆盖的功能。它分成手动亮度和自动亮度两个体系，手动模式把用户设置的背光值写进系统数据库，自动模式则由framework层的光感回调实时计算背光值。很多刚开始改亮度的朋友容易搞混，以为改了某个config就能同时管住两条链路，实际上两条链路在代码里是分开的。
手动模式下，核心存储是Settings.System中的screen_brightness字段，取值范围0到255，默认值一般由SettingsProvider在系统初始化时写入。自动模式下，screen_brightness_mode字段等于1，此时手动值仍然保存在数据库里，但真正生效的是AutomaticBrightnessController根据光线传感器lux值计算出的目标背光。所以你在adb里执行settings get system screen_brightness时看到的数值，并不一定是屏幕当前真实亮度。
理解了这一点，再改framework层就不会抓到哪算哪。默认值修改属于手动链路的种子，自动背光优化则是光感链路的调参。两个方向可以独立做，也可以结合起来，比如把默认亮度调低，同时把自动曲线在低lux段压得更暗，这样设备拿到手既不会白天亮得刺眼，也不会夜里暗到看不清。
1.2 framework层和亮度相关的几个关键文件
Android 10的亮度逻辑主要散落在framework/base的几个目录里。我常跟团队说，搞亮度定制只需要盯住四个地方：
SettingsProvider：负责系统亮度的默认值、数据库缓存和reset逻辑。core/res/res/values/config.xml：自动背光的曲线、抖动时间、光感采样参数都在这里。DisplayPowerController和AutomaticBrightnessController：负责实时算亮度、下发背光。- 厂商设备的overlay目录：用来覆盖AOSP默认曲线，不需要改公共代码。
这里最容易犯的错是直接改AOSP源码里的config.xml。如果你只做单项目，改了其实也能跑，但后续要升级或维护多个平台，就很容易被后续git合并冲掉。更稳妥的方式是在设备自己的overlay里覆盖这些值，确保改动范围可控。
2. 修改默认亮度值的完整实操
2.1 默认亮度值到底藏在哪里
默认亮度的种子在framework/base/packages/SettingsProvider/res/values/defaults.xml里，关键行是这样的：
<integer name="def_screen_brightness">102</integer>102意味着255级亮度的约40%，各家方案根据自己的屏幕特性会调到80到130之间。如果屏幕最大亮度本身不高，102可能显得偏暗；如果屏幕刺眼，102也可能太亮。所以这个值没有绝对标准，得结合屏幕规格和目标用户习惯来定。
但有一点要特别强调：改这个文件只影响“新装机”或“清除数据后首次开机”的默认值。如果一台设备已经亮过机并且设置了用户亮度，数据库里就有了screen_brightness记录，你再改defaults.xml也不会覆盖它。这也就是很多朋友改完源码、刷完机器，发现亮度还是老样子的原因。
2.2 具体改动步骤与代码示例
确定要改后，可以直接修改defaults.xml。我一般会先在当前项目里查一下是否已经有overlay覆盖了SettingsProvider资源：
find device/ vendor/ -path "*SettingsProvider*" -name "defaults.xml"如果已经有overlay，优先改overlay里的值，不碰AOSP公共代码。比如在device/xxx/overlay/frameworks/base/packages/SettingsProvider/res/values/defaults.xml里写：
<?xml version="1.0" encoding="utf-8"?> <resources> <integer name="def_screen_brightness">80</integer> </resources>如果没有overlay，就直接改AOSP源文件里的值，然后单独编译SettingsProvider模块：
source build/envsetup.sh lunch your_device-userdebug m SettingsProvider编译完成后会生成新的SettingsProvider.apk，打包进system镜像刷机即可。如果是完整编译，也可以直接make systemimage，但时间成本高很多。单独编模块适合快速验证。
2.3 数据库缓存与旧数据残留的处理
我刚才提到defaults.xml只在初始化时生效，实际项目里验证时最常踩的坑就是旧数据残留。明确一下screen_brightness值在设备上可能存在于三个层面：
- 系统数据库中的实时值，通过
settings命令读写。 /data/system/users/0/settings_system.xml中的持久化记录。- SettingsProvider进程持有的内存缓存。
改完defaults.xml之后，如果设备里已经有screen_brightness，你不清掉的话，新默认值永远不会出现。验证时可以进Shell手动删除这条记录：
adb shell "su 0 settings delete system screen_brightness"也可以直接把对应用户的system settings文件清掉再重启SystemUI，或者更简单粗暴地恢复出厂设置。在开发机上，我会先保存好当前设置，再用settings delete来做A/B对比，避免反复整机恢复浪费时间。
这里再给一个独家小技巧：改默认值的同时，最好把SettingsProvider的版本号加一，或者用adb shell am force-stop com.android.providers.settings重启进程，否则SettingsProvider可能还在复用内存里的老值。经验上清空数据后重启一次最干净。
3. 自动背光曲线优化实操
3.1 自动背光是怎么工作的
自动背光不是简单照到一个lux就回一个亮度，它要经过传感器采样、滑动平均、滤波、延迟判断、曲线映射、亮度限制等多个环节。Android 10里AutomaticBrightnessController会周期读取SensorManager注册的光传感器事件，把lux值滤波后与预设曲线对比，再判断当前该变亮还是变暗。
很多人以为只要把曲线里的lux数值调大调小就能解决所有问题，但实际体验上，更影响手感的是“变化的时机”和“变化的步长”。比如从暗环境走到窗边，如果系统延迟太久才变亮，你会觉得屏幕跟不上；可如果延迟太短，光感刚扫过一个阴影，屏幕亮度又会来回跳。这些矛盾需要靠debouce参数和时间窗口来平衡。
3.2 config_autoBrightnessLevels参数详解
在Android 10的framework/base/core/res/res/values/config.xml里，定义了两组等长的数组：
<integer-array name="config_autoBrightnessLevels"> <item>5</item> <item>10</item> <item>50</item> <item>100</item> <item>500</item> <item>1000</item> <item>4000</item> </integer-array> <integer-array name="config_autoBrightnessDisplayValues"> <item>10</item> <item>20</item> <item>35</item> <item>60</item> <item>100</item> <item>160</item> <item>240</item> </integer-array>config_autoBrightnessLevels是lux的阈值分档，config_autoBrightnessDisplayValues是对应要达到的屏幕亮度。两个数组必须长度一致，否则系统会直接崩溃或者回退成保守策略。实际上，这套参数在不同源码版本里命名有过微调，部分平台可能是config_autoBrightnessLuxBacklight或拆成config_autoBrightnessBacklight，但思路完全相同。
在真实项目里，我不会直接把AOSP的数组复制过来改，而是先在设备上采集数据。让设备分别处于暗室、台灯下、阴天窗边、正午户外，用dumpsys display或者插上adb shell dumpsys sensorservice记录实时lux和当前背光。然后对照每档lux看一下当前系统给的目标亮度是否符合预期，再按“低lux段细腻、高lux段粗放”的原则调整曲线。
3.3 平滑与防抖参数调校
光有曲线还不够，Android 10还提供了一组控制响应速度的参数，通常在config.xml里也能覆盖：
<integer name="config_autoBrightnessBrighteningLightDebounce">1500</integer> <integer name="config_autoBrightnessDarkeningLightDebounce">3000</integer>BrighteningLightDebounce是“变亮”的等待时间，DarkeningLightDebounce是“变暗”的等待时间。简单说，环境变亮时系统等1.5秒才反应，避免短暂晃光触发误判；环境变暗时等3秒才反应，因为从亮环境进入暗环境时，用户往往需要时间适应，太早降亮度会让人以为屏幕坏了。
实际调校时，我习惯分三步走：
- 静态测试：固定环境照度，确认lux读数稳定。
- 动态测试：用手电筒扫过传感器，观察亮度和跳变次数。
- 场景测试：拿着设备从室内走向户外，记录响应时间和最终亮度。
如果发现屏幕在弱光下反复跳动，可以把DarkeningLightDebounce调大到4000甚至5000。如果发现变亮很不跟手，就把BrighteningLightDebounce调到800左右。需要注意的是，config_autoBrightnessLevels的高低档之间不要落差太大，否则即使debounce再久，一档跳变带来的割裂感也很难消除。
3.4 亮屏灭屏恢复逻辑的取舍
自动背光还有一类容易被忽略的问题：亮屏瞬间的背光恢复。Android 10里，灭屏后光感通常不会再持续上报，亮屏后会出现一小段“亮度不确定”的状态。系统处理方式是利用之前缓存的光感值，但如果你改了曲线，有时缓存值对应的新背光会让屏幕突然亮一下或暗一下。
这种场景下，可以在config.xml里看是否还有config_autoBrightnessInitialLightDebounce这类初始终端延迟参数，部分厂商也会自定义一个“亮屏回退亮度”的中间值。我个人的处理习惯是：亮屏后先恢复到前一次稳定背光的80%，拿到新的有效lux后再按正常曲线调整。这样既不会突兀，又不会长时间停留在明显错误的亮度上。
4. 常见问题与排查技巧实录
4.1 改完默认亮度却不生效
这个问题的原因前面已经提到过，九成是数据库里存了旧值。可以使用下面这组命令做排查：
adb shell settings get system screen_brightness adb shell settings get system screen_brightness_mode adb shell dumpsys settings | grep -i brightness如果确认screen_brightness不是预期值，可以先删掉再重启系统设置：
adb shell "su 0 settings delete system screen_brightness" adb shell "su 0 am force-stop com.android.providers.settings" adb shell "su 0 am force-stop com.android.settings"还有一种特殊情况是厂商在SettingsProvider初始化时又写了一次默认值。如果你手里的定制ROM把默认亮度逻辑改到了其他地方，只改defaults.xml是没用的。排查方法是在DatabaseHelper.java里搜一下def_screen_brightness，或者全文搜字符串screen_brightness，看有没有硬编码覆盖。
4.2 曲线调整后亮度表现仍然不理想
曲线改了之后，屏幕上实际背光和设想的数值不一致，通常不是数组本身错了，而是系统存在“亮度限制”和“夜间模式”两条隐藏规则。Android 10可能会受config_screenBrightnessSettingMinimum和config_screenBrightnessSettingMaximum限制，你曲线里写的10可能被最低亮度限制拉上去。还有低电量自动降亮度、阅读模式、护眼模式的干预，这些叠加在自动亮度之上，会让最终显示偏差很大。
排查时先关闭所有“自适应级别”的附加功能，再通过adb shell dumpsys display | grep -A 40 "Display Power Controller"查看当时的DisplayState，里面会列出target brightness、sensor lux、app scaling等信息。只要看到目标亮度数值和你预期的不同，就能顺着往上找是哪个策略覆盖了。
4.3 自动背光的传感器不刷新
光感数据不通的典型表现是：自动亮度曲线完全没反应，手动拖动亮度却正常。这时候先用：
adb shell dumpsys sensorservice看有没有注册了光传感器，再看logcat里有没有LightSensor的上报。如果没有，优先检查传感器驱动的sysfs节点是否正常，权限对不对，DTS/device tree里是否使能了proximity和light sensor。许多方案会共用一个复合传感器，光感和距离传感器绑在一起，如果距离传感器初始化失败，光感也会连带挂掉。
这类问题很有意思，因为它不是改framework数值能解决的，要从驱动层往上查。真正定位时，我一般会写一个极简的读取脚本，直接cat一下/sys/bus/iio/devices/iio:deviceX/in_illuminance_raw，确认底层有数据，再决定问题是在HAL还是framework。
4.4 常用的亮度调试命令集锦
最后整理一份我在调试Android 10亮度时几乎天天用的命令，放在这里方便大家直接抄：
# 查看当前亮度值 adb shell settings get system screen_brightness adb shell settings get system screen_brightness_mode # 手动设置亮度并切换到自动/手动模式 adb shell settings put system screen_brightness 120 adb shell settings put system screen_brightness_mode 0 adb shell settings put system screen_brightness_mode 1 # 强制settings provider重启 adb shell "su 0 am force-stop com.android.providers.settings" # 查看亮度状态 adb shell dumpsys display | grep -i brightness adb shell dumpsys display | grep -i lux # 实时抓亮度相关日志 adb logcat -v time | grep -E "DisplayPower|AutomaticBrightness|LightSensor"这些命令在验证默认值和自动曲线时都够用了。平时做自动化回归时，我还会用adb shell settings put system screen_brightness_mode 1切到自动模式后，再用一个可变光源照射传感器，同时用dumpsys display循环采样，观察亮度变化曲线是否平滑。整个过程可以脚本化，能省掉很多手工记录的时间。
写在最后
做屏幕亮度调校这件事，给我最大的感受是：framework层的改动只是开头，真正花时间的反而是现场场景验证。默认值改对了只影响第一次开机，曲线改对了才影响用户用手机的每一分钟。每个人对亮度的偏好都不一样，调参不能只看数值，要多试几种真实环境，比如办公室、车里、夜晚床头，甚至是在太阳底下打电话的强光场景。还有个小建议：每次修改配置文件都要留备份，用注释记录当时的屏幕型号和测试环境，过一个月回来看还能想起为什么这么调。这样积累一段时间后，你的设备亮度表现会比随便改个数值稳定得多。
