系统属性与配置定制：build.prop、persist 与 Settings

上一章看了 SystemUI。这一章回答：系统属性、build.prop、persist 属性、Settings 与 config 各是什么，行为类定制怎么选？

属性与 settings 属于不同配置通道

常见误解	正确理解
所有属性都是 build.prop 写的	属性来自多个来源，build.prop 只是其一
persist 属性重启失效	persist 属性会持久化，重启保留
getprop 和 settings 一样	getprop 读属性服务，settings 读写 SettingsProvider

核心结论

1. ro.* 只读且启动时确定，适合构建期/开机期定制。
2. persist.* 可写并持久化，适合运行期动态配置。
3. Settings 分 global/system/secure，用户与系统都可读写。
4. 资源 config 在构建期生效，适合跟随产品的默认值。
5. 选择依据：谁改、何时定、要不要持久化。

配置选择主链

逐步解释：

1. 开机即定且只读 → ro 属性。
2. 运行期可改且要保留 → persist 属性。
3. 设置类 → SettingsProvider。
4. 出厂默认 → 资源 config。

常用命令

环境：开发设备或模拟器；写 persist 属性可能需要权限。

adb shell getprop ro.build.version.sdk
adb shell setprop persist.sys.demo 1
adb shell settings put global window_animation_scale 0
adb shell settings get global window_animation_scale

先想清楚“谁写、何时生效、要不要持久化”，再选机制。

源码证据

阅读目标：确认属性与 Settings 的实现边界。

正文指针：system/core/init/property_service.cpp（属性服务）； SettingsProvider.java（设置存储）。

// property_service.cpp（伪代码，行号以 r75 为准）
// ro.* 只读，persist.* 写回持久化存储

这段代码证明： 属性服务在 init 阶段初始化，ro 属性启动即定，persist 属性写回 持久化；Settings 是另一套数据库式存储。

验证与排障

环境：开发设备或模拟器。

adb shell getprop | grep -iE "persist|ro\.build"
adb shell settings list global
adb shell settings list system

先确认属性是否存在与值是否正确，再查 Settings。定制不生效时按“来源 → 读写权限 → 生效时机（重启/立即）”排查。

常见误区

1. “getprop 和 settings 一样”：两套独立机制。
2. “persist 属性重启丢失”：会持久化。
3. “ro 属性运行期能改”：只读。
4. “属性改完立即生效”：部分属性需重启或服务重读。

延伸问题

1. 属性安全上下文如何限制写入？
2. Settings 的 global/system/secure 区别是什么？
3. 构建期如何通过 PRODUCT_PROPERTY_OVERRIDES 注入属性？
4. 属性与 config 同时存在时优先级如何？

源码入口

文件	关键位置	作用
system/core/init/property_service.cpp	属性服务	属性读写
SettingsProvider.java	设置存储	Settings
build.prop	构建产物	ro 属性来源
资源 config	构建期	出厂默认

公共路径：system/core/init/、 frameworks/base/packages/SettingsProvider/ 与 frameworks/base/core/res/。 行号以 r75 检索为准。

涉及系统应用授权时，见 特权应用与权限白名单。