Database crashes at initialisation

[andras-the-android]

Hi! We use sqlcipher for years and now we've upgraded from 3.5.7 to 4.4.3 and then 4.5.0 It worked very well most of the time but on a small number of devices (~ 1%) the database throws an exception at start which is really bad because those users can't use the app and they lost access to their data. Almost all the cases are happening on Samsung devices, on Android 9-10-11 versions. What can we do?

java.lang.RuntimeException: at android.app.ActivityThread.handleBindApplication (ActivityThread.java:7540) at android.app.ActivityThread.access$1500 (ActivityThread.java:301) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2158) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loop (Looper.java:246) at android.app.ActivityThread.main (ActivityThread.java:8595) at java.lang.reflect.Method.invoke (Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:602) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1130) Caused by: net.sqlcipher.database.SQLiteException: at net.sqlcipher.database.SQLiteCompiledSql.native_compile (Native Method) at net.sqlcipher.database.SQLiteCompiledSql.compile (SQLiteCompiledSql.java:89) at net.sqlcipher.database.SQLiteCompiledSql.<init> (SQLiteCompiledSql.java:62) at net.sqlcipher.database.SQLiteProgram.<init> (SQLiteProgram.java:91) at net.sqlcipher.database.SQLiteQuery.<init> (SQLiteQuery.java:48) at net.sqlcipher.database.SQLiteDirectCursorDriver.query (SQLiteDirectCursorDriver.java:60) at net.sqlcipher.database.SQLiteDatabase.rawQueryWithFactory (SQLiteDatabase.java:2016) at net.sqlcipher.database.SQLiteDatabase.rawQuery (SQLiteDatabase.java:1902) at net.sqlcipher.database.SQLiteDatabase.keyDatabase (SQLiteDatabase.java:2669) at net.sqlcipher.database.SQLiteDatabase.openDatabaseInternal (SQLiteDatabase.java:2599) at net.sqlcipher.database.SQLiteDatabase.openDatabase (SQLiteDatabase.java:1247) at net.sqlcipher.database.SQLiteDatabase.openOrCreateDatabase (SQLiteDatabase.java:1322) at net.sqlcipher.database.SQLiteOpenHelper.getWritableDatabase (SQLiteOpenHelper.java:166) at net.sqlcipher.database.SQLiteOpenHelper.getWritableDatabase (SQLiteOpenHelper.java:135) at net.sqlcipher.database.SQLiteOpenHelper.getWritableDatabase (SQLiteOpenHelper.java:131) at com.company.mfa.database.core.EncryptedOpenHelper.<init> (EncryptedOpenHelper.java:34) at com.company.mfa.database.core.NpSQLiteOpenHelper.<init> (NpSQLiteOpenHelper.kt:29) at com.company.mfa.database.core.NpSQLiteOpenHelper.<init> (NpSQLiteOpenHelper.kt:32) at com.company.mfa.database.core.NpSQLiteOpenHelper_Factory.newInstance (NpSQLiteOpenHelper_Factory.java:37) at com.company.mfa.database.core.NpSQLiteOpenHelper_Factory.get (NpSQLiteOpenHelper_Factory.java:28) at com.company.mfa.database.core.NpSQLiteOpenHelper_Factory.get (NpSQLiteOpenHelper_Factory.java:10) at dagger.internal.DoubleCheck.get (DoubleCheck.java:47) at com.company.mfa.database.core.AccountDaoImpl_Factory.get (AccountDaoImpl_Factory.java:22) at com.company.mfa.database.core.AccountDaoImpl_Factory.get (AccountDaoImpl_Factory.java:8) at dagger.internal.DoubleCheck.get (DoubleCheck.java:47) at com.company.mfa.applock.AppLockLiveData_Factory.get (AppLockLiveData_Factory.java:32) at com.company.mfa.applock.AppLockLiveData_Factory.get (AppLockLiveData_Factory.java:10) at dagger.internal.DoubleCheck.get (DoubleCheck.java:47) at com.company.mfa.core.observer.NpProcessObserver_Factory.get (NpProcessObserver_Factory.java:33) at com.company.mfa.core.observer.NpProcessObserver_Factory.get (NpProcessObserver_Factory.java:11) at dagger.internal.DoubleCheck.get (DoubleCheck.java:47) at com.company.mfa.di.DaggerNpAppComponent.injectNpApplication (DaggerNpAppComponent.java:790) at com.company.mfa.di.DaggerNpAppComponent.inject (DaggerNpAppComponent.java:570) at com.company.mfa.NpApplication.onCreate (NpApplication.kt:42) at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1192) at android.app.ActivityThread.handleBindApplication (ActivityThread.java:7535) at android.app.ActivityThread.access$1500 (ActivityThread.java:301) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2158) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loop (Looper.java:246) at android.app.ActivityThread.main (ActivityThread.java:8595) at java.lang.reflect.Method.invoke (Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:602) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1130)

[developernotes]

Hi @andras-the-android

Have you tried running the SQLCipher for Android test suite on the devices you're receiving crashes on? What are you results from that?

[andras-the-android]

Sadly none of our test devices produce the issue. I can see the exceptions in the google play console.

[developernotes]

Hi @andras-the-android

Are you testing on the devices that report the error?

[andras-the-android]

Yes, the S20 FE with exynos cpu produce the 47% of the crashes and I have a device like that but it works fine. But we have other devices from the list but still nothing.

[stale[bot]]

Hello, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "bug", "enhancement", or "security" and I will leave it open. Thank you for your contributions.

[andras-the-android]

It's still a bug, it looks like we don't have any choice other than to delete and recreate the database on the affected devices.

[developernotes]

Hi @andras-the-android

Unfortunately, it is difficult to perform a root cause analysis without further information. Both your application logic and another database access library are involved in this specific scenario so there are multiple moving parts to consider. As it appears the error originates from the keying of the SQLCipher database a few things you should evaluate:

• Where is the key material coming from?
• Are you certain the key being provided to the database is correct?
• Has SQLiteDatabase.loadLibs(...) been called prior to the keying operation?
• Does the database file exist?
• Is the database file encrypted, or plaintext?
• Can you capture the problematic database on device and export for further analysis?

[andras-the-android]

I understand that it's hard to identify the problem without detailed information. We use the default settings, the password is 42 char long of upper/lowercase characters and numbers. Sadly we still don't have a device in the problematic state, but because of the small number of occurrences, I would say that the setup is fine.

Since this database belongs to a rarely used feature and affects a fraction of our users, we decided to solve the issue by resetting the database instead of putting more effort to solve it.

[developernotes]

Hi @andras-the-android

Thank you for the update, I'm sorry to hear additional information isn't available. Should you identify more information in the future, please feel free to reach out again. Thanks!