Fatal Exception: java.lang.UnsatisfiedLinkError

[ghost]

Expected Behavior

sqlcipher to work

Actual Behavior

On a certain device (Other devices seem to be ok with it), I got the above crash with the following stack trace:

Fatal Exception: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.app.appm-oMdSgIjvGcgfbLLnMzQlIw==/base.apk"],nativeLibraryDirectories=[/data/app/com.app.appm-oMdSgIjvGcgfbLLnMzQlIw==/lib/arm64, /system/lib64, /vendor/lib64]]] couldn't find "libsqlcipher.so"
at java.lang.Runtime.loadLibrary0 + 1011(Runtime.java:1011)
at java.lang.System.loadLibrary + 1657(System.java:1657)
at net.sqlcipher.database.SQLiteDatabase$1.loadLibraries + 223(SQLiteDatabase.java:223)
at net.sqlcipher.database.SQLiteDatabase.loadLibs + 240(SQLiteDatabase.java:240)
at net.sqlcipher.database.SQLiteDatabase.loadLibs + 219(SQLiteDatabase.java:219)
at net.sqlcipher.database.SQLiteDatabase.loadLibs + 212(SQLiteDatabase.java:212)
at com.commonsware.cwac.saferoom.Helper. + 39(Helper.java:39)
at com.commonsware.cwac.saferoom.SafeHelperFactory.create + 190(SafeHelperFactory.java:190)
at com.commonsware.cwac.saferoom.SafeHelperFactory.create + 184(SafeHelperFactory.java:184)
at com.app.appm.dbRoom.AppDatabase_Impl.createOpenHelper + 96(AppDatabase_Impl.java:96)
at androidx.room.RoomDatabase.init + 159(RoomDatabase.java:159)
at androidx.room.RoomDatabase$Builder.build + 852(RoomDatabase.java:852)
at com.app.appm.dbRoom.DatabaseClient. + 19(DatabaseClient.java:19)
at com.app.appm.dbRoom.DatabaseClient.getInstance + 24(DatabaseClient.java:24)
at com.app.appm.MainActivity$2.run + 129(MainActivity.java:129)
at android.os.AsyncTask$SerialExecutor$1.run + 245(AsyncTask.java:245)
at java.util.concurrent.ThreadPoolExecutor.runWorker + 1162(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run + 636(ThreadPoolExecutor.java:636)
at java.lang.Thread.run + 764(Thread.java:764)

Steps to Reproduce

Not sure, it's a crash on a user's device, I guess he just opened the app
Android version: 8.1.0
LGE
nexus 5

Thanks

[sjlombardo]

@amosss if you unpack your APK can you verify that all the sqlcipher.so files are present, including the one for arm64? What version of SQLCipher are you using?

[ghost]

After unpacking, how can I know if I have all the files (including arm64)? I will see only those that I have :)
Unpacking will also tell me the version of SQLCipher?

[developernotes]

@amosss you can use apktool to unpack your application APK file. It will contain folders for the respective ABI platforms as subdirectories within the lib folder.

Unpacking the library will not directly tell you what version of SQLCipher you are using. You should be able to locate that within your Gradle references. Alternatively, from code you can query the library version by executing pragma cipher_version; and reading the String value returned.

[ghost]

I used apktool. with if params it created a 127.apk file and with d it created a 1.apk file. What am I suppose to do now?

I don't have any reference to sqlCipher in both gradle references, just to safe room: implementation 'com.commonsware.cwac:saferoom.x:1.0.5'

[commonsguy]

I have a Nexus 5. Both the demo project and the test suite in SafeRoom work fine on it.

If you have a project that reproduces the problem, I can take a look at it, but there does not appear to be a general problem with SQLCipher for Android or SafeRoom on the Nexus 5.

[ghost]

