file is not a database (code 26)

[mandrachek]

When attempting to run my app using Android Studio, I will occasionally encounter, like I did this evening, this:

2025-08-13 20:09:26.922 17505-17581 sqlcipher               my.app                D  ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
2025-08-13 20:09:26.922 17505-17581 sqlcipher               my.app                D  ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
2025-08-13 20:09:26.922 17505-17581 sqlcipher               my.app                D  ERROR CORE sqlcipher_codec_ctx_set_error 1
2025-08-13 20:09:26.922 17505-17581 SQLiteLog               my.app                E  (26) file is not a database in "SELECT COUNT(*) FROM sqlite_schema;"
2025-08-13 20:09:26.922 17505-17581 SQLiteDatabase          my.app                E  Failed to open database '/data/user/0/my.app/databases/my.db'. (Ask Gemini)
                                                                                                    net.zetetic.database.sqlcipher.SQLiteNotADatabaseException: file is not a database (code 26): , while compiling: SELECT COUNT(*) FROM sqlite_schema;
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteConnection.nativePrepareStatement(Native Method)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteConnection.a(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:23)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteConnection.l(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:11)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteConnection.p(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:80)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteConnectionPool.O(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:12)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteDatabase.o0(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:16)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteDatabase.m0(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:12)
                                                                                                    	at net.zetetic.database.sqlcipher.SQLiteOpenHelper.a(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:162)
                                                                                                    	at net.zetetic.database.sqlcipher.SupportHelper.Q(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:5)
                                                                                                    	at h4.b.D(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:14)
                                                                                                    	at e4.u.x(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:7)
                                                                                                    	at e4.L.g(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:77)
                                                                                                    	at c7.e.invokeSuspend(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:1412)
                                                                                                    	at c7.e.invoke(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:318)
                                                                                                    	at F0.c.F(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:19)
                                                                                                    	at Jg.E.O(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:80)
                                                                                                    	at D6.J.invokeSuspend(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:370)
                                                                                                    	at D6.J.invoke(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:35)
                                                                                                    	at Mg.s0.collect(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:108)
                                                                                                    	at Ng.i.j(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:3)
                                                                                                    	at Ng.h.f(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:6)
                                                                                                    	at A7.H.i(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:35)
                                                                                                    	at A7.H.invokeSuspend(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:117)
                                                                                                    	at kg.a.resumeWith(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:8)
                                                                                                    	at Jg.N.run(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:115)
                                                                                                    	at Mc.b.run(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:1236)
                                                                                                    	at Qg.j.run(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:3)
                                                                                                    	at Qg.a.run(r8-map-id-f6420fa8863cc8c52d240aa7274a83fcdbb76a86493d67bd3d8b55255c8c2aed:88)
2025-08-13 20:09:26.924 17505-17740 SQLiteConnection        my.app                I  Database keying operation returned:0
2025-08-13 20:09:26.987 17505-17819 TRuntime.C...ortBackend my.app                I  Making request to: https://crashlyticsreports-pa.googleapis.com/v1/firelog/legacy/batchlog
2025-08-13 20:09:26.988 17505-17819 TRuntime.C...ortBackend my.app                E  Couldn't open connection, returning with 500
2025-08-13 20:09:27.004 17505-17581 Process                 my.app                I  Sending signal. PID: 17505 SIG: 9

I'm using this with Room, and I'm not sure if there's any way to gracefully recover from this error - other than clearing storage before relaunching the app. I'm a little worried this will happen to a user in production, especially if they're using the app and the phone dies or something.

[mandrachek]

I should probably add that this is with 4.10.0

[sjlombardo]

Hello @mandrachek - the log output included in this report is what you'd expect to see if a database connection was used with incorrect key material. If you are seeing this accessing a previously created database it would indicate that the key is different than when the database was created. Can you provide some information on what you are using for the key?

[mandrachek]

On first access we create a randomly generated byte array, and this is stored in a jetpack datastore (an instance used only for this), where the value is encrypted using the android keystore. On later accesses, we get the encrypted byte array from the key store and decrypt it. This process works fine, and is consistent. The only way this would fail is if they key didn't exist in the keystore, the encrypted byte array didn't exist in the datastore, or the decyption failed. And logging tells me this is all appears to be working correctly. Unfortunately I cannot reproduce this consistently. Which is what leads me to believe perhaps the db file is corrupt (a corrupt file would appear to be the same as a file with an incorrect key, no? The decryption would fail... )

…

On Tue, Aug 19, 2025, 3:11 PM Stephen Lombardo ***@***.***> wrote: *sjlombardo* left a comment (sqlcipher/sqlcipher-android#68) <#68 (comment)> Hello @mandrachek <https://github.com/mandrachek> - the log output included in this report is what you'd expect to see if a database connection was used with incorrect key material. If you are seeing this accessing a previously created database it would indicate that the key is different than when the database was created. Can you provide some information on what you are using for the key? — Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH7HQBKBYQXC272AZOQFPL3ONZG5AVCNFSM6AAAAACD3FSSJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMBRHEYTOMBQGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sjlombardo]

Hi @mandrachek thanks for the details. We like to check that first because we have seen so many cases where the process used to generate the key material is either not stable, or is subject to subtle bugs that could result in the application using an incorrect key to open a database if an unexpected error occurs. It is the cause of the vast majority of the errors we've seen and helped troubleshoot over the past few years.

That said, if you have confidently ruled that out then, yes, database corruption is another possible cause. Database corruption could manifest as an error 26 file is not a database (especially if the corruption is in the first few pages of the database containing the schema) or as an error 11 database disk image is malformed (if the corruption is localized elsewhere in the database).

If this occurs for you locally (even intermittently) can you capture the database for examination? If so, you could take a look for obvious signs of problems (e.g. zero blocks in the database file, a database that is not actually encrypted, some other issue). You could also use cipher_integrity_check to scan the database (though if the header is badly corrupted it won't be able to report meaningful results).

Finally, if you suspect corruption, it's worth just a quick review of the How to Corrupt a SQLite Database document to ensure none of the issues there are applicable (especially, multi-linking SQLite implementations, opening SQLite databases outside of the SQLite library).