Issue attaching DBs Android

Hello team,

We’ve been using SQLCipher for years in our project and are recently migrating from version 4.5.4 to 4.5.5/6. The described below issue is reproducible in both 4.5.5 and 4.5.6 versions.
We have some data split between 2 DB files, let’s call them “principal” and “details”.
Both DBs are encrypted and created with the same KEY. This is during clean app installation - so, no DBs, no migrations, no version conflicts.
After creating and opening the DBs we attach them using the following command, having the key preformatted to hexadecimal representation as expected:

principalDb.execSQL("attach \"" + detailsDb.getPath() + "\" as DetailsDatabase KEY \"" + new String(dbKey.getCharKey()) + "\"");

At this point, we have both DBs created, opened, accessible, writable, and as mentioned created with the same KEY - those statements are confirmed.
This was working without any issues up to version 4.5.4.
Now, I get the following error:

(26) statement aborts at 4: [attach "/data/user/0/" as DetailsDatabase KEY "x'388B37296AD10BEF56C8B199566C55CB1AAF8B50853DA18003C2109FE8D0A7B3'"] file is not a database

This KEY is randomly generated once during the app start and is the same as the one used to create both DBs.

I also tried using the approach without explicitly passing the KEY, so it uses the KEY of the “principal” DB, which in this case is the same… it results in the same error!

A colleague of mine said that she tried the same DB attachment operation with Plain Text (not encrypted) DBs - with the same result.

Please advise,
Thanks beforehand!

Hi @Ivaylo_Todorov,

Are you able to reproduce this? If so, when this occurs in development, can you please pull the database file off the device to see if you are able to access the SQLCipher database file from the command line interface on a host computer?

Yes, this is 100% reproducible, on real devices and Emulators.
Yes, the DB file is there and accessible - I was able to download it using same path.

Hi @Ivaylo_Todorov,

Just for clarification, were you able to open the database file with the raw key using the SQLCipher command line shell? If so, can you reach out to us at with the sample database file and the raw key for further review?

This last helped me to find the issue… and it’s on our side.
A different key representation, of the same key, was provided when creating the OpenHelper.
Thanks for your assistance :slight_smile:

Hi @Ivaylo_Todorov,

Excellent, glad to hear you were able to isolate the issue!