Ablehnung bei Google Play
Google reserviert USE_EXACT_ALARM für Wecker, Timer und Kalender. Ein Habit-Tracker, ein Shop oder eine Buchungs-App, die Erinnerungen sendet, steht nicht auf dieser Liste, und unter Android 14 ist selbst das vom Nutzer erteilte SCHEDULE_EXACT_ALARM bei den meisten Neuinstallationen zunächst verweigert. Die meisten Erinnerungen müssen nicht auf die Sekunde genau kommen. Entferne die Berechtigungen für exakte Alarme, die du nicht begründen kannst, behalte deine Erinnerungen und frag im richtigen Moment nach der Benachrichtigungsberechtigung.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Android bietet zwei Wege, einen Alarm zu planen, der zu einem exakten Zeitpunkt auslöst, auch wenn das Smartphone im Ruhezustand ist. USE_EXACT_ALARM wird bei der Installation erteilt und kann vom Nutzer nicht widerrufen werden. Google Play beschränkt sie deshalb auf Apps, deren zentrale, für den Nutzer sichtbare Funktion von präzisem Timing abhängt: Wecker, Timer und Kalender-Apps, die Terminbenachrichtigungen anzeigen. Eine App außerhalb dieser Kategorien, die sie im Manifest mitliefert, wird abgelehnt.
SCHEDULE_EXACT_ALARM ist die Alternative für alle anderen: Der Nutzer erteilt sie als speziellen App-Zugriff (Wecker und Erinnerungen) und kann sie wieder entziehen. Seit Android 14 ist sie bei den meisten neu installierten Apps standardmäßig verweigert, und Code, der ohne sie einen exakten Alarm plant, scheitert mit einer Security Exception; eine App, die darauf angewiesen ist, muss also vorher prüfen und eine Alternative haben. Androids eigene Empfehlung lautet, dass die meisten Apps überhaupt keine exakten Alarme brauchen: Wiederkehrende Arbeit gehört in WorkManager, ungefähre Erinnerungen können ungenaue Alarme oder Alarme mit Zeitfenster nutzen, und alles, was durch Server-Ereignisse ausgelöst wird, kommt besser als Push. Details stehen auf der Android-Seite zu exakten Alarmen.
Der Eintrag im Richtlinienstatus bezieht sich auf die Berechtigung für exakte Alarme und stellt fest, dass die Kernfunktion der App die Voraussetzungen für USE_EXACT_ALARM nicht erfüllt. Er fordert dich auf, die Berechtigung aus den Bundles deiner Einreichung zu entfernen oder das vom Nutzer erteilte SCHEDULE_EXACT_ALARM zu verwenden, falls präzises Timing für den Nutzer wirklich nötig ist. Bei einer Live-App kann dasselbe Problem als Warnung mit Frist kommen. Die meisten Web-Wrapper-Apps haben die Berechtigung nicht absichtlich hinzugefügt; eine Benachrichtigungs- oder Planungsbibliothek hat sie mitgebracht.
| Anwendungsfall | Erwartete Genauigkeit | Bestes Werkzeug |
|---|---|---|
| Wecker, Countdown-Timer | Auf die Sekunde | Exakte Alarme; genau dafür gibt es USE_EXACT_ALARM, meist eher eine native App als eine Web-App |
| Kalender-App mit Terminbenachrichtigungen | Auf die Minute | Kann für exakte Alarme infrage kommen, wenn der Kalender der Kern der App ist |
| Erinnerung für Gewohnheit, Streak oder Lernen | Ungefähr zur gewählten Zeit | Lokaler Push mit sendlocalpushmsg:// oder geplanter Push von deinem Server |
| Verlassener Warenkorb, Happy Hour, Comeback-Anstupser | Innerhalb von Minuten oder Stunden | Lokaler Push oder eine geplante Nachricht über OneSignal, Firebase oder Pushwoosh |
| Termin- oder Buchungserinnerung | Ein paar Minuten früher oder später sind in Ordnung | Server-Push, von deinem Backend zur richtigen Zeit gesendet |
| Bestell-, Chat- oder Status-Update | Wenn das Ereignis eintritt | Server-Push; überhaupt keine Planung auf dem Gerät |
Mein iOS WebView wurde endlich genehmigt. Danke!!
Plane mit sendlocalpushmsg://push.send?s=… eine Benachrichtigung eine bestimmte Anzahl Sekunden im Voraus, während die App geöffnet ist, und brich mit sendlocalpushmsg://push.send.cancel alle ausstehenden ab. Das braucht keinen Push-Anbieter und eignet sich für einfache Anstupser und Erinnerungen.
OneSignal (PUSH_ENABLED), Firebase (FIREBASE_PUSH_ENABLED) oder Pushwoosh (PUSHWOOSH_ENABLED) stellen zu, was dein Server sendet, und zwar dann, wenn er es sendet, ganz ohne Alarm-Berechtigung in der App. Vergleiche sie im Vergleich der Push-Anbieter.
Android 13 und neuer brauchen die Laufzeitberechtigung POST_NOTIFICATIONS. WebViewGold fragt standardmäßig beim ersten Start (requirePush true). Setze es auf false und ruf registerpush:// auf, sobald der Nutzer Erinnerungen einschaltet; dafür muss mindestens ein Push-Dienst aktiviert sein.
checkNativePushPermissions:// schreibt nativePushEnabled in die Seite. Der Wert ist nur dann true, wenn sowohl die Benachrichtigungseinstellung des Systems als auch die Laufzeitberechtigung erteilt sind.
Hat der Nutzer dauerhaft abgelehnt, biete einen Button an, der mit settingsapp:// den System-Screen App-Info öffnet, wo sich Benachrichtigungen wieder einschalten lassen.
Meist eine Manifest-Änderung, eine kleine Änderung in der Web-App und ein Rebuild.
Prüf die Berechtigungsliste im App Bundle Explorer und dann den Tab „Merged Manifest“ in Android Studio, der die Bibliothek oder das Manifest nennt, das USE_EXACT_ALARM oder SCHEDULE_EXACT_ALARM hinzufügt.
Lösche sie aus deinem Manifest oder entferne sie mit der Regel unten. Für eine Web-Wrapper-App ist das fast immer die Antwort.
Kommt sie aus einer Bibliothek, die du nicht nutzt, entferne sie ebenfalls. Zeigt das Merged Manifest, dass sie aus dem WebViewGold-Projekt selbst stammt, frag den WebViewGold-Support, ob die lokalen Benachrichtigungen deiner Template-Version darauf angewiesen sind, bevor du sie entfernst, denn ein exakter Alarm-Aufruf ohne die Berechtigung schlägt fehl.
Alles, was zu einem bestimmten Zeitpunkt ankommen muss und von deinen Daten abhängt (eine Buchungserinnerung, ein Bestell-Update), ist als Push von deinem Backend zuverlässiger. Behalte lokalen Push für einfache Anstupser. Die Android-Push-Dokumentation behandelt alle drei Anbieter.
Setze requirePush auf false und löse registerpush:// auf dem Screen aus, auf dem Nutzer Erinnerungen einschalten, wie im Code unten. Ein Reviewer, der ablehnt, muss die App trotzdem nutzen können.
Frische Installation aus dem internen Test: Erinnerungen einschalten, einen lokalen Push ein paar Minuten im Voraus planen, das Smartphone sperren und warten. Prüf unter Einstellungen → Apps → Spezieller App-Zugriff → Wecker und Erinnerungen, dass die App nicht mehr nach exakten Alarmen fragt. Lade dann mit höherem Version Code hoch und ersetze die Bundles auf allen Tracks.
Entferne, was eine Abhängigkeit hinzufügt. Behalte die zweite Zeile erst, wenn du bestätigt hast, dass nichts in deinem Build exakte Alarme braucht.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Kein Wecker, Timer oder Kalender: kein USE_EXACT_ALARM -->
<uses-permission android:name="android.permission.USE_EXACT_ALARM" tools:node="remove" />
<!-- Erst nach der Prüfung, dass nichts auf exakte Alarme angewiesen ist -->
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" tools:node="remove" />
</manifest>Web-App-Code für einen Erinnerungs-Screen. showModal und showSettingsHint stehen für deine eigene UI; die URL-Schemes sind die dokumentierten von WebViewGold.
// 1. Der Nutzer schaltet Erinnerungen ein: erst erklären, dann Android fragen
function enableReminders() {
showModal({
title: "Tägliche Erinnerungen einschalten?",
body: "Wir senden dir einmal am Tag eine Erinnerung zur Uhrzeit deiner Wahl. Du kannst das hier jederzeit abschalten.",
primary: { label: "Einschalten", onClick: () => { window.location.href = "registerpush://"; } },
secondary: { label: "Nicht jetzt", onClick: () => {} }
});
}
// 2. Später: prüfen, ob Benachrichtigungen erlaubt sind
function checkReminderStatus() {
window.location.href = "checkNativePushPermissions://";
setTimeout(() => {
if (typeof nativePushEnabled !== "undefined" && nativePushEnabled) {
scheduleNudge();
} else {
showSettingsHint(); // z. B. ein Button mit href="settingsapp://"
}
}, 500);
}
// 3. Eine einfache lokale Erinnerung in zwei Stunden
function scheduleNudge() {
var title = "Deine Serie wartet";
var message = "Zwei Minuten heute halten deine Serie am Leben.";
var seconds = 2 * 60 * 60;
var url = "https://app.example.com/today";
window.location.href = "sendlocalpushmsg://push.send?s=" + seconds + "=msg!" + message + "&!#" + title + "&!#" + url;
}requirePush ist false, und die Berechtigungsabfrage erscheint, nachdem der Nutzer Erinnerungen eingeschaltet hat.settingsapp://, um das später zu ändern.Ja. Ohne exakte Alarme kann Android eine Erinnerung mit anderer Arbeit bündeln und sie im Ruhezustand des Smartphones etwas später als geplant zustellen. Für Streaks, Anstupser und die meisten Buchungserinnerungen spielt das keine Rolle; nutze Server-Push, wenn das Timing von deinen Daten abhängt.
Nein. Sie ist unter Android 13 und neuer eine normale Laufzeitberechtigung. Sie muss trotzdem zur Laufzeit angefragt werden, und die App muss weiter funktionieren, wenn der Nutzer oder der Reviewer ablehnt.
Kannst du, und das ist der WebViewGold-Standard, aber die Abfrage konvertiert besser und wirkt auf Reviewer besser, wenn der Nutzer einen Grund hat, Ja zu sagen. Setze requirePush auf false und nutze registerpush:// auf deinem Erinnerungs- oder Onboarding-Screen.
Wahrscheinlich nicht. Google bindet sie an Apps, deren Kernfunktion ein Wecker, ein Timer oder ein Kalender mit Terminbenachrichtigungen ist. Ein Buchungsdienst mit Terminübersicht ist mit Erinnerungen per Push von deinem Backend besser bedient.
Meist deklariert eine Benachrichtigungs-, Planungs- oder SDK-Abhängigkeit sie in ihrem eigenen Manifest, und beim Build wird sie in deins zusammengeführt. Der Tab „Merged Manifest“ nennt die Quelle, und tools:node="remove" entfernt sie.
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.