Gradle Dependency Resolution Engine: Dependency Graphs and Version Conflict Arbitration Strategies

Gradle's dependency resolution is not as simple as "downloading a jar for implementation('group:name:version')." It is a constraint-solving engine operating over a complex graph.

In Android engineering, dependency issues rarely stem from merely missing a single library. Usually, several models collide simultaneously:

• Configurations like implementation, api, and runtimeOnly dictate which classpath a dependency enters.
• Direct and transitive dependencies fuse into a sprawling dependency graph.
• Multiple versions of the same module trigger version conflict arbitration.
• Libraries with different coordinates but providing the identical capability trigger capability conflicts.
• A single component might publish multiple variants; Gradle must select the correct artifact based on consumer attributes.
• The varying completeness of Maven POMs, Gradle Module Metadata, and Ivy metadata directly impacts resolution outcomes.

Imagine dependency resolution as a massive logistics distribution center. Build scripts merely submit procurement lists. The actual cargo delivered to the compiler and packager must survive supplier identification, warehouse routing, version arbitration, compatibility checks, and final boxing. The compileClasspath, runtimeClasspath, and debugRuntimeClasspath that an Android app ultimately receives are not literal expansions of the procurement list—they are the mathematically solved results of Gradle analyzing the entire graph.

This article focuses on the deepest bedrock of the dependency management directory: how Gradle translates declarative dependencies into executable, diagnosable, and cacheable resolution results.

Dependency Declarations Are Not Resolution Results

Writing this in build.gradle.kts:

dependencies {
    implementation("com.squareup.okhttp3:okhttp:4.12.0")
    debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14")
}

These two lines merely register dependency declarations within the Project model. They do not trigger immediate jar downloads, nor do they instantly lock in the final version. Actual resolution typically occurs only when a resolvable configuration is consumed—for instance, when a Kotlin compilation task reads the debugCompileClasspath, when D8/R8 reads the runtime classpath, or when you execute diagnostic tasks like dependencies or dependencyInsight.

Gradle's configurations can be roughly divided into three categories:

This categorizes why placing the exact same dependency in implementation versus api yields different behaviors. They are not simply aliases for "download scopes"; they are inputs injected into entirely different configuration graphs.

The typical dependency flow of a Java/Android Library can be simplified like this:

dependencies {
  api(...)              ─┐
                         ├─> apiElements      ──> Visible to downstream compileClasspath
  implementation(...)   ─┼─> runtimeElements  ──> Visible to downstream runtimeClasspath
                         └─> Visible to own compile/runtime classpath
}

api is exposed to the downstream compile phase; implementation only enters the module's own compile phase and the downstream runtime phase. This boundary is fundamentally a part of variant metadata, not a superficial restriction enforced by the IDE.

The Two-Phase Model of the Resolution Engine

The official Gradle architecture splits dependency resolution into two massive phases:

Resolvable Configuration
   |
   | 1. Graph Resolution
   |    Builds the resolved dependency graph, solves version conflicts, selects component variants
   v
Resolved Component/Variant Graph
   |
   | 2. Artifact Resolution
   |    Maps variants in the graph to physical files; downloads jar/aar/module/pom
   v
File Collection: jar, aar, classes, resources, metadata

Separating these two phases is highly critical.

The Graph Resolution phase cares exclusively about "who belongs in the graph." It processes component coordinates, version selection, transitive dependencies, constraints, capability conflicts, and variant selection. Resolution results can be read via ResolutionResult, where the core objects are ResolvedComponentResult, ResolvedVariantResult, and the edges between them.

The Artifact Resolution phase cares exclusively about "where the files are." The same component variant might possess a primary jar, a sources jar, a javadoc jar, an AAR, native libraries, or a classes directory. Gradle can overlay an ArtifactView atop an already-resolved graph to extract a subset of these files, without needing to mathematically solve the entire dependency graph again.

This stratified design solves two engineering problems:

• When diagnosing the dependency graph, you don't need to download every artifact.
• The same resolved graph can be reused by multiple artifact views. For example, compilation requires the classpath, packaging requires runtime artifacts, and the IDE might request source code or documentation.

Dependency Graph Nodes are Variants, Not JARs

Dependency nightmares are notoriously hard to debug because developers intuitively envision graph nodes as "jar files." Gradle's true model is far more granular:

