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

Au-delà de la version Preview développeur

Android a remplacé la traditionnelle "Developer Preview" par un canal Canary continu. Ce nouveau modèle "always-on" présente trois avantages principaux :

• Accès plus rapide : les fonctionnalités et les API sont disponibles dans Canary dès qu'elles ont passé les tests internes, sans attendre une version trimestrielle.
• Meilleure stabilité : les premiers tests dans Canary permettent d'obtenir une expérience bêta plus aboutie, avec de nouvelles API et des modifications de comportement qui sont presque définitives.
• Tests plus faciles : Canary est compatible avec les mises à jour OTA (Over-The-Air), ce qui évite le flashage manuel. En tant que canal de mise à jour distinct, il s'intègre plus facilement aux workflows CI et vous permet de donner immédiatement votre avis sur les changements potentiels à 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. À cette étape, nous fournirons les API SDK/NDK finales et les comportements pour les applications qui seront en grande partie définitifs. Vous aurez alors plusieurs mois pour effectuer vos tests avant la version finale.

Un an de sorties

Nous prévoyons de continuer à mettre à jour Android 17 dans une série de versions trimestrielles. La prochaine version du deuxième trimestre est la seule dans laquelle nous introduisons des modifications de comportement planifiées qui peuvent affecter 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 concernant l'orientation et le 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 l'option de désactivation pour les développeurs concernant les restrictions d'orientation et de redimensionnement sur les appareils à grand écran (sw > 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 fassent du multitâche sur une tablette, qu'ils déplient un appareil ou qu'ils utilisent un environnement de fenêtrage sur ordinateur. Ils s'attendent également à ce que l'UI remplisse l'espace et respecte la position de leur appareil.

Principaux changements pour le SDK 37

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

Exemptions et contrôle par l'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 traditionnels au format ardoise). De plus, les applications classées comme jeux (en fonction du tag android:appCategory) sont exemptées de ces restrictions.

Il est également important de noter que les utilisateurs gardent 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 apportées aux changements de configuration

Pour améliorer la compatibilité des applications et réduire les interruptions de lecture vidéo, les pertes d'entrée et d'autres types de perte d'état perturbateurs, nous mettons à jour 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éer l'UI, 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. Les activités de course à pied recevront simplement ces mises à jour via onConfigurationChanged. Si votre application s'appuie sur un redémarrage complet pour recharger les ressources de ces modifications, vous devez désormais l'activer explicitement à l'aide du nouvel attribut de fichier manifeste android:recreateOnConfigChanges, qui vous permet de spécifier les changements de configuration qui doivent déclencher un cycle de vie d'activité complet (de l'arrêt à la destruction et à la recréation), ainsi que les constantes associées mcc, mnc et les nouvelles keyboard, keyboardHidden, navigation, touchscreen et colorMode.

Préparer votre application

Nous avons mis à votre disposition des outils et de la documentation pour vous faciliter la tâche. Pour obtenir d'autres conseils et des stratégies pour résoudre les problèmes courants, consultez notre article de blog dédié. Les applications devront être compatibles avec les mises en page en mode paysage et portrait pour les tailles de fenêtre couvrant toute la gamme de formats. Il ne sera plus possible de limiter l'orientation ou le format. 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 à l'aide du 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 de android.os.MessageQueue, où l'implémentation est sans verrouillage. La nouvelle implémentation améliore les performances et réduit les images manquantes, mais peut casser les clients qui réfléchissent sur 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 récupérateur Mark-Compact simultané d'ART. Cette optimisation introduit des collectes de mémoire de jeune génération plus fréquentes et moins gourmandes en ressources, en plus des collectes de tas complets. L'objectif est de réduire le coût CPU et la durée globale de la récupération de mémoire. Grâce aux mises à jour du système Google Play, les améliorations apportées à ART sont également disponibles sur plus d'un milliard d'appareils équipés d'Android 12 (niveau d'API 31) ou version ultérieure.

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

À partir d'Android 17, les applications ciblant Android 17 ou version ultérieure ne pourront pas 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 le faire par réflexion (et réflexion approfondie) entraînera toujours une exception IllegalAccessException. Si vous les modifiez à l'aide de la famille de méthodes SetStatic<Type>Field de JNI, l'application plantera immédiatement.

