Programmer des alarmes

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 conjointement avec des broadcast receivers pour planifier des tâches ou des WorkRequests afin d'effectuer d'autres opérations.

• Ils fonctionnent en dehors de votre application. Vous pouvez donc les utiliser pour déclencher des événements ou des actions même lorsque votre application n'est pas en cours d'exécution, et même si l'appareil lui-même est en veille.

• Ils vous aident à réduire les besoins en ressources de votre application. Vous pouvez planifier 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é. Les alarmes inexactes fournissent certaines garanties concernant l'heure d'exécution de l'alarme, tout en respectant les restrictions d'économie de batterie telles que Sommeil.

Les développeurs peuvent exploiter les garanties d'API suivantes pour personnaliser le délai de diffusion des alarmes inexactes.

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 fournie.

Sur Android 12 (niveau d'API 31) ou version ultérieure, le système appelle l'alarme dans l'heure qui suit l'heure de déclenchement fournie, sauf si des restrictions d'économie de batterie sont en vigueur, telles que l'économiseur de batterie ou le mode 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'heure de déclenchement fournie. Sauf si des restrictions d'économie de batterie sont en vigueur, l'alarme est diffusée dans le délai spécifié, à partir de l'heure de déclenchement donnée.

Si votre application cible Android 12 ou une version ultérieure, le système peut retarder d'au moins 10 minutes l'appel d'une alarme inexacte associée à une période de temps. Pour cette raison, les valeurs de paramètre windowLengthMillis sous 600000 sont rognées sur 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 temporelle spécifiée, à partir de l'heure de déclenchement donnée.
2. Les alarmes suivantes se déclenchent généralement une fois l'intervalle de temps spécifié écoulé. 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épondre à plusieurs cas d'utilisation courants. Si la fonctionnalité de base de votre application dépend d'une alarme programmée avec précision, par exemple pour une application de réveil ou 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 méthodes pour gérer les opérations de minutage, comme effectuer des tâches toutes 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 sur le 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 tâches périodiques sensibles au facteur temps. Vous pouvez fournir un intervalle de répétition et une 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 minimale de 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 ordonnées de sorte que celles qui se trouvent le plus près du bas de la liste diffusent des tâches plus urgentes, mais nécessitent davantage de ressources système.

setExact()

Appelez une alarme à une heure presque précise à l'avenir, à condition que les autres mesures d'économie de batterie ne soient pas en vigueur.

Utilisez cette méthode pour définir des alarmes exactes, sauf si le travail de votre application est urgent pour l'utilisateur.

setExactAndAllowWhileIdle()

Appelez une alarme à une heure presque précise, même si des mesures d'économie de batterie sont en vigueur.

setAlarmClock()

Appelez une alarme à une heure précise. Comme ces alarmes sont très visibles pour les utilisateurs, le système n'ajuste jamais leur délai d'envoi. Le système identifie ces alarmes comme les plus critiques et laisse des modes basse consommation si nécessaire pour les déclencher.

Consommation des ressources du système

Lorsque le système déclenche des alarmes exactes définies par votre application, l'appareil consomme beaucoup de ressources, telles que l'autonomie de la batterie, en particulier s'il est en mode Économie d'énergie. De plus, le système ne peut pas facilement regrouper ces requêtes pour utiliser les ressources plus efficacement.

Il est vivement recommandé de créer une alarme inexacte dans la mesure du possible. Pour effectuer une tâche plus longue, planifiez-la en utilisant WorkManager ou JobScheduler à partir du BroadcastReceiver de votre alarme. Pour effectuer une tâche lorsque l'appareil est en mode Sommeil, créez une alarme inexacte à l'aide de setAndAllowWhileIdle(), puis démarrez 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 l'accès spécial "Alarmes et rappels". Pour ce faire, déclarez l'autorisation 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éclarer l'autorisation SCHEDULE_EXACT_ALARM ou USE_EXACT_ALARM.

<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, elles sont accordées différemment et acceptent des cas d'utilisation différents. Votre application ne doit utiliser des alarmes exactes et déclarer l'autorisation SCHEDULE_EXACT_ALARM ou USE_EXACT_ALARM que si une fonction visible par l'utilisateur dans votre application nécessite des actions à un moment précis.

USE_EXACT_ALARM

• Accordée automatiquement
• Ne peut pas être révoqué par l'utilisateur
• Soumis à une prochaine règle Google Play
• Cas d'utilisation limités

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 pour les nouvelles installations d'applications ciblant Android 13 (niveau d'API 33) ou version ultérieure. Si un 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 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 lors de la mise à niveau de l'appareil vers Android 14.

Remarque: Si l'alarme exacte est définie à l'aide d'un objet OnAlarmListener, par exemple avec l'API 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ée par l'utilisateur. L'utilisateur et le système peuvent révoquer l'autorisation SCHEDULE_EXACT_ALARM.

Pour vérifier si l'autorisation est accordée à votre application, appelez canScheduleExactAlarms() avant d'essayer de définir une alarme exacte. Lorsque l'autorisation SCHEDULE_EXACT_ALARM est révoquée pour votre application, 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 tout le cycle de vie de votre application.

Lorsque l'autorisation SCHEDULE_EXACT_ALARMS est accordée à votre application, le système lui envoie la diffusion ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED. Votre application doit implémenter un broadcast receiver qui effectue les opérations 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, 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 doit être semblable à ce que fait votre application lorsqu'elle reçoit la diffusion ACTION_BOOT_COMPLETED.

Demander aux utilisateurs d'accorder l'autorisation SCHEDULE_EXACT_ALARM

Si nécessaire, vous pouvez rediriger les utilisateurs vers l'écran Alarms & Tasks (Alarmes et rappels) des paramètres 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 programmer des alarmes exactes.
2. Appelez un intent qui inclut l'action d'intent ACTION_REQUEST_SCHEDULE_EXACT_ALARM.

