Programmer des alarmes

Alarmes (en fonction du AlarmManager) vous permet de réaliser des opérations temporelles en dehors de la durée de vie de votre application. Par exemple, vous pouvez utiliser une alarme pour lancer une opération de longue durée, telle que comme démarrer un service une fois par jour pour télécharger les prévisions météo.

Les alarmes ont les caractéristiques suivantes:

  • Ils vous permettent de déclencher des intents à des heures et/ou des intervalles donnés.

  • Vous pouvez les utiliser avec des broadcast receivers pour planifier jobs ou WorkRequests pour effectuer d'autres opérations.

  • Comme elles fonctionnent en dehors de votre application, vous pouvez les utiliser des événements ou actions, même lorsque votre application n'est pas en cours d'exécution, et même si l'appareil est endormi(e).

  • Ils vous aident à réduire les besoins en ressources de votre application. Vous pouvez programmer des opérations sans utiliser de minuteurs ni de services en cours d'exécution.

Définir une alarme inexacte

Lorsqu'une application définit une alarme inexacte, le système la déclenche à un moment donné à l'avenir. Les alarmes inexactes apportent certaines garanties sur l'heure le déclenchement de l'alarme tout en respectant les restrictions d'économie de batterie telles que Sommeil.

Les développeurs peuvent utiliser les garanties d'API suivantes pour personnaliser le délai le déclenchement de l'alarme inexact.

Générer une alarme après une heure précise

Si votre application appelle set(), setInexactRepeating(), ou setAndAllowWhileIdle(), l'alarme ne se déclenche jamais avant l'heure de déclenchement indiquée.

