Sauvegarder / restaurer SMS / MMS via ADB sur un appareil non rooté?

Existe-t-il un moyen de sauvegarder / restaurer les messages SMS et MMS à l'aide d'ADB, lorsque l'appareil n'est pas enraciné?

adb pullne fonctionnera pas ici, car la base de données correspondante ( /data/data/com.android.providers.telephony/databases/mmssms.db) ne peut pas être lue par ADB si elle ne fonctionne pas en mode non sécurisé (root)
adb shell "cat /data/data/com.android.providers.telephony/databases/mmssms.db > /sdcard/mmssms.db ne fonctionne pas non plus sans accès root
adb backup pour une raison quelconque, ne couvre pas cette base de données sur l'appareil avec lequel j'ai vérifié (sauvegarde vide - juste les 41 octets de l'en-tête de sauvegarde dans le fichier résultant)

Je me demande surtout pourquoi adb backupne couvre pas cela. Si c'est pour des "raisons de confidentialité", alors la même chose devrait s'appliquer à la base de données de contacts - qui est clairement sauvegardée.

Références:

Adb peut-il être utilisé pour récupérer des messages SMS en «mode sans échec» permanent? couvre le même sujet - mais à part ça, je ne suis pas limité au mode sans échec
la sauvegarde du contenu sms / mms complet via adb (sur le site frère de nos développeurs) est pour une "solution enracinée" (et, à part cela, un peu d'âge: les questions et réponses ont plus de 3 ans)

Donc: une solution sur un appareil non rooté? Notez que je ne demande PAS de solution basée sur une application. Je suis pleinement conscient qu'il existe plusieurs applications disponibles pour cela . Je veux spécifiquement une "solution basée sur le shell", à utiliser via ADB.

— Izzy
source

" Je ne demande PAS une solution basée sur les applications " - Forensics encore?

— Firelord

De préférence oui (pour les autres lecteurs: les solutions préférées ne nécessitent aucune modification sur l'appareil). Considérez que l'appareil en question signale déjà "une mémoire insuffisante", il n'est donc pas possible d'installer quelque chose. Comme l'appareil se comporte également de manière étrange dans un autre contexte, une réinitialisation d'usine doit être effectuée - il serait donc intéressant de "sauvegarder" autant de données que possible. J'ai pu sauvegarder la plupart des choses via adb backup: quelques exceptions, la plupart ignorables, mais l'utilisateur aime beaucoup garder les SMS qui n'étaient pas non plus couverts.

— Izzy

Héy! Désolé de déranger avez-vous déjà une solution à cela sans racine? BTW excelent app list, merci pour ce lien!

— Gruber

@Gruber Non, je n'ai toujours rien trouvé. // Heureux que vous aimiez mes listes d'applications!

— Izzy

Je me demande surtout pourquoi la sauvegarde adb ne couvre pas cela.

Ce n'est pas que adb backupne veut pas couvrir l'application com.android.providers.telephony. Cette application n'est pas très différente de toute autre application système basée sur son AndroidManifest.xml. Le problème vient du drapeau que son développeur a déclaré dans le manifeste qui, en tant que mécanisme par défaut, adb backupest tenu de respecter pour une raison quelconque .

Ce drapeau n'est autre que android:allowBackup="false". Il exclut l'application de la sauvegarde et de la restauration ADB. Google doit dire ici :

android:allowBackup

Indique s'il faut autoriser l'application à participer à l'infrastructure de sauvegarde et de restauration. Si cet attribut est défini sur false, aucune sauvegarde ou restauration de l'application ne sera jamais effectuée, même par une sauvegarde complète du système qui autrement entraînerait la sauvegarde de toutes les données d'application via adb. La valeur par défaut de cet attribut est vraie.

_{(Souligner le mien)}

Découvrez la version AndroidManifest.xmlde cette application pour Lollipop ici , ou consultez ces preuves pour mon Android 4.2.1:

IMG: aucun indicateur de sauvegarde

Il y a plus à cette application. Vous ne pouvez même pas effacer les données de Paramètres → Applications → Toutes les applications →<THIS_APP> car android:allowClearUserData="false"est également déclaré, pas quelque chose que nous rencontrons de temps en temps.

Si c'est pour des "raisons de confidentialité", alors la même chose devrait s'appliquer à la base de données de contacts - qui est clairement sauvegardée.

C'est bizarre, non pas que vous puissiez le faire, mais comment votre système vous permet-il de le faire juste avec adb backup!

Le stockage des contacts est géré par l'application "ContactsProvider" qui s'appelle pkg_name = com.android.providers.contacts. Le drapeau android:allowBackup="false"est clairement mentionné dans son AndroidManifest.xmlpour Jelly Bean (cliquez ici pour voir les autres versions).

Utilisez-vous ICS ou un prédécesseur de JB?

J'ai trouvé que cette application n'a aucune déclaration de ce drapeau pour ICS ici . Vous pouvez réellement effacer ce mystère, car je ne peux pas prendre de sauvegarde de cette application dans mon JB 4.2.1 selon la définition de l'indicateur, et obtient toujours ce fichier de sauvegarde de 41 octets.

Comme pour toute autre méthode pour effectuer une sauvegarde / restauration SMS / MMS en utilisant ADB sans accès root - tout le monde ici.

— Seigneur du feu
source

Je sais que c'est ce drapeau. Mais à la fois, cette application et ADB font partie du système - nous ne parlons pas ici d'un fournisseur tiers. Pour plus de précision: l'appareil auquel je fais référence ici exécute JellyBean (4.1.2). Grâce à votre indice, je vais réessayer avec mes autres appareils (4.2 et 4.3). Concernant la confidentialité: il pourrait également y avoir un indice pour que l'utilisateur fournisse un mot de passe. De plus, SharedStorage peut également contenir des "données privées" - plus Google suppose que je veux synchroniser mes contacts / calendriers par défaut lors de l'activation d'un compte Google, au lieu de me le demander (donc aucun moyen de se retirer si vous les ajoutez avec eux déjà là) ).

— Izzy

En danger de devenir une diatribe: s'il est trop privé pour être sauvegardé - pourquoi est-il alors protégé contre les "données claires"? "Ne jamais attribuer à la malveillance ce qui peut s'expliquer par pure stupidité"… // Donc, ce n'est pas possible sans root: cela ne laisse que le module Xposed approprié ("Sauvegarder toutes les applications"). Ce qui doit encore être installé sur l'appareil - ce que je voulais éviter ... Le simple fait de tirer la base de données (avec root) serait une solution de contournement - mais cela ne permet pas la restauration multi-appareils (essayé une fois, ce n'était pas un bonne idée car cela rendait les SMS inutilisables donc j'ai dû réinitialiser)

— Izzy

Je sais @Izzy que vous êtes au courant d'un drapeau aussi simple, (vous n'êtes pas devenu Pro de rien, mais par la recherche et l'expérience :) mais d'autres qui recherchent des réponses à une question aussi simple ne le savent probablement pas, et tout de cette information ne convenait pas au commentaire. En fait, j'avais en tête d'écrire ce commentaire, mais j'ai oublié qu'en fin de compte en écrivant cette réponse, désolé!

— Firelord

// En ce qui concerne le mot de passe, alors qu'ADB fournit une sauvegarde protégée par passe, Google (IMO) pense peut-être qu'il est préférable d'empêcher l'accès à du contenu sensible que d'autoriser l'accès qui, en cas de perte de périphérique, peut entraîner un vidage de données non autorisé personne si le débogage USB a été activé par hasard, suivi d'une attaque par force brute.

— Firelord

- oh, eh bien, ils l'avaient compris depuis le début de la façon de restreindre la liberté au nom de l'entreprise, peut-être autre chose. Je rapporterai quelque chose de bien (sans délire bien sûr) si je rencontre en quelque sorte.

— Firelord