Nous lançons aujourd'hui la première version bêta d' Android 17, poursuivant ainsi nos efforts pour créer une plate-forme qui privilégie la confidentialité, la sécurité et des performances améliorées. Cette version poursuit notre travail pour des applications Android plus adaptables, introduit des améliorations significatives des fonctionnalités de l'appareil photo et des contenus multimédias, de nouveaux outils pour optimiser la connectivité et des profils étendus pour les appareils associés. Cette version met également en évidence un changement fondamental dans la façon dont nous proposons de nouvelles versions à la communauté des développeurs, en passant du modèle traditionnel de version Preview développeur au programme Android Canary

Au-delà de la version Preview développeur

Android a remplacé la version Preview développeur traditionnelle par un canal Canary continu. Ce nouveau modèle "toujours activé" offre trois avantages principaux :

• Accès plus rapide : les fonctionnalités et les API sont disponibles dans Canary dès qu'elles réussissent les tests internes, au lieu d'attendre une version trimestrielle.
• Meilleure stabilité : les premiers tests en conditions réelles dans Canary permettent d'offrir une expérience bêta plus aboutie avec de nouvelles API et des modifications de comportement plus proches de la version finale.
• Tests plus faciles : Canary est compatible avec les mises à jour OTA (plus besoin de flasher manuellement) et, en tant que canal de mise à jour distinct, s'intègre plus facilement aux workflows d'intégration continue. Il vous offre également la possibilité de fournir des commentaires immédiats sur les modifications potentielles à venir.

Calendrier d'Android 17

Nous allons passer rapidement de cette version bêta à notre jalon de stabilité de la plate-forme, prévu pour mars. À ce stade, nous fournirons les API SDK/NDK finales et les comportements dans les applications largement définitifs. Vous disposerez ensuite de plusieurs mois avant la version finale pour effectuer vos tests.

Une année de versions

Nous prévoyons qu'Android 17 continuera de recevoir des mises à jour dans une série de versions trimestrielles. La prochaine version du deuxième trimestre sera la seule dans laquelle nous introduirons des modifications de comportement planifiées qui interrompront les applications. Nous prévoyons de publier une version mineure du SDK au quatrième trimestre avec des API et des fonctionnalités supplémentaires.

Restrictions d'orientation et de redimensionnement

Avec la sortie de la version bêta d'Android 17, nous passons à la phase suivante de notre feuille de route adaptative : Android 17 (niveau d'API 37) supprime la désactivation par les développeurs des restrictions d'orientation et de redimensionnement sur les appareils à grand écran (largeur d'écran > 600 dp).

Lorsque votre application cible le SDK 37, elle doit être prête à s'adapter. Les utilisateurs s'attendent à ce que leurs applications fonctionnent partout, qu'ils effectuent plusieurs tâches sur une tablette, qu'ils déplient un appareil ou qu'ils utilisent un environnement de fenêtrage de bureau. Ils s'attendent également à ce que l'interface utilisateur remplisse l'espace et respecte la position de leur appareil.

Principales modifications pour le SDK 37

Les applications ciblant Android 17 doivent assurer la compatibilité avec la suppression progressive des attributs de fichier manifeste et des API d'exécution introduits dans Android 16. Lorsqu'elles s'exécutent sur un grand écran (dimension la plus petite ≥ 600 dp), les attributs et API suivants sont ignorés :

Exemptions et contrôle utilisateur

Ces modifications sont spécifiques aux grands écrans. Elles ne s'appliquent pas aux écrans plus petits que sw600dp (y compris les téléphones au format ardoise traditionnel). De plus, les applications classées comme jeux (en fonction de l'indicateur android:appCategory) sont exemptées de ces restrictions.

Il est également important de noter que les utilisateurs conservent le contrôle. Ils peuvent activer ou désactiver explicitement le comportement par défaut d'une application via les paramètres de format du système.

Modifications de la configuration

