Sichern/Wiederherstellen von SMS/MMS über ADB auf einem nicht gerooteten Gerät?

Gibt es eine Möglichkeit, SMS- und MMS-Nachrichten mit ADB zu sichern/wiederherstellen, wenn das Gerät nicht gerootet ist?

  • adb pullfunktioniert hier nicht, da die entsprechende Datenbank ( /data/data/com.android.providers.telephony/databases/mmssms.db) nicht von ADB gelesen werden kann, wenn sie nicht im unsicheren (root) Modus läuft
  • adb shell "cat /data/data/com.android.providers.telephony/databases/mmssms.db > /sdcard/mmssms.dbgeht auch nicht ohne Root-Zugriff
  • adb backupdeckt diese Datenbank aus irgendeinem Grund nicht auf dem Gerät ab, mit dem ich überprüft habe (leeres Backup – nur die 41 Bytes des Backup-Headers in der resultierenden Datei)

Ich frage mich besonders, warum adb backupdies nicht abgedeckt wird. Wenn es aus "Datenschutzgründen" ist, dann sollte das gleiche für die Kontaktdatenbank gelten - die eindeutig gesichert ist.

Verweise:

Also: Irgendeine Lösung auf einem nicht gerooteten Gerät? Beachten Sie, dass ich NICHT nach einer App-basierten Lösung frage. Ich bin mir bewusst, dass es dafür mehrere Apps gibt . Ich möchte speziell eine "Shell-basierte Lösung", die über ADB verwendet werden kann.

Ich frage NICHT nach einer App-basierten Lösung “ – Schon wieder Forensik?
Vorzugsweise ja (für andere Leser: bevorzugte Lösungen erfordern keine Änderungen am Gerät). Bedenken Sie, dass das betreffende Gerät bereits "nicht genügend Speicher" meldet, sodass es nicht möglich ist, etwas zu installieren. Da sich das Gerät auch sonst merkwürdig verhält, muss ein Werksreset durchgeführt werden – es wäre also schön, so viele Daten wie möglich zu „retten“. Ich konnte die meisten Dinge über sichern adb backup: wenige Ausnahmen, die meisten davon ignorierbar, aber der Benutzer behält sehr gerne SMS, die ebenfalls nicht abgedeckt wurden.
Sie da! Entschuldigen Sie die Mühe, haben Sie jemals eine Lösung dafür ohne Root? Übrigens ausgezeichnete App-Liste, danke für diesen Link!
@Gruber Nein, habe immer noch nichts gefunden. // Freut mich, dass dir meine App-Listen gefallen!

Antworten (1)

Ich frage mich besonders, warum adb backup dies nicht abdeckt.

Es ist nicht das , was adb backupdie App nicht abdecken möchte com.android.providers.telephony. Diese App unterscheidet sich nicht wesentlich von anderen System-Apps, die auf ihrer AndroidManifest.xml. Das Problem ist das Flag, das sein Entwickler im Manifest deklariert hat, das aus irgendeinem Grund als Standardmechanismus adb backuprespektiert werden muss.

Dieses Flag ist nichts anderes als android:allowBackup="false". Die App wird sowohl von der ADB-Sicherung als auch von der Wiederherstellung ausgeschlossen. Google muss hier sagen:

android:allowBackup

Ob die Anwendung an der Sicherungs- und Wiederherstellungsinfrastruktur teilnehmen darf. Wenn dieses Attribut auf „false“ gesetzt ist, wird niemals eine Sicherung oder Wiederherstellung der Anwendung durchgeführt, auch nicht durch eine vollständige Systemsicherung, die ansonsten dazu führen würde, dass alle Anwendungsdaten über adb gespeichert werden. Der Standardwert dieses Attributs ist wahr.

(Hervorhebung von mir)

Sehen Sie sich hierAndroidManifest.xml die Lollipop-Version dieser App an oder sehen Sie sich diesen Beweis für mein Android 4.2.1 an:

IMG: kein Backup-Flag

Diese App hat noch mehr zu bieten. Sie können nicht einmal Daten aus Einstellungen → Apps → Alle Apps → löschen<THIS_APP> , da android:allowClearUserData="false"dies auch deklariert ist, was uns ab und zu nicht begegnet.

Wenn es aus "Datenschutzgründen" ist, dann sollte das gleiche für die Kontaktdatenbank gelten - die eindeutig gesichert ist.

Es ist bizarr, nicht, dass Sie dazu in der Lage wären, aber wie erlaubt Ihnen Ihr System, das nur mit adb backup!

Die Kontaktspeicherung wird von der "ContactsProvider"-App verwaltet, die den pkg_name= trägt com.android.providers.contacts. Die Flagge android:allowBackup="false"wird deutlich AndroidManifest.xmlfür Jelly Bean erwähnt (klicken Sie hier , um die anderen Versionen zu sehen).

Verwenden Sie ICS oder einen Vorgänger von JB?

