Fixes Docker and Travis build failures related to Android lint.

[clconway]

For some reason "android update" is failing to unpack the new tools and obliterating the /tools dir in the process. But we can do by hand what "android update" is failing to do: unpack the downloaded zip into /tools.

The end-to-end tests still fail with this change, but with a "executable not found" error.

Issue: https://github.com/google/shipshape/issues/27

[ciera]

The unit tests appear to still be failing as well?

[clconway]

It doesn't look like the unit tests are building a fresh image?

[clconway]

Or, wait, it looks like the unit tests are running outside the container but assuming "lint" is in the PATH? https://github.com/google/shipshape/blob/master/shipshape/androidlint_analyzer/androidlint/analyzer.go#L68

[ciera]

Yes, that is correct. They assume your development environment has lint.

We'll need to add it to the Travis CI; you can use the install command to install dependencies.

On Tue, Apr 7, 2015 at 2:11 PM, clconway notifications@github.com wrote:

Or, wait, it looks like the unit tests are running outside the container but assuming "lint" is in the PATH?

https://github.com/google/shipshape/blob/master/shipshape/androidlint_analyzer/androidlint/analyzer.go#L68

— Reply to this email directly or view it on GitHub https://github.com/google/shipshape/pull/28#issuecomment-90734139.

[clconway]

I'll add that to this branch.

[clconway]

Grr...

2015/04/07 21:34:30 lint output is Exception in thread "main" java.lang.NoClassDefFoundError: lombok/ast/Node at com.android.tools.lint.checks.BuiltinIssueRegistry.(BuiltinIssueRegistry.java:42) at com.android.tools.lint.Main.run(Main.java:632) at com.android.tools.lint.Main.main(Main.java:113)

The lombok JAR should be in android-sdk-linux/tools/lib, which I suppose isn't on the CLASSPATH. But it's not on my CLASSPATH either, so I don't know how it ever worked.

[clconway]

I cannot reproduce the NoClassDefFoundError. The lint script itself should be setting the classpath to point at its JARs, so I'm not sure how it's managing to fail to do that.

[clconway]

All right, fixed, at the cost of adding 2-3 minutes to the build's setup time.