Les alarmes exactes programmées sont refusées par défaut

Les alarmes exactes sont destinées aux notifications ou aux actions intentionnelles de l'utilisateur qui doivent se produire à une heure précise.

SCHEDULE_EXACT_ALARM, l'autorisation introduite dans Android 12 pour les applications afin de programmer des alarmes exactes, n'est plus accordée à la plupart des applications nouvellement installées ciblant Android 13 ou version ultérieure (l'autorisation sera refusée par défaut). Si l'utilisateur transfère des données d'application vers un appareil exécutant Android 14 via une opération de sauvegarde et de restauration, l'autorisation sera toujours refusée. Si un application existante dispose déjà de cette autorisation, elle sera pré-accordée lorsque l'appareil les mises à niveau vers Android 14.

L'autorisation SCHEDULE_EXACT_ALARM est requise pour déclencher des alarmes exactes via les API suivantes, sinon une exception SecurityException sera générée :

Les bonnes pratiques existantes concernant l'autorisation SCHEDULE_EXACT_ALARM s'appliquent toujours, y compris les suivantes :

Applications concernées

Si un appareil est équipé d'Android 14 ou version ultérieure, cette modification affectera une application nouvellement installée présentant les caractéristiques suivantes :

  • Cible Android 13 (niveau d'API 33) ou version ultérieure.
  • Déclare l'autorisation SCHEDULE_EXACT_ALARM dans le fichier manifeste.
  • N'entre pas dans le cadre d'une exception ou d'un accord préalable.
  • N'est pas une application d'agenda ou de réveil.

Les applications d'agenda et de réveil doivent déclarer USE_EXACT_ALARM.

Les applications d'agenda ou de réveil doivent envoyer des rappels dans l'agenda, des alarmes de réveil ou des alertes lorsque l'application n'est plus en cours d'exécution. Ces applications peuvent demander l'autorisation normale USE_EXACT_ALARM. L'autorisation USE_EXACT_ALARM sera accordée lors de l'installation. Les applications disposant de cette autorisation pourront programmer des alarmes exactes, tout comme les applications disposant de l'autorisation SCHEDULE_EXACT_ALARM.

Cas d'utilisation ne nécessitant pas forcément d'alarme exacte

Étant donné que l'autorisation SCHEDULE_EXACT_ALARM est désormais refusée par défaut et que le processus d'octroi d'autorisations nécessite des étapes supplémentaires de la part des utilisateurs, les développeurs sont vivement encouragés à évaluer leurs cas d'utilisation et à déterminer si des alarmes exactes sont toujours pertinentes.

La liste suivante répertorie les workflows courants ne nécessitant pas obligatoirement une alarme exacte :

Planifier des tâches récurrentes pendant la durée de vie de votre application
La méthode set() est utile si la tâche doit tenir compte des contraintes en temps réel, par exemple pour partir à 14h demain ou dans 30 minutes. Sinon, nous vous recommandons d'utiliser plutôt les méthodes postAtTime() ou postDelayed().
Travail d'arrière-plan planifié, comme la mise à jour de votre application et l'importation de journaux
WorkManager permet de planifier des tâches périodiques sensibles au facteur temps. Vous pouvez fournir un intervalle de répétition et un intervalle flexible (15 minutes minimum) pour définir un environnement d'exécution précis pour le travail.
Alarme requise pour se déclencher à une heure approximative lorsque le système est inactif
Utilisez une alarme inexacte. Plus précisément, appelez setAndAllowWhileIdle().
Action spécifiée par l'utilisateur devant se produire après une heure précise
Utilisez une alarme inexacte. Plus précisément, appelez set().
Action spécifiée par l'utilisateur pouvant se produire dans un délai donné
Utilisez une alarme inexacte. Plus précisément, appelez setWindow(). Notez que le délai le plus court autorisé est de 10 minutes.

Procédure de migration pour continuer à utiliser des alarmes exactes

Au minimum, les applications doivent vérifier si elles ont l'autorisation avant de programmer des alarmes exactes. Si les applications ne disposent pas de l'autorisation, elles doivent les demander à l'utilisateur en appelant un intent.

Il s'agit du même processus standard que celui pourdemander une autorisation spéciale :

  1. Les applications doivent appeler AlarmManager.canScheduleExactAlarms() pour vérifier qu'elles disposent des autorisations appropriées.

  2. Si l'application ne dispose pas de l'autorisation, appelez un intent qui inclut l'ACTION_REQUEST_SCHEDULE_EXACT_ALARM avec le nom du package de l'application pour demander aux utilisateurs d'accorder l'autorisation.

    Vérifiez la décision de l'utilisateur dans la méthode onResume() de votre application.

  3. Écoutez les diffusions AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED qui sont envoyées si l'utilisateur accorde l'autorisation.

  4. Si l'utilisateur a accordé l'autorisation à votre application, celle-ci peut définir des alarmes exactes. S'il a refusé l'autorisation, effectuez une dégradation élégante de l'expérience de votre application afin qu'elle lui propose une fonctionnalité sans les informations protégées par cette autorisation.

L'extrait de code suivant montre comment vérifier l'autorisation SCHEDULE_EXACT_ALARM :

val alarmManager: AlarmManager = context.getSystemService<AlarmManager>()!!
when {
   // If permission is granted, proceed with scheduling exact alarms.
   alarmManager.canScheduleExactAlarms() -> {
       alarmManager.setExact(...)
   }
   else -> {
       // Ask users to go to exact alarm page in system settings.
       startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))
   }
}

Exemple de code pour vérifier l'autorisation et gérer les décisions de l'utilisateur dans onResume() :

override fun onResume() {
   …  
   if (alarmManager.canScheduleExactAlarms()) {
       // Set exact alarms.
       alarmManager.setExact(...)
   }
   else {
       // Permission not yet approved. Display user notice and revert to a fallback  
       // approach.
       alarmManager.setWindow(...)
   }
}

Dégradation élégante en cas de refus d'autorisation

Certains utilisateurs refusent d'accorder l'autorisation. Dans ce scénario, nous recommandons aux applications de procéder à une dégradation élégante de l'expérience, tout en essayant d'offrir la meilleure expérience utilisateur de remplacement possible en identifiant leurs cas d'utilisation.

Exceptions

Les types d'applications suivants sont toujours autorisés à appeler les méthodes setExact() ou setExactAndAllowWhileIdle(): 

  • Applications signées avec le certificat de plate-forme
  • Applications privilégiées
  • Les applications figurant sur la liste d'autorisation de l'alimentation (si votre application répond aux exigences, vous pouvez en faire la demande à l'aide de l'action d'intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).

Accords préalables

Consignes de test

Pour tester cette modification, désactivez l'autorisation Alarmes et rappels pour votre application sur la page Accès spécifiques des applications dans les paramètres système (Settings > Apps > Special app access > Alarms & reminders) (Paramètres > Applications > Accès spécifiques des applications > Alarmes et rappels) et observez le comportement de votre application.