Module: com.fasterxml.jackson.core:jackson-databind
  |
  `-- Component: com.fasterxml.jackson.core:jackson-databind:2.17.2
        |
        |-- Variant: apiElements
        |     |-- attributes: org.gradle.usage = java-api
        |     |-- dependencies: jackson-annotations, jackson-core, jackson-bom
        |     `-- artifact: jackson-databind-2.17.2.jar
        |
        `-- Variant: runtimeElements
              |-- attributes: org.gradle.usage = java-runtime
              |-- dependencies: jackson-annotations, jackson-core
              `-- artifact: jackson-databind-2.17.2.jar

Several terms must be strictly distinguished:

This elucidates a common Android project phenomenon: the exact same module can simultaneously offer debug/release, api/runtime, and jvm/android/native exit points. Gradle doesn't guess based on the variant's string name; it strictly selects variants based on attributes.

Source Code Perspective: How DependencyGraphBuilder Traverses the Graph

In the Gradle source code, DependencyGraphBuilder is the entry point for understanding the resolution loop. Its resolve(...) method instantiates a ResolveState and then executes three sequential actions:

ResolveState resolveState = new ResolveState(...);

traverseGraph(resolveState);
validateGraph(resolveState, ...);
assembleResult(resolveState, modelVisitor);

Compressed into pseudocode, the core loop resembles this:

Place the root variant into the processing queue

while queue is not empty OR unresolved conflicts exist:
  if queue is not empty:
    node = dequeue

    if node has been replaced or no longer contributes to the graph:
      remove its outgoing edges
      continue

    if capability handler detects a capability conflict:
      pause processing this node, wait for conflict arbitration
      continue

    edges = collect node's outgoing dependencies
    perform version selection for each edge
    PARALLEL: download metadata for target components that require it
    SERIAL: attach the edge to the selected target variant
  else:
    First resolve module version conflicts
    Then resolve capability conflicts

Two details in the source code vividly illustrate Gradle's engineering compromises.

The first detail is that metadata downloads can be parallelized. maybeDownloadMetadataInParallel(...) gathers target components requiring remote metadata; if there is more than one, it submits them to the build operation queue for parallel execution. Dependency resolution is not a pure CPU algorithm; remote repository requests and POM/module metadata downloads act as massive I/O bottlenecks.

The second detail is that attaching edges back into the graph must be serialized. The comments for attachToTargetRevisionsSerially(...) explicitly warn: if edges are added back to the queue directly within resolution threads, it induces a non-deterministic graph order. Gradle would rather parallelize the "downloads" and serialize the "graph structure mutations" to absolutely guarantee that identical inputs yield perfectly stable results.

This represents the chasm between a build tool and a generic downloader. A generic downloader only cares about speed. A build tool must care about reproducibility, diagnosability, and cacheability.

Version Conflicts: Only One Component Per Module

The most ubiquitous conflict occurs when the exact same module is requested at different versions by different paths:

:app
  |-- com.google.guava:guava:20.0
  |
  `-- com.google.inject:guice:4.2.2
        `-- com.google.guava:guava:25.1-android

By default, Gradle will select one version for com.google.guava:guava within the same dependency graph. The official documentation's baseline rule is: Gradle considers all requested versions in the graph and defaults to selecting the highest version.

This strategy is not "whoever is closer to the root wins," nor is it "explicit declarations always override transitive dependencies." A direct dependency is merely one selector in the graph; a transitive dependency is also a selector. They all aggregate into the candidate pool for the same module, and the conflict resolver renders the final verdict.

Imagine multiple teams simultaneously procuring the same part:

Team A requests guava 20.0
Team B requests guava 25.1-android
Team C requests guava [23, 33)

The procurement system cannot install three distinct guavas into the same machine.
It must locate a globally acceptable version that satisfies all demands.

In the Gradle source, LatestModuleConflictResolver proves that the default "pick highest" is not a naive string comparison. It will:

1. Use VersionParser to parse the version string into a structured version.
2. Use VersionComparator to compare the base version.
3. Isolate the candidate set with the highest base version.
4. If multiple candidates share the same base version, it further arbitrates based on qualifiers, release status, Maven snapshot markers, etc.

Thus, 1.0.0, 1.0.0-rc1, and 1.0.0-SNAPSHOT are not arbitrarily sorted by string length or alphabet. Gradle applies its own rigorous version parsing and state-evaluation logic.

Rich Version: Turning "Wants" into "Constraints"

A standard version declaration:

implementation("org.slf4j:slf4j-api:2.0.13")