Sur Android 12 (niveau d'API 31) ou version ultérieure, le système appelle l'alarme dans un heure de déclenchement fournie, sauf si des restrictions d'économie de batterie sont tels que l'économiseur de batterie ou Sommeil.

Générer une alarme pendant une période donnée

Si votre application appelle setWindow(), l'alarme ne se déclenche jamais avant l'alarme l'heure de déclenchement. Sauf si des restrictions d'économie de batterie sont en vigueur, l'alarme est déclenchée livrés dans la période spécifiée, à partir du déclencheur donné en temps réel.

Si votre application cible Android 12 ou une version ultérieure, le système peut retarder l'appel d'une alarme inexacte associée à une période d'au moins 10 minutes. Pour pour cette raison, windowLengthMillis valeurs de paramètre inférieures à 600000 sont rognées pour 600000

Déclencher une alarme récurrente à intervalles réguliers

Si votre application appelle setInexactRepeating(), le système appelle plusieurs alarmes:

  1. La première alarme se déclenche dans la fenêtre horaire spécifiée, au moment précis du déclenchement.
  2. Les alarmes suivantes se déclenchent généralement après le délai spécifié s'écoule. Le temps écoulé entre deux appels consécutifs de l'alarme peut varier.

Régler une alarme exacte

Le système appelle une alarme exacte à un moment précis dans le futur.

La plupart des applications peuvent planifier des tâches et des événements à l'aide d'alarmes inexactes pour répondent à plusieurs cas d'utilisation courants. Si l'objectif principal de votre application la fonctionnalité dépend d'une alarme programmée avec précision, par exemple pour une application de réveil ou une application d'agenda, vous pouvez utiliser une alarme exacte à la place.

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

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

Planifier des opérations temporelles pendant la durée de vie de votre application
La classe Handler inclut plusieurs bonnes pratiques pour gérer les opérations temporelles, comme effectuer des tâches tous les n secondes, tant que votre application est active: postAtTime() et postDelayed(). Notez que ces API reposent sur le temps d'activité du système. et non en temps réel.
Travail d'arrière-plan planifié, comme la mise à jour de votre application et l'importation de journaux
WorkManager permet de planifier des événements périodiques sensibles au facteur temps. travail. Vous pouvez définir un intervalle de répétition et flexInterval (15 minutes minimum) pour définir un environnement d'exécution précis pour le travail.
Action spécifiée par l'utilisateur devant se produire après un délai spécifique (même si 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 au cours d'une période donnée
Utilisez une alarme inexacte. Plus précisément, appelez setWindow() Notez que si votre application cible Android 12 ou une version ultérieure, la durée de la fenêtre autorisée est de 10 minutes.

Comment régler une alarme exacte

Votre application peut définir des alarmes exactes à l'aide de l'une des méthodes suivantes. Ces méthodes sont classées de sorte que celles qui sont proches du bas de la liste servent le plus les tâches urgentes, mais qui nécessitent plus de ressources système.

setExact()

Appelez une alarme à une heure presque précise dans le futur, à condition que d'autres mesures d'économie de batterie ne sont pas appliquées.

Utilisez cette méthode pour définir des alarmes exactes, sauf si votre application à un moment critique pour l'utilisateur.

setExactAndAllowWhileIdle()

Appelez une alarme à une heure presque précise, même si le mode Économie de batterie sont en vigueur.

setAlarmClock()

Appelez une alarme à une heure précise. Parce que ces alarmes sont très visible pour les utilisateurs, le système n'ajuste jamais leurs délais de livraison. La système identifie ces alarmes comme les plus critiques et laisse une faible consommation si nécessaire pour déclencher les alarmes.

Consommation des ressources du système

Lorsque le système déclenche les alarmes exactes définies par votre application, l'appareil consomme beaucoup de ressources, comme l'autonomie de la batterie, surtout un mode Économie d'énergie. De plus, le système ne peut pas traiter facilement ces requêtes par lot afin d'utiliser les ressources plus efficacement.

Nous vous recommandons vivement de créer une alarme inexacte chaque fois que possible. Pour effectuer un travail plus long, planifiez-le avec WorkManager ou JobScheduler de votre alarme BroadcastReceiver Pour effectuer des tâches pendant l'appareil est en mode Sommeil, créez une alarme inexacte en utilisant setAndAllowWhileIdle(), et démarrer une tâche à partir de l'alarme.

Déclarer l'autorisation d'utiliser des alarmes exactes appropriées

Si votre application cible Android 12 ou une version ultérieure, vous devez obtenir "Alarmes et rappels" un accès spécial des applications. Pour ce faire, déclarez SCHEDULE_EXACT_ALARM dans le fichier manifeste de votre application, comme indiqué dans l'extrait de code suivant:

<manifest ...>
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

Si votre application cible Android 13 (niveau d'API 33) ou une version ultérieure, vous pouvez déclarez soit SCHEDULE_EXACT_ALARM, ou USE_EXACT_ALARM l'autorisation.

<manifest ...>
    <uses-permission android:name="android.permission.USE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

Bien que les autorisations SCHEDULE_EXACT_ALARM et USE_EXACT_ALARM signalent les mêmes capacités, mais sont accordées différemment et acceptent différentes dans différents cas d'utilisation. Votre application doit utiliser des alarmes exactes et déclarer Autorisation SCHEDULE_EXACT_ALARM ou USE_EXACT_ALARM, uniquement si un utilisateur dans votre application nécessite des actions à un moment précis.

USE_EXACT_ALARM

SCHEDULE_EXACT_ALARM

  • Accordée par l'utilisateur
  • Élargissement de l'ensemble des cas d'utilisation
  • Les applications doivent confirmer que l'autorisation n'a pas été révoquée

L'autorisation SCHEDULE_EXACT_ALARM n'est pas pré-accordée aux nouvelles installations de Applications ciblant Android 13 (niveau d'API 33) ou version ultérieure Si un utilisateur transfère une application à un appareil équipé d'Android 14 via une opération de sauvegarde et de restauration, L'autorisation SCHEDULE_EXACT_ALARM sera refusée sur le nouvel appareil. Toutefois, si une application existante dispose déjà de cette autorisation, elle sera pré-accordée lorsque le les mises à niveau d'appareils vers Android 14.

Remarque: Si l'alarme exacte est définie à l'aide d'un OnAlarmListener objet, comme dans l'objet setExact l'autorisation SCHEDULE_EXACT_ALARM n'est pas requise.

Utiliser l'autorisation SCHEDULE_EXACT_ALARM

Contrairement à USE_EXACT_ALARM, l'autorisation SCHEDULE_EXACT_ALARM doit être accordé par l'utilisateur. L'utilisateur et le système peuvent révoquer l'accès Autorisation SCHEDULE_EXACT_ALARM.

Pour vérifier si l'autorisation est accordée à votre appli, appelez canScheduleExactAlarms() avant d'essayer de régler une alarme exacte. Lorsque l'autorisation SCHEDULE_EXACT_ALARM est révoqué pour votre appli, celle-ci s'arrête et toutes les alarmes exactes futures sont annulées. Cela signifie également que la valeur renvoyée par canScheduleExactAlarms() reste valide pendant l'intégralité du cycle de vie de votre application.

Lorsque l'autorisation SCHEDULE_EXACT_ALARMS est accordée à votre application, le système l'envoie ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED annonce. Votre application doit implémenter une diffusion récepteur qui effectue suivantes:

  1. confirme que votre application dispose toujours de l'accès spécial de l'application ; Pour ce faire, appelez canScheduleExactAlarms() Cette vérification protège votre application dans le cas où l'utilisateur lui accorde l'autorisation l'autorisation, puis la révoque presque immédiatement après.
  2. Reprogramme toutes les alarmes exactes dont votre application a besoin, en fonction de son état actuel. Cette logique est semblable à celle de votre application lorsqu'elle reçoit le ACTION_BOOT_COMPLETED annonce.

Demander aux utilisateurs d'accorder l'autorisation SCHEDULE_EXACT_ALARM

L&#39;option est appelée « Autoriser à définir des alarmes et des rappels »
Figure 1. "Alarmes et rappels" accès spécial des applis dans les paramètres système, sur laquelle les utilisateurs peuvent autoriser votre application à définir les alarmes

Si nécessaire, vous pouvez rediriger les utilisateurs vers le menu Alarmes et l'écran des rappels du système. , comme illustré dans la figure 1. Pour ce faire, procédez comme suit :

  1. Dans l'interface utilisateur de votre application, expliquez à l'utilisateur pourquoi votre application doit planifier les alarmes.
  2. Appelez un intent qui inclut les ACTION_REQUEST_SCHEDULE_EXACT_ALARM une action d'intent.

Définir une alarme récurrente

Les alarmes répétées permettent au système d'avertir votre application lors d'une programmation.

Une alarme mal conçue peut décharger la batterie et exercer une charge importante sur serveurs. Pour cette raison, sur Android 4.4 (niveau d'API 19) ou version ultérieure, Les alarmes répétées sont des alarmes inexactes.

Une alarme récurrente présente les caractéristiques suivantes:

  • Type d'alarme. Pour plus d'informations, consultez la section Choisir un type d'alarme.

  • Heure de déclenchement. Si l'heure de déclenchement que vous spécifiez est passée, l'alarme immédiatement.

  • Intervalle de l'alarme. Par exemple, une fois par jour, toutes les heures ou toutes les cinq minutes.

  • Un intent en attente qui se déclenche lorsque l'alarme est déclenchée. Lorsque vous définissez un deuxième alarme qui utilise le même intent en attente, elle remplace l'alarme d'origine.

Pour annuler un PendingIntent(), transmettez FLAG_NO_CREATE à PendingIntent.getService() pour obtenir une instance de l'intent (le cas échéant), puis le transmettre à AlarmManager.cancel()

Kotlin

val alarmManager =
    context.getSystemService(Context.ALARM_SERVICE) as? AlarmManager
val pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE)
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent)
}

Java

AlarmManager alarmManager =
    (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
PendingIntent pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE);
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent);
}

