Upgrading 2.2.2 -> 3.5.3 breaks database... new version in App Store


Hi All,

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?



Instructions can be found at https://www.zetetic.net/blog/2013/11/11/sqlcipher-300-release.html, as AFAIK you are running into the changes introduced in 3.0.0.


Ah…I found PRAGMA kdf_iter mentioned here:




Yep, I tried to report the links I found to fix it, but newbies can’t put more than 2 links in a post.

If you google for ‘android kdf_iter’, and go to a post entitled ‘Android SQLcipher PRAGMA problems’, you’ll find an article explaining how to provide this on Android.


BTW, thanks for the quick answer!



Hi @kcorey

As @commonsguy mentioned, you are seeing issues related to the change of the database file format between 2.x and 3.x databases. The link provided by @commonsguy covers the options available, our recommended route would be invoking PRAGMA cipher_migrate; on all 2.x database files.


Taht seems to be a command-line fix. Does this apply to Android in some way?


Hi @kcorey

The PRAGMA cipher_migrate; command can be executed through the command line, or from a SQLCipher library directly. You can find a SQLCipher for Android example of this usage within our test suite here.


Fantastic, that seems to have sorted the issue for us. Thanks!



Hi @kcorey

I’m glad to hear that resolved the issue for you. Take care!