I’ve inherited a codebase that was using the 2.2.2 jar file version of sqlcipher. In testing with Android 7, we were seeing a dialog box that would be alarming to our users…so we put sqlcipher in our build.gradle file as 3.5.3@aar, did the build, tested it, and it was good. We released it to the app store.
Turns out that we didn’t test upgrading an install of the old version of our app (sqlcipher 2.2.2) to the new version of our app (sqlcipher 3.5.3).
When our new app sees a database build with the old sqlcipher, it claims the database is corrupted, and the app crashes.
Some portion of my users can’t start the app right now as it’s crashing. Yes, deleting and reinstalling it will fix this for them, but then any data that’s waiting to be uploaded is of course lost.
Given that I’ve got some users unable to run the app now…if I downgrade to the old version of the app for them, the new users who currently can run the app will also have a crash on startup, and be told that they might lose some data.
I know it’s the same password used both times.
And yes, in fact, I do appreciate we should have testing data migration before sending the app to the app store, as well as more gracefully handling the error from trying to open the database.
Is there a migration strategy for sqlcipher that allows the latest version of the library to read databases encrypted with 2.2.2?