I discovered https://github.com/requery/sqlite-android which builds with a recent version of SQLite along with a recent version of the AOSP SQLite database classes, and it seems to support 64-bit CPUs. It is apparently based on Android SQLite bindings at: https://www.sqlite.org/android/doc/trunk/www/index.wiki
Unfortunately I did not have a chance to experiment so much with it but I suspect a version could be used to provide SQLCipher with a number of recent AOSP features. I would recommend adapting it to pass as much of the existing SQLCipher for Android test suite as practical.
Yes it would be possible to adapt the current SQLCipher for Android source to support 64-bit native pointer values but then it would deviate even further from the AOSP code. That could potentially make it even harder to integrate newer features from AOSP in the future.
I hope this helps and apologize for the timing. I wish I had found it before you guys did the hard work to support Android N.
Hello @brodybits - thanks for getting in touch about this. I wasn’t familiar with requery, but have come across the Android SQLite bindings a few times before when customers have raised questions about the differences between SEE and SQLCipher on Android.
Before we undertook the project to update SQLCipher for Android N, we did discuss the option of rebasing on a newer AOSP version. However, after reviewing the pros and cons, we determined that the risk for substantial regressions and issues was higher with a full replacement than it would be working with the existing, familiar, codebase (i.e. fixing the specific items that need to be addressed for N). It’s worth noting that at the time 64-bit was not a consideration in that decision because the pre-requisite support from OpenSSL was missing anyway.
That said, we’ll likely be revisiting the plans for future upgrades soon since SQLCipher 3.5.x is stabilizing, adoption is increasing, and OpenSSL has released newer versions that may add core 64-bit Android support. We will certainly consider this option. Luckily I don’t think the time spent on the Android N updates was wasted at all, since many of the changes, especially related to unicode, keying, test suite expansion, etc, would likely be preserved in some form even if we were to switch to a more recent upstream snapshot.
Thanks again for bringing this up, and for your continued attention to the SQLCipher project!
Thanks @sjlombardo for the response and thanks to Zetetic for the open source efforts in general. Yes I think you guys were right to make the quicker fix to support Android 7.