Restrictions concernant le démarrage d'activités en arrière-plan

Android 10 (niveau d'API 29) et les versions ultérieures imposent des restrictions sur le moment où les applications peuvent démarrer des activités lorsqu'elles s'exécutent en arrière-plan. Ces restrictions permettent de minimiser les interruptions pour l'utilisateur et de lui donner plus de contrôle sur ce qui s'affiche à l'écran.

Ce guide présente les notifications comme une alternative pour démarrer des activités en arrière-plan. Il liste également les cas spécifiques où la restriction ne s'applique pas.

Afficher les notifications à la place

Dans la quasi-totalité des cas, les applications en arrière-plan doivent afficher des notifications urgentes pour fournir des informations urgentes à l'utilisateur au lieu de démarrer directement une activité. Ces notifications incluent la gestion d'un appel téléphonique entrant ou d'un réveil actif.

Ce système d'alertes et de rappels basés sur les notifications présente plusieurs avantages pour les utilisateurs :

  • Lorsqu'il utilise l'appareil, l'utilisateur voit une notification heads-up qui lui permet de répondre. L'utilisateur conserve son contexte actuel et contrôle le contenu qui s'affiche à l'écran.
  • Les notifications urgentes respectent les règles Ne pas déranger de l'utilisateur. Par exemple, les utilisateurs peuvent autoriser les appels uniquement de certains contacts ou des appelants récurrents lorsque le mode Ne pas déranger est activé.
  • Lorsque l'écran de l'appareil est éteint, l'intent en plein écran se lance immédiatement.
  • Sur l'écran Paramètres de l'appareil, l'utilisateur peut voir les applications qui ont récemment envoyé des notifications, y compris à partir de canaux de notification spécifiques. Sur cet écran, l'utilisateur peut contrôler ses préférences de notification.

Quand les applications peuvent démarrer des activités

Les applications exécutées sur Android 10 ou version ultérieure peuvent démarrer des activités lorsque l'une ou plusieurs des conditions suivantes sont remplies :

  • L'application dispose d'une fenêtre visible, telle qu'une activité au premier plan.
  • L'application présente une activité dans la pile "Retour" de la tâche au premier plan.

  • L'application présente une activité dans la pile "Retour" d'une tâche existante sur l'écran "Récents".

  • L'application a une activité qui a commencé très récemment.

  • L'application finish() a appelé une activité très récemment. Cela ne s'applique que lorsque l'application avait une activité au premier plan ou une activité dans la pile arrière de la tâche au premier plan au moment où finish() a été appelé.

  • L'application possède l'un des services suivants, qui est lié au système. Ces services peuvent avoir besoin de lancer une UI.

  • L'application dispose d'un service lié à une autre application visible. L'application liée au service doit rester visible pour que l'application en arrière-plan puisse démarrer des activités.

  • L'application reçoit une notification PendingIntent du système. Dans le cas d'intents en attente pour les services et les broadcast receivers, l'application peut démarrer des activités pendant quelques secondes après l'envoi de l'intent en attente.

  • L'application reçoit un PendingIntent envoyé depuis une autre application visible.

  • L'application reçoit une diffusion système où elle est censée lancer une UI. Par exemple, il peut s'agir de ACTION_NEW_OUTGOING_CALL et SECRET_CODE_ACTION. L'application peut démarrer des activités pendant quelques secondes après l'envoi de la diffusion.

  • L'application est associée à un appareil matériel compagnon via l'API CompanionDeviceManager. Cette API permet à l'application de démarrer des activités en réponse aux actions effectuées par l'utilisateur sur un appareil associé.

  • L'application est un outil de contrôle des règles relatives aux appareils qui s'exécute en mode propriétaire de l'appareil. Parmi les cas d'utilisation, citons les appareils d'entreprise entièrement gérés et les appareils dédiés tels que les bornes interactives et les supports de signalétique numérique.

  • L'utilisateur accorde à l'application l'autorisation SYSTEM_ALERT_WINDOW.

L'activation est requise lors du démarrage d'activités à partir de PendingIntents

Pour éviter les démarrages d'activité accidentels en fonction des conditions listées, des API explicites vous permettent, à partir d'Android 14, d'activer ou de désactiver l'octroi d'autorisations de démarrage d'activité à une application.

Les applications ciblant Android 15 ou version ultérieure ne seront plus autorisées par défaut à accorder implicitement les droits de lancement d'activité en arrière-plan (BAL, Background Activity Launch) aux PendingIntents qu'elles créent. Un consentement explicite est requis. Pour ce faire, voici les options disponibles selon que l'application envoie ou crée des PendingIntents.

Tableau des intents en attente
Figure 1 : Organigramme des décisions pour les lancements d'activités en arrière-plan.

Par l'expéditeur du PendingIntent

Les applications ciblant Android 14 ou version ultérieure qui souhaitent démarrer un PendingIntent doivent

  • remplir les conditions listées et
  • activer le lancement d'activités en arrière-plan en fonction de ces exceptions.

Cette activation ne doit avoir lieu que si le développeur de l'application sait que l'application va démarrer une activité.

Pour l'activer, l'application doit transmettre un bundle ActivityOptions avec setPendingIntentBackgroundActivityStartMode(ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOWED) aux méthodes PendingIntent.send() ou similaires.

Par le créateur de PendingIntent

Les applications ciblant Android 15 ou version ultérieure qui créent un PendingIntent doivent désormais activer explicitement le lancement d'activité en arrière-plan si elles souhaitent que ces PendingIntents puissent être démarrés dans les conditions listées.

Dans la plupart des cas, l'application qui démarre PendingIntent doit être celle qui active le service. Toutefois, si l'application de création doit accorder ces droits :

  • L'PendingIntent peut être démarré à tout moment lorsque l'application de création est visible.
  • Le PendingIntent peut être démarré à tout moment si l'application de création dispose de privilèges spéciaux.

Pour l'activer, l'application doit transmettre un bundle ActivityOptions avec setPendingIntentCreatorBackgroundActivityStartMode (ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOWED) aux méthodes PendingIntent.getActivity() ou similaires.

Pour en savoir plus, consultez la documentation de référence correspondante :

Mode Strict

À partir d'Android 16, le développeur d'applications peut activer le mode Strict pour être averti lorsqu'un lancement d'activité est bloqué (ou risque de l'être lorsque le SDK cible de l'application est augmenté).

Exemple de code à activer dès le début de la méthode Application.onCreate() de votre application, de votre activité ou d'un autre composant d'application :

 override fun onCreate(savedInstanceState: Bundle?) {
     super.onCreate(savedInstanceState)
     StrictMode.setVmPolicy(
         StrictMode.VmPolicy.Builder()
         .detectBlockedBackgroundActivityLaunch()
         .penaltyLog()
         .build());
     )
 }

Pour en savoir plus, consultez la documentation sur le mode strict.