Last week, Google released Room, which is an ORM for SQLite (more or less).
On the plus side, Google did abstract out their database API, so that it is possible to plug in separate classes that could bridge to another SQLite implementation besides the platform one. That abstraction isn’t complete, though with luck they’ll clean that up.
However, the abstraction is based mostly on the API Level 16 edition of the SQLite classes. As was discussed previously, while we can fake some of that API, other aspects (e.g., CancellationSignal support) seem unlikely to be the sort of thing that we can layer on top of the existing SQLCipher for Android API.
So, the question is: is there a plan to upgrade the SQLCipher for Android API to support API Level 16 methods?
I’ll be happy to write the SQLCipher/Room bridge code (assuming nobody else is tackling that), but I don’t want to wander down that path too far until I have a picture of whether my code would ever be useful.
Now, as it turns out, some of what SQLCipher for Android does not support also seems to be unused in Room. With half an ounce of luck, I will convince The Powers That Be at Google to reduce their API to only what they need, and perhaps that will clear up the issue.
If nothing else, consider the existence of Room as yet another pressure point on moving SQLCipher for Android’s supported API to include newer methods.
Thanks for reaching out regarding the possibility of SQLCipher for Android and Room. Room certainly looks interesting!
So, the question is: is there a plan to upgrade the SQLCipher for Android API to support API Level 16 methods?
That is an good question. In short, yes. While we would like to continue to support the widest audience possible, we do realize the importance of cultivating the API such that it is closer to it’s upstream parent. We are working to publish a roadmap and deprecation approach for both SQLCipher core, and the various downstream client libraries. Moving forward, we want to provide the proper communications to users when we plan to drop support for older platforms versions, to allow for forward progression of the API.
I’ll be happy to write the SQLCipher/Room bridge code (assuming nobody else is tackling that), but I don’t want to wander down that path too far until I have a picture of whether my code would ever be useful.
Any idea when Room will stabilize? Only when Android O is RTM?
If you are asking “could we expect an update to CWAC-SafeRoom that supports version 1.0.0?”, it already does. If you depend upon android.arch.persistence:db:1.0.0 as well as the SafeRoom artifact, Gradle should use version 1.0.0, and that appears to work fine. I will release an update to SafeRoom that directly depends upon 1.0.0 next week sometime.
We are working to publish a roadmap and deprecation approach for both SQLCipher core, and the various downstream client libraries.
Was this published?
Any idea when Room will stabilize?
It reached 1.0.0 last week. More importantly, the support DB API reached 1.0.0 last week. That API is what CWAC-SafeRoom implements, wrapping the SQLCipher for Android API. Room can work with any support DB implementation. This API changed a bit from when I started this topic in May, but not by a lot. However, CWAC-SafeRoom still has a whole lotta methods that are stubbed out because there is no SQLCipher for Android equivalent.
Going forward, and IMHO, SQLCipher for Android either should:
aim to support a more modern version of the framework’s SQLite API, or
aim to support the support database API
The latter would allow SQLCipher to work with Room directly (no CWAC-SafeRoom needed) and with other libraries (e.g., ORMs) that adopt that support database API. Basically, it makes SQLCipher for Android even more plug-and-play than it already is.
If this is something that I can help with, please let me know how you would like me to proceed – thanks!
I’m also interested in this since this would mean I could easily switch different database engines in different projects without having to think how did I do this last time, for sqlcipher + ORM combination.
There is already another SQLite library the supports SupportSQLiteDatabase SQLite-android which is a custom SQLite version for android based on the latest SQLite version.
Apologies for the delayed response. This is something we’re planning to look into but we haven’t had a chance to evaluate the impact of these changes or come up with a plan. We will circle back on this after the next upcoming SQLCipher release (forthcoming). We will update this thread when we have additional information.
Hello @gwilliams - We had a great preliminary conversation with @commonsguy before the new year about how to proceed with this. We sketched out a plan to make some changes to SQLCipher for Android that would provide full coverage of the APIs required by CWAC-SafeRoom, i.e. that fills in all the gaps that were previously stubbed out. We’re committed to making these changes, so the ball is in our court initially, and we’ll be working this into our development schedule as available. Once our changes are complete @commonsguy has generously offered work with us to flesh out the rest of the updates and testing that would be required to make this more officially supported. Stay tuned, we’ll update this thread as more informations available.
:: breathes sigh of relief that I didn’t misfile the ball ::
Once our changes are complete @commonsguy has generously offered work with us to flesh out the rest of the updates and testing that would be required to make this more officially supported.
Yup! To that end, I already grabbed test code from SQLCipher for Android, AOSP, and other places, and assembled a test suite to exercise a support database API implementation:
Personally, I don’t have anything to add beyond what I have said previously. Until Zetetic elects to move forward in some fashion (with or without my involvement), all I can do is keep up after SafeRoom. I’ll be updating it for Room 1.1.0 soon.
We are actively working on some performance related improvements to SQLCipher for Android. Our current roadmap includes bundling the changes for necessary for Room interoperability to be included in our next public release of SQLCipher for Android. Thank you for your patience!
Thank you for acknowledging that this is on the roadmap. My team is looking forward to utilizing the solution.
Can you share any (rough) timetable for the next public release?
While we cannot comment on a timetable, we need to finish our changes, which are needed by @commonsguy to be integrated in SafeRoom, along with various testing. Our public release of SQLCipher for Android will be in lockstep with an update to SQLCipher core.