NOTE: The lint model API is not yet stable; it is in active development. There is a TODO list at the end of this document which lists some of the planned work.
This library provides a build-system-agnostic view of the project layout, to be consumed by lint. It does not give a complete description of the project; it only contains information that lint cares about. For example, while the Gradle builder-model provides information such as the
applicationId of a given variant, the lint model does not contain that since it is not used by any lint checks.
The current shape of the API is heavily influenced by the builder-model library for the Android Gradle plugin: it contains concepts such as variants, source providers, artifacts, manifest place holders, and so on -- though it has removed a number of concepts such as product flavors and build types; these attributes from these have been merged and folded into the variants directly.
AndroidProject -> LintModelModule
ProjectType -> LintModelModuleType
Variant -> LintModelVariant
DependencyGraphs -> LintModelDependencies
GraphIten -> LintModelDependency
GlobalLibraryMap -> LintModelLibraryResolver
MavenCoordinates -> LintModelMavenName
- Create a project model which references the various lint models; handles the checkDependencies stuff, and includes whole project metadata like global lint rules, target platform (android vs jdk vs studio etc)
- Should the model have a build id?
- Add support for lint.jars not just at the library level
- Add a plugin for Gradle (depending on older versions, such as 3.6) which can spit out the XML model. That way you can point to it from a separate lint task (4.1).
- getTestSourceProviders() in LintModelVariant needs to not combine instrumentation and unit tests, as described in the javadoc.
- LintCliClient#addBootClassPath should use the bootclasspath from the lint model
- Replace the Project.dependsOn implementations and the various findLibrary lookups to make sure they're correct in terms of AndroidX handling; see AndroidxNameUtils.getCoordinateMapping(c)
- LintModelModuleProject has this question which is good: // TODO: Why direct here and all in test libraries? And shouldn‘t // this be tied to checkDependencies somehow? If we’re creating // project from the android libraries then I'll get the libraries there // right?
- I‘ve stubbed in the DependencyGraphs builder-model bridge but it’s not hooked up beyond the getDependencies(DependencyGraphs, GlobalLibraryMap) method
- Lazily construct File instances from Strings
- Look more deeply into project dependencies and how we model those
- Use switch statement in LintModelSerialization to more quickly multiplex
- Get rid of late-binding for Gradle model!