La quatrième bêta d'Android 17

Android 17 a atteint la version bêta 4, la dernière version bêta prévue de ce cycle de publication, une étape cruciale pour la compatibilité des applications et la stabilité de la plate-forme. Que vous souhaitiez affiner l'expérience utilisateur de votre application, assurer un rendu bord à bord fluide ou exploiter les dernières API, la version bêta 4 fournit l'environnement quasi final dont vous avez besoin pour effectuer vos tests. 

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

Si vous développez un SDK Android, une bibliothèque, un outil ou un moteur de jeu, il est essentiel de préparer dès maintenant les mises à jour nécessaires pour éviter que les 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 assurer une compatibilité complète avec Android 17.

Pour effectuer les tests, vous devez installer votre application de production ou une application de test utilisant votre bibliothèque ou votre moteur sur un appareil ou un émulateur exécutant Android 17 bêta 4, à l'aide de Google Play ou d'un autre moyen. Parcourez tous les flux de votre application et recherchez les problèmes fonctionnels ou d'UI. Chaque version d'Android apporte des modifications à la plate-forme qui améliorent la confidentialité, la sécurité et l'expérience utilisateur globale. Examinez les modifications de comportement qui ont un impact sur les applications qui s'exécutent sur et qui ciblent Android 17 pour cibler vos tests, y compris les éléments suivants :

• Redimensionnement sur les grands écrans : une fois que vous ciblez Android 17, vous ne pouvez plus désactiver les contraintes d'orientation, de redimensionnement et de format sur les grands écrans.
• Chargement dynamique du code : si votre application cible Android 17 ou une version ultérieure, la protection Safer Dynamic Code Loading (DCL) 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 erreur UnsatisfiedLinkError.
• Activer la transparence des certificats par défaut : la transparence des certificats est activée par défaut. (Sur Android 16, la CT est disponible, mais les applications doivent l' activer.)
• Protections du réseau local : l'accès au réseau local est bloqué par défaut pour les applications ciblant Android 17 ou version ultérieure. Si possible, passez à des sélecteurs qui protègent la confidentialité et utilisez la nouvelle autorisation ACCESS_LOCAL_NETWORK pour un accès étendu 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. En fonction de vos commentaires, nous avons apporté quelques modifications depuis la version bêta 2, y compris l'application de la restriction targetSDK pour les services de premier plan en cours d'utilisation et l'exclusion de l'audio des alarmes. Pour en savoir plus, consultez les nouvelles consignes.

Limites de mémoire des applications

Android introduit des limites de mémoire pour les applications en fonction de la RAM totale de l'appareil afin de créer un environnement plus stable et déterministe pour vos applications et les utilisateurs d'Android. Dans Android 17, les limites sont définies de manière prudente pour établir des références système, en ciblant les fuites de mémoire extrêmes et d'autres anomalies avant qu'elles ne déclenchent une instabilité à l'échelle du système, entraînant des saccades de l'interface utilisateur, une décharge plus rapide de la batterie et l'arrêt 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 suivantes concernant la mémoire, y compris d'établir une référence pour la mémoire.

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

Pour vous aider à identifier les fuites de mémoire, Android Studio Panda intègre 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.

Un espace mémoire utilisé plus léger se traduit directement par des performances plus fluides, une autonomie de la batterie plus longue 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 d'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 binder excessifs et l'utilisation excessive de la mémoire. Lorsqu'une application dépasse les limites de mémoire définies par l'OS, le déclencheur d'anomalie permet aux développeurs de recevoir des empreintes de la mémoire spécifiques à l'application pour les aider à identifier et à résoudre les problèmes de mémoire. De plus, en cas de spam excessif de liaison, le déclencheur d'anomalie fournit un profil d'échantillonnage de la pile sur les transactions de liaison.

Ce rappel d'API se produit avant toute mesure d'application imposée par le système. Par exemple, cela 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 d'un 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 prend désormais en charge l'algorithme 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écurité quantique, 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 enregistrer n'importe quel appareil Pixel compatible pour recevoir cette mise à jour et les futures mises à jour de la version bêta d'Android par liaison radio. 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 (OTA) vers la version bêta 4.

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

• Compilez avec le nouveau SDK, testez 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, puis 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 recevez 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.

Participez à la discussion

Vos commentaires restent notre ressource la plus précieuse. Que vous soyez un utilisateur de la première heure sur le canal Canary ou un développeur d'applications effectuant des tests sur la version bêta 4, n'hésitez pas à rejoindre nos communautés et à nous faire part de vos commentaires. Nous sommes à votre écoute.