Chez ChromeOS, nous nous engageons à améliorer les outils et frameworks pour les développeurs afin de leur permettre d'optimiser facilement leurs applications Android pour les Chromebooks. Pour ce faire, nous devons constamment chercher des moyens de fournir aux développeurs des ensembles d'outils efficaces afin d'améliorer l'expérience de développement pour les grands écrans et ChromeOS.
ChromeOS a évolué au fil des ans pour faire face à de nouveaux défis. L'un de ces défis consiste à identifier les problèmes critiques pour les ingénieurs de manière précoce et fréquente. Les règles Lint sont au cœur de la qualité, car elles fournissent des signaux d'alerte aux développeurs pour les problèmes qui surviendront s'ils ne sont pas résolus. Nos règles lint mises à jour offrent aux développeurs une meilleure visibilité sur le fonctionnement de leurs applications sur ChromeOS. Elles mettent en évidence les problèmes logiciels et matériels qui entraîneront inévitablement des problèmes pour les applications Android exécutées sur n'importe quel appareil ChromeOS.
Pour en savoir plus sur l'existence de ces règles lint et leur importance, consultez notre article de blog.
Où se trouvent ces règles lint ?
Nous développons activement cette fonctionnalité depuis quelques mois. Avec le calendrier de publication d'Android Studio, certaines règles lint sont introduites avec les builds Canary d'Electric Eel. Certaines de ces règles lint sont désormais disponibles dans les versions Canary de Flamingo. Nous continuerons à travailler pour les intégrer aux versions stables d'Android Studio au cours des prochains mois.
Autre point important à noter : ces règles seront activées par défaut dans les versions plus récentes d'Android Studio. L'objectif est de fournir des conseils plus précis sur la façon dont nous souhaitons aider les ingénieurs à développer des applications pour ChromeOS et les grands écrans à l'avenir.
Nouvelles règles lint (mises à jour dans Flamingo Canary 3)
Compatibilité avec les ABI x86/x86_64
La majorité des Chromebooks fonctionnent avec l'architecture Intel, ce qui en fait une plate-forme principalement basée sur l'architecture x86. Pour que ChromeOS soit correctement pris en charge lorsque le code NDK est inclus dans le binaire, le fait d'avoir x86 améliore les performances en supprimant la traduction requise à partir des bibliothèques ARM. Il est donc fortement recommandé que votre équipe de développement ajoute la prise en charge de l'architecture x86 ou, de préférence, x86_64, car cela améliorerait les performances de tout code natif sur ChromeOS ou sur tout appareil Intel.
Solution
Si possible, ajoutez x86 et x86_64 dans votre abiSplits au sein de votre build.gradle. Assurez-vous également d'ajouter le code aux dossiers appropriés pour prendre en charge ces ABI. Pour en savoir plus, consultez la documentation sur les ABI Android et la présentation sur la compatibilité des ABI avec ADS.
Remarque : Assurez-vous que toutes les bibliothèques tierces incluses et utilisées disposent également de binaires x86 et x86-64.
Limitation matérielle de ChromeOS
La plupart des appareils ChromeOS sont équipés d'un ensemble plus restreint de capteurs matériels et d'autres fonctionnalités que les téléphones Android. L'objectif de cette règle est d'indiquer aux développeurs que si vous utilisez le flag <uses-feature> avec android:required=true, votre application ne sera pas disponible sur le Google Play Store sur ChromeOS. Pour que votre application soit accessible sur le plus grand nombre d'appareils possible, nous vous recommandons vivement de vous assurer que la fonctionnalité matérielle n'est pas requise par défaut. À la place, vous pouvez ajouter du code défensif pour vérifier le matériel spécifique au moment de l'exécution. Par exemple,
<uses-feature android:name="android.hardware.camera" android:required="true">
Solution
Assurez-vous que les fonctionnalités de votre application sont réellement nécessaires. Si ce n'est pas le cas, remplacez le paramètre android:required par false et ajoutez une programmation défensive lorsque des appels d'API sont requis. Pour en savoir plus, consultez la documentation sur les fonctionnalités déclarées de manière explicite.
Activités non redimensionnables
Par défaut, Android Runtime pour ChromeOS, qui exécute Android R ou version ultérieure sur les Chromebooks, démarre une application Android dans la version pour téléphone ou tablette de l'application, en fonction de l'état de l'interface utilisateur par défaut. Toutefois, il existe une troisième option qui offre une meilleure expérience aux utilisateurs de ChromeOS : le mode redimensionnable. En activant ce signalement dans votre activité, les utilisateurs qui peuvent utiliser votre application dans n'importe quel environnement multifenêtre peuvent redimensionner votre application à la taille appropriée. Ces modifications permettront aux utilisateurs d'adapter l'UI à leurs besoins. Après avoir ajouté ces modifications à votre fichier manifeste, testez votre application sur l'émulateur de bureau référencé ci-dessous.
Solution
Ajoutez l'attribut resizableActivity="true" à votre activité dans votre fichier AndroidManifest.xml. Pour en savoir plus, consultez la documentation sur les restrictions liées aux grands écrans.
Modifications de configuration
Un point important à noter concernant les écrans redimensionnables est que onConfigurationChanged() est appelé chaque fois qu'un utilisateur modifie la taille de l'application. Si votre application effectue un redessin complet dans cette méthode, cela aura des conséquences sur les performances. Actuellement, nous vérifions que finish() n'est pas appelé dans onConfigurationChanged, car vous devez gérer savedInstanceState avec plus de précision au lieu d'appliquer un redessin complet. Nous continuerons à identifier les cas de dégradation des performances et à mettre à jour cette règle en conséquence.
Solution
Assurez-vous que finish() n'est pas appelé dans l'API onConfigurationChanged() de vos activités et fragments. Pour en savoir plus, consultez la documentation sur la gestion des modifications de configuration.
Prise en charge du clavier et de la souris
L'adoption de Jetpack Compose étant de plus en plus répandue, nous avons voulu nous assurer que la création avec ces bibliothèques inclue également la prise en charge de la souris et du clavier à l'avenir. Au fil du temps, nous continuerons d'améliorer l'utilisation de la souris, du clavier, du pavé tactile et d'autres périphériques. Pour obtenir les expériences de référence, vous devez mettre à jour vos dépendances Gradle vers les versions minimales requises.
Solution
Mettez à jour androidx.compose.foundation:foundation vers la version 1.2 ou ultérieure. Pour en savoir plus, consultez les notes de version de Compose.
Remarque : 90 % des utilisateurs interagissent avec les applications sur les Chromebooks à l'aide d'un clavier et d'une souris. (Source : données internes Google, 2022*)
Commentaires
L'équipe cherche constamment à améliorer ces outils et la documentation sur l'optimisation pour les grands écrans. Une étape essentielle de ce processus consiste à nous faire part de vos commentaires sur l'exactitude et l'utilité des règles lint déployées dans Android Studio. Pour ce faire, envoyez des commentaires sur la règle. Lorsque la règle lint s'affiche dans Android Studio, cliquez sur "Envoyer des commentaires sur cet avertissement". Une boîte de dialogue semblable à celle ci-dessous devrait s'afficher. Plus les informations fournies sont précises et descriptives, plus nous pouvons rapidement apporter les modifications appropriées.
