Unbundle mobile tools

[ulfjack]

We're about to add another tool for Android builds to do sharded dex compilation, and that depends on having an Android SDK available. If we put it into @bazel_tools, then we'd implicitly require every user of Bazel to also have an Android SDK, whether they work with Android or not.

After talking to @ahumesky and others, it seems to me that the right solution is to unbundle the Android tools - all of them. This requires that all devs who work with Android now also need to depend on the android tools repository (@android_tools?), but that's better than the alternative.

I think we have to do this before we can declare a 1.0, and if we want to ship further improvements to Android builds, sooner rather than later.

[ulfjack]

@lberki @damienmg

[damienmg]

SGTM we used to have it.

We could take the opportunity to put that android tooling outside of bazel completely and people would just fetch it when declaring a android_sdk_repository

[lberki]

LGTM. This is probably the sanest solution of them all.

We should also unbundle the tools for other languages. Linux users won't find j2objc and objc very useful.

@aragos

[helenalt]

@ahumesky is this still in progress (and P1)?

[ahumesky]

Yes, for example we've put the tools for android_device and android_instrumentation_test in separate repositories. We're moving the rest of the rules to skylark, and once those are ready we'll move the tooling out of bazel.

[meisterT]

You can already move the tooling out while the rules are still native. @iirina is doing the same currently for the Java rules.

[meisterT]

@iirina is done with the changes for the java tools (next to other improvements) and we are now below 100 MB on all platforms. Looking what to do next to improve binary size, this bug is the next logical step.

These are the biggest files in the bazel binary:

   388Ki process-wrapper
   395Ki linux-sandbox
   452Ki embedded_tools/tools/jdk/singlejar/singlejar
   761Ki embedded_tools/third_party/java/proguard/proguard5.3.3/lib/proguard.jar
   934Ki embedded_tools/tools/android/desugar_jdk_libs.jar
   3.3Mi embedded_tools/jdk/lib/ct.sym
   3.8Mi embedded_tools/tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/all_lcov_merger_tools_deploy.jar
   5.7Mi embedded_tools/src/java_tools/import_deps_checker/java/com/google/devtools/build/importdeps/ImportDepsChecker_deploy.jar
   7.2Mi embedded_tools/jdk/lib/server/libjvm.so
   11Mi embedded_tools/src/tools/android/java/com/google/devtools/build/android/all_android_tools_deploy.jar
   18Mi embedded_tools/jdk/lib/modules
   35Mi A-server.jar

Side note: out of the modules file, ~10MB is the java.desktop module which is necessary for android_sdk_repository (and maven_jar which already is on the way out, see #6799).

So with unbundling the android tools we could save ~28MB of the binary size (~30%).

[jin]

What exactly is the dep from android_sdk_repository to java.desktop? I'm not familiar with how Java modules work.

[meisterT]

I filed #7502 as a separate issue for the desktop dependency.

[jin]

Taking a stab at this.

[jin]

Together with -c opt and unbundling ImportDepsChecker and all_android_tools_deploy.jar:

$ ls -l --block-size=M bazel-bin/src/bazel
-r-xr-xr-x 1 jingwen primarygroup 74M Mar 29 13:20 bazel-bin/src/bazel

[jin]

Re-opening this, the CL just unbundled some of the Android tools. The Android rules and tools are not completely out of the Bazel source yet.

[jin]

The following Android tools have been removed from the binary:

   934Ki embedded_tools/tools/android/desugar_jdk_libs.jar
   5.7Mi embedded_tools/src/java_tools/import_deps_checker/java/com/google/devtools/build/importdeps/ImportDepsChecker_deploy.jar
   11Mi embedded_tools/src/tools/android/java/com/google/devtools/build/android/all_android_tools_deploy.jar