Choisir un type d'alarme

Lorsque vous utilisez une alarme récurrente, vous devez d'abord déterminer son type doit être.

Il existe deux types d'horloges pour les alarmes : "temps réel écoulé" et "horloge en temps réel" (RTC). Le temps réel écoulé utilise le "temps écoulé depuis le démarrage du système" en tant que tandis que l'horloge en temps réel utilise l'heure UTC (horloge murale). Cela signifie que le temps réel écoulé permet de définir une alarme en fonction du temps écoulé (par comme une alarme qui se déclenche toutes les 30 secondes), car elle n'est pas affectée par fuseau horaire ou paramètres régionaux. Le type d'horloge en temps réel convient mieux aux alarmes dépendent des paramètres régionaux actuels.

Les deux types ont un « réveil » qui indique d’activer le CPU de l’appareil si l'écran est éteint. Ainsi, l'alarme se déclenchera à l'heure programmée. Cela est utile si votre application a une dépendance temporelle. Par exemple, s'il comporte une fenêtre limitée pour effectuer une opération particulière. Si vous n'utilisez pas version wakeup de votre type d'alarme, toutes les alarmes récurrentes se déclencheront lorsque votre appareil sera de nouveau activé.

Si vous souhaitez simplement que votre alarme se déclenche à une certaine fréquence (par exemple, toutes les demi-heures), utilisez l'un des types de temps réel écoulé. En général, est le meilleur choix.

