最近碰到一個用戶出現(xiàn)聯(lián)系人丟失問題胳蛮，問題是用戶也沒有提供Log和復(fù)現(xiàn)路徑，本地測試也無法復(fù)現(xiàn)丛晌，所以暫時就擱置了仅炊，但是后續(xù)又陸陸續(xù)續(xù)碰到了用戶反饋聯(lián)系人丟失的問題，測試部才重視起來澎蛛，開始做對應(yīng)的專項測試抚垄。經(jīng)過幾天的專項測試才找到復(fù)現(xiàn)概率較高的路徑，插入無法駐網(wǎng)的Sim卡谋逻，刷機(jī)或者恢復(fù)出廠設(shè)置后第一次開機(jī)呆馁，新建手機(jī)聯(lián)系人，然后重啟毁兆，就會有一定概率出現(xiàn)聯(lián)系人丟失的現(xiàn)象浙滤，。
一般出現(xiàn)這種問題气堕，第一時間都是要先看聯(lián)系人數(shù)據(jù)庫的纺腊，然后就發(fā)現(xiàn)問題手機(jī)有兩個聯(lián)系人數(shù)據(jù)庫：
/data/user/0/com.android.providers.contacts/databases/contacts2.db
/data/user_de/0/com.android.providers.contacts/databases/contacts2.db
而在user_de目錄的聯(lián)系人數(shù)據(jù)庫里面正好包含了重啟之前新建的手機(jī)聯(lián)系人畔咧，這下問題就明確了，就是因為在手機(jī)第一次開機(jī)后新建的聯(lián)系人插入到了user_de下的數(shù)據(jù)庫摹菠，而重啟之后卻一直使用的user目錄的數(shù)據(jù)導(dǎo)致的盒卸。問題是為什么第一次開機(jī)使用的聯(lián)系人數(shù)據(jù)庫會創(chuàng)建到user_de下面，這個目錄應(yīng)該是在device lock狀態(tài)下才會使用的次氨。
現(xiàn)在問題復(fù)現(xiàn)概率高了后蔽介，就可以通過添加log的方式來查看聯(lián)系人數(shù)據(jù)庫創(chuàng)建時的堆棧打印了，于是就在聯(lián)系人數(shù)據(jù)庫發(fā)現(xiàn)了以下代碼：
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();
}
現(xiàn)在問題基本上明確了煮寡，是因為在device lock的狀態(tài)下虹蓄，有應(yīng)用啟動了聯(lián)系人數(shù)據(jù)庫進(jìn)程(android.process.acore)，所以android.process.acore會把進(jìn)程下所有數(shù)據(jù)庫進(jìn)行一次遍歷判斷幸撕，然后判斷AndroidManifest是否有有android:directBootAware="true"屬性薇组，如果有，就會進(jìn)入數(shù)據(jù)庫的onCreate流程坐儿，結(jié)果結(jié)果導(dǎo)致context.createDeviceProtectedStorageContext()這個context來創(chuàng)建ContactsDatabaseHelper的單例模式了律胀，于是乎聯(lián)系人數(shù)據(jù)庫的創(chuàng)建路徑就變成了/data/user_de/0/com.android.providers.contacts/databases/contacts2.db。
但是這個代碼是原生代碼貌矿，按理來說google應(yīng)該不會出現(xiàn)這種問題才對炭菌，那么問題就出現(xiàn)在了android.process.acore進(jìn)程不應(yīng)該在device lock狀態(tài)下啟動，這個問題就要后續(xù)在查看了逛漫，先解決用戶的問題要緊黑低，現(xiàn)在最重要的就是要先恢復(fù)用戶的聯(lián)系人數(shù)據(jù)。
恢復(fù)聯(lián)系人數(shù)據(jù)方式就是把user_de下的聯(lián)系人數(shù)據(jù)導(dǎo)出酌毡，然后再導(dǎo)入到user目錄克握，重要的是預(yù)防這個問題再次出現(xiàn)，因為聯(lián)系人數(shù)據(jù)本身就不需要在user_de下面創(chuàng)建（因為聯(lián)系人數(shù)據(jù)庫沒有android:directBootAware="true"屬性）枷踏，所以再把ContactsDatabaseHelper.getInstance(mContext)里面的context再次轉(zhuǎn)換一次菩暗，轉(zhuǎn)成user環(huán)境的context就行了。
