App Standby — qu’est-ce que c’est, niveaux d’attente et principe de fonctionnement

Qu'est-ce que App Standby

App Standby est un composant du système de gestion d'énergie Android, introduit dans Android 6.0 (API 23) et considérablement remanié dans Android 9 (API 28). Sa tâche est d'identifier les applications que l'utilisateur utilise rarement et de restreindre leur activité en arrière-plan : requêtes réseau, synchronisation, JobScheduler et AlarmManager. Contrairement à Doze, App Standby ne dépend pas de l'état de l'écran ni du mouvement de l'appareil.

Le système classe les applications en quatre buckets (niveaux) : Active, Working Set, Frequent et Rare. Chaque niveau détermine à quel point l'activité en arrière-plan est restreinte. Les transitions entre niveaux se font automatiquement en fonction des modèles d'utilisation de l'application : fréquence d'ouverture par l'utilisateur, réception de notifications, interaction avec les widgets.

App Standby fonctionne avec Doze Mode mais ne le remplace pas. Alors que Doze limite l'activité en arrière-plan de toutes les applications lorsque l'appareil est inactif, App Standby restreint des applications spécifiques indépendamment de l'état de l'appareil. Une application au niveau Rare subira des restrictions même lorsque le téléphone est utilisé activement, si l'utilisateur ne l'a pas ouverte depuis plusieurs jours.

Buckets dans Android 9+

À partir d'Android 9 (API 28), Google a introduit les App Standby Buckets — une classification formelle avec des valeurs numériques. Le système utilise l'apprentissage automatique pour prédire le prochain lancement de l'application. Si le modèle prédit que l'application sera ouverte dans les prochaines heures, elle reçoit un bucket Active. Si la prédiction indique une utilisation rare — Rare est attribué.

Comment fonctionne App Standby

App Standby analyse plusieurs facteurs pour déterminer le bucket : temps depuis la dernière ouverture de l'application par l'utilisateur, fréquence d'interaction (nombre de lancements par jour/semaine), réception de notifications FCM, présence de widgets actifs sur l'écran d'accueil et abonnement à AlarmManager. Plus une application reste inutilisée longtemps, plus son bucket est bas et plus les restrictions sont strictes.

Le service système UsageStatsManager collecte les statistiques d'utilisation des applications et les transmet à StandbyController — un composant du framework qui calcule le bucket pour chaque application. StandbyController prend également en compte les événements système : après une mise à jour de l'application, son bucket est réinitialisé à Active pendant quelques jours pour permettre à l'utilisateur d'évaluer les nouvelles fonctionnalités.

Une caractéristique importante : App Standby ne tue pas le processus de l'application, mais limite ses capacités en arrière-plan. L'application continue de fonctionner si l'utilisateur interagit avec elle (bucket Active). Dès que l'utilisateur minimise l'application et n'y revient pas, le système commence à compter le temps d'inactivité et peut abaisser le bucket à Working Set ou Frequent.

Impact de FCM sur le bucket

La réception d'un message FCM haute priorité peut temporairement élever le bucket de l'application à Active. Cela donne à l'application l'opportunité d'effectuer une tâche (traiter le message, synchroniser les données) sans restrictions. Cependant, une fois le traitement terminé, le bucket revient à sa valeur d'origine. Google recommande d'utiliser ce mécanisme pour la livraison de notifications importantes, pas pour maintenir l'application en vie.

Niveaux de App Standby

App Standby utilise quatre niveaux (buckets) pour classer les applications. Chaque niveau détermine le temps de retard pour les tâches en arrière-plan : plus le niveau est bas, plus le retard est long. Le système déplace automatiquement l'application entre les niveaux en fonction des statistiques d'utilisation collectées au cours des 7–14 derniers jours.

Active — Application active

Active — une application avec laquelle l'utilisateur a récemment interagi (lancée, reçu une notification ou utilisé un widget). Dans ce bucket, il n'y a aucune restriction : JobScheduler s'exécute immédiatement, le réseau est disponible, AlarmManager se déclenche avec précision. L'application reste en Active jusqu'à ce que l'utilisateur cesse d'interagir avec elle pendant plusieurs heures.

