Ablehnung bei Google Play
Das WebViewGold-Template unterstützt viele native Funktionen, und die Berechtigungen für die, die du nicht nutzt, müssen vor der Einreichung raus. Google prüft, ob jede Berechtigung einen sichtbaren Zweck in der App hat. Hier erfährst du, welches Config.java-Flag und welcher AndroidManifest.xml-Eintrag jede einzelne steuert und welche Berechtigungen zusätzlich ein Erklärungsformular brauchen.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Googles Berechtigungsrichtlinie besagt, dass eine App nur Zugriff auf Daten und Fähigkeiten anfordern darf, die sie für Funktionen braucht, die der Nutzer sehen kann und erwartet. Einige Berechtigungen sind zusätzlich eingeschränkt: Standort im Hintergrund, Zugriff auf alle installierten Apps, umfassender Dateizugriff, SMS und Anrufprotokolle sowie umfassender Foto- oder Videozugriff erfordern eine Erklärung in der Play Console, einen deutlich sichtbaren Hinweis in der App vor der Abfrage und in manchen Fällen ein Video, das die Funktion zeigt. Sie ohne eine qualifizierende Funktion anzufordern, führt zu einer Ablehnung oder, bei einer bestehenden App, zu einer Entfernungsankündigung mit Frist.
Eine Web-Wrapper-App braucht typischerweise sehr wenige Berechtigungen: Internet, Benachrichtigungen, wenn du Push nutzt, und Kamera oder Standort nur, wenn deine Web-App diese APIs tatsächlich aufruft. Alles andere sind Template-Fähigkeiten, die du abschalten kannst.
| Berechtigung | Begründet, wenn | WebViewGold-Einstellung |
|---|---|---|
| Standort (Vordergrund) | Deine Web-App ruft die HTML5-Geolocation-API für eine sichtbare Funktion auf (Filialfinder, Check-in, Route) | requireLocation in Config.java; auf false setzen und die Standort-Einträge in AndroidManifest.xml löschen, wenn ungenutzt |
| Standort im Hintergrund | Der Standort wird benötigt, während die App geschlossen ist, und das ist die Kernfunktion (Lieferverfolgung, Fitness-Aufzeichnung); erfordert eine Erklärung und ein Demo-Video | requireBackgroundLocation, plus die Blöcke FOREGROUND_SERVICE_LOCATION und GPSService in AndroidManifest.xml; andernfalls alles auskommentiert lassen |
| Kamera | QR- oder Barcode-Scan, Dokumentenscanner, Foto-Uploads aus der Kamera | requireCamera; setze filePickerMode auf „nur Galerie“, wenn du die Kamera nie brauchst |
| Mikrofon | Sprachnotizen, Audioaufnahmen, Voice-Chat in deiner Web-App | requireRecordAudio; false für fast jede Web-App |
| Speicher / Fotos | Datei-Downloads oder Uploads aus der Galerie | requireStorage; moderne Targets nutzen für Uploads den System-Foto-Picker, der keine umfassende Fotoberechtigung braucht |
| Benachrichtigungen | Push-Benachrichtigungen oder lokaler Push | Mit Push aktiviert; die Laufzeitabfrage erscheint, wenn deine Web-App über registerpush:// danach fragt, oder beim Start |
| Alle Pakete abfragen (Query all packages) | Launcher, Geräteverwaltung, Antivirus. Praktisch nie für eine Web-App | Nicht Teil des Templates; taucht sie im zusammengeführten Manifest auf, hat eine Bibliothek sie hinzugefügt; entferne sie wie unten gezeigt |
| Kontakte | Eine sichtbare Funktion, die Kontakte importiert | Nur vorhanden, wenn du READ_CONTACTS für die Kontakte-API hinzugefügt hast |
Zwanzig Minuten in Android Studio oder ein paar Schalter im Cloud Builder.
Gehe requireLocation, requireBackgroundLocation, requireCamera, requireRecordAudio und requireStorage durch und setze jedes auf false, es sei denn, deine Web-App nutzt die Funktion. Die Docs zu Geolocation und Setup beschreiben jedes Flag.
Die Flags verhindern, dass die App eine Fähigkeit nutzt; die Manifest-Einträge sind das, was Google liest. Entferne die uses-permission-Zeilen für die Fähigkeiten, die du abgeschaltet hast, wie es die Beschreibungen der Einstellungen verlangen.
Öffne in Android Studio die AndroidManifest.xml und wechsle auf den Tab „Merged Manifest“. Er zeigt Berechtigungen, die Bibliotheken beisteuern, und daher kommen Überraschungen wie die Werbe-ID-Berechtigung oder eine unerwartete Package-Visibility-Berechtigung.
Bevor deine Web-App eine sensible Abfrage auslöst (Standort, Kamera), zeige in der App eine kurze Erklärung, warum du sie brauchst und was mit den Daten passiert. Ein Modal in deiner Web-App vor dem API-Aufruf reicht, und es gehört auch in die Datenschutzerklärung.
Play Console → App-Inhalte → Sensible App-Berechtigungen (und ähnliche Formulare) für jede eingeschränkte Berechtigung, die du behältst. Beschreibe die Funktion, nenne den Screen und lade das angeforderte Video hoch. Ohne qualifizierende Funktion stellst du keinen Antrag; entferne stattdessen die Berechtigung.
Baue das Bundle, installiere es aus dem internen Test-Track und gehe die Abläufe durch, die eine Berechtigung abfragen sollen. Prüfe dann vor dem Rollout den App Bundle Explorer in der Play Console, der die Berechtigungen auflistet, die Google aus deinem Bundle extrahiert hat.
Mein iOS WebView wurde endlich genehmigt. Danke!!
Wenn eine Abhängigkeit eine Berechtigung beisteuert, die du nicht begründen kannst, kann der Manifest-Merger sie entfernen. Füge den tools-Namespace zum manifest-Element hinzu, falls er fehlt.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<uses-permission android:name="android.permission.QUERY_ALL_PACKAGES" tools:node="remove" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" tools:node="remove" />
</manifest>Ja, genau diesen Fall deckt diese Richtlinie ab. Eine deklarierte Berechtigung ohne sichtbare Funktion gilt als nicht begründet, egal ob die Abfrage je erscheint.
Ja, wenn die Funktion echt und sichtbar ist und die App die Berechtigung im Kontext anfragt. Beschreibe sie in der Erklärung, falls danach gefragt wird, und erwähne den Standort in der Datenschutzerklärung.
Bibliotheken steuern Manifest-Einträge bei. Das Google Mobile Ads SDK fügt zum Beispiel die Werbe-ID-Berechtigung hinzu. Der Tab „Merged Manifest“ zeigt die Quelle, und tools:node="remove" entfernt, was du nicht begründen kannst.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.