Ich habe festgestellt, dass diese App hier keine Deklaration dieses Flags für ICS hat . Sie können dieses Rätsel tatsächlich lösen, da ich gemäß der Definition des Flags kein Backup dieser App in meinem JB 4.2.1 erstellen kann und immer diese 41-Byte-Backup-Datei bekomme.


Wie bei jeder anderen Methode zum Sichern/Wiederherstellen von SMS/MMS mit ADB ohne Root-Zugriff – alle Hände hoch hier.

Mir ist bewusst, dass es diese Flagge ist. Aber sowohl diese App als auch ADB sind Teil des Systems – wir sprechen hier nicht von einem Drittanbieter. Zur Klarstellung: Das Gerät, auf das ich mich hier beziehe, läuft mit JellyBean (4.1.2). Dank Deines Hinweises werde ich es nochmal mit meinen anderen Geräten (4.2 und 4.3) versuchen. Zum Datenschutz: Es könnte auch ein Hinweis darauf geben, dass der Benutzer ein Passwort angeben muss. Außerdem kann SharedStorage auch „private Daten“ enthalten – außerdem geht Google davon aus, dass ich meine Kontakte/Kalender standardmäßig synchronisieren möchte, wenn ich ein Google-Konto aktiviere, anstatt mich zu fragen (also keine Möglichkeit, sich abzumelden, wenn Sie es bereits dort hinzufügen ).
Auf die Gefahr hin, dass es zum Geschwätz wird: Wenn es zu privat ist, um gesichert zu werden – warum ist es dann auch gegen "klare Daten" geschützt? „Schreibe niemals der Bosheit zu, was sich durch reine Dummheit erklären lässt“ … // Ohne root geht es also nicht: da bleibt nur das passende Xposed-Modul („Backup all Apps“). Was wiederum auf dem Gerät installiert werden muss – was ich vermeiden wollte … Einfach die Datenbank ziehen (mit root) wäre ein Workaround – aber das erlaubt keine geräteübergreifende Wiederherstellung (habe das einmal versucht, war kein gute Idee, da es SMS unbrauchbar machte, also musste ich zurücksetzen)
Ich weiß, @Izzy, dass Sie sich einer so einfachen Flagge bewusst sind (Sie sind nicht aus dem Nichts zum Profi geworden, sondern durch Forschung und Erfahrung :), aber andere, die Antworten auf solch einfache Fragen suchen, wissen wahrscheinlich nichts davon und alles dieser Info war nicht für den Kommentar geeignet. Ich hatte eigentlich vor, diesen Kommentar zu schreiben, habe das aber am Ende vergessen, als ich diese Antwort schrieb, sorry!
// Was das Passwort angeht: ADB bietet zwar ein passgeschütztes Backup, aber Google (IMO) könnte der Meinung sein, dass es besser ist, den Zugriff auf vertrauliche Inhalte zu verhindern, als den Zugriff zuzulassen, was im Falle eines Geräteverlusts zu einem Datendump durch Unbefugte führen kann Person, ob das USB-Debugging zufällig aktiviert war, gefolgt von einem Brute-Force-Angriff.
// Was die Synchronisierung angeht, ein Unternehmen tut normalerweise nichts kostenlos, es sei denn, es handelt sich um ein Geschäft, und die Daten jedes einzelnen Benutzers sind ziemlich viele Daten für die Recherche und für Kunden, die sie möglicherweise benötigen, // ich weiß es nicht "Daten löschen", nur in XML gesehen, also darüber geschrieben, // Ohne Root sind die Chancen sehr gering, und das bedeutet reine Abhängigkeit von Google Cloud-Backup in einem nicht gerooteten Gerät, für das viele OEMs sorgen, indem die Gerätegarantie erlischt Richtlinien, damit viele Benutzer überhaupt nicht rooten
-- na ja, sie hatten von Anfang an herausgefunden, wie man die Freiheit im Namen des Geschäfts einschränkt, vielleicht etwas anderes. Ich werde was Gutes berichten (nicht schimpfen natürlich), wenn mir das irgendwie begegnet.
LOL zum letzten Satz Ihres letzten Kommentars – insbesondere zur Wenn-Bedingung :) Und vielleicht sollten wir sehen, was aus diesen Kommentaren in Ihre Antwort integriert werden sollte (abzüglich der ~ 70% Schimpfwörter von uns beiden eingeschlossen) und dann aufräumen? Ich habe es inzwischen positiv bewertet (für den Hintergrund, den Sie so ausführlich beschrieben haben). Das Problem nicht wirklich lösen , ich wage es nicht, es zu "akzeptieren" - obwohl ein "nicht möglich, da ..." eine voll gültige Antwort ist. Wäre nicht das erste Mal, dass hier bei ASE aus heiterem Himmel eine Lösung für das „scheinbar Unmögliche“ auftaucht (und für eine meiner Fragen).