Respecter le niveau d'API cible requis par Google Play

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

À partir du 31 août 2023 :

• Les nouvelles applications doivent cibler Android 13 (niveau d'API 33) ou version ultérieure, à l'exception des applications Wear OS, qui doivent cibler une version comprise entre Android 11 (niveau d'API 30) et Android 13 (niveau d'API 33).

• Les mises à jour d'applications doivent cibler Android 13 ou version ultérieure et s'adapter aux changements de comportement dans Android 13, à l'exception des applications Wear OS, qui doivent cibler Android 11.

Les applications privées de manière permanente (limitées aux utilisateurs d'une organisation spécifique et destinées à une distribution interne uniquement) n'ont pas besoin de répondre aux exigences du niveau d'API cible.

Remarque :Les applications obsolètes ne sont pas disponibles pour les nouveaux utilisateurs d'appareils équipés de versions plus récentes d'Android. Pour en savoir plus, consultez la section "Exigences concernant la disponibilité des applications" de l'article Niveau d'API cible requis pour les applications Google Play dans l'aide de la Play Console.

Pourquoi cibler des SDK plus récents ?

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

Si vous configurez votre application pour qu'elle cible un niveau d'API récent, les utilisateurs pourront bénéficier de ces améliorations, tout en continuant à exécuter votre application sur d'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 verront un avertissement lorsqu'ils démarreront 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. Reportez-vous aux instructions des sections suivantes selon la version vers laquelle vous migrez.

Remarque :Si votre fichier Gradle contient des entrées de fichier manifeste, vous pouvez confirmer ou modifier la valeur actuelle de targetSdkVersion dans le fichier Gradle de votre application, comme décrit dans Configurer votre build. Vous pouvez également utiliser l'attribut android:targetSdkVersion dans le fichier manifeste, comme décrit dans la documentation de l'élément <uses-sdk> du fichier manifeste.

Passer d'Android 12 (niveau d'API 31) à Android 13 (niveau d'API 33)

Pour mettre à jour votre application afin qu'elle cible Android 13, suivez la liste des changements de comportement.

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

Sécurité et autorisations

• Bluetooth: vous devez remplacer les déclarations des autorisations BLUETOOTH et BLUETOOTH_ADMIN par les autorisations BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE ou BLUETOOTH_CONNECT. Vous n'avez plus besoin d'effectuer de demandes d'autorisation d'exécution LOCATION pour les opérations Bluetooth.
• Localisation: les utilisateurs peuvent demander aux applications de ne récupérer que des informations de position approximatives. Vous devez demander l'autorisation ACCESS_COARSE_LOCATION chaque fois que vous demandez ACCESS_FINE_LOCATION.
  • Filtres d'intent: si votre application contient des activités, des services ou des broadcast receivers qui utilisent des filtres d'intent, vous devez déclarer explicitement l'attribut android:exported pour ces composants.
• Hibernation: les applications peuvent passer en mode hibernation si elles ne sont pas utilisées pendant une période donnée. En mode hibernation, les autorisations d'exécution et le cache de votre application sont réinitialisés, et vous ne pouvez pas exécuter de tâches ni d'alertes. Vous pouvez vérifier l'état d'hibernation de votre application.
• Mutabilité des intents en attente: vous devez spécifier la mutabilité de chaque objet PendingIntent créé par votre application.

Expérience utilisateur

• Notifications personnalisées: les notifications avec des vues de contenu personnalisées n'utilisent plus la zone de notification complète. 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 l'é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 alors qu'elle s'exécute 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 l'utilisateur appuie sur les notifications, certaines applications réagissent 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() au sein d'un service ou d'un broadcast receiver.

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

Effectuer une migration depuis 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 :

• Android 5.0 (niveau d'API 21)
• Android 4.4 (niveau d'API 19)
• Android 4.1.x (niveau d'API 16).

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

• Limites d'exécution en arrière-plan
  • Le système limite les services pour les applications qui ne s'exécutent pas au premier plan.
    • startService() génère désormais une exception lorsqu'une application tente de l'appeler alors que startService() est interdit.
    • Pour démarrer les services de premier plan, une application doit utiliser startForeground() et startForegroundService().
    • Examinez attentivement les modifications apportées à l'API JobScheduler, comme indiqué sur la page Changements de comportement d'Android 8.0 (niveau d'API 26).
    • Firebase Cloud Messaging nécessite la version 10.2.1 ou ultérieure du SDK des services Google Play.
    • Lorsque vous utilisez Firebase Cloud Messaging, la distribution des messages est soumise aux limites d'exécution en arrière-plan. Lorsque des tâches en arrière-plan sont nécessaires à la réception du message, par exemple pour effectuer la synchronisation des données en arrière-plan, votre application doit planifier des tâches à l'aide de Firebase Job Dispatcher ou JobIntentService. Pour en savoir plus, consultez la documentation de Firebase Cloud Messaging.
  • Diffusions implicites
    • Les diffusions implicites sont limitées. Pour en savoir plus sur la gestion des événements en arrière-plan, consultez la documentation de l'API JobScheduler.
  • Limites de localisation en arrière-plan
    • Les applications exécutées en arrière-plan ont un accès limité aux données de localisation.
      • Sur les appareils équipés des services Google Play, utilisez le Fused Location Provider pour obtenir des notifications de position périodiques.
• Canaux de notification
  • Vous devez définir des propriétés d'interruption de notification pour chaque canal.
  • Vous devez attribuer les notifications à un canal pour qu'elles s'affichent.
  • Cette version de la plate-forme est compatible avec NotificationCompat.Builder.
• Confidentialité
  • L'accès à ANDROID_ID s'effectue par clé de signature d'application.

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)

• Gestion de l'alimentation
  • Les buckets de mise en veille des applications apportent de nouvelles restrictions en arrière-plan basées sur l'engagement avec les applications, telles que les tâches différées, les alarmes et les quotas sur les messages à priorité élevée
  • Les améliorations de l'économiseur de batterie optimisent les limites associées aux applications de mise en veille d'application
• Autorisation de service de premier plan
  • Besoin de demander l'autorisation normale FOREGROUND_SERVICE (et non l'autorisation d'exécution)
• Modifications des paramètres de confidentialité
  • Accès limité aux capteurs en arrière-plan
  • Accès limité aux journaux d'appels désormais dans le groupe d'autorisations CALL_LOG
  • Restriction d'accès aux numéros de téléphone, qui nécessite l'autorisation READ_CALL_LOG
  • Restriction d'accès aux informations Wi-Fi

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)

• Notifications avec intent plein écran
  • Besoin de demander l'autorisation normale USE_FULL_SCREEN_INTENT (et non l'autorisation d'exécution)
• Compatibilité avec les appareils pliables et les grands écrans
  • Plusieurs activités peuvent désormais être réactivées en même temps, mais une seule est ciblée
    • Cette modification affecte le comportement de onResume() et de onPause()
    • Nouveau concept de cycle de vie ("application la plus réactivée") que vous pouvez détecter en vous abonnant à onTopResumedActivityChanged()
      • Seule une seule activité peut être l'activité la plus réactivée
  • Lorsque resizeableActivity est défini sur false, les applications peuvent également spécifier un élément minAspectRatio qui applique automatiquement un format letterbox à l'application avec des proportions plus étroites.
• Modifications des paramètres de confidentialité
  • Espace de stockage cloisonné
    • L'accès au stockage externe est limité à un répertoire spécifique à l'application et à des types de supports spécifiques créés par l'application.
  • Accès limité à la position lorsque l'application est exécutée en arrière-plan, ce qui nécessite l'autorisation ACCESS_BACKGROUND_LOCATION.
  • Accès limité à des identifiants non réinitialisables tels que le code IMEI et le numéro de série.
  • Accès limité à des informations sur l'activité physique telles que le nombre de pas de l'utilisateur, ce qui nécessite l'autorisation ACTIVITY_RECOGNITION.
  • Restriction de l'accès à certaines API de téléphonie, Bluetooth et Wi-Fi, qui nécessitent l'autorisation ACCESS_FINE_LOCATION.
  • Restriction de l'accès aux paramètres Wi-Fi
    • Les applications ne peuvent plus activer ni désactiver directement le Wi-Fi, et doivent le faire à l'aide des panneaux de paramètres.
    • Restrictions concernant l'établissement d'une connexion à un réseau Wi-Fi, qui nécessite l'utilisation de WifiNetworkSpecifier ou de WifiNetworkSuggestion.

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

• Confidentialité
  • Application de l'espace de stockage cloisonné : les applis doivent adopter le modèle d'espace de stockage cloisonné, dans lequel les types de fichiers spécifiques aux applis, aux contenus multimédias et aux autres types de fichiers sont enregistrés et accessibles à l'aide d'emplacements dédiés.
  • Réinitialisation automatique des autorisations: si les utilisateurs n'ont pas interagi avec une application depuis plusieurs mois, le système réinitialise automatiquement les autorisations sensibles de l'application. Cela ne devrait pas affecter la plupart des applications. Si votre application fonctionne principalement en arrière-plan sans interaction utilisateur, vous pouvez demander aux utilisateurs de désactiver la réinitialisation automatique.
  • Accès à la localisation en arrière-plan: les applications doivent demander séparément l'autorisation d'accéder à la position au premier plan et en arrière-plan. Vous ne pouvez accorder l'accès à la localisation en arrière-plan que dans les paramètres de l'application et non dans les boîtes de dialogue d'autorisation d'exécution.
  • Visibilité des packages: lorsqu'une application demande la liste des applications et services installés sur l'appareil, la liste renvoyée est filtrée.
    • Si vous utilisez les services de synthèse vocale ou de reconnaissance vocale, vous devez ajouter au fichier manifeste des éléments de requête correspondant à ces services.
• Sécurité
  • Les fichiers "resource.arsc" compressés ne sont plus acceptés
  • APK Signature Scheme v2 est désormais obligatoire. Pour des raisons de rétrocompatibilité, les développeurs doivent également continuer à proposer la signature avec APK Signature Scheme v1.
  • Restriction des interfaces autres que les SDK. L'utilisation d'interfaces non SDK n'est pas recommandée pour les applications ciblant le niveau d'API 30, car certaines de ces interfaces non SDK sont désormais bloquées. Consultez Interfaces non SDK désormais bloquées dans Android 11 pour obtenir la liste complète des interfaces non SDK bloquées.

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.

• Pensez à 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.
  • Acceptez des formats plus grands (supérieurs à 16:9) pour bénéficier des dernières avancées matérielles. Assurez-vous que votre application est redimensionnée pour occuper l'espace disponible à l'écran. Ne déclarez un format maximal qu'en dernier recours. Pour en savoir plus sur les formats maximaux, consultez Déclarer une compatibilité d'écran limitée.
  • Ajoutez le mode multifenêtre pour aider votre application à augmenter la productivité et à gérer plusieurs écrans.
  • Si une excellente expérience d'application réduite est susceptible d'améliorer l'expérience utilisateur, ajoutez la prise en charge du Picture-in-picture.
    • Optimisez l'application pour les appareils avec encoche pour écran.
    • Ne partez pas de la hauteur de la barre d'état. Utilisez plutôt WindowInsets et View.OnApplyWindowInsetsListener. Regardez la vidéo droidcon NYC 2017 pour en savoir plus.
    • Ne partez pas du principe que l'application occupe toute la fenêtre. Confirmez plutôt son emplacement en utilisant View.getLocationInWindow(), et non View.getLocationOnScreen(). * Lors du traitement de MotionEvent, utilisez MotionEvent.getX() et MotionEvent.getY(), et non MotionEvent.getRawX() ni MotionEvent.getRawY().

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

Assurez-vous que vos dépendances de SDK tierces sont compatibles avec l'API 31. Certains fournisseurs de SDK la publient dans leur fichier manifeste, tandis que d'autres nécessitent un examen supplémentaire. Si vous utilisez un SDK qui n'est pas compatible avec l'API 31, adressez-vous en priorité au 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 de plate-forme Android privées. Pour en savoir plus, consultez Association d'applications NDK à des bibliothèques de plate-forme.

Vous devez également vérifier les éventuelles restrictions dans la version de la bibliothèque Android Support que vous utilisez. Comme toujours, vous devez assurer la compatibilité entre la version majeure d'Android Support Library et le 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 application

Après avoir mis à jour le niveau d'API et les fonctionnalités de votre application, le cas échéant, vous devez tester certains cas d'utilisation principaux. Les suggestions suivantes ne sont pas exhaustives, mais visent à guider 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.

• Assurez-vous que votre application dispose d'une stratégie pour les cas où l'utilisateur refuse les demandes d'autorisation et qu'il 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 les tests des principaux cas d'utilisation 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, passez votre appareil de test en mode Sommeil pendant l'exécution de votre application.
    • 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.
  • Définissez 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

  • Vérifiez que votre application gère correctement les diffusions limitées ACTION_NEW_PICTURE et ACTION_NEW_VIDEO (elles ont été déplacées vers les tâches JobScheduler).
  • Assurez-vous que tous les cas d'utilisation critiques qui dépendent de ces événements fonctionnent toujours.

• Gère le partage de fichiers avec d'autres applications - Testez tous les cas d'utilisation qui partagent 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 depuis Android et Google Play, y compris notre newsletter mensuelle pour les partenaires.