...expresses a simple selector. In complex engineering, merely stating "I want this version" is often insufficient. You need the vocabulary to express:

• This version is just a preference; stronger constraints can override it.
• This version must be strictly met; otherwise, fail the build.
• Certain broken versions must be violently rejected.
• Any version within a specific range is acceptable.

Gradle utilizes "rich versions" to articulate these semantics:

dependencies {
    implementation("org.slf4j:slf4j-api") {
        version {
            strictly("[2.0, 3.0[")
            prefer("2.0.13")
            reject("2.0.9")
        }
        because("Keep logging API major version stable, while dodging known bad versions")
    }
}

The semantic boundaries differ substantially:

strictly is the most dangerously misused tool in large Android projects. It is not an elegant syntax for a "forced upgrade"; it injects a hard, uncompromising constraint into the resolver. If multiple modules author mutually incompatible strictly bounds, Gradle is under no obligation to guess a compromise version—it will, and should, fail the build.

Robust version governance operates in hierarchical layers:

libs.versions.toml      Consolidates coordinate declarations and common version aliases.
platform / BOM          Aligns versions across a cohesive set of modules.
dependency constraints  Injects publishable constraints onto transitive dependencies.
component metadata rule Patches factual errors inside third-party metadata.
resolutionStrategy      The absolute last resort fallback; use sparingly and always with a 'because'.

The subsequent article will thoroughly dissect Version Catalogs and BOMs. For now, etch this into your mind: A Version Catalog is not a resolution rule; it is merely an entry point for declarations. True conflict arbitration is waged by dependency declarations, platforms, constraints, metadata, and resolution strategies.

Dependency Constraints: Participating in Arbitration Without Introducing Dependencies

constraints are easily misunderstood as "just another type of implementation." Its paramount semantic trait is: a constraint itself will never pull a module into the dependency graph. The constraint only participates in version arbitration if that module is already introduced into the graph via some other path.

dependencies {
    implementation("com.example:feature-a:1.0")

    constraints {
        implementation("org.apache.commons:commons-lang3") {
            version {
                strictly("3.14.0")
            }
            because("Unify transitive dependency versions to prevent runtime API drift")
        }
    }
}

If feature-a (or any other dependency) never introduces commons-lang3, the constraint above will not spawn a jar out of thin air. It acts as a procurement red-line in a warehouse: the red-line only triggers if the specific material actually appears on an incoming order.

This trait is invaluable for Android multi-module architectures. Injecting constraints into a centralized java-platform or a convention plugin allows modules to align transitive dependency versions without repeatedly declaring them, preventing the accidental bloating of the APK with unused libraries just to "control a version."

Capability Conflicts: Different Coordinates Can Be Mutually Exclusive

Version conflicts arbitrate "multiple versions of the same module." Capability conflicts arbitrate "different modules providing the same capability."

Classic examples include logging bindings, connection pool implementations, or duplicated libraries stemming from legacy coordinate migrations:

