Keywords: Gradle build error | Android dependency resolution | Android support libraries
Abstract: This article provides an in-depth analysis of the common "Could not resolve all dependencies" error encountered when building Android projects with Gradle, specifically focusing on dependency resolution failures for Android support libraries such as support-v4 and appcompat-v7. Based on high-scoring Stack Overflow answers, the article systematically explains the root cause—Android support libraries are not available in Maven Central—and presents three solutions: installing the Android Support Repository via Android SDK Manager, configuring the Google online Maven repository, and using the sdkmanager command-line tool. Each method is detailed with implementation steps, applicable scenarios, and considerations, helping developers thoroughly understand Android dependency management mechanisms to avoid similar build errors.
Problem Background and Error Analysis
In Android app development, using Gradle as the build tool has become standard practice. However, developers often encounter the "Could not resolve all dependencies" build error when initially configuring Gradle projects, particularly when introducing Android support libraries such as com.android.support:support-v4 and com.android.support:appcompat-v7. From the provided console output, it is evident that Gradle attempts to download these dependencies from the Maven Central repository (http://repo1.maven.org/maven2/), but returns "Resource missing" errors, ultimately causing the build to fail.
Root Cause: Repository Location of Android Support Libraries
The core issue is that Android support libraries are not hosted in the standard Maven Central repository. Many developers mistakenly assume that all Java/Android libraries can be resolved via the mavenCentral() repository, but in reality, Google stores proprietary components like Android support libraries and Play services in separate repositories. Below is a typical example of incorrect configuration:
repositories {
mavenCentral()
}
dependencies {
compile "com.android.support:support-v4:18.0.+"
compile "com.android.support:appcompat-v7:18.0.+"
}
When Gradle executes, it requests metadata files (e.g., maven-metadata.xml) for these dependencies from Maven Central. Since these libraries are not present in that repository, the server returns 404 errors, leading to dependency resolution failure.
Solution 1: Install Android Support Repository (Local Approach)
The most direct solution is to install the "Android Support Repository" via the Android SDK Manager. This repository contains Maven artifacts for all Android support libraries and, once installed, is placed in the extras folder of the Android SDK directory. Specific steps include:
- Open the Android SDK Manager (via Android Studio or command-line tools like
android.batorandroid). - Under the "SDK Tools" tab, locate and check "Android Support Repository."
- Ensure "Android Support Library" is also installed to obtain the actual library files.
- Click "Install" to complete the installation.
After installation, Gradle automatically detects the repository in the local SDK directory, resolving dependencies without additional configuration. This method is suitable for all Android development environments, including offline or internal network scenarios.
Solution 2: Configure Google Online Maven Repository (Recommended Approach)
With the evolution of Android development tools, Google now provides an online Maven repository that developers can reference directly in build.gradle files. This is currently the most recommended method as it simplifies configuration and ensures access to the latest versions. A configuration example is as follows:
repositories {
google()
jcenter()
}
dependencies {
implementation "com.android.support:support-v4:28.0.0"
implementation "com.android.support:appcompat-v7:28.0.0"
}
Note several key improvements:
- Use the
google()repository instead ofmavenCentral()to access Android-specific libraries. - Add
jcenter()as a general-purpose repository hosting many popular open-source libraries. - Change dependency configuration from
compiletoimplementation(recommended for Gradle 3.0+), providing better control over dependency transitivity. - Avoid dynamic version numbers (e.g.,
18.0.+) in favor of fixed versions (e.g.,28.0.0) to enhance build reproducibility.
Solution 3: Command-Line Tools and CI Environment Configuration
For headless CI (Continuous Integration) environments or scripted installations, command-line tools can manage Android SDK components. The traditional method uses the android update sdk command:
android update sdk --no-ui --filter extra-android-m2repository,extra-google-m2repository
However, note that starting from Android SDK Tools version 22.6.4, the android command has been deprecated and replaced by the sdkmanager tool. The new workflow is as follows:
# List all available components
sdkmanager --list
# Install Android support repositories
sdkmanager "extras;android;m2repository"
sdkmanager "extras;google;m2repository"
# Install specific versions of build tools and platforms
sdkmanager "build-tools;28.0.3"
sdkmanager "platforms;android-28"
This approach is particularly suitable for automated deployments and CI/CD pipelines, ensuring consistency in build environments.
Best Practices for Project Configuration
Based on the above analysis, we rewrite a complete and correct build.gradle file example:
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath "com.android.tools.build:gradle:3.5.0"
}
}
apply plugin: "com.android.application"
android {
compileSdkVersion 28
buildToolsVersion "28.0.3"
defaultConfig {
minSdkVersion 16
targetSdkVersion 28
versionCode 1
versionName "1.0"
}
}
repositories {
google()
jcenter()
}
dependencies {
implementation "com.android.support:support-v4:28.0.0"
implementation "com.android.support:appcompat-v7:28.0.0"
// Optional: Add constraint layout library
implementation "com.android.support.constraint:constraint-layout:1.1.3"
}
Key improvements include using the latest Gradle plugin version, explicitly specifying SDK versions, adopting implementation for dependencies, and correctly ordering repositories (Google repository first).
Troubleshooting and Debugging Techniques
If dependency resolution issues persist, the following debugging steps can be taken:
- Run
./gradlew --refresh-dependenciesto force a refresh of the dependency cache. - Use
./gradlew -ior./gradlew --debugto obtain detailed logs, inspecting specific network requests and error messages. - Check network connectivity and proxy settings to ensure access to
https://dl.google.com(Google repository domain). - Verify that the Android SDK path is correctly configured, particularly in environment variables like
ANDROID_HOMEorANDROID_SDK_ROOT. - For corporate internal networks, configuring mirror repositories or local Nexus repositories to proxy Google repositories may be necessary.
Conclusion and Summary
The "Could not resolve all dependencies" error is common in Android Gradle projects but easily resolvable. The root cause is that Android support libraries are not located in Maven Central and must be fetched from Google-specific repositories. This article presented three solutions: installing the local Android Support Repository, configuring the Google online repository, and using command-line tools to manage SDK components. Among these, configuring the google() online repository is the simplest and most recommended method, applicable to most development scenarios and ensuring dependency currency. By correctly understanding Android dependency management mechanisms and following best practices, developers can avoid such build errors and improve development efficiency.
As Android development tools continue to evolve, developers are advised to regularly update Gradle plugins, Android SDK Tools, and dependency library versions to benefit from performance improvements and new features. Additionally, unifying build configurations in team projects and using dependency version management (e.g., ext variables or version catalogs) can further reduce the occurrence of build issues.