Resolving "Could not resolve all dependencies" Error in Gradle Android Projects: Comprehensive Guide to Android Support Library Configuration

Dec 03, 2025 · Programming · 13 views · 7.8

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:

  1. Open the Android SDK Manager (via Android Studio or command-line tools like android.bat or android).
  2. Under the "SDK Tools" tab, locate and check "Android Support Repository."
  3. Ensure "Android Support Library" is also installed to obtain the actual library files.
  4. 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:

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:

  1. Run ./gradlew --refresh-dependencies to force a refresh of the dependency cache.
  2. Use ./gradlew -i or ./gradlew --debug to obtain detailed logs, inspecting specific network requests and error messages.
  3. Check network connectivity and proxy settings to ensure access to https://dl.google.com (Google repository domain).
  4. Verify that the Android SDK path is correctly configured, particularly in environment variables like ANDROID_HOME or ANDROID_SDK_ROOT.
  5. 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.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.