Working Set et Frequent

Working Set — l'application est utilisée régulièrement (plusieurs fois par semaine). Retard des tâches en arrière-plan jusqu'à 2 heures. Frequent — l'application est utilisée plusieurs fois par mois. Retard jusqu'à 4 heures. Dans les deux niveaux, le réseau n'est disponible que dans les fenêtres de maintenance, et AlarmManager peut être différé. JobScheduler exécute les tâches dans la fenêtre la plus proche.

Rare — Rarement utilisée

Rare — le niveau le plus strict, attribué aux applications que l'utilisateur n'a pas ouvertes depuis plus de 30 jours. Le retard des tâches en arrière-plan atteint 24 heures. Le réseau est complètement bloqué en dehors des fenêtres de maintenance, AlarmManager ne se déclenche qu'avec les indicateurs setAndAllowWhileIdle() avec une limite d'1 fois toutes les 9 minutes. Les notifications FCM haute priorité sont toujours livrées mais ne peuvent pas augmenter le bucket.

Restrictions dans App Standby

App Standby impose des restrictions sur plusieurs catégories d'opérations en arrière-plan. Contrairement à Doze, les restrictions de App Standby s'appliquent indépendamment de l'état de l'écran et du chargeur. Le développeur doit concevoir l'application en tenant compte de ces restrictions, surtout si le public cible utilise l'application de manière irrégulière.

JobScheduler et WorkManager

JobScheduler — l'API principale affectée par App Standby. Selon le bucket, le retard d'exécution des tâches varie de 2 à 24 heures. WorkManager, qui utilise JobScheduler sous le capot (sur API 23+), est également sujet à ces retards. Pour les tâches critiques en temps, utilisez Expedited Work, qui lance un Foreground Service sous le capot et n'est pas affecté par le bucket.

Restrictions réseau

Les applications dans les buckets Working Set, Frequent et Rare ne peuvent pas effectuer de requêtes réseau arbitraires à tout moment. Le système n'autorise l'accès au réseau que pendant les fenêtres de maintenance, synchronisées avec Doze. Pour envoyer des données critiques, utilisez FCM haute priorité avec synchronisation ultérieure dans la fenêtre de maintenance.

AlarmManager

AlarmManager dans App Standby suit les mêmes règles que dans Doze : les alarmes exactes (setExact()) sont différées, et setAndAllowWhileIdle() est limité à 1 déclenchement toutes les 9 minutes. Pour le bucket Rare, le retard peut atteindre 24 heures, rendant AlarmManager inadapté à la planification précise de tâches dans les applications rarement utilisées.

• JobScheduler — les tâches sont différées de 2–24 heures selon le bucket
• Réseau — accès uniquement dans les fenêtres de maintenance pour Working Set et inférieurs
• AlarmManager — alarmes exactes différées ; setAndAllowWhileIdle — 1/9 min
• SyncManager — la synchronisation des comptes est retardée jusqu'à la fenêtre de maintenance
• Widget updates — la fréquence de mise à jour des widgets peut être réduite

Comment obtenir une exemption

Une exemption de App Standby peut être obtenue de deux manières : via les paramètres de batterie de l'utilisateur (Whitelist manuelle) ou via l'Intent système ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Cependant, Google régule strictement l'accès aux exemptions — les applications sans raison valable risquent d'être rejetées sur Google Play.

L'utilisateur peut désactiver manuellement les restrictions pour une application spécifique via Paramètres → Applications → [Application] → Batterie → Optimisation → Ne pas optimiser. Cela supprime complètement les restrictions App Standby et Doze pour l'application sélectionnée. Le développeur peut montrer des instructions ou une boîte de dialogue système à l'utilisateur, mais ne peut pas forcer l'ajout d'une application aux exemptions.

Foreground Service avec une notification obtient automatiquement une exemption temporaire de App Standby. Pendant que le service s'exécute et affiche une notification, l'application est déplacée vers le bucket Active indépendamment de son niveau réel. Après l'arrêt du service, le bucket revient à sa valeur d'origine. C'est le moyen le plus fiable de garantir le travail en arrière-plan sans demander d'exemptions système.

