En mettant à niveau vos dépendances, vous accédez à leurs dernières fonctionnalités, corrections de bugs et améliorations. Pour mettre à niveau vos dépendances, vous devez comprendre comment Gradle résout les versions que vous demandez, les risques encourus et les mesures que vous pouvez prendre pour atténuer ces risques.
Réfléchir à votre stratégie de mise à niveau
L'étape la plus importante de toute mise à niveau est l'analyse des risques. Déterminez votre niveau de confort avec chaque dépendance que vous mettez à niveau. De nombreux éléments doivent être pris en compte lors de la définition de votre stratégie de migration, y compris les suivants:
Créer une bibliothèque |
Créez-vous une application que les utilisateurs téléchargent et exécutent sur un appareil ? Ou créez-vous une bibliothèque pour aider d'autres développeurs à créer leurs applications ? Si vous créez une application, votre objectif doit être de la maintenir à jour et stable. Si vous créez une bibliothèque, votre objectif doit être les applications d'autres développeurs. Vos mises à niveau ont un impact sur vos clients. Si vous mettez à niveau l'une de vos dépendances, cette version devient éligible pour la résolution des dépendances de Gradle, ce qui peut perturber l'utilisation de cette dépendance par l'application. Tout d'abord, réduisez autant que possible les dépendances de votre bibliothèque. Moins vous avez de dépendances, plus l'impact sur la résolution de dépendance de l'utilisateur est faible. Veillez à suivre le versionnage sémantique pour indiquer les types de modifications que vous apportez. Par exemple, AndroidX suit la gestion sémantique des versions et ajoute un schéma de gestion des versions préliminaires. Essayez d'éviter les mises à niveau de la version Envisagez de créer un build-candidate (RC) de votre bibliothèque pour que les utilisateurs puissent le tester en amont. Pour savoir comment assurer la compatibilité de l'interface binaire d'application (ABI) de votre bibliothèque, consultez les consignes de rétrocompatibilité pour les auteurs de bibliothèques. Utilisez des tests d'intégration et des outils tels que l'outil de validation de la compatibilité binaire pour vous assurer que vos modifications d'ABI correspondent à la modification de version prévue. Si vous publiez des correctifs dans une Si la mise à niveau de votre bibliothèque nécessite des modifications de rupture qui peuvent être particulièrement difficiles pour vos utilisateurs, envisagez de les publier en tant que nouvel artefact afin que les anciennes et nouvelles versions puissent coexister et permettre un déploiement plus progressif. Remarque: Si une mise à niveau de l'une de vos dépendances contient une modification majeure de l'API, vous devrez probablement la mettre à niveau dans une version |
Cycle de publication |
À quelle fréquence publiez-vous votre application ou votre bibliothèque ? Cycles de développement et de publication plus courts
Cycles de développement et de publication plus longs
|
Tenez-vous informé des dernières fonctionnalités |
Préférez-vous utiliser les dernières fonctionnalités et API disponibles ou ne passer à la version supérieure que lorsque vous avez besoin d'une fonctionnalité ou d'une correction de bug ? Réfléchissez aux inconvénients des mises à niveau fréquentes. Les futures mises à niveau sont plus faciles (moins de modifications à intégrer), mais vous prenez des risques plus souvent. Tester les mises à niveau vers les versions préliminaires (alpha, bêta, version candidate) des bibliothèques peut vous aider à vous préparer lorsque les versions stables seront disponibles. |
Nouvelle dépendance |
Si vous ajoutez une nouvelle dépendance, envisagez un processus d'examen rigoureux qui examine cette bibliothèque pour tous les critères de risque afin de s'assurer qu'ils ont été correctement évalués. N'autorisez pas l'ajout de nouvelles dépendances sans examen. |
Équipe dédiée |
Disposez-vous d'une équipe de compilation dédiée ? Vos ingénieurs logiciels gèrent-ils la compilation ? Une équipe dédiée peut souvent consacrer plus de temps à analyser les risques de mise à niveau et à tester les nouvelles versions pour s'assurer que le build fonctionne correctement avant que les ingénieurs ne les utilisent. |
Type de mise à niveau |
Certaines mises à niveau sont plus importantes que d'autres. Réfléchissez à celles qui sont les plus importantes pour vous. Les mises à niveau de l'outil de compilation, telles que les plug-ins Gradle et Gradle, ont généralement moins d'impact sur vos utilisateurs, et une grande partie des risques est interne à votre build. La compilation elle-même aide à valider ces modifications. Les mises à niveau de la bibliothèque et du SDK sont plus difficiles à valider et présentent un risque plus élevé pour vos utilisateurs. Plug-in Android Gradle (AGP) : les outils utilisés pour créer votre application ou bibliothèque Android. Il s'agit de la mise à niveau la plus importante que vous puissiez effectuer, car elle inclut ou active souvent des améliorations des performances, des corrections de bugs, de nouvelles règles lint et la compatibilité avec les nouvelles versions de la plate-forme Android. Gradle : vous devrez souvent mettre à niveau Gradle lorsque vous mettrez à niveau l'AGP ou un autre plug-in Gradle. Autres plug-ins Gradle : l'API du plug-in Gradle est parfois modifiée. Lorsque vous mettez à niveau Gradle, recherchez les mises à niveau des plug-ins que vous utilisez. Kotlin et Java : certaines bibliothèques et plug-ins nécessitent des versions minimales de Kotlin ou de Java, ou vous souhaitez profiter de nouvelles fonctionnalités, API ou améliorations de performances du langage. Plate-forme Android : le Play Store nécessite des mises à niveau régulières du SDK Android. Vous devez tester les nouvelles versions du SDK Android dès que possible. Certaines mises à niveau du SDK nécessitent des modifications au niveau de votre application, telles que de nouvelles autorisations ou l'utilisation de nouvelles API. Bibliothèques : souhaitez-vous hiérarchiser les bibliothèques en fonction de leur proximité avec votre architecture globale ?
Android Studio : en maintenant Android Studio à jour, vous accédez aux dernières fonctionnalités et corrections de bugs de la plate-forme et des outils IntelliJ IDEA sous-jacents, et pouvez ainsi utiliser les derniers SDK Android. |
Outils disponibles |
De nombreux outils et plug-ins sont disponibles pour vous aider à effectuer vos mises à niveau. Des outils tels que Dependabot et Renovate mettent automatiquement à niveau les versions de bibliothèques dans votre build, mais veillez à analyser les résultats pour détecter les risques. |
Stratégies pour des types spécifiques de mises à niveau
La mise à niveau de certains types de dépendances peut avoir un effet en cascade, ce qui peut nécessiter la mise à niveau d'autres types de dépendances. Nous abordons les relations entre les éléments de compilation dans la section Interdépendances des outils et des bibliothèques.
Lorsque vous mettez à niveau chaque type de composant, tenez compte de l'impact de la mise à niveau sur les autres composants de la compilation.
Plug-in Android Gradle (AGP) |
Android Studio inclut un assistant de mise à niveau AGP qui peut vous aider à effectuer ces tâches. Si vous utilisez l'assistant ou effectuez la mise à niveau manuellement, tenez compte des points suivants: Consultez les notes de version de l'AGP. Mettez à niveau Gradle au moins vers la version indiquée. Mettez à niveau Android Studio vers une version compatible avec la version d'AGP choisie. Utilisez des versions d'Android Studio et d'AGP compatibles avec le SDK Android que vous souhaitez utiliser. Vérifiez la compatibilité avec SDK Build Tools, le NDK et le JDK. Si vous développez un plug-in Gradle (à usage interne ou public) qui étend ou utilise des données d'AGP, vérifiez si vous devez mettre à niveau votre plug-in. Parfois, AGP abandonne et supprime ensuite des API, ce qui entraîne des incompatibilités avec les plug-ins précédents. |
Compilateur, langage et environnement d'exécution Kotlin |
Consultez les notes de version de Kotlin pour connaître les problèmes connus et les incompatibilités. Si vous utilisez Jetpack Compose:
Si vous utilisez le traitement des symboles Kotlin (KSP), consultez le guide de démarrage rapide KSP pour la configuration et les versions KSP pour les versions disponibles. Notez que vous devez utiliser une version de KSP correspondant à la version de Kotlin. Par exemple, si vous utilisez Kotlin 2.0.21, vous pouvez utiliser n'importe quelle version du plug-in KSP commençant par 2.0.21, comme 2.0.21-1.0.25. En règle générale, vous n'avez pas besoin de mettre à niveau les processeurs KSP (tels que le compilateur Room, qui apparaît comme une dépendance Mettez à niveau tous les autres plug-ins du compilateur Kotlin que vous utilisez. L'API du plug-in de compilation Kotlin change souvent d'une version à l'autre, et les plug-ins doivent utiliser une API compatible. Si le plug-in est listé dans Compiler plugins (Plug-ins de compilation), vous devez utiliser la même version que le compilateur Kotlin. Consultez la documentation de tous les autres plug-ins de compilation pour connaître le mappage approprié. Notez que les plug-ins de compilation qui ne sont pas gérés avec le compilateur Kotlin lui-même subissent souvent des retards de publication, car ils attendent que l'API du plug-in de compilation se stabilise. Avant de mettre à niveau Kotlin, vérifiez que des mises à niveau correspondantes sont disponibles pour tous les plug-ins de compilation que vous utilisez. Enfin, il arrive que la langue Kotlin change, ce qui vous oblige à mettre à jour votre code. Cela se produit généralement si vous testez des fonctionnalités expérimentales. Si votre code ne se compile pas correctement après la mise à niveau du compilateur Kotlin, recherchez les modifications de langage ou les problèmes de la bibliothèque d'exécution dans les notes de version de Kotlin. |
Plug-ins du compilateur Kotlin |
Si vous devez mettre à niveau un plug-in de compilateur Kotlin, passez à la version correspondante de Kotlin utilisée. La plupart des plug-ins du compilateur Kotlin utilisent la même version que le compilateur Kotlin ou commencent avec la version requise du compilateur Kotlin. Par exemple, si la version du plug-in est 2.0.21-1.0.25, vous devez utiliser la version 2.0.21 du compilateur Kotlin. Modifier la version du compilateur Kotlin nécessite parfois d'apporter d'autres modifications. |
Bibliothèques |
Les bibliothèques sont la dépendance la plus fréquemment mise à niveau dans votre build. Les mises à niveau disponibles s'affichent dans l'éditeur Android Studio ou si vous utilisez certains outils et plug-ins de dépendance. Certaines bibliothèques spécifient un Certaines bibliothèques spécifient également une version minimale de Kotlin à utiliser. Mettez à jour la version de Kotlin dans vos fichiers de compilation pour qu'elle soit au moins égale à la version spécifiée. |
Gradle |
Il arrive que les nouvelles versions de Gradle rendent obsolètes des API existantes, et les suppriment dans une prochaine version. Si vous développez un plug-in Gradle, mettez-le à niveau dès que possible, en particulier s'il est public. Certaines mises à niveau de Gradle nécessitent de localiser les nouvelles versions des plug-ins que vous utilisez. Notez que le développement de ces plug-ins peut être retardé, car ils doivent être mis à niveau pour correspondre aux dernières API de plug-in Gradle. Pour mettre à niveau Gradle:
|
Plug-ins Gradle |
Les plug-ins Gradle mis à niveau utilisent parfois de nouvelles API Gradle ou des API modifiées, ce qui nécessite une mise à niveau de Gradle ou éventuellement des modifications de leur configuration dans vos fichiers de compilation. Dans les deux cas, des avertissements ou des erreurs de compilation s'affichent pour indiquer l'incompatibilité. Chaque fois que vous mettez à niveau des plug-ins, mettez à niveau Gradle. |
SDK Android |
Android Studio inclut un assistant de mise à niveau du SDK Android qui peut vous aider à effectuer ces tâches. Si vous utilisez l'Assistant ou effectuez la mise à niveau manuellement, tenez compte des points suivants: Chaque version du SDK Android contient de nouvelles fonctionnalités et API, des corrections de bugs et des modifications de comportement. Le Play Store exige la mise à jour de votre Avant de mettre à niveau le SDK Android, lisez attentivement les notes de version. Soyez particulièrement attentif à la section "Modifications de comportement", qui comprend les éléments suivants:
La section "Modifications de comportement" peut être assez longue, mais soyez attentif, car elle contient souvent des modifications critiques que vous devez apporter à votre application. Vous devez mettre à niveau Pour profiter des nouvelles fonctionnalités du SDK pendant le développement et assurer la compatibilité lors de la compilation, mettez à niveau le plug-in Android Gradle (AGP) et Android Studio. Cela inclut de nouveaux outils et des outils améliorés pour les nouveaux SDK. Consultez la section Versions minimales des outils pour le niveau d'API Android. Lorsque vous mettez à niveau le SDK Android, mettez à niveau toutes les bibliothèques AndroidX que vous utilisez. AndroidX utilise souvent de nouvelles API et des API mises à jour pour améliorer la compatibilité et les performances entre les versions du SDK Android. |
Android Studio |
En général, vous pouvez mettre à niveau Android Studio à tout moment. Des messages peuvent s'afficher pour vous inviter à mettre à niveau AGP ou à mettre à niveau le SDK Android. Ces mises à niveau sont vivement recommandées, mais pas obligatoires. Si vous souhaitez ultérieurement utiliser Android Studio pour mettre à niveau AGP ou le SDK Android, vous trouverez ces options dans le menu Tools (Outils) : |
Java |
Si votre application Android contient du code source Java, vous pouvez exploiter les API Java plus récentes. Chaque version du SDK Android est compatible avec un sous-ensemble d'API Java et de fonctionnalités de langage. AGP assure la compatibilité avec les versions antérieures du SDK Android à l'aide d'un processus appelé désucrage. Les notes de version du SDK Android indiquent le niveau Java compatible et les problèmes potentiels. Certains de ces problèmes peuvent également avoir une incidence sur le code source Kotlin, car Kotlin a accès aux mêmes API Java. Veillez à prêter une attention particulière aux sections de l'API JDK qui apparaissent dans la section des modifications de comportement des notes de version, même si vous ne disposez d'aucun code source Java. L'utilisation du JDK est spécifiée à plusieurs endroits dans vos scripts de compilation. Pour en savoir plus, consultez la section Versions de Java dans le build Android. |
Analyse de la mise à niveau
La mise à niveau d'une dépendance peut présenter des risques sous la forme de modifications de l'API et du comportement, de nouvelles exigences d'utilisation, de nouveaux problèmes de sécurité ou même de modifications de licence. Par exemple:
- Modifier le code en cas de modification de l'API ?
- Ajouter de nouvelles vérifications d'autorisation ?
- Créer des tests supplémentaires ou modifier des tests existants pour détecter les changements de comportement ?
Notez que la dépendance que vous avez mise à niveau a mis à niveau les versions de ses dépendances. Cela peut rapidement se transformer en un ensemble massif de modifications.
Si vous utilisez un outil tel que Renovate ou Dependabot pour automatiser vos mises à niveau, sachez qu'il ne vous effectue aucune analyse. Il met à niveau les bibliothèques vers les dernières versions. Ne partez pas du principe que tout fonctionnera correctement après ces types de mises à niveau automatiques.
La clé d'une migration réussie est l'analyse de la migration:
- Déterminez les différences de dépendances avant et après vos mises à niveau.
- Examinez chaque modification et déterminez les risques encourus.
- atténuer les risques, ou accepter ou refuser les modifications ;
Déterminer les différences de dépendance
La première étape de l'analyse de la mise à niveau consiste à déterminer comment vos dépendances changent. Profitez du contrôle des versions (VCS, comme Git) et du plug-in Dependency Guard pour voir rapidement les modifications. Votre objectif est de créer un instantané avant et un instantané après, puis de les comparer.
Configurer et créer votre première référence
Avant de commencer la mise à niveau, assurez-vous que votre projet a bien été compilé.
Dans l'idéal, résolvez autant d'avertissements que possible ou créez des références pour suivre les avertissements que vous avez déjà vus.
- Lint: examinez vos avertissements lint existants et créez une référence lint Android.
- Compilateur Kotlin :
- Activez
-Werrorpour traiter tous les avertissements comme des erreurs. Consultez Définir des options. - Envisagez d'utiliser des plug-ins tels que Kotlin Warning Baseline ou Kotlin Warnings Baseline Generator.
- Activez
- Autres outils: si vous utilisez d'autres outils d'analyse statique (comme Detekt) compatibles avec le suivi de référence, configurez leurs références.
Ces références permettent de voir plus facilement les nouveaux avertissements introduits lorsque vous mettez à niveau vos dépendances.
Créez une référence de dépendance en configurant et en exécutant Dependency Guard. Dans votre catalogue de versions gradle/libs.versions.toml, ajoutez:
[versions]
dependencyGuard = "0.5.0"
[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }
Ajoutez ensuite les éléments suivants au fichier de compilation de votre application:
Kotlin
plugins { alias(libs.plugins.dependency.guard) } dependencyGuard { configuration("releaseRuntimeClasspath") }
Groovy
plugins { alias(libs.plugins.dependency.guard) } dependencyGuard { configuration('releaseRuntimeClasspath') }
La configuration releaseRuntimeClasspath est probablement une cible, mais si vous souhaitez utiliser une autre configuration, exécutez ./gradlew dependencyGuard sans configuration répertoriée dans votre fichier de compilation pour afficher toutes les configurations disponibles.
Après la configuration, exécutez ./gradlew dependencyGuard pour générer un rapport dans app/dependencies/releaseRuntimeClasspath.txt. Il s'agit de votre rapport de référence.
Validez ce code dans votre système de contrôle des versions (VCS) pour l'enregistrer.
N'oubliez pas que Dependency Guard ne capture que la liste des dépendances de la bibliothèque. D'autres dépendances figurent dans vos fichiers de compilation, comme les versions du SDK Android et du JDK. Si vous effectuez un commit dans votre VCS avant que votre dépendance ne change, votre VCS diff peut également mettre en évidence ces modifications.
Mettre à niveau et comparer avec votre référence
Une fois que vous avez un point de référence, mettez à niveau les dépendances et les autres modifications de compilation que vous souhaitiez tester. Ne mettez pas à niveau votre code source ni vos ressources à ce stade.
Exécutez ./gradlew lint pour afficher les nouveaux avertissements ou erreurs lint. Résolvez les problèmes importants, puis mettez à jour votre référence d'alerte en exécutant ./gradlew lint
-Dlint.baselines.continue=true. Si vous avez utilisé d'autres outils pour capturer des références d'avertissement, tels que la référence d'avertissement Kotlin ou le générateur de référence d'avertissements Kotlin, corrigez les nouveaux avertissements et mettez également à jour leurs références.
Exécutez ./gradlew dependencyGuard pour mettre à jour votre rapport de référence. Exécutez ensuite la différence de votre système de contrôle des versions pour afficher les modifications autres que celles apportées aux bibliothèques. Il est probable qu'il inclue beaucoup plus de mises à niveau de bibliothèques que vous ne le pensiez.
Analyser les risques
Une fois que vous savez ce qui a changé, examinez les risques possibles pour chaque bibliothèque mise à niveau. Cela vous permet de cibler vos tests ou d'examiner plus en détail les modifications. Définissez un ensemble de risques à analyser pour votre projet afin de garantir une analyse cohérente.
Éléments à prendre en compte:
Accélération des versions majeures |
Le numéro de la version majeure a-t-il changé ? Dans ce cas, soyez particulièrement attentif aux bibliothèques concernées lorsque vous examinez les éléments suivants. Si votre code utilise des API expérimentales (qui nécessitent souvent d'activer l'utilisation à l'aide d'annotations ou de spécifications de fichier de compilation), même les modifications de version mineure ou de correctif, telles que la mise à niveau de la version 1.2.3 vers la version 1.3.1 ou de la version 1.2.3 vers la version 1.2.5, peuvent présenter des risques supplémentaires. |
API non stable |
Certaines versions de bibliothèques peuvent inclure des API non stables. Il s'agit généralement d'API en cours de développement ou qui dépendent d'une autre API instable. Bien que généralement limitées aux versions preview, telles que les versions alpha, de développement ou expérimentales, certaines bibliothèques incluent des API marquées comme expérimentales ou instables. Dans la mesure du possible, évitez ces API. Si vous avez besoin de les utiliser, veillez à enregistrer votre utilisation et à surveiller les modifications ou les suppressions dans les versions ultérieures. |
Comportement dynamique |
Certaines bibliothèques se comportent différemment en fonction de facteurs externes. Par exemple, une bibliothèque qui communique avec un serveur dépend des modifications apportées à ce serveur.
|
Fusion de fichiers manifestes |
Les bibliothèques publiées en tant qu'archives Android (AAR) peuvent contenir des ressources et des fichiers manifestes fusionnés dans votre application. Ils peuvent ajouter de nouvelles autorisations et des composants Android, tels que des activités ou des broadcast receivers, qui s'exécutent indirectement. |
Mises à jour de l'environnement d'exécution |
Certaines bibliothèques utilisent des fonctionnalités qui peuvent être mises à jour en dehors du contrôle de votre application. Une bibliothèque peut utiliser les services Play, qui sont mis à niveau indépendamment du SDK Android. D'autres bibliothèques peuvent être associées à des services dans des applications externes mises à jour indépendamment (souvent à l'aide d'AIDL). |
Combien de versions sautez-vous ? |
Plus vous attendez de mettre à niveau une bibliothèque, plus les risques potentiels sont élevés. Si une version change de manière significative, par exemple de 1.2.3 à 1.34.5, soyez particulièrement attentif à cette bibliothèque. |
Guides de migration |
Vérifiez si la bibliothèque dispose d'un guide de migration. Cela peut réduire considérablement votre analyse des risques et votre planification d'atténuation. Notez que la présence d'un tel guide est un bon indicateur que le développeur s'est concentré sur la compatibilité et a pris en compte votre atténuation de la mise à niveau. |
Notes de version |
Consultez les notes de version (le cas échéant) de chaque bibliothèque modifiée. Recherchez des indications de modifications destructives ou de nouvelles exigences, telles que des autorisations ajoutées. |
Fichiers README |
Certains fichiers README d'une bibliothèque indiquent les risques potentiels, en particulier si la bibliothèque ne fournit pas de notes de version. Recherchez les _problèmes connus_, en particulier les problèmes de sécurité. |
Vérifier les failles connues |
Le Play SDK Index suit les failles de nombreux SDK populaires. La Play Console indique si vous utilisez l'un des SDK listés présentant des failles connues. Lorsque vous modifiez des fichiers de compilation dans Android Studio, l'IDE vérifie l'index du SDK et signale l'utilisation de versions de bibliothèques vulnérables. Le NIST (National Institute of Standards and Technology) gère une vaste base de données nationale sur les failles (NVD, National Vulnerability Database). Le plug-in Gradle Dependency Check compare les dépendances que vous utilisez avec la NVD. Pour utiliser la vérification des dépendances, demandez une clé API NVD, configurez le plug-in Gradle et exécutez |
Conflits de versions |
Les versions fonctionnent-elles comme prévu ? Recherchez les conflits, en particulier les différences de version majeure. Pour savoir comment rechercher des conflits, consultez la section Résolution des dépendances Gradle. Recherchez en particulier Lorsque cela est possible, travaillez avec les auteurs d'une dépendance afin de désamorcer les conflits de leurs dépendances. Si votre entreprise vous y autorise, apportez des modifications à la bibliothèque (mise en amont) pour améliorer sa compatibilité. |
Vérifier les licences |
Recherchez les modifications apportées aux licences lors de la mise à niveau d'une bibliothèque. La bibliothèque elle-même peut passer à une licence qui n'est plus compatible avec votre application ou votre bibliothèque. De nouvelles dépendances transitives peuvent également introduire des licences incompatibles. Pour savoir comment vérifier l'ensemble actuel de licences pour vos dépendances, consultez Valider les licences. |
Risques de maintenance et de |
Pour les bibliothèques avec des dépôts publics:
|
Open Source et source fermée |
Si une bibliothèque est Open Source, il est plus facile de déboguer les problèmes qu'avec une source fermée, que les problèmes se trouvent dans votre code ou dans le code de la bibliothèque. Minimisez les dépendances à source fermée et appliquez un examen plus approfondi lors de leur évaluation. Existe-t-il de bonnes alternatives adaptées à votre cas d'utilisation ? Quels contrats de niveau de service sont disponibles pour les bibliothèques propriétaires ? Si vous choisissez d'utiliser une dépendance de source fermée, préparez-vous à écrire des scénarios de test supplémentaires afin de limiter les risques. |
Exécuter un build
Compilez votre projet. Recherchez de nouvelles erreurs ou avertissements. Si vous pouvez identifier la bibliothèque à l'origine de ces erreurs, notez-le comme risque de mise à niveau de cette bibliothèque.
Si vous voyez de nouveaux avertissements de dépréciation, ajoutez-les en tant que risques spécifiques pour la bibliothèque qui les génère. Elles pourront être supprimées dans les versions ultérieures. Si vous souhaitez continuer à utiliser cette bibliothèque, consacrez du temps à la conversion des API obsolètes vers leurs remplacements, ou notez les obsolescences pour garder un œil sur ces fonctions et savoir si elles sont supprimées par la suite.
Utiliser lint pour détecter les problèmes d'API
Android Lint peut détecter de nombreux problèmes dans votre application, y compris certains résultant de la modification des versions des dépendances ou du SDK Android. Par exemple, si vous mettez à niveau votre compileSdk et que vous utilisez ses nouvelles API, lint signale celles qui ne sont pas disponibles dans les versions précédentes du SDK.
Lint s'exécute dans l'éditeur Android Studio et signale les problèmes à mesure que vous apportez des modifications.
Toutefois, elle n'est normalement pas exécutée dans le cadre de votre compilation dans Studio ni lorsque vous exécutez une compilation en ligne de commande, sauf si vous utilisez les cibles build ou lint.
Si vous utilisez l'intégration continue (CI), exécutez gradlew
build ou gradlew lint lors de vos builds CI (ou au moins lors de vos builds quotidiens) pour détecter ces types d'erreurs.
Si vous n'utilisez pas la CI, veillez à exécuter au moins de temps en temps gradlew lint.
Portez une attention particulière aux erreurs et avertissements de lint. Certaines bibliothèques sont fournies avec leurs propres vérifications lint, ce qui permet de garantir une utilisation appropriée de leur API. Certaines nouvelles versions d'une bibliothèque incluent de nouveaux avertissements et erreurs lint, ce qui génère de nouveaux rapports lors de la compilation.
Atténuer les risques
Après avoir déterminé les risques de la mise à niveau, décidez comment les atténuer:
- Acceptez certains risques tels quels. Certains risques sont suffisamment faibles pour être acceptables, en particulier lorsque le temps et les ressources de mise à niveau sont limités.
- Refuser certains risques de manière définitive. Certaines mises à niveau peuvent sembler trop risquées, en particulier si vous disposez de peu de temps ou de ressources pour les atténuer à ce stade. Si vous devez effectuer un tri, concentrez-vous sur les mises à niveau nécessaires pour les bugs que vous avez rencontrés ou les nouvelles fonctionnalités dont vous avez besoin.
- Atténuer les risques restants
- Envisagez de regrouper vos mises à niveau dans des ensembles de modifications plus petits et indépendants. Cela réduit le risque global et permet un rollback partiel.
- Examinez les modifications en détail.
- Testez votre application pour détecter les modifications inattendues. Ajoutez des tests si nécessaire pour renforcer la confiance dans la mise à niveau.
- Examinez la source (si elle est disponible) lorsqu'un élément douteux est détecté.
- Apportez les modifications nécessaires dans votre source ou votre compilation.
Documentez vos décisions. Si les risques d'une mise à niveau deviennent des problèmes lors de l'exécution de votre application, la documentation de votre analyse des risques peut réduire l'analyse des erreurs nécessaire.
Valider les licences
Les développeurs de bibliothèques vous accordent une licence pour les utiliser. Vous devez respecter les conditions de la licence, sans quoi vous ne pouvez pas utiliser la bibliothèque. Certaines licences sont très permissives, et ne nécessitent souvent que l'attribution de la bibliothèque et la diffusion du texte de sa licence auprès des utilisateurs finaux. Certaines sont considérées comme virales. Si vous utilisez ces bibliothèques, vous devez appliquer la même licence à votre application ou à votre bibliothèque.
Les licences peuvent changer à chaque version. Chaque fois que vous effectuez une mise à niveau, vous devez vérifier que les dépendances que vous utilisez sont sous licence compatible avec votre application ou votre bibliothèque.
Si une licence n'est pas compatible (ou a été modifiée pour ne plus l'être), vous ne pouvez pas utiliser cette version de la bibliothèque. Vous pouvez :
- Contactez le propriétaire de la bibliothèque et demandez la poursuite de la licence existante ou une double licence pour continuer à autoriser l'ancienne licence.
- Contactez votre équipe juridique pour déterminer si vous pouvez modifier votre licence pour qu'elle soit compatible.
- Recherchez une autre bibliothèque avec une licence compatible et modifiez votre application si nécessaire.
- Créez un fork de la dernière version compatible de la bibliothèque (si cette licence autorise les dérivées et que les modifications ne sont pas rétroactives) et apportez vos propres modifications.