最近碰到一个用户出现联系人丢失问题，问题是用户也没有提供Log和复现路径，本地测试也无法复现，所以暂时就搁置了，但是后续又陆陆续续碰到了用户反馈联系人丢失的问题，测试部才重视起来，开始做对应的专项测试。经过几天的专项测试才找到复现概率较高的路径，插入无法驻网的Sim卡，刷机或者恢复出厂设置后第一次开机，新建手机联系人，然后重启，就会有一定概率出现联系人丢失的现象，。
一般出现这种问题，第一时间都是要先看联系人数据库的，然后就发现问题手机有两个联系人数据库：
/data/user/0/com.android.providers.contacts/databases/contacts2.db
/data/user_de/0/com.android.providers.contacts/databases/contacts2.db
而在user_de目录的联系人数据库里面正好包含了重启之前新建的手机联系人，这下问题就明确了，就是因为在手机第一次开机后新建的联系人插入到了user_de下的数据库，而重启之后却一直使用的user目录的数据导致的。问题是为什么第一次开机使用的联系人数据库会创建到user_de下面，这个目录应该是在device lock状态下才会使用的。
现在问题复现概率高了后，就可以通过添加log的方式来查看联系人数据库创建时的堆栈打印了，于是就在联系人数据库发现了以下代码：
packages/providers/ContactsProvider/src/com/android/providers/contacts/CallLogDatabaseHelper.java
public static synchronized CallLogDatabaseHelper getInstanceForShadow(Context context) {
if (sInstanceForShadow == null) {
// Shadow provider is always encryption-aware.
sInstanceForShadow = new CallLogDatabaseHelper(
context.createDeviceProtectedStorageContext(), SHADOW_DATABASE_NAME);
}
return sInstanceForShadow;
}
@VisibleForTesting
@Nullable // We return null during tests when migration is not needed.
SQLiteDatabase getContactsWritableDatabaseForMigration() {
return ContactsDatabaseHelper.getInstance(mContext).getWritableDatabase();
}
现在问题基本上明确了，是因为在device lock的状态下，有应用启动了联系人数据库进程(android.process.acore)，所以android.process.acore会把进程下所有数据库进行一次遍历判断，然后判断AndroidManifest是否有有android:directBootAware="true"属性，如果有，就会进入数据库的onCreate流程，结果结果导致context.createDeviceProtectedStorageContext()这个context来创建ContactsDatabaseHelper的单例模式了，于是乎联系人数据库的创建路径就变成了/data/user_de/0/com.android.providers.contacts/databases/contacts2.db。
但是这个代码是原生代码，按理来说google应该不会出现这种问题才对，那么问题就出现在了android.process.acore进程不应该在device lock状态下启动，这个问题就要后续在查看了，先解决用户的问题要紧，现在最重要的就是要先恢复用户的联系人数据。
恢复联系人数据方式就是把user_de下的联系人数据导出，然后再导入到user目录，重要的是预防这个问题再次出现，因为联系人数据本身就不需要在user_de下面创建（因为联系人数据库没有android:directBootAware="true"属性），所以再把ContactsDatabaseHelper.getInstance(mContext)里面的context再次转换一次，转成user环境的context就行了。
