Google Play rejection
Google reserves USE_EXACT_ALARM for alarm clocks, timers and calendars. A habit tracker, a shop or a booking app that sends reminders is not on that list, and on Android 14 even the user-granted SCHEDULE_EXACT_ALARM starts out denied for most new installs. Most reminders do not need to fire to the second. Remove the exact alarm permissions you cannot justify, keep your reminders, and ask for notification permission at the right moment.
From $109 one-time per platform, or let our team do it all from $698.
Android offers two ways to schedule an alarm that fires at an exact moment, even when the phone is idle. USE_EXACT_ALARM is granted at install and cannot be revoked by the user. Google Play therefore restricts it to apps whose core, user-facing function depends on precise timing: alarm clocks, timers, and calendar apps that show event notifications. An app outside those categories that ships with it in the manifest is rejected.
SCHEDULE_EXACT_ALARM is the alternative for everyone else: the user grants it as special app access (Alarms and reminders) and can take it back. Since Android 14 it is denied by default for most newly installed apps, and code that schedules an exact alarm without it fails with a security exception, so an app that relies on it has to check first and fall back. Android's own guidance is that most apps do not need exact alarms at all: periodic work belongs in WorkManager, approximate reminders can use inexact or windowed alarms, and anything triggered by server events is better sent as push. Details are on the Android exact alarm page.
The Policy status entry refers to the exact alarm permission and states that the app's core functionality does not qualify for USE_EXACT_ALARM. It asks you to remove the permission from the bundles in your submission, or to use the user-granted SCHEDULE_EXACT_ALARM if precise timing really is a user-facing need. For a live app the same issue can arrive as a warning with a deadline. Most web-wrapped apps did not add the permission on purpose; a notification or scheduling library brought it in.
| Use case | Precision the user expects | Best tool |
|---|---|---|
| Alarm clock, countdown timer | To the second | Exact alarms; this is what USE_EXACT_ALARM exists for, and usually a native app rather than a web app |
| Calendar app with event notifications | To the minute | Can qualify for exact alarms when the calendar is the core of the app |
| Habit, streak or study reminder | Roughly at the chosen time | Local push with sendlocalpushmsg://, or scheduled push from your server |
| Abandoned cart, happy hour, come-back nudge | Within minutes or hours | Local push, or a scheduled message from OneSignal, Firebase or Pushwoosh |
| Appointment or booking reminder | A few minutes either way are fine | Server push, sent by your backend at the right time |
| Order, chat or status update | When the event happens | Server push; no scheduling on the device at all |
My iOS WebView is finally approved. Thanks!!
Schedule a notification a number of seconds ahead with sendlocalpushmsg://push.send?s=… while the app is open, and cancel all pending ones with sendlocalpushmsg://push.send.cancel. It needs no push provider and suits simple nudges and reminders.
OneSignal (PUSH_ENABLED), Firebase (FIREBASE_PUSH_ENABLED) or Pushwoosh (PUSHWOOSH_ENABLED) deliver what your server sends, when it sends it, with no alarm permission in the app. Compare them in the push provider comparison.
Android 13 and later need the POST_NOTIFICATIONS runtime permission. WebViewGold asks on first launch by default (requirePush true). Set it to false and call registerpush:// once the user turns on reminders; this needs at least one push service enabled.
checkNativePushPermissions:// injects nativePushEnabled into the page. It is true only when both the system notification setting and the runtime permission are granted.
If the user declined for good, offer a button that opens the system App info screen with settingsapp://, where notifications can be turned back on.
Usually a manifest change, a small web app change and one rebuild.
Check the permission list in the App bundle explorer, then the Merged Manifest tab in Android Studio, which names the library or manifest that adds USE_EXACT_ALARM or SCHEDULE_EXACT_ALARM.
Delete it from your manifest or strip it with the rule below. For a web-wrapped app this is almost always the answer.
If it comes from a library you do not use, remove it as well. If the Merged Manifest shows it comes from the WebViewGold project itself, ask WebViewGold support whether your template version's local notifications rely on it before you remove it, because an exact alarm call without the permission fails.
Anything that has to arrive at a specific moment and depends on your data (a booking reminder, an order update) is more reliable as push sent by your backend. Keep local push for simple nudges. The Android push documentation covers all three providers.
Set requirePush to false and trigger registerpush:// from the screen where users switch reminders on, as in the code below. A reviewer who declines must still be able to use the app.
Fresh install from internal testing: turn on reminders, schedule a local push a few minutes ahead, lock the phone and wait. Under Settings → Apps → Special app access → Alarms and reminders, confirm the app no longer asks for exact alarms. Then upload with a higher version code and replace the bundles on all tracks.
Strip what a dependency adds. Keep the second line only after you confirmed nothing in your build needs exact alarms.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Not an alarm, timer or calendar app: no USE_EXACT_ALARM -->
<uses-permission android:name="android.permission.USE_EXACT_ALARM" tools:node="remove" />
<!-- Only after checking that nothing relies on exact alarms -->
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" tools:node="remove" />
</manifest>Web app code for a reminders screen. showModal and showSettingsHint stand for your own UI; the URL schemes are the documented WebViewGold ones.
// 1. The user switches reminders on: explain first, then ask Android
function enableReminders() {
showModal({
title: "Turn on daily reminders?",
body: "We send one reminder a day at the time you choose. You can switch it off here at any time.",
primary: { label: "Turn on", onClick: () => { window.location.href = "registerpush://"; } },
secondary: { label: "Not now", onClick: () => {} }
});
}
// 2. Later: check whether notifications are allowed
function checkReminderStatus() {
window.location.href = "checkNativePushPermissions://";
setTimeout(() => {
if (typeof nativePushEnabled !== "undefined" && nativePushEnabled) {
scheduleNudge();
} else {
showSettingsHint(); // e.g. a button with href="settingsapp://"
}
}, 500);
}
// 3. A simple local reminder, two hours from now
function scheduleNudge() {
var title = "Your streak is waiting";
var message = "Two minutes today keep your streak alive.";
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 is false and the permission prompt appears after the user switches reminders on.settingsapp:// to fix it later.Yes. Without exact alarms, Android may batch a reminder with other work and deliver it a little later than scheduled while the phone is idle. For streaks, nudges and most booking reminders that does not matter; use server push when the timing depends on your data.
No. It is a normal runtime permission on Android 13 and later. It still has to be requested at runtime, and the app must keep working if the user, or the reviewer, declines.
You can, and it is the WebViewGold default, but the prompt converts better and looks better to reviewers after the user has a reason to say yes. Set requirePush to false and use registerpush:// on your reminders or onboarding screen.
Probably not. Google ties it to apps whose core function is an alarm, a timer or a calendar with event notifications. A booking service with a schedule screen is better served by reminders pushed from your backend.
Usually a notification, scheduling or SDK dependency declares it in its own manifest, and it is merged into yours at build time. The Merged Manifest tab names the source, and tools:node="remove" strips it.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main page$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demo$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.