After a reboot, i lost all my accounts. i looked into the logcat and got:

04-02 11:54:01.535  5305  8068 E SQLiteLog: (11) statement aborts at 24: [SELECT key, value FROM extras WHERE accounts_id=(select _id FROM accounts WHERE name=? AND type=?)] database disk image is malformed
04-02 11:54:01.537  5305  8068 E DefaultDatabaseErrorHandler: Corruption reported by sqlite on database: /data/system/users/0/accounts.db
04-02 11:54:01.538  5305  8068 E DefaultDatabaseErrorHandler: deleting the database file: /data/system/users/0/accounts.db

I restored the file completely from a TitaniumBackup XML-file (so the database is created cleanly again, no backup of a possible corrupt db file). After a reboot, android deletes it again and recreates it, accessing it just after restoring (i.e. using a program, which looks up an account) gives the message

04-02 11:45:22.855 12225 12225 W System.err: Caused by: java.lang.IllegalStateException: The database '/data/system/users/0/accounts.db' is not open.

just after restore, i can open my accounts.db with sqlite3 and SELECT * FROM ACCOUNTS returns a correct list and SELECT key, value FROM extras works as expected, too.

The file permissions are

-rw-rw---- 1 system system  72K 2017-04-02 11:55 accounts.db
-rw------- 1 system system  17K 2017-04-02 11:55 accounts.db-journal

My ROM is a CyanogenMod 13.

1 Answer 1


I got it fixed, even when i do not understand what happend

I checked the created sqlite file with PRAGMA integrity_check;, and after reindex and vacuum i actually got a message its corrupted (not before).

I tried to recreate it like in this blogpost and set the file permissions, which caused a bootloop.

Then i rebootet to recovery and replaced the accounts.db with a empty one from a second account on the phone and then read the dump_all.sql created before into the database.

Now it works, even when i do not know what's the difference between reading the data into a fresh database (which caused a bootloop) and reading it into a android created empty database. It may be related to missing selinux contexts or something similiar.

So the working steps for anyone with a similiar problem:

  • dump the data from the possibly broken db (even when freshly created by TitaniumBackup)
  • copy an empty db
  • import the data into the db
  • reboot

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .