Respecter le niveau d'API cible requis par Google Play

Lorsque vous importez un APK, celui-ci doit répondre aux exigences de niveau d'API cible de Google Play.

À partir du 31 août 2024:

  • Les nouvelles applications et mises à jour d'applications doivent cibler Android 14 (niveau d'API 34) ou version ultérieure pour être envoyées à Google Play, à l'exception des applications Wear OS et Android TV, qui doivent cibler Android 13 (niveau d'API 33) ou version ultérieure.
  • Les applications existantes doivent cibler Android 13 (niveau d'API 33) ou version ultérieure pour rester disponibles pour les nouveaux utilisateurs se servant d'appareils exécutant une version de l'OS Android supérieure au niveau d'API cible de votre application. Les applications qui ciblent Android 12 (niveau d'API 31) ou version antérieure (Android 10 (niveau d'API 29) ou version antérieure pour Wear OS et Android 11 (niveau d'API 30) ou version antérieure pour Android TV) ne seront disponibles que sur les appareils exécutant l'OS Android identique ou inférieur au niveau d'API cible de votre application.

Si vous avez besoin de plus de temps pour mettre à jour votre application, vous pourrez demander un délai jusqu'au 1er novembre 2024. Vous pourrez accéder aux formulaires de demande de délai pour votre application dans la Play Console plus tard dans l'année.

Il existe quelques exceptions à ces exigences :

  • Applications définitivement privées qui sont limitées aux utilisateurs d'une organisation spécifique et destinées à une distribution interne uniquement.
  • Applications qui ciblent Android Automotive OS ou qui sont empaquetées avec des APK ciblant Android Automotive OS.

Pourquoi cibler des SDK plus récents ?

Chaque nouvelle version d'Android apporte des modifications qui améliorent la sécurité et les performances, ainsi que l'expérience utilisateur. Certaines de ces modifications ne s'appliquent qu'aux applications qui déclarent explicitement la prise en charge via leur attribut de fichier manifeste targetSdkVersion (également appelé niveau d'API cible).

Si vous configurez votre application pour cibler un niveau d'API récent, vous vous assurez que les utilisateurs peuvent bénéficier de ces améliorations, tout en continuant à s'exécuter sur les anciennes versions d'Android. Cibler un niveau d'API récent permet également à votre application de bénéficier des dernières fonctionnalités de la plate-forme pour satisfaire vos utilisateurs. De plus, à partir d'Android 10 (niveau d'API 29), les utilisateurs voient un avertissement au démarrage d'une application pour la première fois si celle-ci cible Android 5.1 (niveau d'API 22) ou version antérieure.

Ce document met en évidence les points importants dont vous devez tenir compte lors de la mise à jour du niveau d'API cible afin de répondre aux exigences de Google Play. Consultez les instructions des sections suivantes, selon la version vers laquelle vous effectuez la migration.

Passer d'Android 12 ou version ultérieure (niveau d'API 31) à une version plus récente

Pour mettre à jour votre application afin qu'elle cible une version plus récente d'Android, suivez la liste des modifications de comportement correspondante:

Passer d'Android 11 (niveau d'API 30) à Android 12 (niveau d'API 31)

Sécurité et autorisations

Expérience utilisateur

  • Notifications personnalisées: les notifications avec des vues de contenu personnalisées n'utilisent plus l'intégralité de la zone de notification. Le système applique à la place un modèle standard. Ce modèle garantit que les notifications personnalisées ont la même décoration que les autres notifications, quel que soit leur état. Ce comportement est presque identique à celui de Notification.DecoratedCustomViewStyle.
  • Modifications apportées à la validation Android App Links: lorsque vous utilisez la validation Android App Links, assurez-vous que vos filtres d'intent incluent la catégorie BROWSABLE et sont compatibles avec le schéma HTTPS.

Performances

  • Restrictions de lancement des services de premier plan: pour cibler Android 12 ou version ultérieure, votre application ne peut pas démarrer de services de premier plan lorsqu'elle s'exécute en arrière-plan, sauf dans quelques cas particuliers. Si une application tente de démarrer un service de premier plan en arrière-plan, une exception se produit (sauf dans les quelques cas particuliers).

    Envisagez d'utiliser WorkManager pour planifier et démarrer des tâches prioritaires pendant que votre application s'exécute en arrière-plan. Pour effectuer des actions urgentes demandées par l'utilisateur, démarrez les services de premier plan dans une alarme exacte.

  • Restrictions liées aux trampolines de notification: lorsque les utilisateurs appuient sur les notifications, certaines applications répondent en lançant un composant d'application qui lance l'activité que l'utilisateur voit et avec laquelle il interagit. Ce composant d'application est appelé trampoline de notification.

    Les applications ne doivent pas démarrer d'activités à partir de services ou de broadcast receivers utilisés comme trampolines de notification. Lorsqu'un utilisateur appuie sur une notification ou un bouton d'action dans la notification, votre application ne peut pas appeler startActivity() dans un service ou un broadcast receiver.

Consultez l'ensemble complet des modifications qui affectent les applications ciblant Android 12 (niveau d'API 31).