runtimeClasspath
  |-- ch.qos.logback:logback-classic
  `-- org.slf4j:slf4j-simple

Both modules potentially provide the SLF4J binding.
At runtime, only one can truly assume control of logging output.

Naked Maven coordinates are blind to this conflict because their group/name pairs are entirely distinct. Gradle introduced capabilities precisely to transmute "functional equivalence or mutual exclusivity" into machine-readable metadata.

dependencies {
    components {
        withModule("org.slf4j:slf4j-simple") {
            allVariants {
                withCapabilities {
                    addCapability("org.slf4j", "slf4j-binding", id.version)
                }
            }
        }
        withModule("ch.qos.logback:logback-classic") {
            allVariants {
                withCapabilities {
                    addCapability("org.slf4j", "slf4j-binding", id.version)
                }
            }
        }
    }
}

configurations.configureEach {
    resolutionStrategy.capabilitiesResolution
        .withCapability("org.slf4j:slf4j-binding") {
            select("ch.qos.logback:logback-classic:1.5.6")
            because("Unify application runtime to use logback as the SLF4J binding")
        }
}

When Gradle detects multiple identical capabilities within the same dependency graph, it typically halts and reports a conflict. This failure is immensely beneficial: it hauls a lethal runtime explosion ("two implementations fighting for the same entry point") violently forward into the build phase.

Variant-Aware Resolution: Gradle Selects the Usage Scenario

Modern Gradle dependency resolution is heavily variant-aware. A component can publish an array of variants, with each variant utilizing attributes to broadcast the exact usage scenario it is designed for.

A consumer configuration also carries attributes, articulating exactly what it demands:

consumer: debugRuntimeClasspath
  org.gradle.usage              = java-runtime
  org.gradle.category           = library
  org.gradle.libraryelements    = jar / aar
  com.android.build.api.attributes.BuildTypeAttr = debug

producer: :library
  debugRuntimeElements
    usage = java-runtime
    buildType = debug

  releaseRuntimeElements
    usage = java-runtime
    buildType = release

Gradle's job isn't lazily "finding a configuration named debug." It injects both the consumer attributes and the producer variant attributes into an AttributeMatcher.

GraphVariantSelector within the source code illustrates this path:

Candidate Variants
   |
   |-- First, filter by requested capabilities
   |
   |-- AttributeMatcher.matchMultipleCandidates(...)
   |
   |-- If multiple candidates survive, attempt strict capability matching
   |
   |-- If ambiguity remains, throw ambiguous variants failure

Deep inside DefaultAttributeMatcher lives an extremely critical method: allCommonAttributesSatisfy(...). It only verifies compatibility for attributes shared by both the consumer and the candidate. If the requested attributes are empty, or the candidate attributes are empty, the baseline matching might perceive them as non-conflicting. Only when multiple candidates survive does it funnel them into MultipleCandidateMatcher for disambiguation.

This clarifies two recurring engineering phenomena:

1. Missing attributes do not immediately equate to incompatibility; Gradle may simply proceed to downstream disambiguation.
2. When variant matching fails, the attribute discrepancies listed in the error log are vastly more critical than the variant's string name.

The official algorithm unfolds roughly as follows:

1. Filter out incompatible candidates.
2. If exactly one survives, select it.
3. Disambiguate against requested attributes by priority.
4. Disambiguate against additional candidate attributes.
5. If a unique determination is still impossible, fail.

The Android Gradle Plugin relies entirely on this mechanism to ensure a debug app consumes a debug library, a runtime classpath consumes a runtime variant, and a test APK pairs flawlessly with its corresponding main APK variant.

Metadata Dictates Resolution Quality

Gradle requires metadata to resolve dependencies. Different publication formats possess vastly different expressive capacities:

If a third-party library's metadata is flawed, the error cascades down the dependency graph. For example:

• A POM inaccurately flags a dependency as required when it is only optional for a specific feature.
• A library migrates coordinates, but the old coordinates fail to declare the capability of the new coordinates.
• A library ships -jre and -android architectures, but its metadata fails to model them as discrete variants.
• Transitive dependency declarations are overly broad, dragging unused libraries into the Android APK.

In these scenarios, do not reflexively write global exclude rules. The surgically precise remediation is a Component Metadata Rule:

abstract class Slf4jBindingCapabilityRule : ComponentMetadataRule {
    override fun execute(context: ComponentMetadataContext) {
        context.details.allVariants {
            withCapabilities {
                addCapability("org.slf4j", "slf4j-binding", context.details.id.version)
            }
        }
    }
}

dependencies {
    components {
        withModule("org.slf4j:slf4j-simple", Slf4jBindingCapabilityRule::class.java)
    }
}

The unparalleled value of a metadata rule is that it patches "the facts of the component" rather than brutally hacking off graph edges on a specific consumer configuration. Once patched, Gradle's downstream version arbitration, capability conflict resolution, and variant selection will continue to function seamlessly according to the mathematical model.

Exclude Is Cutting an Edge, Not a Cure

This syntax is pervasive in Android engineering:

implementation("com.example:legacy-sdk:1.0") {
    exclude(group = "commons-logging", module = "commons-logging")
}

The true semantic of exclude is merely severing a specific transitive dependency from this particular dependency edge. It is not a global module ban, nor does it guarantee that your runtime code paths will actually survive without the library.

:app
  |
  |-- legacy-sdk --X--> commons-logging
  |
  `-- other-sdk ------> commons-logging

The exclude on legacy-sdk only severs the first edge.
If other-sdk still demands it, commons-logging will inevitably bleed into the graph.

When is exclude acceptable?

• You have definitively confirmed the metadata is flawed; the library declares a transitive dependency it never actually utilizes.
• You have definitively confirmed your current code execution paths will never trigger the classloading of the excluded library.
• You have robust test coverage verifying critical execution paths.
• Superior tools like constraints, capabilities, or metadata rules are incapable of expressing the factual reality.

