Detecting mangled gradle wrapper downloads

If you’re running the gradle wrapper in a portal network environment, the wrapper may think it has downloaded a gradle distribution, but instead the contents are actual a portal HTML page asking for login credentials or access payment or terms of service acceptance etc.

And then obviously executing the “code” will fail.

A number of people have run into this using Android Studio; see for example

Somebody filed a request that in Android Studio we should verify the gradle wrapper before trying to use it:

I was about to do that when I realized that it would probably be much better for the wrapper itself to check this, such that it works not just when Gradle is run from Studio, but whenever anyone tries to run the gradle wrapper, and it fails in a scenario like the above.

We probably don’t need to do anything super fancy, but the shell/.bat script could, before attempting to launch the “jar” file, do something simple to make sure it’s at least a .jar file.

There are several possible ways to do that; I’m not sure what’s most portable in terms of script commands available to the shell; the “file” command is obviously useful, and you could just run say “jar tf gradle/wrapper/gradle-wrapper.jar META-INF/MANIFEST.MF” to see if it succeeds etc. The most efficient thing might be to look for the magic number at the beginning of the .jar file. I’m not certain what it is; in several files I’ve looked at it’s


K 003 004

Probably the simplest expedient thing to do is to simply see if the downloaded .jar file starts with “<html” and if so, state that something is wrong with the network connection!

– Tor

(Apparently the magic number for jar files is 50 4B 03 04 14 00 08 00 08 00)

Hi Tor, sounds like and/or

IMO we should be able to expose MD5 sums and verify against them. Don’t you want to write a patch? :wink: