When you run Gradle Sync or build a project in Android Studio,
an error called “Could not GET” may be displayed.
This error occurs when Gradle accesses a repository to retrieve libraries, plugins, or other files,
but the HTTP or HTTPS communication fails.
The main possible causes include the internet connection, proxy, VPN, firewall, SSL certificate, and repository-side outages.
This article explains the main causes and solutions for the “Could not GET” error in Android Studio Gradle.
- What Is “Could not GET”?
- Main Causes
- Check the Details of the Error Message
- Check the Internet Connection
- Check the Destination URL
- Check the repositories Settings
- Check the Proxy Settings
- Check the Proxy Settings in gradle.properties
- Check the VPN
- Check the Firewall and Security Software
- Check Gradle Offline Mode
- Run Gradle Sync Again
- Retrieve Gradle Dependencies Again
- Check SSL Certificate-Related Errors
- Check the JDK Settings
- Check for Repository-Side Outages
- Check Whether an Old Repository URL Is Being Used
- If Only a Specific Repository Fails
- Check Repositories That Require Authentication
- Check the HTTP Status Code
- What to Check for Each Error
- Steps to Check If the Problem Is Not Resolved
- Summary
What Is “Could not GET”?
“Could not GET” is an error indicating that Gradle sent a GET request to the specified URL,
but could not successfully retrieve the required file.
For example, an error like the following may be displayed.
Could not GET 'https://repo.maven.apache.org/maven2/...'
In this case, Gradle attempted to connect to the displayed URL and retrieve a library or other file,
but the communication failed.
“Could not GET” may be displayed together with errors such as
Could not resolve all files for configuration
and
Could not resolve.
Main Causes
The main causes of the “Could not GET” error in Gradle include the following.
- No internet connection
- The network connection is unstable
- The repository cannot be reached
- The proxy settings are incorrect
- Communication is restricted by a VPN
- Communication is blocked by a firewall or security software
- There is a problem with the SSL certificate
- There is a problem with the JDK certificate settings
- The target repository is experiencing an outage
- An old URL or unavailable repository is being used
Point:
It is important to check not only “Could not GET,” but also the detailed errors displayed immediately after it,
such as
Connection timed out,
Connection refused, and
PKIX path building failed.
Check the Details of the Error Message
First, check the entire error displayed in the Build window or during Gradle Sync.
For example, an error like the following may be displayed.
Could not GET 'https://repo.maven.apache.org/maven2/...'
Connect timed out
In this case, you can see that Gradle attempted to connect to the repository,
but could not establish the connection within a certain period of time.
An error like the following may also be displayed.
Could not GET 'https://...'
Connection refused
In this case, the connection may be being refused by the destination server or the network.
Check the Internet Connection
Gradle retrieves the required libraries and plugins from external repositories.
If you cannot connect to the internet, the repository cannot be accessed,
causing
Could not GET
to occur.
Use a browser or another method to check whether you can connect to the internet normally.
If your Wi-Fi or other connection is unstable, reconnect to the network and then run Gradle Sync.
Check the Destination URL
The URL that Gradle could not access is displayed after “Could not GET.”
Could not GET 'https://example.com/maven/...'
By checking this URL, you can determine which repository Gradle failed to connect to.
If the problem occurs only with a specific Maven Repository, check the settings and operating status of that repository.
Check the repositories Settings
If Gradle is accessing an unnecessary or old repository,
a connection failure to that repository may cause the error.
In Android projects, Google Maven Repository and Maven Central are commonly used.
repositories {
google()
mavenCentral()
}
In current Gradle projects, repositories may be configured inside
dependencyResolutionManagement
in
settings.gradle
or
settings.gradle.kts.
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
Check whether repositories that are no longer needed or are currently unavailable are configured.
Check the Proxy Settings
On company or school networks, a proxy server may be required to connect to the external internet.
If the proxy settings in Android Studio or Gradle are incorrect,
the repository cannot be reached and
Could not GET
may occur.
Check the proxy settings in Android Studio and confirm that they match the network environment you are using.
Check the Proxy Settings in gradle.properties
In Gradle,
proxy settings may be configured in
gradle.properties.
systemProp.http.proxyHost=proxy.example.com
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=proxy.example.com
systemProp.https.proxyPort=8080
If proxy settings that were used previously remain in the file,
you may not be able to connect on the current network.
If you are in an environment that does not use a proxy, check whether unnecessary settings remain.
Check the VPN
If you are using a VPN, Gradle may fail to connect because of communication restrictions or routing on the VPN side.
Even if normal websites can be accessed,
connections only to Maven Central or Google Maven Repository may fail.
If you are using a VPN, check whether the error changes depending on whether the VPN connection is enabled or disabled.
Check the Firewall and Security Software
Communication from Java or Gradle may be blocked by a firewall or security software.
Even if websites can be accessed normally from a browser,
only external communication from Java processes may be restricted.
If Gradle Sync works normally on a different network environment,
the network or security settings currently being used may be the cause.
Check Gradle Offline Mode
If Gradle Offline mode is enabled,
Gradle basically resolves dependencies from the local cache without using the network.
If the required dependencies do not exist in the cache, the project cannot be built normally.
Check the Gradle settings in Android Studio,
and if Offline mode is enabled, disable it and then run Gradle Sync.
Run Gradle Sync Again
If the cause is a temporary network failure or a delayed response from the repository,
simply running Gradle Sync again may resolve the problem.
Run
Sync Project with Gradle Files
or a similar option from Android Studio.
If the error occurs only once and synchronization works normally afterward,
it may have been caused by a temporary communication failure.
Retrieve Gradle Dependencies Again
If there is a problem with the cache or retrieval state,
retrieving the dependencies again may resolve the issue.
Run the following from the project’s Terminal.
./gradlew build --refresh-dependencies
On Windows, depending on the environment, run the following.
gradlew.bat build --refresh-dependencies
This rechecks the dependencies and retries retrieving the required files.
Check SSL Certificate-Related Errors
If an SSL certificate cannot be properly verified when connecting to a repository over HTTPS,
Could not GET
may also be displayed.
For example, errors such as the following may be displayed together.
PKIX path building failed
SSLHandshakeException
In this case, check the JDK certificates, network environment, proxy, security software, and related settings.
On company or school networks, a system that intercepts HTTPS communication may prevent Java from properly verifying the certificate.
Check the JDK Settings
Because Gradle runs on Java, the JDK settings being used may affect communication.
In particular, if an SSL certificate-related error is displayed,
check the Gradle JDK being used in Android Studio.
Check whether a JDK compatible with the project and Android Gradle Plugin is selected.
Check for Repository-Side Outages
Even if there is no problem with your environment,
a temporary outage may occur on the repository you are trying to access.
In that case, only a specific repository may be unreachable,
or running Gradle Sync again after some time may allow the files to be retrieved normally.
If only the same URL fails even on multiple network environments,
the repository itself may be experiencing a problem.
Check Whether an Old Repository URL Is Being Used
Old Android projects or old sample code may contain repository URLs that are no longer available.
Even a URL that was previously available may become inaccessible because the repository has moved or the service has ended.
Check the current official documentation for the library you are using,
and confirm that the latest distribution repository is configured.
If Only a Specific Repository Fails
You may be able to connect to Google Maven Repository and Maven Central,
while
Could not GET
occurs only with a custom Maven Repository.
In this case, check the repository URL, service status, and whether authentication is required.
If the repository is not being used, it may be possible to remove it from the configuration.
Check Repositories That Require Authentication
Some Maven Repositories may require authentication information such as a username and password for access.
If authentication information is not configured or is no longer valid,
Gradle cannot retrieve the files.
Check the official documentation for the repository you are using,
and confirm whether authentication settings are required.
Check the HTTP Status Code
An HTTP status code may be displayed together with “Could not GET.”
| Status Code | Main Meaning |
|---|---|
| 401 | Authentication is required, or there is a problem with the authentication information |
| 403 | Access is denied |
| 404 | The file does not exist at the specified URL |
| 500 | Internal error on the repository side |
| 502・503・504 | Temporary problem with the server or communication route |
If a status code is displayed, its contents make it easier to determine whether the problem is related to the network,
authentication, or the repository itself.
What to Check for Each Error
The error displayed together with “Could not GET” can help narrow down what should be checked.
| Displayed Error | Main Points to Check |
|---|---|
| Connection timed out | Network, proxy, firewall |
| Connection refused | Destination server, network settings |
| Unknown host | DNS, network, URL |
| PKIX path building failed | SSL certificate, JDK, proxy |
| 401 Unauthorized | Authentication information |
| 403 Forbidden | Access permissions, authentication, repository settings |
| 404 Not Found | URL, library, version |
Steps to Check If the Problem Is Not Resolved
If you do not know the cause, checking the following in order makes it easier to narrow down the problem.
- Check the URL displayed after “Could not GET”
- Check the detailed error displayed immediately afterward
- Check the internet connection
- Run Gradle Sync again
- Check Gradle Offline mode
- Check the
repositoriessettings - Check whether an old repository URL remains
- Check the proxy settings
- Check the proxy settings in
gradle.properties - Check the VPN and firewall
- Check the SSL certificate and JDK settings
- If an HTTP status code is displayed, check its contents
- Check whether the repository is experiencing an outage
Important:
“Could not GET” is an error indicating that Gradle communicated with the destination,
but failed to retrieve the file.
First, it is important to check the URL that could not be accessed and the detailed communication error displayed immediately afterward.
Summary
The Android Studio Gradle
“Could not GET”
error is displayed when Gradle accesses a repository to retrieve libraries, plugins, or other files,
but the communication fails.
The cause may be not only the internet connection, but also a proxy, VPN, firewall,
SSL certificate, JDK, repository URL, or repository-side outage.
First, check the URL displayed after
Could not GET
and detailed errors such as
Connection timed out,
Connection refused, and
PKIX path building failed,
and narrow down where in the communication path the problem is occurring to address it efficiently.
