Respecter le niveau d'API cible requis par Google Play

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Lorsque vous importez un fichier APK, il doit respecter le niveau d'API cible requis par Google Play.

À partir du 31 août 2024 :

• Les nouvelles applications et mises à jour d'application 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 accessibles aux nouveaux utilisateurs se servant d'appareils équipés d'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 équipés d'un OS Android identique ou anté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 supplémentaire jusqu'au 1er novembre 2024. Vous trouverez les formulaires de demande pour votre application dans la Play Console plus tard dans l'année.

Il existe quelques exceptions à ces exigences :

• Applications définitivement privées 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 renforcent la sécurité, améliorent les performances et optimisent l'expérience utilisateur Android. Certaines de ces modifications ne concernent que les applications qui déclarent explicitement la compatibilité via leur attribut de manifeste targetSdkVersion (connu également sous le nom de niveau d'API cible).

En configurant votre application pour qu'elle cible un niveau d'API récent, vous permettez aux utilisateurs de bénéficier de ces améliorations, et votre application peut toujours s'exécuter sur les anciennes versions d'Android. Cibler un niveau d'API récent permet également à votre application de tirer parti 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 lorsqu'ils lancent 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, en fonction de 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 appropriée:

• Changements de comportement d'Android 13
• Changements de comportement d'Android 14
• Changements de comportement d'Android 15
• Changements de comportement d'Android 16

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 pour les autorisations BLUETOOTH et BLUETOOTH_ADMIN par les autorisations BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE ou BLUETOOTH_CONNECT. Vous n'avez plus besoin de demander des autorisations d'exécution LOCATION pour les opérations Bluetooth.
• Localisation: les utilisateurs peuvent demander aux applications de récupérer uniquement des informations de localisation 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 au cours d'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é de l'intent en attente: vous devez spécifier la mutabilité de chaque objet PendingIntent que votre application crée.

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 qu'ils 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 pendant l'exécution en arrière-plan, une exception se produit (sauf dans les quelques cas particuliers mentionnés).

  Envisagez d'utiliser WorkManager pour planifier et commencer 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 déclenchent un composant 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 ni de broadcast receivers utilisés comme trampolines de notification. Lorsqu'un utilisateur appuie sur une notification ou sur un bouton d'action dans une 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).

Moderniser 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 exploiter tout le potentiel de la fonctionnalité de caméra/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.
• Faites migrer 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 de plus grands formats (supérieurs à 16:9) pour bénéficier des progrès récents sur le plan matériel. Assurez-vous que votre application redimensionne l'affichage pour occuper l'espace disponible à l'écran. Ne déclarez un format maximum qu'en dernier recours. Pour en savoir plus sur les formats maximums, consultez la section Déclarer une compatibilité d'écran limitée.
  • Proposez le mode multifenêtre pour contribuer à améliorer la productivité de votre application et gérer plusieurs écrans.
  • Si l'utilisation d'une taille d'appli réduite est susceptible d'améliorer sensiblement l'expérience utilisateur, ajoutez la prise en charge de la fonctionnalité Picture-in-picture.
    • Optimisez l'application pour les appareils avec encoche pour écran.
    • Ne laissez pas la hauteur de la barre d'état au hasard. Utilisez plutôt WindowInsets et View.OnApplyWindowInsetsListener. Pour en savoir plus, regardez la vidéo de la conférence droidcon NYC 2017.
    • Ne partez pas du principe que l'application occupe toute la fenêtre. Confirmez plutôt son emplacement à l'aide de View.getLocationInWindow(), et non de 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. Pour d'autres, un examen complémentaire est nécessaire. 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.

Notez également que l'attribut targetSdkVersion de votre application ou de votre jeu peut limiter l'accès à des bibliothèques de plate-forme Android privées. Pour plus d'informations, reportez-vous à la section Association d'applications NDK à des bibliothèques de plate-forme.

Vous devez également valider les éventuelles restrictions définies dans la version d'Android Support Library que vous utilisez. Comme toujours, vous devez vous assurer de la compatibilité entre la version principale d'Android Support Library et la version compileSdkVersion de votre application.

Nous vous recommandons de choisir une version targetSdkVersion inférieure ou égale à la version principale de la bibliothèque d'assistance. 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 les fonctionnalités et le niveau d'API de votre application, vous devez tester quelques scénarios d'utilisation principaux. Les suggestions suivantes ne sont pas exhaustives, mais visent à vous guider dans 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.

• Vérifiez que votre application dispose d'une stratégie pour les cas où l'utilisateur refuse les demandes d'autorisation et qu'elle demande des autorisations à l'utilisateur. Voici la marche à suivre :

  • 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 d'utilisation et vérifiez 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, mettez votre appareil de test en mode Sommeil pendant que votre application s'exécute.
    • 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 mode Mise 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 ACTION_NEW_PICTURE et ACTION_NEW_VIDEO restreintes (qui devraient être déplacées vers les tâches JobScheduler).
  • Assurez-vous que les scénarios d'utilisation critiques qui dépendent de ces événements continuent de fonctionner.

• Gère le partage de fichiers avec d'autres applications. - Testez tout scénario d'utilisation dans lequel des fichiers sont partagés avec d'autres applications (y compris une autre application du même développeur).

  • Vérifiez si le contenu est visible dans l'autre application et ne provoque pas de plantages.

Informations supplémentaires

Activez les e-mails dans la console Google Play afin que nous puissions vous envoyer des mises à jour et des annonces importantes depuis Android et Google Play, y compris notre newsletter mensuelle pour les partenaires.