Quand demander une exemption

Demander une Whitelist n'a de sens que pour les applications ayant des fonctionnalités critiques en arrière-plan : navigation en temps réel, surveillance de la santé, appels VoIP, protection de l'appareil. Pour la plupart des applications, il suffit d'utiliser Foreground Service ou WorkManager. Google Play peut rejeter la publication si l'application demande une exemption sans nécessité évidente.

// Demander une exemption de App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Vérifier le statut actuel
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Tester App Standby

Tester App Standby via ADB permet d'attribuer forcément n'importe quel bucket à une application et de vérifier son comportement. C'est crucial pour les applications qui dépendent de la synchronisation en arrière-plan, des notifications ou des mises à jour périodiques. Les tests doivent être effectués sur un appareil physique ou un émulateur avec Android 9+.

Pour définir forcément un bucket, utilisez la commande adb shell am set-standby-bucket [package] [bucket], où bucket peut être : active, working_set, frequent ou rare. Pour voir le bucket actuel — adb shell am get-standby-bucket [package]. Le système permet également de simuler une inactivité prolongée de l'application via la commande adb shell dumpsys usagestats.

# Définir le bucket Rare pour l’application
$ adb shell am set-standby-bucket com.example.app rare

# Voir le bucket actuel
$ adb shell am get-standby-bucket com.example.app

# Réinitialiser tous les buckets à Active
$ adb shell dumpsys usagestats clear

# Voir tous les buckets du système
$ adb shell dumpsys usagestats

Que vérifier

Après avoir défini le bucket sur Rare, vérifiez : si la tâche WorkManager s'exécute dans les 24 heures, si AlarmManager se déclenche, si les notifications FCM sont livrées et si Foreground Service fonctionne sans restrictions. WorkManager avec la politique Expedited Work doit s'exécuter immédiatement même dans le bucket Rare, car il utilise Foreground Service. Les tâches WorkManager régulières seront différées selon le bucket.

Bonnes pratiques

Développer une application résistante à App Standby nécessite une approche réfléchie des tâches en arrière-plan. Le principe principal : ne pas supposer que l'application est toujours dans le bucket Active. Concevez le travail en arrière-plan pour qu'il s'exécute correctement avec les retards caractéristiques des buckets Frequent et Rare.

Utiliser WorkManager avec Expedited Work

Expedited Work (WorkManager 2.7+) lance un Foreground Service sous le capot, donnant à la tâche une exécution immédiate indépendamment du bucket. C'est le choix optimal pour les tâches qui ne peuvent pas être différées : envoi de message, synchronisation après paiement, traitement d'un appel entrant. Les tâches WorkManager régulières s'exécutent dans les fenêtres de maintenance selon le bucket.

FCM pour la réactivation

Utilisez les messages FCM haute priorité pour réveiller une application de App Standby. Lorsque l'application reçoit un tel message, son bucket est temporairement élevé à Active, lui permettant d'effectuer les tâches nécessaires (synchronisation, mise à jour des données). Une fois le traitement terminé, le bucket revient à son niveau d'origine.

Éviter la rétention constante en mémoire

N'essayez pas de contourner App Standby avec des services en arrière-plan persistants, WakeLock ou des messages FCM périodiques. Google lutte activement contre ces pratiques — l'application peut être marquée comme énergivore et restreinte encore plus sévèrement. Utilisez WorkManager pour les tâches périodiques et Foreground Service uniquement lorsque la tâche est vraiment visible pour l'utilisateur.

• WorkManager — API préférée ; Expedited Work exécute les tâches sans retard
• FCM haute priorité — élève temporairement le bucket à Active pour le traitement du message
• Ne contournez pas App Standby — cela entraîne le blocage de l'application par le système
• Foreground Service — déplace temporairement l'application en Active pendant l'exécution
• Testez l'application dans les buckets Rare et Frequent via ADB avant chaque version