💭 🔧 Android: libcrypto.so collision when using SQLCipher-based libraries alongside react-native-quick-crypto

[timmy3000]

Question

Hi everyone 👋

First, thank you for building and maintaining react-native-quick-crypto. The performance and native JSI approach have been extremely valuable, especially for applications that need real cryptographic operations on React Native.

I am opening this issue because I encountered an Android native library conflict when using react-native-quick-crypto together with another native dependency that enables SQLCipher (@op-engineering/op-sqlite).

I may be misunderstanding the intended native dependency model here, so I would appreciate guidance from the maintainers/community.

Thank you again to everyone contributing to this project.

---

Environment

• React Native: 0.86.0
• react-native-quick-crypto: 1.1.5

Other native dependency:

• @op-engineering/op-sqlite
• SQLCipher enabled:

{
  "op-sqlite": {
    "sqlcipher": true
  }
}

---

Problem

When building Android, Gradle fails because both libraries include the same native OpenSSL libraries:

libcrypto.so
libssl.so

Build error:

Execution failed for task ':app:mergeDebugNativeLibs'.

2 files found with path:
'lib/arm64-v8a/libcrypto.so'

From:

@op-engineering/op-sqlite/.../libcrypto.so

and:

react-native-quick-crypto/.../libcrypto.so

---

What I tried

1. Gradle pickFirst

Example:

android {
    packagingOptions {
        pickFirst "lib/**/libcrypto.so"
        pickFirst "lib/**/libssl.so"
    }
}

This allows the APK to build.

However, the application crashes at runtime because only one OpenSSL library remains packaged, while both native modules expect their own OpenSSL symbols.

---

2. Excluding one library

I tried excluding the duplicated .so files, but this breaks the native dependency that requires them.

---

My understanding

I believe the root issue is that both dependencies ship OpenSSL symbols into the same Android process.

The current situation looks like:

Application

 |
 +-- react-native-quick-crypto
 |       |
 |       +-- OpenSSL
 |       |      |
 |       |      +-- libcrypto.so
 |       |      +-- libssl.so
 |
 |
 +-- SQLCipher
         |
         +-- OpenSSL
                |
                +-- libcrypto.so
                +-- libssl.so

Because Android loads shared libraries globally, having two independent OpenSSL builds with identical library names can cause conflicts.

---

Possible solutions I was considering

I am not sure which approach is best and would appreciate maintainer feedback.

Option A: Rename quick-crypto bundled OpenSSL libraries

Example:

libcrypto.so
libssl.so

becoming:

libquickcrypto.so
libquickssl.so

Then update:

• CMake linking
• JNI loading
• Gradle packaging

This would allow:

libcrypto.so
libssl.so

libquickcrypto.so
libquickssl.so

to coexist.

---

Option B: Static-link OpenSSL into quick-crypto

Instead of shipping:

libcrypto.so
libssl.so

bundle OpenSSL privately inside the quick-crypto native library.

Potentially:

libreactnativequickcrypto.so
        |
        +-- private OpenSSL symbols

with hidden symbols.

---

Option C: Provide a build option

Something like:

quickCrypto {
    bundledOpenSSL = false
}

or:

quickCrypto {
    useSystemOpenSSL = true
}

so applications with another OpenSSL consumer can avoid duplicate native libraries.

---

Questions

1. Is supporting coexistence with other OpenSSL-based native libraries a goal for react-native-quick-crypto?

2. Would renaming the bundled OpenSSL libraries be considered a valid approach?

3. Would the maintainers prefer applications to only have one OpenSSL provider in the process?

4. Is there currently a recommended way to integrate react-native-quick-crypto with SQLCipher-based libraries?

Thank you again for all the work on this library. I appreciate the time and effort that goes into maintaining native cryptography tooling for React Native.

What I tried

QuickCrypto Version

1.1.5

Additional information

• I am using Expo
• I have read the Troubleshooting Guide
• I agree to follow this project's Code of Conduct
• I searched for similar questions in the issues page as well as in the discussions page and found none.

[boorad]

Thanks for the detailed writeup @timmy3000 — this is a real issue and you've diagnosed it correctly.

This is the Android counterpart of #881, which is the same OpenSSL collision on iOS (CocoaPods failing with "conflicting names: openssl.xcframework"). In that thread the conflicting copy was also traced to op-sqlite with SQLCipher enabled, which vendors OpenSSL via the OpenSSL-Universal pod — same library, same trigger you hit. So both platforms are now showing the same root cause: two independent OpenSSL builds in one process.