Otherwise, exclude threatens to mutate a build-time conflict into a runtime ClassNotFoundException, NoSuchMethodError, or a catastrophic Android startup crash.

Why Android Dependency Conflicts Are More Dangerous

Standard JVM applications suffer dependency conflicts, but Android's risk profile is exponentially higher.

First, the final APK/AAB does not simply dump all jars directly to a JVM. The Android build pipeline forces jars through D8/R8, merging classes into dex files while executing desugaring, shrinking, optimization, and obfuscation. API discrepancies birthed by version conflicts can detonate at any stratum: during compilation, dex merging, R8 optimization, or runtime.

Second, the Android runtime utterly lacks the forgiving classpath debugging leeway afforded to traditional Java server environments. If a transitive dependency is upgraded, and legacy code attempts to invoke a method annihilated in the new version, the standard results are:

java.lang.NoSuchMethodError
java.lang.NoClassDefFoundError
java.lang.IncompatibleClassChangeError
Duplicate class ... found in modules ...

Third, AGP heavily weaponizes variant attributes. If a local library fails to correctly publish debugRuntimeElements, or if a custom plugin spawns a consumable configuration missing crucial attributes, Gradle might silently select the wrong variant, or violently crash with an ambiguous variant error.

Therefore, Android dependency governance must treat "successful compilation" as the absolute minimum baseline, not proof of correctness. The only bulletproof methodology is forcing the Gradle model to reflect authentic constraints: utilize platforms for version alignment, constraints for transitive versioning, capabilities for mutually exclusive implementations, and component metadata rules for patching flawed facts—leaving exclude and force as absolute last resorts.

dependencyInsight: Tracing the Arbitration Chain

When dependency outcomes defy expectations, the supreme diagnostic weapon is dependencyInsight:

./gradlew :app:dependencyInsight \
  --configuration debugRuntimeClasspath \
  --dependency com.google.guava:guava

Do not merely verify "does the library exist." Scrutinize three vectors:

1. Which version was ultimately selected?
2. Why was it selected? (conflict resolution / constraint / forced / selected by rule)
3. Which paths requested it?

If you observe:

com.google.guava:guava:20.0 -> 33.4.8-android
   Selection reasons:
      - By conflict resolution: between versions 20.0 and 33.4.8-android

It confirms that your direct declaration did not "override" the transitive dependency. Gradle executed full-graph version arbitration and elevated the selection to the higher version.

If you observe a capability conflict, verify if it masks a missing model:

Cannot choose between ...
All of them match the consumer attributes
They provide the same capability ...

Do not hack through these issues with exclude. First, determine architecturally which implementation the business logic must retain, and then utilize capabilitiesResolution or metadata rules to encode that decision with absolute clarity.

If variant selection fails, intensely audit the attributes:

No matching variant of project :library was found.
The consumer was configured to find a runtime of a library ...

The root cause of these errors is virtually always that the producer failed to expose the requisite usage/buildType/flavor/libraryElements, or that the consumer requested an attribute entirely outside the semantic space of the producer's variant geometry.

A Complete Conflict Governance Example

Assume an Android application generates this dependency graph:

:app
  |-- com.fasterxml.jackson.core:jackson-databind:2.13.0
  |
  `-- com.example:network-sdk:1.8.0
        |-- com.fasterxml.jackson.core:jackson-core:2.17.2
        `-- com.fasterxml.jackson.core:jackson-annotations:2.17.2

Relying purely on default highest-version arbitration might yield:

jackson-databind      2.13.0
jackson-core          2.17.2
jackson-annotations   2.17.2

This matrix might not trigger an immediate compilation failure, but for deeply coupled libraries like Jackson that co-evolve across modules, mixing versions invites volatile runtime behavior. The architecturally sound model is not hardcoding the highest version in every submodule, but declaring a platform alignment:

dependencies {
    implementation(platform("com.fasterxml.jackson:jackson-bom:2.17.2"))

    implementation("com.fasterxml.jackson.core:jackson-databind")
    implementation("com.example:network-sdk:1.8.0")
}

Now, the Gradle parser receives a cohesive web of version constraints rather than a pile of disparate strings. Any Jackson platform member surfacing in the graph is strictly aligned according to the constraints provisioned by the BOM.

If a specific third-party ecosystem fails to publish a BOM, you can centrally synthesize an internal java-platform:

plugins {
    `java-platform`
}

