Android 6.0 Marshmallow SettingsProvider

综述

最近几天在看看SettingsProvider的问题，修改系统的一些默认配置。例如默认铃声等。调查了一下发现Android6.0(Marshmallow)中的SettingsProvider同之前的Android版本有较大区别。

在Android6.0上，SettingsProvider涉及到如下修改

• 这次修改，涉及到了global,secure,system 三个表；并且实现方式从之前的数据库，改为异步性能更加优良的xml
• 这次修改，主要是基于性能的考量(写入一条耗时从400ms降低为10ms)，同时也能够使得保存数据的过程更加可信！
• 实际上，得保存数据的过程更加可信这一条并不是问题的关键，写入失败的情况不仅非常罕见，而且上层应用修改SettingsProvider设置都是通过SettingsProvider来实现的。所以当上层APP下次再次启动的时候，并不知道数据写入失败！
• 还有一种情况需要注意，改变SettingsProvider的实现方式(从db改为xml以及相应逻辑)，可以有效的防止某些恶意APP监听某些设置选项，进而频繁的进行操作
• 每个用户都有自己的一份SettingsProvider设置xml文档。通常位于/data/system/users/userid/
  
• 为了方便向下兼容，数据从数据库迁移到xml的时机：当数据库升级完毕之后，即可开始将数据迁移到xml
• SettingsProvider的升级由SettingsProvider.UpgradeController控制，而不再由DatabaseHelper控制
• 控制APP针对SettingsProvider的写入(合法性的判断)
• 控制SettingsProvider的大小(数据量大小，占用内存大小,etc.)
• 当某个app写入的设置，当该APP写在之后，对应的设置也一同被清除。

详细的递交commit参见如下：

commit 683914bfb13908bf380a25258cd45bcf43f13dc9
Author: Svetoslav [e-mail]
Date: Thu Jan 15 14:22:26 2015 -0800

Rewrite of the settings provider.This change modifies how global, secure, and system settings aremanaged. In particular, we are moving away from the database toan in-memory model where the settings are persisted asynchronouslyto XML.This simplifies evolution and improves performance, for example,changing a setting is down from around 400 ms to 10 ms as we do nothit the disk. The trade off is that we may lose data if the systemdies before persisting the change.In practice this is not a problem because 1) this is very rare;2) apps changing a setting use the setting itself to know if itchanged, so next time the app runs (after a reboot that lost data)the app will be oblivious that data was lost.When persisting the settings we delay the write a bit to batchmultiple changes. If a change occurs we reschedule the writebut when a maximal delay occurs after the first non-persistedchange we write to disk no matter what. This prevents a maliciousapp poking the settings all the time to prevent them being persisted.The settings are persisted in separate XML files for each type ofsetting per user. Specifically, they are in the user's systemdirectory and the files are named: settings_type_of_settings.xml.Data migration is performed after the data base is upgraded to itslast version after which the global, system, and secure tables aredropped.The global, secure, and system settings now have the same versionand are upgraded as a whole per user to allow migration of settingsbetween these them. The upgrade steps should be added to theSettingsProvider.UpgradeController and not in the DatabaseHelper.Setting states are mapped to an integer key derived from the userid and the setting type. Therefore, all setting states are ina lookup table which makes all opertions very fast.The code is a complete rewrite aiming for improved clarity andincreased maintainability as opposed to using minor optimizations.Now setting and getting the changed setting takes around 10 ms. Wecan optimize later if needed.Now the code path through the call API and the one through thecontent provider APIs end up being the same which fixes bugs wheresome enterprise cases were not implemented in the content providercode path.Note that we are keeping the call code path as it is a bit fasterthan the provider APIs with about 2 ms for setting and gettinga setting. The front-end settings APIs use the call method.Further, we are restricting apps writing to the system settings.If the app is targeting API higher than Lollipop MR1 we do notlet them have their settings in the system ones. Otherwise, wewarn that this will become an error. System apps like GMS corecan change anything like the system or shell or root.Since old apps can add their settings, this can increase thesystem memory footprint with no limit. Therefore, we limit theamount of settings data an app can write to the system settingsbefore starting to reject new data.Another problem with the system settings was that an app with apermission to write there can put invalid values for the settings.We now have validators for these settings that ensure only validvalues are accepted.Since apps can put their settings in the system table, when theapp is uninstalled this data is stale in the sytem table withoutever being used. Now we keep the package that last changed thesetting and when the package is removed all settings it touchedthat are not in the ones defined in the APIs are dropped.Keeping in memory settings means that we cannot handle arbitrarySQL operations, rather the supported operations are on a singlesetting by name and all settings (querying). This should not bea problem in practice but we have to verify it. For that reason,we log unsupported SQL operations to the event log to do somecrunching and see what if any cases we should additionally support.There are also tests for the settings provider in this change.Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68

总的来说：
改善了性能
提高了安全性
换了架构
提高了稳定性