Back in 2014, the team published their integration with Android studio, which requested the the .so native libraries be manually added to get SQLCipher working with Gradle. It doesn’t seem to be the case for a long time now. I was looking through the release notes at Updates - Zetetic Community Discussion, I was hoping to find out when the *.so files were automatically being added for the supported abis (armeabi, armeabi-v7a,x86). I’m trying to see what changes we might still need to make to our gradle files in order to better support SQLCipher for our debug, release, and CI environments.
We only really support those architectures anyway, and likely only include those ABIs. I also ran into a few posts that mentioned not needing to include the x86 abi and rely on libhoudini. Can you tell me more about the impact of using libhoudini and how to include it?
Hi @simontse
SQLCipher for Android transitioned to the standard AAR packaging of the software, you no longer need to manually bundle the .so files for integration purposes. You can see the current library integration approach here.
libhoudini is an ARM translation layer for x86 devices. This is not necessary with SQLCipher for Android now as we include native x86 support within our AAR package.
1 Like
Thank you @developernotes, you replied so quickly.
So the abifilters is meant to specify the exact native platforms SQLCipher would include when building correct? Byt default, they provide the armeabi, armeabi-v7a,x86. But if we wanted to only have the arm based abis, then we’d leave x86 out correct in gradle?
ndk {
abiFilters "armeabi", "armeabi-v7a"
}
Hi @simontse
Correct, abiFilters specifies the ABI’s which are to be included within your application, so this will impact any native libraries being included in your application, including SQLCipher for Android. You’ve listed the 32-bit ARM variants, so you might also consider whether you wish to include arm64-v8a in your list too.