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. Vous devez prendre en compte de nombreux éléments lorsque vous définissez 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 consommateurs. Si vous mettez à niveau l'une de vos dépendances, cette version devient une candidate pour la résolution de dépendances de Gradle, ce qui peut endommager 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, moins l'impact sur la résolution des dépendances de votre consommateur est important. 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 une version candidate (RC) de votre bibliothèque pour permettre aux utilisateurs de la tester en avant-première. 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 ? Tenez compte des 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 de mettre en place 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 à l'analyse des risques de mise à niveau et aux tests des nouvelles versions pour s'assurer que le build fonctionne correctement avant que les ingénieurs ne l'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 des outils de compilation, tels que Gradle et les plug-ins Gradle, ont généralement un impact moindre sur vos utilisateurs. La plupart des risques sont internes à votre build. La compilation elle-même permet de valider ces modifications. Les mises à niveau de bibliothèques et de SDK sont plus difficiles à valider et présentent un risque plus élevé pour vos utilisateurs. Plug-in Android Gradle (AGP) : ensemble d'outils utilisé 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 prise en charge de 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 des plug-ins Gradle change parfois. 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 de SDK nécessitent des modifications 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 de mises à niveau spécifiques
La mise à niveau de certains types de dépendances peut avoir un effet en cascade, nécessitant la mise à niveau d'autres types de dépendances. Nous abordons les relations entre les éléments de compilation dans la section Interdépendances entre les outils et les 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 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 les outils de compilation du SDK, 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 et les incompatibilités connus. 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 (tel 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. Pour les autres plug-ins de compilation, consultez leur documentation 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 sont souvent retardés, 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 apportées au langage ou les erreurs de 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 affecter 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, devez-vous:
- Modifier le code en cas de modification de l'API ?
- Ajouter de nouvelles vérifications d'autorisation ?
- Créez-vous des tests supplémentaires ou modifiez-vous des tests existants pour détecter les modifications 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 après, puis de les comparer.
Configurer et créer votre première référence
Avant de commencer la mise à niveau, vérifiez 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 d'avertissement vous 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 une cible probable, mais si vous souhaitez utiliser une autre configuration, exécutez ./gradlew dependencyGuard sans configuration listé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.
Enregistrez-le dans votre système de contrôle des versions (VCS).
N'oubliez pas que Dependency Guard ne capture que la liste des dépendances de 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 pourra é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é, réfléchissez aux risques potentiels de 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.
Points à prendre en compte:
Mises à jour majeures |
Le numéro de 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 devez 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 se lier à 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 de la mitigation. 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 grande 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 Dependency Check, demandez une clé API NVD, configurez le plug-in Gradle et exécutez |
Conflits de versions |
Les versions sont-elles résolues 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 Dans la mesure du possible, collaborez avec les auteurs d'une dépendance pour résoudre les conflits. 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 dans 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 celui 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 à source fermée, préparez-vous à écrire des scénarios de test supplémentaires pour 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 liés aux API
Android Lint peut détecter de nombreux problèmes dans votre application, y compris certains qui résultent de la modification des versions des dépendances ou du SDK Android. Par exemple, si vous mettez à niveau votre compileSdk et 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, il n'est généralement pas exécuté dans le cadre de votre compilation dans Studio ni lorsque vous exécutez une compilation par 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 de CI, veillez à exécuter gradlew lint au moins de temps en temps.
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 en 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 pourrez 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 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 si elle ne l'est plus), 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.