Restrictions concernant l'affichage des notifications personnalisées

Pour réduire l'utilisation de la mémoire, nous limitons la taille des vues de notifications personnalisées. Cette mise à jour comble une faille qui permet aux applications de contourner les limites existantes à l'aide d'URI. Ce comportement est contrôlé par la version du SDK cible et s'applique aux applications ciblant l'API 37 ou une version ultérieure.

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 et 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 caméras

Nous avons ajouté updateOutputConfigurations() à CameraCaptureSession. Cela vous permet d'attacher et de détacher dynamiquement des surfaces de sortie sans avoir à reconfigurer l'intégralité de la session de capture de la caméra. Cette modification permet des transitions fluides entre les cas d'utilisation et les modes de l'appareil photo (par exemple, prendre des photos ou des 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 du dispositif multicaméra logique

Lorsque vous travaillez avec des caméras logiques qui combinent plusieurs capteurs de caméras 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 codec VVC (Versatile Video Coding)

Android 17 est désormais 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 prise en charge dans MediaExtractor. Cette fonctionnalité sera disponible sur les appareils compatibles avec le décodage matériel et disposant de pilotes adaptés.

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 donne un contrôle plus précis sur la qualité vidéo au-delà des simples paramètres de débit.

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 focus audio et les API de modification du volume, afin de 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 échouent silencieusement, 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 s'appuie sur usesCleartextTraffic="true" sans configuration de sécurité réseau correspondante, le trafic en texte clair sera interdit par défaut. Nous vous encourageons à migrer vers les fichiers de configuration de la sécurité réseau pour un contrôle précis.

Cryptographie hybride HPKE

Nous lançons une interface SPI (Service Provider Interface) publique pour une implémentation de la cryptographie hybride HPKE, qui permet 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 lançons 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 des participants dans le composeur 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 mesure de distance Wi-Fi a été améliorée avec de nouvelles fonctionnalités de détection de proximité, qui permettent une mesure de distance continue et une découverte sécurisée de pair à pair. Les mises à jour de la mesure de distance Wi-Fi Aware incluent de nouvelles API pour les identifiants de pairs et la mise en cache PMKID pour la mesure de distance sécurisée 11az.

Productivité et outils pour les développeurs

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

Nous avons ajouté deux nouveaux profils au CompanionDeviceManager pour mieux distinguer les appareils et gérer les autorisations :

• Appareils médicaux : ce profil permet aux applications mobiles pour appareils médicaux de demander toutes les autorisations nécessaires en un seul geste, ce qui simplifie le processus de configuration.
• Bracelets d'activité : le profil DEVICE_PROFILE_FITNESS_TRACKER permet aux applications associées d'indiquer explicitement qu'elles gèrent un bracelet d'activité. Cela garantit une expérience utilisateur précise avec des icônes distinctes tout en réutilisant les autorisations de rôle de spectateur 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 utiliser 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 mise à jour et les futures mises à jour Android bêta par voie hertzienne. Si vous ne possédez pas d'appareil Pixel, vous pouvez utiliser les images système 64 bits avec l'émulateur Android 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 d'Android 26Q1 bêta et que vous souhaitez obtenir la version stable finale de 26Q1 et quitter la version bêta, vous devez ignorer la mise à jour OTA vers 26Q2 bêta 1 et attendre la sortie de 26Q1.

Nous aimerions connaître votre avis. N'hésitez pas à signaler des problèmes et à nous faire part de vos demandes de fonctionnalités sur la page de commentaires. Plus tôt nous recevrons vos commentaires, plus nous pourrons en tenir compte dans la version finale.

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

• Compilez le nouveau SDK, effectuez des tests 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, vérifiez si elle est affectée par les modifications apportées à Android 17, installez-la sur un appareil ou un émulateur exécutant Android 17, puis testez-la de manière approfondie.

Nous mettrons à jour régulièrement 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 Over The Air pour toutes les versions Preview et bêta ultérieures.

Pour en savoir plus, consultez le site pour les développeurs Android 17.

Participer à la discussion

Alors que nous nous dirigeons vers la stabilité de la plate-forme et la version stable finale d'Android 17 plus tard dans l'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 qui effectue des tests sur la version bêta 1, pensez à rejoindre nos communautés et à nous faire part de vos commentaires. Nous sommes à votre écoute.