Si vous souhaitez que votre alarme se déclenche à une heure précise de la journée, choisissez-en une des types d'horloges en temps réel basées sur l'horloge. Notez toutefois que cette approche présentent quelques inconvénients. Il est possible que l'application ne fonctionne pas correctement dans les autres langues. si l'utilisateur modifie le paramètre d'heure de l'appareil, cela peut provoquer un comportement inattendu dans votre application. L'utilisation d'un type d'alarme d'horloge en temps réel ne s'adapte pas bien non plus, comme expliqué ci-dessus. Nous vous recommandons d'utiliser une métrique "Temps réel écoulé" alarme si possible.

Voici la liste des types:

  • ELAPSED_REALTIME: Déclenche l'intent en attente en fonction de la durée écoulée depuis que l'appareil démarré, mais ne réactive pas l’appareil. La Le temps écoulé inclut le temps de veille de l'appareil.

  • ELAPSED_REALTIME_WAKEUP: Active l'appareil et déclenche l'intent en attente après la durée spécifiée de temps s'est écoulé depuis le démarrage de l'appareil.

  • RTC: Déclenche l'intent en attente au moment spécifié, mais ne réactive pas l'appareil.

  • RTC_WAKEUP: wakes l'appareil pour déclencher l'intent en attente au moment spécifié.

Exemples d'alarmes en temps réel écoulées

Voici quelques exemples d'utilisation de ELAPSED_REALTIME_WAKEUP

Réactivez l'appareil pour déclencher l'alarme dans 30 minutes et toutes les 30 minutes. après cela:

Kotlin

// Hopefully your alarm will have a lower frequency than this!
alarmMgr?.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR,
        alarmIntent
)

Java

// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);

Activez l'appareil pour déclencher une alarme unique (non récurrente) en une minute:

Kotlin

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

alarmMgr?.set(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + 60 * 1000,
        alarmIntent
)

Java

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() +
        60 * 1000, alarmIntent);

Exemples d'alarmes en temps réel

Voici quelques exemples d'utilisation RTC_WAKEUP

Activez l'appareil pour déclencher l'alarme vers 14 h 00, et répétez l'opération une fois par jour à la même heure:

Kotlin

// Set the alarm to start at approximately 2:00 p.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 14)
}

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr?.setInexactRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        AlarmManager.INTERVAL_DAY,
        alarmIntent
)

Java

// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        AlarmManager.INTERVAL_DAY, alarmIntent);

