1 votes

Android pense que accounts.db est corrompu et le supprime.

Après un redémarrage, j'ai perdu tous mes comptes. J'ai regardé dans le logcat et j'ai obtenu :

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

J'ai restauré le fichier complètement à partir d'un fichier XML de TitaniumBackup (ainsi la base de données est à nouveau créée proprement, pas de sauvegarde d'un éventuel fichier db corrompu). Après un redémarrage, Android le supprime à nouveau et le recrée, en y accédant juste après la restauration (c'est-à-dire en utilisant un programme qui recherche un compte), le message suivant s'affiche

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.

juste après la restauration, je peux ouvrir mon accounts.db avec sqlite3 y SELECT * FROM ACCOUNTS renvoie une liste correcte et SELECT key, value FROM extras fonctionne aussi comme prévu.

Les autorisations de fichiers sont

-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

Ma ROM est une CyanogenMod 13.

1voto

Nick Veitch Points 864

Je l'ai réparé, même si je ne comprends pas ce qui s'est passé.

J'ai vérifié le fichier sqlite créé avec PRAGMA integrity_check; Après la réindexation et l'aspiration, j'ai reçu un message indiquant qu'il était corrompu (pas avant).

J'ai essayé de le recréer comme dans ce blogpost et définir les permissions du fichier, ce qui a causé une boucle de démarrage.

Ensuite, j'ai redémarré en mode de récupération et j'ai remplacé le accounts.db avec un vide d'un deuxième compte sur le téléphone et ensuite lire le dump_all.sql créé auparavant dans la base de données.

Maintenant cela fonctionne, même si je ne sais pas quelle est la différence entre lire les données dans une base de données fraîche (ce qui a provoqué un bootloop) et les lire dans une base de données vide créée par Android. Cela peut être lié à des contextes selinux manquants ou quelque chose de similaire.

Donc les étapes de travail pour quiconque a un problème similaire :

  • vidange des données de la base de données éventuellement cassée (même si elle vient d'être créée par TitaniumBackup)
  • copier une base de données vide
  • Importer les données dans la base de données
  • redémarrer

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X