Pour améliorer la compatibilité des applications et réduire au minimum les interruptions de la lecture vidéo, les pertes d'entrée et d'autres types de perte d'état perturbateurs, nous modifions le comportement par défaut de la recréation d'activité. À partir d'Android 17, le système ne redémarrera plus les activités par défaut pour certaines modifications de configuration qui ne nécessitent généralement pas de recréation de l'interface utilisateur, y compris CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE (lorsque seul UI_MODE_TYPE_DESK est modifié), CONFIG_TOUCHSCREEN, et CONFIG_COLOR_MODE. Au lieu de cela, les activités en cours recevront simplement ces mises à jour via onConfigurationChanged.Si votre application repose sur un redémarrage complet pour recharger les ressources de ces modifications, vous devez maintenant activer explicitement le nouvel attribut de fichier manifeste android:recreateOnConfigChanges, qui vous permet de spécifier les modifications de configuration qui doivent déclencher un cycle de vie d'une activité complet (de l'arrêt à la destruction, puis à la recréation), ainsi que les constantes associées mcc, mnc, et les nouvelles constantes keyboard, keyboardHidden, navigation, touchscreen et colorMode.

Préparer votre application

Nous avons publié des outils et de la documentation pour vous faciliter la tâche. Notre article de blog dédié fournit plus de conseils, avec des stratégies pour résoudre les problèmes courants. Les applications devront être compatibles avec les mises en page en mode paysage et portrait pour les tailles de fenêtre sur toute la gamme de formats, car la restriction de l'orientation ou du format ne sera plus une option. Nous vous recommandons de tester votre application à l'aide de la version bêta 1 d'Android 17 avec les émulateurs Pixel Tablet ou Pixel Fold (configurés sur targetSdkPreview = "CinnamonBun") ou en utilisant le framework de compatibilité des applications pour activer UNIVERSAL_RESIZABLE_BY_DEFAULT sur les appareils Android 16.

Performances

MessageQueue sans verrouillage

Dans Android 17, les applications ciblant le SDK 37 ou une version ultérieure recevront une nouvelle implémentation d' android.os.MessageQueue où l'implémentation est sans verrouillage. La nouvelle implémentation améliore les performances et réduit le nombre d'images manquées, mais peut interrompre les clients qui reflètent les champs et méthodes privés de MessageQueue.

Récupération de mémoire générationnelle

Android 17 introduit la récupération de mémoire générationnelle dans le collecteur Concurrent Mark-Compact d'ART. Cette optimisation introduit des collectes de jeunes générations plus fréquentes et moins gourmandes en ressources, ainsi que des collectes de tas complets. L'objectif est de réduire le coût et la durée globale de la récupération de mémoire en termes de processeur. Les améliorations d'ART sont également disponibles sur plus d'un milliard d'appareils équipés d'Android 12 (niveau d'API 31) ou version ultérieure grâce aux mises à jour du système Google Play.

Les champs finaux statiques sont désormais réellement finaux

À partir d'Android 17, les applications ciblant Android 17 ou une version ultérieure ne pourront plus modifier les champs "static final", ce qui permettra à l'environnement d'exécution d'appliquer des optimisations de performances de manière plus agressive. Toute tentative de modification via la réflexion (et la réflexion approfondie) entraînera toujours la levée d'une exception IllegalAccessException. La modification via la famille de méthodes SetStatic<Type>Field de JNI entraînera immédiatement le plantage de l'application.

Restrictions d'affichage des notifications personnalisées

Pour réduire l'utilisation de la mémoire, nous limitons la taille des vues de notification personnalisées. Cette mise à jour corrige une faille qui permet aux applications de contourner les limites existantes à l'aide d'URI. Ce comportement est limité par la version du SDK cible et prend effet pour les applications ciblant l'API 37 et les versions ultérieures.

Nouveaux déclencheurs ProfilingManager pour le débogage des performances

Nous avons introduit plusieurs nouveaux déclencheurs système dans ProfilingManager pour vous aider à collecter des données détaillées afin de déboguer les problèmes de performances. Ces déclencheurs sont TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM, et TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE.

Pour savoir comment configurer les nouveaux déclencheurs système, consultez la documentation sur le profilage basé sur les déclencheurs, ainsi que sur la récupération et l'analyse des données de profilage.

Multimédia et appareil photo

Android 17 apporte des outils de qualité professionnelle aux applications multimédias et d'appareil photo, avec des fonctionnalités telles que des transitions fluides et une intensité sonore standardisée.

Mises à jour dynamiques des sessions de l'appareil photo

Nous avons introduit updateOutputConfigurations() dans CameraCaptureSession. Cela vous permet d'associer et de dissocier dynamiquement des surfaces de sortie sans avoir à reconfigurer l'intégralité de la session de capture de l'appareil photo. Cette modification permet des transitions fluides entre les cas d'utilisation et les modes de l'appareil photo (par exemple, la prise de photos par rapport à l'enregistrement de vidéos) sans le coût de mémoire ni la complexité du code liés à la configuration et à la conservation de toutes les surfaces de sortie de l'appareil photo dont votre application pourrait avoir besoin au démarrage de l'appareil photo. Cela permet d'éliminer les problèmes ou les blocages visibles par l'utilisateur pendant le fonctionnement.

fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs:  List<OutputConfiguration>)) {
    // Dynamically update the session without closing and reopening
    try {
        
        // Update the output configurations
        session.updateOutputConfigurations(newOutputConfigs)
    } catch (e: CameraAccessException) {
        // Handle error
    }
}

Métadonnées logiques des appareils multi-caméras

Lorsque vous utilisez des caméras logiques qui combinent plusieurs capteurs de caméra physiques, vous pouvez désormais demander des métadonnées supplémentaires à toutes les caméras physiques actives impliquées dans une capture, et pas seulement à la caméra principale. Auparavant, vous deviez implémenter des solutions de contournement, en allouant parfois des flux physiques inutiles, pour obtenir des métadonnées à partir de caméras actives secondaires (par exemple, lors d'un changement d'objectif pour le zoom lorsqu'une caméra de suivi est active). Cette fonctionnalité introduit une nouvelle clé, LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS, dans CaptureRequest et CaptureResult. Si vous définissez cette clé sur ON dans votre CaptureRequest, le TotalCaptureResult inclura les métadonnées de ces caméras physiques actives supplémentaires. Vous pouvez accéder à ces métadonnées complètes à l'aide de TotalCaptureResult.getPhysicalCameraTotalResults() pour obtenir des informations plus détaillées qui peuvent vous permettre d'optimiser l'utilisation des ressources dans vos applications d'appareil photo.

Compatibilité avec le codage vidéo polyvalent (VVC)

Android 17 est compatible avec la norme Versatile Video Coding (VVC). Cela inclut la définition du type MIME video/vvc dans MediaFormat, l'ajout de nouveaux profils VVC dans MediaCodecInfo et l'intégration de la compatibilité dans MediaExtractor. Cette fonctionnalité sera disponible sur les appareils compatibles avec le décodage matériel et les pilotes.

Qualité constante pour l'enregistrement vidéo

Nous avons ajouté setVideoEncodingQuality() à MediaRecorder. Cela vous permet de configurer un mode de qualité constante (CQ) pour les encodeurs vidéo, ce qui vous offre un contrôle plus précis de la qualité vidéo au-delà des simples paramètres de débit binaire.

Renforcement de l'audio en arrière-plan

À partir d'Android 17, le framework audio appliquera des restrictions sur les interactions audio en arrière-plan, y compris la lecture audio, les requêtes de priorité audio et les API de modification du volume pour s'assurer que ces modifications sont lancées intentionnellement par l'utilisateur. 

Si l'application tente d'appeler des API audio alors qu'elle ne se trouve pas dans un cycle de vie valide, les API de lecture audio et de modification du volume échoueront en mode silencieux sans qu'aucune exception ni aucun message d'échec ne soient fournis. L'API de focus audio échouera avec le code de résultat AUDIOFOCUS_REQUEST_FAILED.

Confidentialité et sécurité

Obsolescence de l'attribut de trafic en texte clair

L'attribut android:usesCleartextTraffic est désormais obsolète. Si votre application cible (Android 17) ou une version ultérieure et repose sur usesCleartextTraffic="true" sans configuration de sécurité réseau correspondante, le trafic en texte clair sera désactivé par défaut. Nous vous encourageons à migrer vers des fichiers de configuration de sécurité réseau pour un contrôle précis.

Cryptographie hybride HPKE

Nous introduisons une interface de fournisseur de services (SPI) publique pour une implémentation de la cryptographie hybride HPKE, permettant une communication sécurisée à l'aide d'une combinaison de chiffrement à clé publique et symétrique (AEAD).

Connectivité et télécommunications

Historique des appels VoIP amélioré

Nous introduisons la gestion des préférences utilisateur pour l'intégration de l'historique des appels VoIP des applications. Cela inclut la prise en charge des URI d'avatar de l'appelant et du participant dans le numéroteur système, ce qui permet aux utilisateurs de contrôler précisément la confidentialité de l'historique des appels et d'enrichir l'affichage visuel des journaux d'appels VoIP intégrés.

Portée et proximité Wi-Fi

La portée Wi-Fi a été améliorée avec de nouvelles fonctionnalités de détection de proximité, qui prennent en charge la portée continue et la découverte sécurisée de pair à pair. Les mises à jour de la portée Wi-Fi Aware incluent de nouvelles API pour les handles de pairs et la mise en cache PMKID pour la portée sécurisée 11az.

Productivité et outils pour les développeurs

Mises à jour pour les applications associées d'appareils

Nous avons introduit deux nouveaux profils dans le CompanionDeviceManager pour améliorer la distinction des appareils et la gestion des autorisations :

• Appareils médicaux : ce profil permet aux applications mobiles d'appareils médicaux de demander toutes les autorisations nécessaires en un seul geste, ce qui simplifie le processus de configuration.
• Bracelets d'activité sport : le profil DEVICE_PROFILE_FITNESS_TRACKER permet aux applications associées d'indiquer explicitement qu'elles gèrent un bracelet d'activité sport. Cela garantit des expériences utilisateur précises avec des icônes distinctes tout en réutilisant les autorisations de rôle de montre existantes.

De plus, le CompanionDeviceManager propose désormais une boîte de dialogue unifiée pour l'association d'appareils et les demandes d'autorisation "À proximité". Vous pouvez tirer parti de la nouvelle méthode setExtraPermissions dans AssociationRequest.Builder pour regrouper les invites d'autorisation "À proximité" dans le flux d'association existant, ce qui réduit le nombre de boîtes de dialogue présentées à l'utilisateur.

Premiers pas avec Android 17

Vous pouvez inscrire n'importe quel appareil Pixel compatible pour recevoir cette version et les futures mises à jour bêta d'Android par voie hertzienne. Si vous ne possédez pas d'appareil Pixel, vous pouvez utiliser les images système 64 bits avec Android Emulator dans Android Studio.

Si vous participez actuellement au programme Android Bêta, vous recevrez une mise à jour OTA vers la version bêta 1.

Si vous disposez de la version bêta d'Android 26Q1 et que vous souhaitez utiliser la version stable finale de 26Q1 et quitter la version bêta, vous devez ignorer la mise à jour OTA vers la version bêta 1 de 26Q2 et attendre la sortie de 26Q1.

Nous sommes à l'écoute de vos commentaires. Veuillez donc signaler les problèmes et envoyer des demandes de fonctionnalités sur la page de commentaires. Plus tôt nous recevrons vos commentaires, plus nous pourrons en inclure dans notre travail sur la version finale.

Pour une expérience de développement optimale avec Android 17, nous vous recommandons d'utiliser la dernière version preview de Android Studio (Panda). Une fois la configuration terminée, voici quelques actions à effectuer :

• Compilez le nouveau SDK, testez-le dans des environnements d'intégration continue et signalez tout problème dans notre outil de suivi sur la page de commentaires.
• Testez la compatibilité de votre application actuelle, déterminez si elle est affectée par les modifications apportées à Android 17, installez-la sur un appareil ou un émulateur exécutant Android 17 et testez-la de manière approfondie.

Nous mettrons régulièrement à jour les images système preview/bêta et le SDK tout au long du cycle de publication d'Android 17. Une fois que vous avez installé une version bêta, vous recevrez automatiquement les futures mises à jour OTA pour toutes les versions preview et bêta ultérieures.

Pour obtenir des informations complètes, consultez le site pour les développeurs Android 17.

Participez à la discussion

Alors que nous nous dirigeons vers la stabilité de la plate-forme et la version stable finale d'Android 17 plus tard cette année, vos commentaires restent notre atout le plus précieux. Que vous soyez un utilisateur précoce sur le canal Canary ou un développeur d'applications testant la version bêta 1, pensez à rejoindre nos communautés et à envoyer des commentaires. Nous sommes à votre écoute.