Passer à une version antérieure à Android 11 (niveau d'API 30)

Sélectionnez la version d'Android à partir de laquelle vous souhaitez effectuer la migration :

Passer à Android 5 (niveau d'API 21)

Consultez la page relative aux modifications de comportement de chacune des versions suivantes pour vous assurer que votre application a pris en compte les modifications qui y ont été apportées :

Pour continuer, conformez-vous aux instructions de la section suivante.

Passer à Android 6 (niveau d'API 23)

Les considérations suivantes concernent les applications qui ciblent Android 6.0 et les versions ultérieures de la plate-forme :

  • Autorisations d'exécution

    • Les autorisations dangereuses ne sont accordées qu'au moment de l'exécution. Les chemins de navigation de l'UI doivent fournir des affordances pour l'octroi de ces autorisations.

    • Dans la mesure du possible, assurez-vous que votre application est prête à traiter le refus des demandes d'autorisation. Par exemple, si un utilisateur refuse une demande d'accès au GPS de l'appareil, votre application doit disposer d'une autre façon de procéder.

Pour obtenir la liste exhaustive des modifications introduites dans Android 6.0 (niveau d'API 23), consultez la page Changements de comportement de cette version de la plate-forme.

Pour continuer, conformez-vous aux instructions de la section suivante.

Passer à Android 7 (niveau d'API 24)

Les considérations suivantes concernent les applications qui ciblent Android 7.0 et les versions ultérieures de la plate-forme :

  • Sommeil et Mise en veille des applications

    Lors de la conception, vous devez tenir compte des comportements décrits dans la section Adapter votre application aux fonctionnalités Sommeil et Mise en veille des applications, ce qui comprend les modifications incrémentielles introduites dans plusieurs versions de la plate-forme.

    Lorsqu'un appareil est en mode Sommeil et Mise en veille des applications, le système adopte le comportement suivant :

    • Il limite l'accès au réseau.
    • Il diffère les alarmes, les synchronisations et les tâches.
    • Il limite les recherches de réseaux Wi-Fi et de signaux GPS.
    • Limite les messages Firebase Cloud Messaging de priorité normale.
  • Modifications des autorisations

    • Le système limite l'accès aux répertoires privés des applications.
    • L'exposition d'un URI file:// en dehors de votre application déclenche une erreur FileUriExposedException. Si vous devez partager des fichiers en dehors de votre application, implémentez FileProvider.
  • Le système interdit la liaison avec des bibliothèques non NDK.

Pour obtenir la liste exhaustive des modifications introduites dans Android 7.0 (niveau d'API 24), consultez la page Changements de comportement de cette version de la plate-forme.

Pour continuer, conformez-vous aux instructions de la section suivante.

Passer à Android 8 (niveau d'API 26)

Les considérations suivantes concernent les applications qui ciblent Android 8.0 et les versions ultérieures de la plate-forme :

Pour obtenir la liste exhaustive des modifications introduites dans Android 8.0 (niveau d'API 26), consultez la page Changements de comportement de cette version de la plate-forme.

Passer d'Android 8 (niveau d'API 26) à Android 9 (niveau d'API 28)

Pour obtenir la liste exhaustive des modifications introduites dans Android 9.0 (niveau d'API 28), consultez la page Changements de comportement.

Passer d'Android 9 (niveau d'API 28) à Android 10 (niveau d'API 29)

Passer d'Android 10 (niveau d'API 29) à Android 11 (niveau d'API 30)

Pour obtenir la liste exhaustive des modifications introduites dans Android 11 (niveau d'API 30), consultez la page Changements de comportement.

Pour poursuivre la mise à jour vers l'API 31, suivez les instructions de la section précédente.

Modernisez vos applications

Lorsque vous mettez à jour le niveau d'API cible de vos applis, pensez à adopter les fonctionnalités récentes de la plate-forme afin de moderniser vos applis et d'offrir une expérience utilisateur optimale.

  • Envisagez d'utiliser CameraX, qui est en version bêta, pour tirer le meilleur parti de l'appareil photo.
  • Utilisez les composants Jetpack afin de suivre les bonnes pratiques, d'éviter l'écriture de code récurrent et de simplifier les tâches complexes. Vous pouvez ainsi vous concentrer sur le code qui fait la différence.
  • Utilisez Kotlin pour écrire des applications plus performantes plus rapidement, avec moins de code.
  • Veillez à respecter les bonnes pratiques et les exigences en matière de confidentialité.
  • Ajoutez le thème sombre à vos applications.
  • Ajoutez la navigation par gestes à vos applications.
  • Migrez votre application de Google Cloud Messaging (GCM) vers la dernière version de Firebase Cloud Messaging.
  • Profitez de la fonctionnalité de gestion avancée des fenêtres.

Vérifier et mettre à jour vos SDK et vos bibliothèques

Assurez-vous que vos dépendances de SDK tiers sont compatibles avec l'API 31. Certains fournisseurs de SDK la publient dans leur fichier manifeste. D'autres nécessitent un examen supplémentaire. Si vous utilisez un SDK qui n'est pas compatible avec l'API 31, il est essentiel de collaborer avec le fournisseur du SDK pour résoudre le problème.

En outre, notez que le targetSdkVersion de votre application ou de votre jeu peut limiter l'accès aux bibliothèques privées de la plate-forme Android. Pour en savoir plus, consultez Associer des applications NDK à des bibliothèques de plate-forme.

Vous devez également vérifier les restrictions qui peuvent exister dans la version d'Android Support Library que vous utilisez. Comme toujours, vous devez assurer la compatibilité entre la version majeure d'Android Support Library et la version compileSdkVersion de votre application.

Nous vous recommandons de choisir une targetSdkVersion inférieure ou égale à la version majeure de la bibliothèque Support. Nous vous invitons à effectuer une mise à jour vers une version récente et compatible d'Android Support Library afin de bénéficier des dernières fonctionnalités de compatibilité et des corrections de bugs.

Tester votre appli

Après avoir mis à jour le niveau d'API et les fonctionnalités de votre application, vous devez tester certains cas d'utilisation principaux. Les suggestions suivantes ne sont pas exhaustives, mais visent à orienter votre processus de test. pour réaliser votre processus de test :

  • Vérifiez que la compilation de votre application avec l'API 29 s'effectue sans erreurs ni avertissements.
  • Votre application dispose d'une stratégie pour les cas où l'utilisateur refuse les demandes d'autorisation et invite l'utilisateur à accorder des autorisations. Pour ce faire :

    • Accédez à l'écran "Infos sur l'appli" de votre application et désactivez chaque autorisation.
    • Ouvrez l'application et vérifiez l'absence de plantages.
      • Effectuez des tests de cas d'utilisation principaux et assurez-vous que les autorisations requises sont à nouveau demandées.
  • Vérifiez que la fonctionnalité Sommeil génère les résultats attendus et ne provoque aucune erreur.

    • À l'aide d'adb, placez votre appareil de test en mode Sommeil pendant que votre application est en cours d'exécution.
      • Testez les scénarios d'utilisation qui déclenchent des messages Firebase Cloud Messaging, le cas échéant.
      • Testez les scénarios d'utilisation qui font appel à des alarmes ou des tâches, le cas échéant.
      • Éliminez toute dépendance sur les services en arrière-plan.
    • Mettez votre application en veille des applications.
      • Testez les scénarios d'utilisation qui déclenchent des messages Firebase Cloud Messaging, le cas échéant.
      • Testez les scénarios d'utilisation qui font appel à des alarmes, le cas échéant.
  • Vérifiez l'enregistrement de nouvelles photos/vidéos

  • Gère le partage de fichiers avec d'autres applications - Testez tout cas d'utilisation qui partage des données de fichiers avec une autre application (même une autre application du même développeur).

    • Vérifiez que le contenu est visible dans l'autre application et ne déclenche pas de plantage.

Informations supplémentaires

Activez les e-mails dans la Google Play Console afin que nous puissions vous envoyer des informations et des annonces importantes sur Android et Google Play, y compris notre newsletter mensuelle pour les partenaires.