Gradle and Proxy Authentication in Android Studio
2 min read

Gradle and Proxy Authentication in Android Studio

Gradle and Proxy Authentication in Android Studio

Update: This is obsolete as Android Studio is going to eliminate JVM arguments for gradle. See this post for a more future-proof approach.

The other day I did an exercise to install Android Studio ("AS" henceforth) (0.8.4 at the moment of writing) and create a project with gradle in an environment with an authenticated proxy. It didn't work out of the box, of course. Worse, it generated an exception (internal error). I found two solutions to make it work:

  1. Via configuration file
  2. JVM variables

Configuration file

When you create a project in AS, it'll have a gradle.properties file in the root directory. This file contains configuration information for gradle (d'oh!).

By default, the file is empty (or, to be more accurate, it has a bunch of information in comments). All you need to do is to add the relevant data:

# /gradle.properties

systemProp.http.proxyHost=www.somehost.org
systemProp.http.proxyPort=8080
systemProp.http.proxyUser=userid
systemProp.http.proxyPassword=password
systemProp.http.nonProxyHosts=*.nonproxyrepos.com|localhost

The entries are self-explanatory.

However, this apparently does not work in some instances. If that's the case, just follow the accepted answer :)

JVM Variables

Gradle accepts VM input parameters. The Gradle section of preferences in AS allows for such parameters to be passed:

Gradle preferences

They replicate the same as the ones in the above configuration approach:

-Dhttp.proxyHost=www.somehost.org \
-Dhttp.proxyPort=8080 \
-Dhttp.proxyUser=userid \
-Dhttp.proxyPassword=password

This "just works" :)

Conclusion

Both variants work for me. In the end, I've chosen the JVM variables approach because:

  • gradle.properties ends up committed in a repository and it would contain my user's credentials for the proxy. This is bad. Very, very bad!
  • Normally I don't need proxy authentication. Also, other members would have their own settings (e.g. credentials). So, the only way I could see this file being used would be to be committed (and checked out only once) and added to .gitignore so subsequent commits don't alter it.
  • It violates Rule III of the 12 factor app

HTH,