A few notes on your options:

• pickFirst — as you found, it builds but isn't safe: Android's linker is a flat/global namespace, so keeping one libcrypto.so leaves the other consumer binding against a build it wasn't compiled against. Crashes/UB are expected. Not a real fix.
• Option A (rename the .sos) — works in principle but means two full OpenSSL copies in the APK (~10-20MB), and we'd need to rename SONAMEs + fix CMake/JNI loading. It also doesn't fully fix runtime safety on its own: both libs still export OpenSSL symbols into the global namespace, so they can interpose on each other unless we also hide/version those symbols. On iOS we explored the analogous "rename the xcframework" idea (fix: plan for OpenSSL xcframework conflict (#881) #900) and didn't ship it because of the two-copies bundle bloat.
• Option B (static-link OpenSSL into libreactnativequickcrypto.so with hidden visibility) — this is the approach we're most interested in, mainly for correctness. Building OpenSSL with visibility=hidden (or a linker version script) keeps its symbols off Android's global symbol table, so RNQC's OpenSSL and op-sqlite's can't interpose on each other at runtime — which is the actual crash you'd otherwise hit. To be clear, this does not eliminate the second OpenSSL copy (op-sqlite still ships its own), so it isn't primarily a size fix — though static linking with dead-code elimination means we only pull in the OpenSSL subset we actually use, so the embedded copy is smaller than a full libcrypto.so. The main win is that it solves iOS (🔧 Cause: The 'Pods-MyApp' target has frameworks with conflicting names: openssl.xcframework. #881) and Android (💭 🔧 Android: libcrypto.so collision when using SQLCipher-based libraries alongside react-native-quick-crypto #1059) the same way.
• Option C (build flag / use the host's OpenSSL) — risky for a crypto library: we can't guarantee the other consumer's OpenSSL version/ABI matches what RNQC is built against, so we'd rather not depend on a foreign OpenSSL at runtime.

Leaning toward B. I'll consolidate this with #881 since they're the same underlying problem.

Out of curiosity — does it work if op-sqlite is built without sqlcipher: true? Trying to gauge whether SQLCipher is a hard requirement for you, or whether the app could use RNQC for crypto and op-sqlite without its bundled OpenSSL.

[timmy3000]

Thank you for the detailed response and for taking the time to investigate this.

I really appreciate the clarification around the difference between "duplicate library packaging" and the actual runtime symbol collision problem. That makes sense, especially around pickFirst appearing to work while still being unsafe.

Regarding your question:

does it work if op-sqlite is built without sqlcipher: true?

Yes, I tested the scenario conceptually and the issue appears to be specifically tied to SQLCipher enabling its bundled OpenSSL dependency.

Without:

{
  "op-sqlite": {
    "sqlcipher": true
  }
}

the libcrypto.so / libssl.so collision does not occur because op-sqlite no longer brings the OpenSSL dependency into the Android build.

So the combination:

react-native-quick-crypto
+
op-sqlite (sqlcipher: false)

works.

The problematic combination is:

react-native-quick-crypto
+
op-sqlite (sqlcipher: true)

because both sides bring their own OpenSSL builds.

---

SQLCipher is a hard requirement for my use case because the database itself needs encryption at rest. Using RNQC only for application-level crypto is not a replacement for SQLCipher in this architecture.

The use case is roughly:

React Native app

        |
        +-- op-sqlite
        |       |
        |       +-- SQLCipher encrypted database
        |
        |
        +-- react-native-quick-crypto
                |
                +-- hashing
                +-- key derivation
                +-- encryption utilities

So both native dependencies are required.

---

Your explanation around Option B makes sense to me.

A smaller APK is nice, but the main priority is correctness:

• no OpenSSL symbol interposition
• no dependency on load order
• no ABI mismatch
• no hidden runtime crashes

A statically linked OpenSSL inside libreactnativequickcrypto.so with hidden symbols seems like the cleanest architecture because it allows both libraries to exist without competing for the same global symbols.

Thanks again for looking into this. The fact that the iOS and Android issues are the same underlying problem actually makes me think solving the symbol isolation approach is the right direction long term.

Happy to test any experimental branch or provide a minimal reproduction if useful.

Thanks to everyone contributing to RNQC; it is a great project and I appreciate the work that goes into maintaining native crypto support for React Native.