Seit der neue ADT Preview-Version (Version 21), sie haben eine neue Flusenwarnung, die mir das nächste in der Manifestdatei (im Anwendungs-Tag) mitteilt:
Sollte android:allowBackup explizit auf „true“ oder „false“ setzen (es ist standardmäßig „true“ und das kann einige Auswirkungen auf die Sicherheit der Anwendungsdaten haben)
Ein paar neue Checks: Sie müssen explizit entscheiden, ob Ihre App Backups und einen Label-Check zulässt. Es gibt ein neues Befehlszeilen-Flag zum Festlegen des Bibliothekspfads. Viele Verbesserungen der inkrementellen Fusselanalyse während der Bearbeitung.
Was ist diese Warnung? Was ist die Sicherungsfunktion und wie verwende ich sie?
Warum sagt mir die Warnung auch, dass es Auswirkungen auf die Sicherheit hat? Was sind die Nachteile und Vorteile der Deaktivierung dieser Funktion?
Es gibt zwei Sicherungskonzepte für das Manifest:
“Android:Sicherung zulassen” ermöglicht das Sichern und Wiederherstellen über adb, wie gezeigt Hier:
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.
Dies wird als Sicherheitsproblem angesehen, da Personen Ihre App über sichern könnten ADB und dann private Daten Ihrer App auf ihren PC übertragen.
Ich denke jedoch, dass dies kein Problem darstellt, da die meisten Benutzer nicht wissen, was adb ist, und wenn sie dies tun, wissen sie auch, wie sie das Gerät rooten. ADB-Funktionen würden nur funktionieren, wenn auf dem Gerät die Debugging-Funktion aktiviert ist, und dazu muss der Benutzer sie aktivieren.
Es wären also nur Benutzer betroffen, die ihre Geräte an den PC anschließen und die Debugging-Funktion aktivieren. Wenn sie eine schädliche App auf ihrem PC haben, die die ADB-Tools verwendet, könnte dies problematisch sein, da die App die privaten Speicherdaten lesen könnte.
Ich denke, Google sollte einfach eine standardmäßig deaktivierte Funktion in der Entwicklerkategorie hinzufügen, um das Sichern und Wiederherstellen von Apps über ADB zu ermöglichen.
“Android:backupAgent” ermöglicht die Verwendung der Sicherungs- und Wiederherstellungsfunktion der Cloud, wie gezeigt Hier und Hier:
Der Name der Klasse, die den Sicherungsagenten der Anwendung implementiert, eine Unterklasse von BackupAgent. Der Attributwert sollte ein vollständig qualifizierter Klassenname sein (z. B. “com.example.project.MyBackupAgent”). Wenn das erste Zeichen des Namens jedoch ein Punkt ist (z. B. “.MyBackupAgent”), wird es als Kurzform an den im Element angegebenen Paketnamen angehängt. Es gibt keine Vorgabe. Der Name muss angegeben werden.
Dies ist kein Sicherheitsproblem.
Ich denke, Sie sollten diese zusätzlichen Informationen in Ihrer Bearbeitung entfernen, da sich dies auf den Backup-Cloud-Dienst bezieht, anstatt auf das ADB-Backup-Tool, auf das sich dieses Problem tatsächlich bezieht (gemäß der Antwort von Tor Norbye).
– Toni Chan
23. September 13 um 23:23 Uhr
@Turbo ja du hast recht. Ich denke, es wurde nicht so viel aktualisiert, als ich es gelesen habe, aber jetzt ist es klar. Ich werde die Frage aktualisieren. Danke. Ich frage mich, ob die ADB-Backup-Funktion auf gerooteten Geräten auch für Apps verwendet werden kann, die sie auf „false“ gesetzt haben.
– Android-Entwickler
24. September 13 um 7:02 Uhr
@IgorGanapolsky also bin ich gerade total verwirrt. Warum haben sie es in 2 völlig unterschiedlichen Funktionen erwähnt? ist es möglich, dass das gleiche Flag für beide Features verantwortlich ist? oder ist es vielleicht ein fehler? Glaubst du, ich sollte die Antwort, die ich angekreuzt habe, abhaken?
– Android-Entwickler
24. September 13 um 14:36 Uhr
@androiddeveloper Der Grund dafür, dass für beide Funktionen genau dasselbe Attribut vorhanden ist, liegt wahrscheinlich darin, dass es für denselben ultimativen Zweck bestimmt ist: das Sichern von Daten. Ob auf dem Gerät oder in der Cloud…
– IgorGanapolsky
25. September 13 um 14:13 Uhr
Als Android Nutzer Ich möchte für jeden, der dies findet, abwägen und sagen, dass ich Apps nicht ausstehen kann – und es gibt viele -, die die Sicherung deaktivieren. Wenn eine Person Zugriff auf ein entsperrtes Telefon hat, sollte sie in der Lage sein, Daten davon zu kopieren. Jede „Sicherheits“-Maßnahme an diesem Punkt ist bedeutungslos, da sie das Telefon immer rooten könnten, um an die Daten zu kommen. Aber als Benutzer ist es enorm wertvoll, meine App-Daten sichern zu können (ohne zu rooten und mein Knox-Bit auszulösen). Es ist wirklich frustrierend, dass so viele Apps dies nicht zulassen, und ehrlich gesagt, dass Android diesen Schalter überhaupt hat.
– Nathan Stretch
14. Juli 16 um 6:51 Uhr
Tor Norbye
Beachten Sie für diese Flusenwarnung, wie für alle anderen Flusenwarnungen, dass Sie eine ausführlichere Erklärung erhalten können als nur das, was in der einzeiligen Fehlermeldung steht; Sie müssen nicht im Internet nach weiteren Informationen suchen.
Wenn Sie Lint über Eclipse verwenden, öffnen Sie entweder die Lint-Warnungsansicht, in der Sie den Lint-Fehler auswählen und eine längere Erklärung sehen können, oder rufen Sie die Schnellkorrektur (Strg-1) in der Fehlerzeile auf, und einer der Vorschläge lautet ” Erklären Sie dieses Problem”, wodurch auch eine ausführlichere Erklärung angezeigt wird. Wenn Sie Eclipse nicht verwenden, können Sie einen HTML-Bericht aus lint (lint --html <filename>), die neben den Warnungen vollständige Erklärungen enthält, oder Sie können lint bitten, ein bestimmtes Problem zu erklären. Zum Beispiel das Problem im Zusammenhang mit allowBackup hat die ID AllowBackup (wird am Ende der Fehlermeldung angezeigt), daher lautet die ausführlichere Erklärung:
$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest
Priority: 3 / 10
Severity: Warning
Category: Security
Der allowBackup Das Attribut bestimmt, ob die Daten einer Anwendung wie dokumentiert gesichert und wiederhergestellt werden können Hier.
Standardmäßig ist dieses Flag auf gesetzt true. Wenn dieses Flag gesetzt ist truekönnen Anwendungsdaten vom Benutzer mit gesichert und wiederhergestellt werden adb backup und adb restore.
Dies kann Auswirkungen auf die Sicherheit einer Anwendung haben. adb backup ermöglicht Benutzern, die das USB-Debugging aktiviert haben, Anwendungsdaten vom Gerät zu kopieren. Einmal gesichert, können alle Anwendungsdaten vom Benutzer gelesen werden. adb restore ermöglicht die Erstellung von Anwendungsdaten aus einer vom Benutzer angegebenen Quelle. Nach einer Wiederherstellung sollten Anwendungen nicht davon ausgehen, dass die Daten, Dateiberechtigungen und Verzeichnisberechtigungen von der Anwendung selbst erstellt wurden.
Einstellung allowBackup="false" sperrt eine Anwendung sowohl für die Sicherung als auch für die Wiederherstellung.
Um diese Warnung zu beheben, entscheiden Sie, ob Ihre Anwendung Sicherungen unterstützen und explizit festlegen soll android:allowBackup=(true|false)
Benutzer wissen normalerweise nicht einmal, was ADB ist, und wenn sie es wissen, wissen sie wahrscheinlich sowieso, wie sie ihr Gerät rooten und die Daten selbst abrufen können, oder?
– Android-Entwickler
10. Dezember 2012 um 19:36 Uhr
@Tor Wenn Sie “Anwendungsdaten vom Gerät kopieren” sagen, meinen Sie das Kopieren von data/data/com.myapp oder von der SD-Karte? Das frühere Verzeichnis ist geschützt und kann nicht gelesen werden, es sei denn, das Gerät ist gerootet.
– IgorGanapolsky
1. April 13 um 12:53 Uhr
Zur Verdeutlichung ist dieses Backup, auf das Lint verweist, das ADB-Tool und nicht der Cloud-Backup-Service, richtig? Scheint, dass viele der anderen Antworten so verwirrt sind.
– Toni Chan
23. September 13 um 23:23 Uhr
@IgorGanapolsky Ich denke, dass die Verwendung von ADB die privaten Daten kopiert, und deshalb gibt es eine Warnung. Ich denke, nur Leute, die die Debugging-Funktion aktiviert haben und ihr Gerät mit dem PC verbinden, sind betroffen. Solche Leute sind normalerweise Power-User oder Entwickler, also sollten sie wissen, was sie tun. Das Sicherheitsrisiko besteht für Personen, die dies versehentlich getan und eine schädliche App auf dem PC installiert haben, die das ADB-Tool verwendet, um diese Vorgänge auszuführen. Es gibt eine App für Backup&Restore ohne Root namens “Helium”: play.google.com/store/apps/…
– Android-Entwickler
24. September 13 um 7:15 Uhr
„Wenn Sie lint über Eclipse verwenden …“ sollten Sie wahrscheinlich zu AndroidStudio migrieren, da das ADT-Plug-in veraltet ist.
– throws_exceptions_at_you
10. Februar 15 um 10:44 Uhr
IgorGanapolsky
Hier ist, was Backup in diesem Sinne wirklich bedeutet:
Mit dem Sicherungsdienst von Android können Sie Ihre persistenten Anwendungsdaten auf einen Remote-“Cloud”-Speicher kopieren, um einen Wiederherstellungspunkt für die Anwendungsdaten und -einstellungen bereitzustellen. Wenn ein Benutzer einen Werksreset durchführt oder zu einem neuen Android-betriebenen Gerät konvertiert, stellt das System Ihre Sicherungsdaten automatisch wieder her, wenn die Anwendung neu installiert wird. Auf diese Weise müssen Ihre Benutzer ihre vorherigen Daten oder Anwendungseinstellungen nicht reproduzieren.
Die Datentypen, die gesichert werden können, sind Dateien, Datenbanken, gemeinsam genutzte Einstellungen, Cache und Lib. Diese werden in der Regel im Ordner /data/data/ Ihres Geräts gespeichert.[com.myapp] Verzeichnis, das lesegeschützt ist und auf das nur mit Root-Rechten zugegriffen werden kann.
AKTUALISIEREN: Sie können dieses Flag im API-Dokument von BackupManager sehen: BackupManager
Dies wird nicht explizit erwähnt, aber basierend auf den folgenden Dokumenten denke ich, dass es impliziert ist, dass eine App einen BackupAgent deklarieren und implementieren muss, damit die Datensicherung funktioniert, selbst in dem Fall, in dem allowBackup auf true gesetzt ist (was die Standardwert).
Was ist, wenn die App nichts mit dem BackupAgent zu tun hat? Wird Android seine Daten trotzdem automatisch sichern?
– Android-Entwickler
20. Februar 13 um 21:09 Uhr
Die richtige Antwort finden Sie hier: stackoverflow.com/a/13806946/878126 . Es scheint, dass es nichts mit dem BackupAgent zu tun hat. Ich habe auch meine Frage aktualisiert, um zu zeigen, worum es geht.
– Android-Entwickler
24. September 13 um 7:30 Uhr
Ayaz Alifov
es ist Privatsphäre Anliegen. Es wird empfohlen, Benutzern das Sichern einer App zu verbieten, wenn sie vertrauliche Daten enthält. Zugriff auf Backup-Dateien haben (dh wann android:allowBackup="true") ist es möglich, den Inhalt einer App auch auf einem nicht gerooteten Gerät zu ändern/zu lesen.
Lösung – verwenden android:allowBackup="false" in der Manifestdatei.
Ich denke, Sie sollten diese zusätzlichen Informationen in Ihrer Bearbeitung entfernen, da sich dies auf den Backup-Cloud-Dienst bezieht, anstatt auf das ADB-Backup-Tool, auf das sich dieses Problem tatsächlich bezieht (gemäß der Antwort von Tor Norbye).
– Toni Chan
23. September 13 um 23:23 Uhr
@Turbo ja du hast recht. Ich denke, es wurde nicht so viel aktualisiert, als ich es gelesen habe, aber jetzt ist es klar. Ich werde die Frage aktualisieren. Danke. Ich frage mich, ob die ADB-Backup-Funktion auf gerooteten Geräten auch für Apps verwendet werden kann, die sie auf „false“ gesetzt haben.
– Android-Entwickler
24. September 13 um 7:02 Uhr
@IgorGanapolsky also bin ich gerade total verwirrt. Warum haben sie es in 2 völlig unterschiedlichen Funktionen erwähnt? ist es möglich, dass das gleiche Flag für beide Features verantwortlich ist? oder ist es vielleicht ein fehler? Glaubst du, ich sollte die Antwort, die ich angekreuzt habe, abhaken?
– Android-Entwickler
24. September 13 um 14:36 Uhr
@androiddeveloper Der Grund dafür, dass für beide Funktionen genau dasselbe Attribut vorhanden ist, liegt wahrscheinlich darin, dass es für denselben ultimativen Zweck bestimmt ist: das Sichern von Daten. Ob auf dem Gerät oder in der Cloud…
– IgorGanapolsky
25. September 13 um 14:13 Uhr
Als Android Nutzer Ich möchte für jeden, der dies findet, abwägen und sagen, dass ich Apps nicht ausstehen kann – und es gibt viele -, die die Sicherung deaktivieren. Wenn eine Person Zugriff auf ein entsperrtes Telefon hat, sollte sie in der Lage sein, Daten davon zu kopieren. Jede „Sicherheits“-Maßnahme an diesem Punkt ist bedeutungslos, da sie das Telefon immer rooten könnten, um an die Daten zu kommen. Aber als Benutzer ist es enorm wertvoll, meine App-Daten sichern zu können (ohne zu rooten und mein Knox-Bit auszulösen). Es ist wirklich frustrierend, dass so viele Apps dies nicht zulassen, und ehrlich gesagt, dass Android diesen Schalter überhaupt hat.
– Nathan Stretch
14. Juli 16 um 6:51 Uhr