I saw the above report in my Crashlytics. Maybe a combination of some kind caused it or specifically how my apk was built (actually it's aab). May I ask how can I contact you for your to test it? And ofcourse, I appreciate it very much!

[commonsguy]

May I ask how can I contact you for your to test it?

If it is on the Play Store, post a link. Or, if it is open source, post a link to the repository.

Or, since this is a Nexus device, it should be in the Firebase Test Lab, so you could try running your test suite there.

[ghost]

This is the play store link: https://play.google.com/store/apps/details?id=com.stockdiv.stockdivm
I ran a test in test lab of Firebase that came out good but I don't know what happened behind the scenes. Thanks!

From the report, it looks like it happened when the app opens up.

[commonsguy]

The app starts up fine. I get to the registration screen without issue.

[ghost]

Thanks, so that brings me back to point 1, what might have happen on that user's mobile

[commonsguy]

I have no idea. All that I can say is that it is not a general problem with the Nexus 5.

[ghost]

It might be a combination of some kind. Does the fact that it works on your mobile, change any of the instructions I got before?

[commonsguy]

It would not appear to be a direct packaging problem -- otherwise the problem should be reproducible here.

Depending on how your AAB is set up, it's conceivable that the Play Store screwed up delivery to that device and failed to install the part that contains the SQLCipher for Android bits. I avoid AAB at all costs (and any other solution that involves Google signing the binaries), but I don't know if you can switch back to APK-based distribution. If you can, you could try that and see if the problem shows up when you have everything in the one package.

There are one-off possibilities. For example, the user might have a rooted device and has something that interfered with your app's installation.

[ghost]

It was only one crash and I don't even know who is he :) I understand that I won't have an easy way to understand what happened on his specific device

[ghost]

Now I got this in Crashlytics, same crash, different user:
Brand: unknown
Model: GCE x86 phone
Android 9
Unfortunately I have no other information about this

[stale]

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.

[ghost]

I didn't see this issue again in crashlytics but maybe it's because the relevant users are not using the app anymore because of this bug.

[developernotes]

Hello @amosss

Would you mind running apktool on your application APK file again, using this as the command:

apktool decode -o output YourApplication.apk

This will generate a folder titled output containing the extraction. Please share the full contents of your output/lib folder.

[ghost]

C:\Windows\output\lib>dir /s
Volume in drive C has no label.
Volume Serial Number is 328E-AC19

Directory of C:\Windows\output\lib

09/05/2019 07:14 PM

.
09/05/2019 07:14 PM ..
09/05/2019 07:14 PM arm64-v8a
09/05/2019 07:14 PM armeabi
09/05/2019 07:14 PM armeabi-v7a
09/05/2019 07:14 PM x86
09/05/2019 07:14 PM x86_64
0 File(s) 0 bytes

Directory of C:\Windows\output\lib\arm64-v8a

09/05/2019 07:14 PM

.
09/05/2019 07:14 PM ..
09/05/2019 07:14 PM 3,056,544 libsqlcipher.so
1 File(s) 3,056,544 bytes

Directory of C:\Windows\output\lib\armeabi

09/05/2019 07:14 PM

.
09/05/2019 07:14 PM ..
09/05/2019 07:14 PM 1,926,540 libsqlcipher.so
1 File(s) 1,926,540 bytes

Directory of C:\Windows\output\lib\armeabi-v7a

09/05/2019 07:14 PM

.
09/05/2019 07:14 PM ..
09/05/2019 07:14 PM 1,926,548 libsqlcipher.so
1 File(s) 1,926,548 bytes

Directory of C:\Windows\output\lib\x86

09/05/2019 07:14 PM

.
09/05/2019 07:14 PM ..
09/05/2019 07:14 PM 3,426,084 libsqlcipher.so
1 File(s) 3,426,084 bytes

Directory of C:\Windows\output\lib\x86_64

09/05/2019 07:14 PM

.
09/05/2019 07:14 PM ..
09/05/2019 07:14 PM 3,590,600 libsqlcipher.so
1 File(s) 3,590,600 bytes

 Total Files Listed:
           5 File(s)     13,926,316 bytes
          17 Dir(s)  117,896,478,720 bytes free

[ghost]

If there is anything else I should be adding, please let me know, thanks

[developernotes]

Hello @amosss

Unfortunately, we are unable to reproduce the behavior you are experiencing. If you have the device present that is causing the issue, you might look at experimenting with providing an alternative LibraryLoader implementation, possibly by looking on the device to find the actual location of the unpacked .so file and calling System.load with an absolute path.

[stale]

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.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to reopen with up-to-date information.