Android 17 est disponible en version bêta 4, la dernière version bêta prévue pour ce cycle de publication. Il s'agit d'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 fluide de bord à bord ou exploiter les dernières API, la version bêta 4 vous offre l'environnement presque 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 prendre en charge entièrement Android 17.

Pour effectuer des 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'autres moyens. 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. Pour concentrer vos tests, examinez les modifications de comportement ayant un impact sur les applications s'exécutant sur et ciblant Android 17, y compris les suivantes :

• Redimensionnement sur les grands écrans : une fois que vous ciblez Android 17, vous ne pouvez plus désactiver le maintien des 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 CT par défaut : Certificate Transparency (CT) est activé par défaut. (Sur Android 16, la CT est disponible, mais les applications doivent l'activer.)
• Protections du réseau local : les applications ciblant Android 17 ou version ultérieure ont l'accès au réseau local bloqué par défaut. Si possible, passez à l'utilisation de sélecteurs respectueux de 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. Suite à vos commentaires, nous avons apporté quelques modifications depuis la version bêta 2, y compris le gating targetSDK pour l'application des FGS en cours d'utilisation et l'exemption de l'audio des alarmes. Pour en savoir plus, consultez les consignes mises à jour.

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 Android. Dans Android 17, les limites sont définies de manière conservatrice pour établir des références 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 saccades 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 minime 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 contient 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 vidages de tas collectés lorsque la limite de mémoire est atteinte.

Pour vous aider à détecter 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.

Une empreinte mémoire plus légère se traduit directement par des performances plus fluides, une autonomie de 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 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 binder excessifs et l'utilisation excessive de 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 vidages du tas 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 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 les déclencheurs.

    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 (CPQ) dans Android Keystore

Le keystore Android prend désormais en charge 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é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 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 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 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

Vos commentaires restent notre atout le plus précieux. Que vous soyez un utilisateur précoce du canal Canary ou un développeur d'applications qui effectue des tests sur la version bêta 4, pensez à rejoindre nos communautés et à nous faire part de vos commentaires. Nous sommes à votre écoute.