Android 17 est disponible en version bêta 4, la dernière version bêta prévue de ce cycle de publication. Il s'agit d'une étape essentielle pour la compatibilité des applications et la stabilité de la plate-forme. Que vous affiniez l'expérience utilisateur de votre application, que vous assuriez un rendu fluide de bord à bord ou que vous exploitiez les dernières API, la version bêta 4 fournit l'environnement presque final dont vous avez besoin pour effectuer des tests. 

Préparez vos applications, vos bibliothèques, vos outils et vos moteurs de jeux !

Si vous développez un SDK Android, une bibliothèque, un outil ou un moteur de jeux, il est essentiel de préparer dès maintenant toutes les mises à jour nécessaires pour éviter que vos développeurs d'applications et de jeux en aval ne soient bloqués par des problèmes de compatibilité et pour leur permettre de cibler les dernières fonctionnalités du SDK. Veuillez informer vos développeurs en aval si des mises à jour sont nécessaires pour prendre en charge pleinement Android 17.

Les tests consistent à installer votre application de production ou une application de test utilisant votre bibliothèque ou votre moteur à l'aide de Google Play ou d'autres moyens sur un appareil ou un émulateur exécutant Android 17 version bêta 4. Parcourez tous les flux de votre application et recherchez les problèmes fonctionnels ou d'interface utilisateur. Chaque version d'Android contient des modifications de la plate-forme qui améliorent la confidentialité, la sécurité et l'expérience utilisateur globale. Examinez les modifications de comportement ayant un impact sur les applications exécutées sur et ciblant Android 17 pour concentrer vos tests, y compris les suivants :

• Redimensionnement sur les grands écrans : une fois que vous ciblez Android 17, vous ne pouvez plus désactiver le maintien de l'orientation, du redimensionnement et des contraintes de format d'image sur les grands écrans.
• Chargement dynamique du code : si votre application cible Android 17 ou une version ultérieure, la protection de chargement dynamique du code (DCL) plus sécurisée introduite dans Android 14 pour les fichiers DEX et JAR s'étend désormais aux bibliothèques natives. Tous les fichiers natifs chargés à l'aide de System.load() doivent être marqués en lecture seule. Sinon, le système génère une exception UnsatisfiedLinkError.
• Activer CT par défaut :La transparence des certificats (CT) est activée par défaut. (Sur Android 16, CT est disponible, mais les applications devaient s'inscrire.)
• Protections du réseau local : les applications ciblant Android 17 ou une version ultérieure ont l'accès au réseau local bloqué par défaut. Passez à l'utilisation de sélecteurs préservant la confidentialité si possible, et utilisez la nouvelle ACCESS_LOCAL_NETWORK autorisation pour un accès large et persistant.
• Renforcement de l'audio en arrière-plan : à partir d'Android 17, le framework audio applique 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. Suite à vos commentaires, nous avons apporté quelques modifications depuis la version bêta 2, y compris le contrôle targetSDK lors de l'application FGS en cours d'utilisation et l'exemption de l'audio d'alarme. Pour en savoir plus, consultez les consignes mises à jour.

Limites de mémoire des applications

Android introduit des limites de mémoire des applications basées sur la RAM totale de l'appareil afin de créer un environnement plus stable et déterministe pour vos applications et les utilisateurs Android. Dans Android 17, les limites sont définies de manière conservatrice pour établir des bases de référence système, en ciblant les fuites de mémoire extrêmes et autres valeurs aberrantes avant qu'elles ne déclenchent une instabilité à l'échelle du système entraînant des problèmes de stuttering de l'interface utilisateur, une décharge de la batterie plus élevée et la fermeture des applications. Bien que nous prévoyions un impact minimal sur la grande majorité des sessions d'application, nous vous recommandons de suivre les bonnes pratiques de mémoire suivantes, y compris l'établissement d'une base de référence pour la mémoire.

Dans l'implémentation actuelle, getDescription dans ApplicationExitInfo contient la chaîne "MemoryLimiter" si votre application a été affectée. Vous pouvez également utiliser le profilage basé sur un déclencheur avec TRIGGER_TYPE_ANOMALY pour obtenir des vidages de tas collectés lorsque la limite de mémoire est atteinte.

Pour vous aider à trouver les fuites de mémoire, Android Studio Panda ajoute l'intégration de LeakCanary directement dans le Profileur Android Studio en tant que tâche dédiée, contextualisée dans l'IDE et entièrement intégrée à votre code source.

Une empreinte mémoire plus légère se traduit directement par des performances plus fluides, une plus grande autonomie de la batterie et une expérience premium sur tous les facteurs de forme. Ensemble, construisons un avenir plus rapide et plus fiable pour l'écosystème Android !

Déclencheurs de profilage pour les anomalies d'application

Android introduit un service de détection des anomalies sur l'appareil qui surveille les comportements gourmands en ressources et les régressions de compatibilité potentielles. Intégré à ProfilingManager, ce service permet à votre application de recevoir des artefacts de profilage déclenchés par des événements spécifiques détectés par le système.

Utilisez le déclencheur TRIGGER_TYPE_ANOMALY pour détecter les problèmes de performances du système, tels que les appels de liaison excessifs et l'utilisation excessive de la mémoire. Lorsqu'une application dépasse les limites de mémoire définies par le système d'exploitation, le déclencheur d'anomalie permet aux développeurs de recevoir des vidages de tas spécifiques à l'application pour les aider à identifier et à résoudre les problèmes de mémoire. De plus, en cas de spam de liaison excessif, le déclencheur d'anomalie fournit un profil d'échantillonnage de pile sur les transactions de liaison.

Ce rappel d'API se produit avant toute application imposée par le système. Par exemple, il peut aider les développeurs à collecter des données de débogage avant que l'application ne soit arrêtée par le système en raison du dépassement des limites de mémoire. Pour savoir comment utiliser le déclencheur, consultez notre documentation sur le profilage basé sur un déclencheur.

    val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  
    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 
    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

Cryptographie post-quantique (PQC) dans Android Keystore

Android Keystore a ajouté la prise en charge de l'algorithme de signature numérique ML-DSA (Module-Lattice-Based Digital Signature Algorithm) normalisé par le NIST. Sur les appareils compatibles, vous pouvez générer des clés ML-DSA et les utiliser pour produire des signatures sécurisées quantiques, entièrement dans le matériel sécurisé de l'appareil. Android Keystore expose les variantes d'algorithme ML-DSA-65 et ML-DSA-87 via les API Java Cryptographic Architecture standards : KeyPairGenerator, KeyFactory et Signature. Pour en savoir plus, consultez notre documentation pour les développeurs.

KeyPairGenerator generator = KeyPairGenerator.getInstance(
        “ML-DSA-65”, "AndroidKeyStore");
generator.initialize(
        new KeyGenParameterSpec.Builder(
                “my-key-alias”,
                KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
        .build());
KeyPair keyPair = generator.generateKeyPair();

Premiers pas avec Android 17

Vous pouvez inscrire n'importe quel appareil Pixel compatible pour recevoir cette mise à jour 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 Over The Air vers la version bêta 4.

Continuez à signaler les problèmes et à envoyer vos demandes de fonctionnalités sur la page de commentaires. Plus tôt nous recevrons vos commentaires, plus nous pourrons les 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-unes des choses à faire :

• 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 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

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 4, pensez à rejoindre nos communautés et à envoyer vos commentaires. Nous sommes à votre écoute.