Définir une alarme récurrente

Les alarmes répétées permettent au système d'informer votre application selon un calendrier récurrent.

Une alarme mal conçue peut décharger la batterie et exercer une charge importante sur les serveurs. Pour cette raison, sur Android 4.4 (niveau d'API 19) ou version ultérieure, toutes 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 se déclenche 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 une 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() afin d'obtenir une instance de l'intent (le cas échéant), puis transmettez cet intent à AlarmManager.cancel().

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)
}

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

L'une des premières considérations concernant l'utilisation d'une alarme récurrente est son type.

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" comme référence, tandis que l'horloge en temps réel utilise l'heure UTC (horloge murale). Cela signifie que le temps réel est adapté pour définir une alarme en fonction du temps écoulé (par exemple, une alarme qui se déclenche toutes les 30 secondes), car elle n'est pas affectée par le fuseau horaire ou les paramètres régionaux. Le type d'horloge en temps réel est mieux adapté aux alarmes qui dépendent des paramètres régionaux actuels.

Les deux types ont une version "réveil", qui indique de réactiver le processeur de l'appareil si l'écran est éteint. Cela garantit que l'alarme se déclenchera à l'heure programmée. Cela est utile si votre application a une dépendance temporelle. (par exemple, s'il dispose d'une fenêtre limitée pour effectuer une opération particulière). Si vous n'utilisez pas la version de réveil de votre type d'alarme, toutes les alarmes récurrentes se déclencheront la prochaine fois que votre appareil sera activé.

Si vous souhaitez simplement que votre alarme se déclenche à un intervalle particulier (par exemple, toutes les demi-heures), utilisez l'un des types de temps réel écoulé. En général, il s'agit du meilleur choix.

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

Voici la liste des types:

• ELAPSED_REALTIME : déclenche l'intent en attente en fonction du temps écoulé depuis le démarrage de l'appareil, mais ne le réactive pas. Le temps écoulé inclut tout moment pendant lequel l'appareil était en veille.

• ELAPSED_REALTIME_WAKEUP : active l'appareil et déclenche l'intent en attente une fois le délai spécifié é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: active l'appareil pour déclencher l'intent en attente à l'heure spécifiée.

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

Voici quelques exemples d'utilisation de ELAPSED_REALTIME_WAKEUP

Activez l'appareil pour déclencher l'alarme au bout de 30 minutes, puis toutes les 30 minutes:

// 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
)

// 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:

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
)

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 de RTC_WAKEUP.

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

// 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
)

// 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, puis toutes les 20 minutes :

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
)

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 décrit précédemment, le choix du type d'alarme constitue souvent la première étape de la création d'une alarme. Une autre distinction est le niveau de précision requis pour votre alarme. Pour la plupart des applications, setInexactRepeating() est le bon choix. Lorsque vous utilisez cette méthode, Android synchronise plusieurs alarmes inexactes et les déclenche 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 qui a des exigences de temps rigides, 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, telles que INTERVAL_FIFTEEN_MINUTES, INTERVAL_DAY, etc. Consultez AlarmManager pour 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 le PendingIntent que vous ne souhaitez plus déclencher. Par exemple :

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

// 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 de sorte qu'elle redémarre automatiquement une alarme récurrente si l'utilisateur redémarre l'appareil. Cela garantit que AlarmManager continuera à accomplir sa tâche sans que l'utilisateur n'ait à redémarrer l'alarme manuellement.

Voici la procédure à suivre :

1. Définissez l'autorisation RECEIVE_BOOT_COMPLETED dans le fichier manifeste de votre application. Votre application peut ainsi recevoir le ACTION_BOOT_COMPLETED diffusé une fois le démarrage du système terminé (cela ne fonctionne que si l'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 filtre l'action ACTION_BOOT_COMPLETED:

   <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 sera appelé que si l'application l'active explicitement. Cela empêche que le récepteur de démarrage soit 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 le reste même si l'utilisateur redémarre l'appareil. En d'autres termes, l'activation programmatique du récepteur remplace le paramètre du fichier manifeste, même lors des redémarrages. Le récepteur reste activé jusqu'à ce que votre application le 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

Les appareils équipés d'Android 6.0 (niveau d'API 23) sont compatibles avec le mode Sommeil, qui contribue à prolonger l'autonomie de la batterie de l'appareil. Les alarmes ne se déclenchent pas lorsque l'appareil est en mode Sommeil. Les alarmes programmées sont différées jusqu'à ce que l'appareil quitte le mode Sommeil. Si vous devez effectuer une tâche même lorsque l'appareil est inactif, plusieurs options sont disponibles:

• Régler une alarme exacte

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

pour réussir votre lancement

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

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

  • Effectuez des interventions locales lorsque l'alarme se déclenche. « Travail local » signifie tout ce qui n'atteint pas un serveur ou qui n'a pas besoin des données du serveur.

  • En même temps, programmez le déclenchement de l'alarme contenant les requêtes réseau à une période aléatoire.

• 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 la section 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 déclenche en même temps. Cela réduit le nombre total de fois où le système doit activer l'appareil, ce qui réduit la décharge de la batterie. À partir d'Android 4.4 (niveau d'API 19), toutes les alarmes récurrentes sont des alarmes inexactes. Notez que bien que setInexactRepeating() soit une amélioration par rapport à setRepeating(), il peut toujours surcharger un serveur si chaque instance d'une application atteint le serveur à peu près au même moment. Par conséquent, pour les requêtes réseau, ajoutez un caractère aléatoire à vos alarmes, comme indiqué 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. Si possible, utilisez ELAPSED_REALTIME. Les différents types d'alarmes sont décrits plus en détail dans la section suivante.