LaunchLint Academy
Die kurze Antwort
- Das Data-Safety-Formular beschreibt, welche Nutzerdaten deine veröffentlichte App erhebt oder weitergibt, wofür sie genutzt werden und welche Sicherheits- und Löschpraktiken gelten. Auch Apps ohne Datenerhebung müssen das Formular ausfüllen und eine Datenschutzerklärung verlinken.
- package.json, app.json und Android-Permissions liefern wichtige Signale, aber keine fertige Erklärung. Drittanbieter-SDKs, serverseitige Verarbeitung, optionale Einwilligung und tatsächliche Laufzeitübertragungen müssen zusätzlich geprüft werden.
- Erstelle pro SDK und eigenem Endpoint einen Datensteckbrief, entscheide gesammelt versus geteilt anhand der Google-Definitionen und gleiche das Ergebnis bei jeder Änderung von SDK, Zweck, Backend oder Account-Löschung erneut mit Play Console ab.
1. Welche App-Version und welche Daten Data Safety abdeckt
Google verlangt das Formular für veröffentlichte Apps in Closed-, Open- und Production-Tracks; reine Internal-Testing-Apps sind ausgenommen. Die Erklärung gilt auf Ebene des App-Pakets und soll die aktuell verteilten Artefakte abbilden. Deshalb reicht es nicht, nur den neuesten Branch anzusehen, wenn ältere aktive Versionen noch ein anderes SDK oder einen anderen Datenfluss enthalten.
Als Erhebung gilt grundsätzlich, wenn Daten vom Gerät an den Entwickler oder einen Dritten übertragen werden. Rein lokale Verarbeitung kann außerhalb der Definition liegen, solange nichts das Gerät verlässt. Ein Permission-Eintrag beweist daher keine Erhebung, und fehlende sensible Permissions beweisen umgekehrt nicht, dass keine Telemetrie, IP-Adresse oder App-Interaktion übertragen wird.
3. Expo-SDKs und native Abhängigkeiten vollständig inventarisieren
Expo abstrahiert native Projekte, entfernt aber nicht die Verantwortung für eingebettete Bibliotheken. Analytics, Crash Reporting, Push, Auth, Maps, Ads, Payments und Social Login können eigene Datenpraktiken haben. Prüfe direkte Dependencies und transitive native Komponenten, Produktionskonfiguration, optionale Module und ob ein SDK vor Einwilligung initialisiert wird.
Google macht Entwickler ausdrücklich für Drittanbieter-Code verantwortlich und empfiehlt, Daten, Permissions und Zwecke jedes SDKs zu kennen. Anbieter-Dokumentation und Google Play SDK Index sind gute Ausgangspunkte, aber deine Konfiguration entscheidet. Ein SDK kann mehrere Betriebsarten haben oder Daten nur in bestimmten Modulen senden.
{
"sdk": "example-analytics",
"enabledInProduction": true,
"dataTypes": ["Device identifiers", "App interactions"],
"transmittedOffDevice": true,
"purpose": ["Analytics"],
"requiredOrOptional": "optional after consent",
"encryptedInTransit": true,
"deletionPath": "privacy@example.com"
}Nachweise in den Projektdateien suchen:
- package.json und Lockfile für direkte und transitive SDKs
- app.json oder app.config für Plugins und Produktionswerte
- AndroidManifest- und Permission-Signale
- Initialisierung, Consent-Gates und Feature Toggles
- API-Endpunkte, Uploads und eigene Telemetrie
- Lösch- und Opt-out-Flows
- Release-spezifische Environment-Konfiguration
4. Zweck, Optionalität, Verschlüsselung und Löschung korrekt beantworten
Für jeden Datentyp fragt Data Safety nach Zwecken. Wähle nicht vorsorglich alle möglichen Zwecke eines SDK-Anbieters, sondern nur die in deiner App tatsächlich verwendeten. Ebenso ist ‚optional‘ nur belastbar, wenn Nutzer die Erhebung sinnvoll vermeiden oder abwählen können. Ein versteckter Toggle nach bereits erfolgter Initialisierung ändert den vorherigen Transfer nicht.
Verschlüsselung bei der Übertragung darf nur angegeben werden, wenn sie für alle relevanten übertragenen Nutzerdaten gilt. Prüfe daher auch alte HTTP-Endpunkte, Medien-Uploads, WebViews und SDKs. Bei Löschung unterscheide Account, serverseitige Profildaten, Backups, gesetzliche Aufbewahrung und Daten bei Drittanbietern. Die Store-Antwort muss dem echten Prozess entsprechen.
- Zweck pro Datentyp und Empfänger festhalten
- Required oder optional am tatsächlichen Consent-Flow prüfen
- TLS für alle eigenen und dritten Übertragungen bestätigen
- Aufbewahrungsfristen in Datenschutzerklärung nennen
- In-App- und Webweg zur Account-Löschung testen
- Abos und rechtlich aufbewahrte Daten verständlich erklären
5. Account-Löschung ist Teil der Data-Safety-Nachweis
Wenn Nutzer in der App Accounts erstellen können, verlangt Google sowohl einen In-App-Weg zur Löschanfrage als auch eine Web-Ressource, über die Account und zugehörige Daten gelöscht werden können. Der Weblink wird in Play Console hinterlegt und kann öffentlich in der Data-Safety-Sektion erscheinen. Er darf nicht nur auf eine allgemeine Startseite führen.
Teste den Prozess ohne eingeloggte Entwicklersession: Identifikation des Accounts, Bestätigung, Bearbeitungszeit, Statusmeldung und Umgang mit unvollständigen Anfragen. Wenn bestimmte Daten aus legitimen Gründen aufbewahrt werden, benenne Art und Dauer. ‚Account deaktivieren‘ oder ‚App deinstallieren‘ ist nicht dasselbe wie eine Löschanfrage.
6. Die Erklärung gegen Build und Laufzeit validieren
Statische Analyse priorisiert Fragen, kann aber keine vollständige Laufzeitbeobachtung ersetzen. Baue das vorgesehene Produktionsartefakt, installiere es auf einem frischen Gerät und führe Erststart, Consent, Login, Kernfunktion, Upload, Kauf, Push und Löschung aus. Protokolliere, welche Dienste wann initialisiert werden und welche Netzwerkziele auftreten.
Vergleiche anschließend Datentyp für Datentyp: Hinweis in den Projektdateien, beobachtete Übertragung, Backend-Verarbeitung, SDK-Dokumentation, Datenschutzerklärung und Play-Console-Antwort. Unklare Fälle werden nicht durch Raten gelöst; frage den SDK-Anbieter oder die verantwortliche Backend-Person und dokumentiere die Entscheidung.
Release-Gate:
- Produktions-SDK-Liste eingefroren
- Consent vor optionaler SDK-Initialisierung getestet
- Datentypen und Zwecke abgeglichen
- Sharing-Ausnahmen dokumentiert
- Verschlüsselung und Löschung geprüft
- Datenschutzerklärung aktualisiert
- Data Safety als Draft gegengelesen
- Verantwortliche Person und Prüfdatum notiert
7. Data Safety bei jedem relevanten Release pflegen
Data Safety ist kein einmaliges Launch-Dokument. Neue Analytics, ein anderer Auth-Anbieter, ein Werbe-SDK, zusätzliche Uploads oder ein geänderter Backend-Zweck können Antworten verändern. Nimm die Prüfung deshalb in Definition of Done und Release-Checkliste auf, bevor das neue Artefakt breit ausgerollt wird.
LaunchLint kann SDKs, Plugins, Permissions, Endpoints und Löschsignale mit Nachweise in den Dateien finden, führt aber keinen Nutzer-Code aus und beobachtet keine echten Übertragungen. Der vollständige Prüfung der Projektdateien erzeugt daraus gezielte Fragen und Fix-Aufgaben; die abschließende Erklärung bleibt eine gemeinsame Prüfung von Projektdateien, Laufzeitverhalten, Backend und Store-Konsole.
Häufige Fragen
Muss eine Expo-App ohne eigene Datenerhebung Data Safety ausfüllen?
Ja, wenn sie auf relevanten Google-Play-Tracks veröffentlicht wird. Auch Apps ohne Erhebung oder Sharing müssen das Formular ausfüllen und eine Datenschutzerklärung verlinken. Prüfe zusätzlich, ob eingebundene SDKs dennoch Daten übertragen.
Kann package.json das Data-Safety-Formular automatisch erzeugen?
Nein. Dependencies liefern Risikosignale, kennen aber weder alle Laufzeitoptionen noch eigene Backends, Zwecke, Einwilligung, Aufbewahrung oder Löschung. Nutze das Projektdateien für ein Inventar, nicht als alleinige Wahrheit.
Ist ein Datentransfer an einen Dienstleister immer Sharing?
Nicht zwingend. Google beschreibt Ausnahmen, unter anderem für bestimmte Service-Provider-Beziehungen. Ob sie greifen, hängt von Vertrag, Zweck und tatsächlicher Weiterverwendung ab und sollte dokumentiert werden.
Wann muss ich Data Safety aktualisieren?
Immer wenn sich Datentypen, Zwecke, Empfänger, SDKs, Consent, Sicherheits- oder Löschpraktiken ändern. Prüfe das Formular als Teil jedes Releases mit relevanten Änderungen.