SIM card stopped working / Phone corrupted?

I got a FP3+ with /e/ preinstalled this week.

While copying data over from the old phone (was a LineageOS 18.1 device) using adb push etc I somehow managed to get the SIM card from working. Strangely, I could send and receive text messages (SMS) over the phone provider but not make or receive phone calls.

This morning I wanted to restart the phone as a last measure to fix it. Unfortunately, I was not asked for the SIM pin but right away for the normal login-pin. And before I could finish entering that, I got a message to the effect that the data is corrupted and then it rebooted into the /e/ recovery screen.

Is there a way to get to the data? And activate the SIM card again? Since the recovery only offers me the options to “Try again” and “Factory data reset”, I’m not sure what to do. |adb devices| lists the device while in recovery but I’m not sure what kind of recovery that really is and how to get it to do something useful.

(Sorry this is my first post, I’m not yet sure to which topic such a problem belongs.)

Some progress: I noticed by chance that the phone does not reboot when the lockscreen appears if I connect the USB cable to the computer before that.

So I can connect with adb to the decrypted phone. Now I just need to know what to look for. Why does the OS think that it is corrupted and why does it reboot when not connected?

To follow up on myself once more: In the meantime I found that I could run “adb logcat” and in the output find many repeating cases of FATAL EXCEPTIONs in the com.android.phone process.
I think the relevant error message with the call stack is always

AndroidRuntime: Shutting down VM
AndroidRuntime: FATAL EXCEPTION: main
AndroidRuntime: Process: com.android.phone, PID: 12972
AndroidRuntime: java.lang.RuntimeException: Unable to create application com.android.phone.PhoneApp: android.database.sqlite.SQLiteException: Can't downgrade database from version 2949128 to 2818056
AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6465)
AndroidRuntime: 	at android.app.ActivityThread.access$1300(ActivityThread.java:219)
AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1859)
AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:107)
AndroidRuntime: 	at android.os.Looper.loop(Looper.java:214)
AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:7356)
AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:940)
AndroidRuntime: Caused by: android.database.sqlite.SQLiteException: Can't downgrade database from version 2949128 to 2818056
AndroidRuntime: 	at android.database.sqlite.SQLiteOpenHelper.onDowngrade(SQLiteOpenHelper.java:541)
AndroidRuntime: 	at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:415)
AndroidRuntime: 	at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:317)
AndroidRuntime: 	at com.android.providers.telephony.TelephonyProvider.getWritableDatabase(TelephonyProvider.java:2399)
AndroidRuntime: 	at com.android.providers.telephony.TelephonyProvider.update(TelephonyProvider.java:3569)
AndroidRuntime: 	at android.content.ContentProvider$Transport.update(ContentProvider.java:420)
AndroidRuntime: 	at android.content.ContentResolver.update(ContentResolver.java:1993)
AndroidRuntime: 	at com.android.internal.telephony.SubscriptionController.clearSlotIndexForSubInfoRecords(SubscriptionController.java:258)
AndroidRuntime: 	at com.android.internal.telephony.SubscriptionController.init(SubscriptionController.java:224)
AndroidRuntime: 	at com.android.internal.telephony.SubscriptionController.<init>(SubscriptionController.java:201)
AndroidRuntime: 	at com.qualcomm.qti.internal.telephony.QtiSubscriptionController.<init>(QtiSubscriptionController.java:121)
AndroidRuntime: 	at com.qualcomm.qti.internal.telephony.QtiSubscriptionController.init(QtiSubscriptionController.java:103)
AndroidRuntime: 	at com.qualcomm.qti.internal.telephony.QtiTelephonyComponentFactory.initSubscriptionController(QtiTelephonyComponentFactory.java:164)
AndroidRuntime: 	at com.android.internal.telephony.PhoneFactory.makeDefaultPhone(PhoneFactory.java:176)
AndroidRuntime: 	at com.android.internal.telephony.PhoneFactory.makeDefaultPhones(PhoneFactory.java:103)
AndroidRuntime: 	at com.android.phone.PhoneGlobals.onCreate(PhoneGlobals.java:319)
AndroidRuntime: 	at com.android.phone.PhoneApp.onCreate(PhoneApp.java:39)
AndroidRuntime: 	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1189)
AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6460)
AndroidRuntime: 	... 8 more
RescueParty: Disabled because of active USB connection

(The RescueParty line probably explains why using the USB cable prevented the phone from rebooting to Recovery.)

Now, can anyone tell me how I find out which SQLite database has the wrong version? I haven’t found any in the directories named “com.android.phone”, “com.qualcomm.qti*”, or “com.android.internal.*”.

It may be com.android.providers.telephony (search in /data/user/0 and /data/user_de/0 …).
A factory reset may overwrite this database with a correct version.

1 Like

Right, thanks! That is the hint that I needed. :grinning:

Since I have data on the system, a factory reset seemed a bit harsh. So instead I zipped the files in /data/user_de/0/com.android.providers.telephony/databases up (zip -mr databases.zip databases/). And immediately I was asked for the SIM pin. Using “adb shell” I can see that the databases dir was populated again as you predicted. :white_check_mark:

2 Likes