Activez l'appareil pour déclencher l'alarme à 8h30 précisément et toutes les 20 minutes par la suite:

Kotlin

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

// Set the alarm to start at 8:30 a.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 8)
    set(Calendar.MINUTE, 30)
}

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr?.setRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        1000 * 60 * 20,
        alarmIntent
)

Java

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        1000 * 60 * 20, alarmIntent);

Choisissez la précision de votre alarme

Comme indiqué précédemment, le choix du type d'alarme constitue souvent la première étape pour créer une alarme. Autre distinction : la précision requise pour votre alarme de l'IA générative. Pour la plupart des applications, setInexactRepeating() est le bon choix. Lorsque vous utilisez cette méthode, Android synchronise plusieurs alarmes et incendies qui se répètent de façon inexacte. en même temps. Cela réduit la décharge de la batterie.

Évitez d'utiliser des alarmes exactes si possible. Toutefois, pour l'application rare en fonction du temps nécessaire, vous pouvez définir une alarme exacte en appelant setRepeating()

Avec setInexactRepeating(), vous ne pouvez pas spécifier d'intervalle personnalisé comme vous le pouvez avec setRepeating() Vous devez utiliser l'une des constantes d'intervalle, comme INTERVAL_FIFTEEN_MINUTES, INTERVAL_DAY, et ainsi de suite. Voir AlarmManager pour en obtenir la liste complète.

Annuler une alarme

En fonction de votre application, vous pouvez inclure la possibilité d'annuler l'alarme. Pour annuler une alarme, appelez cancel() dans Alarm Manager, en transmettant PendingIntent dont vous ne voulez plus pour déclencher l'alarme. Exemple :

Kotlin

// If the alarm has been set, cancel it.
alarmMgr?.cancel(alarmIntent)

Java

// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
    alarmMgr.cancel(alarmIntent);
}

Lancer une alarme lorsque l'appareil redémarre

Par défaut, toutes les alarmes sont annulées lorsqu'un appareil s'éteint. Pour éviter cela, vous pouvez concevoir votre application pour redémarrer automatiquement une alarme récurrente si l'utilisateur redémarre l'appareil. Ce garantit que AlarmManager de continuer à accomplir sa tâche sans que l'utilisateur n'ait besoin de redémarrer manuellement l'alarme.

Voici la procédure à suivre :

  1. Définissez la RECEIVE_BOOT_COMPLETED dans le fichier manifeste de votre application. Cela permet à votre application de recevoir ACTION_BOOT_COMPLETED diffusée une fois le démarrage du système terminé (cela ne fonctionne que si application a déjà été lancée par l'utilisateur au moins une fois):

    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

  2. Implémentez un BroadcastReceiver pour recevoir la diffusion:

    Kotlin

    class SampleBootReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == "android.intent.action.BOOT_COMPLETED") {
            // Set the alarm here.
        }
    }
}

    Java

    public class SampleBootReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
            // Set the alarm here.
        }
    }
}

  3. Ajoutez le récepteur au fichier manifeste de votre application avec un filtre d'intent qui des filtres ACTION_BOOT_COMPLETED action:

    <receiver android:name=".SampleBootReceiver"
        android:enabled="false">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"></action>
    </intent-filter>