dependencies {
    constraints {
        api("com.fasterxml.jackson.core:jackson-databind:2.17.2")
        api("com.fasterxml.jackson.core:jackson-core:2.17.2")
        api("com.fasterxml.jackson.core:jackson-annotations:2.17.2")
    }
}

Android modules then consume this internal platform. This architecture allows constraints to co-evolve alongside project version governance, rather than decaying in the build.gradle.kts files of fifty fragmented modules.

The Design Trade-offs Behind the Resolution Engine

The intimidating complexity of Gradle dependency resolution stems from multiple intersecting objectives demanding simultaneous fulfillment:

Once these trade-offs are internalized, many esoteric rules become starkly logical:

• Never use force as the primary tool for version governance; it brutally bypasses refined constraint semantics.
• Never deploy a global exclude to mask flawed metadata; it severs graph edges but ignores physical facts.
• Never treat the Version Catalog as a BOM; catalogs do not participate in transitive dependency arbitration.
• Never disregard variant attributes; Android's debug/release/flavor topologies rely absolutely upon this selection apparatus.
• Never permit dynamic versions into core classpaths without constraint; resolution outcomes will warp based on repository mutation.

Industrial-Grade Android Dependency Resolution Guidelines

A rock-solid Android dependency governance strategy must adhere to the following sequence:

1. Use the Version Catalog to govern human-readable coordinate entry points, but do not expect it to solve conflicts.
2. Use a BOM or java-platform to rigidly align modules belonging to the same technology stack.
3. Use dependency constraints to govern minimum versions, strict versions, and rejected versions for transitive dependencies.
4. Use component metadata rules to surgically patch factual errors in third-party publication metadata.
5. Use capabilities to assert mutually exclusive implementations, forcing conflicts to cleanly detonate at build time.
6. Use dependencyInsight and ResolutionResult to diagnose the authentic mathematical graph—never guess outcomes merely by staring at declaration files.
7. Deploy exclude only when absolute certainty exists that the execution path remains safe.
8. Weaponize failOnDynamicVersions(), failOnChangingVersions(), and dependency locking exclusively for release pipelines to obliterate non-reproducible resolutions.

The core essence of Gradle's dependency resolution engine is not to "automatically pick versions for you." It is to provision a dialect through which the build system can meticulously express facts and constraints. Superior build logic forces conflicts to expose themselves clearly at the model layer, establishing observable, auditable diagnostic paths; inferior build logic drags model-layer catastrophes all the way into D8, R8, or, ultimately, the user's device.

References

• Gradle User Manual: Dependency Resolution: https://docs.gradle.org/current/userguide/dependency_resolution.html
• Gradle User Manual: Graph Resolution: https://docs.gradle.org/current/userguide/graph_resolution.html
• Gradle User Manual: Variant Selection and Attribute Matching: https://docs.gradle.org/current/userguide/variant_aware_resolution.html
• Gradle User Manual: Variants and Attributes: https://docs.gradle.org/current/userguide/variant_attributes.html
• Gradle User Manual: Dependency Constraints and Conflict Resolution: https://docs.gradle.org/current/userguide/dependency_constraints_conflicts.html
• Gradle User Manual: Declaring Dependency Constraints: https://docs.gradle.org/current/userguide/dependency_constraints.html
• Gradle User Manual: Declaring Versions and Ranges: https://docs.gradle.org/current/userguide/dependency_versions.html
• Gradle User Manual: Capabilities: https://docs.gradle.org/current/userguide/component_capabilities.html
• Gradle User Manual: Component Metadata Rules: https://docs.gradle.org/current/userguide/component_metadata_rules.html
• Android Developers: Gradle dependency resolution: https://developer.android.com/build/gradle-dependency-resolution
• Gradle source: DependencyGraphBuilder: https://github.com/gradle/gradle/blob/master/platforms/software/dependency-management/src/main/java/org/gradle/api/internal/artifacts/ivyservice/resolveengine/graph/builder/DependencyGraphBuilder.java
• Gradle source: LatestModuleConflictResolver: https://github.com/gradle/gradle/blob/master/platforms/software/dependency-management/src/main/java/org/gradle/api/internal/artifacts/ivyservice/resolveengine/LatestModuleConflictResolver.java
• Gradle source: GraphVariantSelector: https://github.com/gradle/gradle/blob/master/platforms/software/dependency-management/src/main/java/org/gradle/internal/component/model/GraphVariantSelector.java
• Gradle source: DefaultAttributeMatcher: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/attributes/matching/DefaultAttributeMatcher.java