最近碰到一个用户出现联系人丢失问题,问题是用户也没有提供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就行了。
网友评论