Refus Google Play
Google réserve USE_EXACT_ALARM aux réveils, minuteurs et agendas. Un suivi d'habitudes, une boutique ou une app de réservation qui envoie des rappels ne figure pas sur cette liste, et sous Android 14, même SCHEDULE_EXACT_ALARM, accordée par l'utilisateur, est refusée par défaut pour la plupart des nouvelles installations. La plupart des rappels n'ont pas besoin de se déclencher à la seconde près. Retirez les autorisations d'alarme exacte que vous ne pouvez pas justifier, gardez vos rappels et demandez l'autorisation de notifications au bon moment.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Android propose deux façons de programmer une alarme qui se déclenche à un moment précis, même quand le téléphone est en veille. USE_EXACT_ALARM est accordée à l'installation et l'utilisateur ne peut pas la révoquer. Google Play la réserve donc aux apps dont la fonction principale, visible par l'utilisateur, dépend d'une heure précise : réveils, minuteurs et agendas qui affichent des notifications d'événements. Une app hors de ces catégories qui l'embarque dans son manifeste est refusée.
SCHEDULE_EXACT_ALARM est l'alternative pour tous les autres : l'utilisateur l'accorde en tant qu'accès spécial des applications (Alarmes et rappels) et peut la retirer. Depuis Android 14, elle est refusée par défaut pour la plupart des apps nouvellement installées, et un code qui programme une alarme exacte sans elle échoue avec une exception de sécurité ; une app qui en dépend doit donc d'abord vérifier et prévoir une solution de repli. Les consignes d'Android elles-mêmes disent que la plupart des apps n'ont pas du tout besoin d'alarmes exactes : le travail périodique relève de WorkManager, les rappels approximatifs peuvent utiliser des alarmes inexactes ou à fenêtre, et tout ce qui est déclenché par des événements côté serveur gagne à être envoyé en push. Les détails figurent sur la page Android sur les alarmes exactes.
L'entrée dans État des règles fait référence à l'autorisation d'alarme exacte et indique que la fonctionnalité principale de l'app n'est pas admissible pour USE_EXACT_ALARM. Elle vous demande de retirer l'autorisation des bundles de votre soumission, ou d'utiliser SCHEDULE_EXACT_ALARM, accordée par l'utilisateur, si une heure précise est vraiment un besoin visible pour l'utilisateur. Pour une app en ligne, le même problème peut arriver sous forme d'avertissement avec une échéance. La plupart des apps web encapsulées n'ont pas ajouté l'autorisation volontairement ; c'est une bibliothèque de notifications ou de planification qui l'a apportée.
| Cas d'usage | Précision attendue par l'utilisateur | Meilleur outil |
|---|---|---|
| Réveil, compte à rebours | À la seconde | Alarmes exactes ; c'est la raison d'être de USE_EXACT_ALARM, et en général une app native plutôt qu'une app web |
| Agenda avec notifications d'événements | À la minute | Peut être admissible aux alarmes exactes quand l'agenda est le cœur de l'app |
| Rappel d'habitude, de série ou de révision | À peu près à l'heure choisie | Push local avec sendlocalpushmsg://, ou push programmé depuis votre serveur |
| Panier abandonné, happy hour, relance de retour | À quelques minutes ou heures près | Push local, ou message programmé depuis OneSignal, Firebase ou Pushwoosh |
| Rappel de rendez-vous ou de réservation | Quelques minutes d'écart ne posent pas de problème | Push serveur, envoyé par votre backend au bon moment |
| Mise à jour de commande, de chat ou de statut | Au moment où l'événement se produit | Push serveur ; aucune planification sur l'appareil |
Mon WebView iOS est enfin approuvé. Merci !!
Programmez une notification quelques secondes à l'avance avec sendlocalpushmsg://push.send?s=… pendant que l'app est ouverte, et annulez toutes celles en attente avec sendlocalpushmsg://push.send.cancel. Aucun fournisseur push n'est nécessaire, et cela convient aux relances et rappels simples.
OneSignal (PUSH_ENABLED), Firebase (FIREBASE_PUSH_ENABLED) ou Pushwoosh (PUSHWOOSH_ENABLED) délivrent ce que votre serveur envoie, au moment où il l'envoie, sans aucune autorisation d'alarme dans l'app. Comparez-les dans le comparatif des fournisseurs push.
Android 13 et plus récent exigent l'autorisation d'exécution POST_NOTIFICATIONS. Par défaut, WebViewGold la demande au premier lancement (requirePush sur true). Mettez-la sur false et appelez registerpush:// quand l'utilisateur active les rappels ; il faut pour cela au moins un service push activé.
checkNativePushPermissions:// injecte nativePushEnabled dans la page. La valeur n'est true que si le réglage de notifications du système et l'autorisation d'exécution sont tous deux accordés.
Si l'utilisateur a refusé définitivement, proposez un bouton qui ouvre l'écran Infos sur l'appli du système avec settingsapp://, où les notifications peuvent être réactivées.
En général une modification du manifeste, un petit changement dans l'app web et une recompilation.
Vérifiez la liste des autorisations dans l'explorateur d'app bundles, puis l'onglet Merged Manifest d'Android Studio, qui nomme la bibliothèque ou le manifeste qui ajoute USE_EXACT_ALARM ou SCHEDULE_EXACT_ALARM.
Supprimez-la de votre manifeste ou retirez-la avec la règle ci-dessous. Pour une app web encapsulée, c'est presque toujours la bonne réponse.
Si elle vient d'une bibliothèque que vous n'utilisez pas, retirez-la aussi. Si le Merged Manifest montre qu'elle vient du projet WebViewGold lui-même, demandez au support WebViewGold si les notifications locales de votre version du modèle en dépendent avant de la retirer, car un appel d'alarme exacte sans l'autorisation échoue.
Tout ce qui doit arriver à un moment précis et dépend de vos données (un rappel de réservation, une mise à jour de commande) est plus fiable en push envoyé par votre backend. Gardez le push local pour les relances simples. La documentation push pour Android couvre les trois fournisseurs.
Mettez requirePush sur false et déclenchez registerpush:// depuis l'écran où les utilisateurs activent les rappels, comme dans le code ci-dessous. Un examinateur qui refuse doit pouvoir continuer à utiliser l'app.
Installation neuve depuis les tests internes : activez les rappels, programmez un push local quelques minutes plus tard, verrouillez le téléphone et attendez. Sous Paramètres → Applications → Accès spéciaux des applications → Alarmes et rappels, vérifiez que l'app ne demande plus d'alarmes exactes. Importez ensuite avec un code de version plus élevé et remplacez les bundles sur tous les canaux.
Retirez ce qu'une dépendance ajoute. Ne gardez la deuxième ligne qu'après avoir vérifié que rien dans votre build n'a besoin d'alarmes exactes.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Ni réveil, ni minuteur, ni agenda : pas de USE_EXACT_ALARM -->
<uses-permission android:name="android.permission.USE_EXACT_ALARM" tools:node="remove" />
<!-- Uniquement après avoir vérifié que rien ne dépend des alarmes exactes -->
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" tools:node="remove" />
</manifest>Code d'app web pour un écran de rappels. showModal et showSettingsHint représentent votre propre interface ; les schémas d'URL sont ceux documentés par WebViewGold.
// 1. L'utilisateur active les rappels : expliquer d'abord, puis demander à Android
function enableReminders() {
showModal({
title: "Activer les rappels quotidiens ?",
body: "Nous envoyons un rappel par jour à l'heure de votre choix. Vous pouvez le désactiver ici à tout moment.",
primary: { label: "Activer", onClick: () => { window.location.href = "registerpush://"; } },
secondary: { label: "Plus tard", onClick: () => {} }
});
}
// 2. Plus tard : vérifier si les notifications sont autorisées
function checkReminderStatus() {
window.location.href = "checkNativePushPermissions://";
setTimeout(() => {
if (typeof nativePushEnabled !== "undefined" && nativePushEnabled) {
scheduleNudge();
} else {
showSettingsHint(); // par ex. un bouton avec href="settingsapp://"
}
}, 500);
}
// 3. Un rappel local simple, dans deux heures
function scheduleNudge() {
var title = "Votre série vous attend";
var message = "Deux minutes aujourd'hui suffisent à garder votre série.";
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 vaut false et la demande d'autorisation apparaît une fois que l'utilisateur a activé les rappels.settingsapp:// pour corriger cela plus tard.Oui. Sans alarmes exactes, Android peut regrouper un rappel avec d'autres tâches et le délivrer un peu plus tard que prévu pendant que le téléphone est en veille. Pour les séries, les relances et la plupart des rappels de réservation, cela n'a pas d'importance ; utilisez le push serveur quand le moment dépend de vos données.
Non. C'est une autorisation d'exécution normale sous Android 13 et plus récent. Elle doit quand même être demandée à l'exécution, et l'app doit continuer de fonctionner si l'utilisateur, ou l'examinateur, refuse.
Vous pouvez, et c'est le réglage par défaut de WebViewGold, mais la demande convertit mieux et fait meilleure impression aux examinateurs quand l'utilisateur a une raison de dire oui. Mettez requirePush sur false et utilisez registerpush:// sur votre écran de rappels ou d'onboarding.
Probablement pas. Google la réserve aux apps dont la fonction principale est un réveil, un minuteur ou un agenda avec notifications d'événements. Un service de réservation avec un écran de planning est mieux servi par des rappels envoyés en push depuis votre backend.
En général, une dépendance de notifications, de planification ou un SDK la déclare dans son propre manifeste, qui est fusionné avec le vôtre au moment du build. L'onglet Merged Manifest en indique la source, et tools:node="remove" la retire.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.