However, in practice androidx.sqlite:sqlite often resolves to a different version due to Gradle dependency resolution. For example, if the app uses Room, it bring a newer version (e.g. androidx.sqlite:sqlite:2.6.2), and Gradle will select the newer one.
Also, looking at the published metadata (POM), net.zetetic:sqlcipher-android:4.13.0 already declares a dependency on androidx.sqlite:sqlite:2.2.0, so explicitly adding it in the app seems redundant unless the intention is to force/pin the version.
Question 1: Why does the integration documentation explicitly instruct adding implementation("androidx.sqlite:sqlite:2.2.0")
if SQLCipher already declares it as a transitive dependency?
Question 2: Why is SQLCipher depending on androidx.sqlite:sqlite:2.2.0 (released 2021-12-15) instead of a more recent androidx.sqlite version? Since many client apps will resolve this dependency to a newer version anyway (Room, other androidx components), would it make sense for SQLCipher to update its declared dependency to a newer baseline to better match typical dependency graphs?
The SQLiteDatabase class implements the SupportSQLiteDatabase interface in the androidx.sqlite package. This is only to support the Room API, however, sqlcipher-android currently supports a min SDK version of 21. Updating androidx.sqlite to 2.6.2 (current stable release) will requiring moving the library min SDK version to 23. We plan on updated the library version in the next release.
Thanks for the quick response! I’ve marked your previous answers as the solution, since my original questions were mainly out of curiosity and to better understand the rationale, rather than to point out any concrete issue.
Regarding question 1, I’d just like to add a small nuance. In the screenshot you show `implementation “net.zetetic:sqlcipher-android:4.13.0@aar”`. Have you tried using the dependency without the @aar postfix? My understanding is that the @aar suffix prevents Gradle from resolving the published POM, which in turn hides transitive dependencies (such as androidx.sqlite).
I also wasn’t able to identify a clear reason why the @aar postfix would be required here, so I wondered whether it is still necessary or if it is mainly a historical / defensive recommendation.
Just thought I’d mention this nuance in case it’s useful—thanks again for the clarification and for maintaining SQLCipher!
I just tried removing the @aar bit from a small sample application and left androidx.sqlite commented out in the Gradle configuration, however, it does not automatically pull in the transitive dependency for me. See the screenshot below. Are you seeing different behavior?
Hi Nick, I don’t have a setup where I could easily test this myself, so my previous statement was based purely on theory and my understanding of how Gradle dependency resolution should behave. Thanks for verifying it in practice and for pointing out that my assumption was incorrect.
Much appreciated — thanks again for taking the time to check this!