</receiver>

    Notez que dans le fichier manifeste, le récepteur de démarrage est défini sur android:enabled="false" Cela signifie que le récepteur ne doit pas être appelé, sauf si l'application l'active explicitement. Cela permet d'éviter que le récepteur de démarrage d'être appelé inutilement. Vous pouvez activer un récepteur (par exemple, si l'utilisateur définit une alarme) comme suit:

    Kotlin

    val receiver = ComponentName(context, SampleBootReceiver::class.java)

context.packageManager.setComponentEnabledSetting(
        receiver,
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP
)

    Java

    ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();

pm.setComponentEnabledSetting(receiver,
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP);

    Une fois le récepteur activé, il reste activé, même si l'utilisateur redémarre l'appareil. En d'autres termes, activer de manière programmatique le récepteur remplace le paramètre du fichier manifeste, même lors des redémarrages. Le récepteur jusqu'à ce que votre application la désactive. Vous pouvez désactiver un récepteur (par exemple, si l'utilisateur annule une alarme), comme suit:

    Kotlin

    val receiver = ComponentName(context, SampleBootReceiver::class.java)

context.packageManager.setComponentEnabledSetting(
        receiver,
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
        PackageManager.DONT_KILL_APP
)

    Java

    ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
PackageManager pm = context.getPackageManager();

pm.setComponentEnabledSetting(receiver,
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
        PackageManager.DONT_KILL_APP);

Appeler des alarmes lorsque l'appareil est en mode Sommeil

Compatibilité avec les appareils équipés d'Android 6.0 (niveau d'API 23) Sommeil , ce qui contribue à prolonger l'autonomie de la batterie de l'appareil. Les alarmes ne se déclenchent pas lorsque l'appareil est en mode Mode Sommeil Toutes les alarmes programmées sont reportées jusqu'à ce que l'appareil quitte le mode Sommeil. Si vous avez besoin de même lorsque l'appareil est inactif, plusieurs options s'offrent à vous disponibles:

  • Régler une alarme exacte

  • Utilisez l'API WorkManager, conçue pour effectuer le travail en arrière-plan. Vous pouvez indiquer que le système devrait accélérer votre travail afin que le travail se termine dès que possible. Pour en savoir plus, consultez Planifier des tâches avec WorkManager

Bonnes pratiques

Chaque choix que vous faites dans la conception de votre alarme récurrente peut avoir des conséquences sur la manière dont votre application utilise (ou abuse) des ressources système. Par exemple, imaginez qu'un une application populaire qui se synchronise avec un serveur. Si l'opération de synchronisation est basée sur l'horloge et que chaque instance de l'application est synchronisée à 23 h 00, la charge sur le peut entraîner une latence élevée, voire "déni de service". Suivez ces bonnes pratiques d'utilisation des alarmes:

  • ajouter un caractère aléatoire (gigue) à toutes les requêtes réseau qui se déclenche à la suite d’une alarme récurrente:

    • Effectuez des interventions locales lorsque l'alarme se déclenche. "Travail local" signifie tout ce qui qui n'appelle pas un serveur et n'exige pas que les données lui soient transmises.

    • En même temps, programmez l'alarme contenant les demandes du réseau se déclenche à une période aléatoire de temps.

  • Maintenez la fréquence de vos alarmes au minimum.

  • Ne réactivez pas l'appareil inutilement (ce comportement est déterminé par le type d'alarme, comme décrit dans Choisir un type d'alarme).

  • Ne définissez pas l'heure de déclenchement de votre alarme plus précise qu'elle ne devrait l'être.

    Utilisez setInexactRepeating() au lieu de setRepeating() Lorsque vous utilisez setInexactRepeating(), Android synchronise les alarmes répétées de plusieurs applications et les incendies en même temps. Cela réduit le nombre total de fois où le système doit activer ce qui réduit la décharge de la batterie. À partir d'Android 4.4 (niveau d'API 19), toutes les alarmes répétées sont des alarmes inexactes. Remarque bien que setInexactRepeating() est une amélioration par rapport setRepeating(), Elle peut toujours surcharger un serveur si toutes les instances d'une application atteignent le serveur à peu près au même moment. Par conséquent, pour les requêtes réseau, ajoutez un peu de hasard vos alarmes, comme mentionné précédemment.

  • Dans la mesure du possible, évitez de baser votre réveil sur l'heure.

    Les alarmes répétées, basées sur une heure de déclenchement précise, ne sont pas adaptées. Utilisez ELAPSED_REALTIME si que possible. Les différentes alarmes sont décrits plus en détail dans la section suivante.