One option is to add the following:
    srcjars = filter(lambda t: not t.endswith('__process_resources.srcjar'), srcjars)
    srcjars = filter(lambda t: not t.endswith('__build_config_java.srcjar'), srcjars)
    srcjars = filter(lambda t: not t.endswith('__native_libraries_java.srcjar'), srcjars)

This will reduce a clean build from 49000 tasks to about 9000 tasks. Not sure if the extra complexity is worth pursuing since assuming devs would build chrome anyways, this is not a big burden if done incrementally.

This will need to be fixed since generate_gradle.py is taking a long time. With native possibly using explicit targets and re-running for new targets, this will result in a very poor experience if left unchecked.

The other benefit of depending on fewer targets is that once Android Studio is used to edit most/all native code, it will be necessary to run generate_gradle.py to make edits.

If the build is then broken, in order to make the edits to unbreak the build, one would need to run generate_gradle.py, which would require targets from the build to not be broken, a chicken and egg problem.

Although it is nice to have the srcjar and generated files to edit, perhaps that should be optional. And since native already needs to parse project.json, perhaps java could parse that too.

In fact, if eventually we can get to a state where just running "gn gen out/Debug --ide=as" will result in a mostly usable Android Studio (albeit missing some generated files which can be generated explicitly with generate_gradle.py afterwards), that would be ideal.

sgtm to make them optional. I think the original rationale was just for java to not have red underlines for generated classes.

I don't think parsing json to get the java info will work well, as all the info would need to be extracted from the flags of write_build_config.py actions.

It may also be worth figuring out what generated sources have such large dependencies, and seeing if we can make them not :P.

Data:
gen/chrome/android/chrome_sync_shell_apk__compile_resources.srcjar
Produces final R.java but also depends on all java, which runs lint, which compiles all java files and the like.
Results in 9k+ targets
gen/chrome/android/chrome_sync_shell_apk__native_libraries_java.srcjar
gen/chrome/android/chrome_public_apk_for_test__native_libraries_java.srcjar
Deps is the apk's shared libraries, so builds the entire .so
Results in 29k+ targets
gen/android_webview/glue/glue_resource_rewriter.srcjar
Deps is almost all of non-chrome _java targets. Produces ResourceRewriter.java for R.java files.
Results in 6k+ targets
gen/chrome/android/chrome_junit_tests__prepare_resources.srcjar
Generates R.java in a srcjar, R.txt and resources.zip
Results in 8k+ targets

Removing all of the above, we get to ~2.5k targets for "all", taking 76s to finish, of which 20s is in earlier steps. Surprisingly 100 of the 418 generated files (results in ~800 targets) takes 74s to finish with -j10000.

All targets (718 generated files) 48k+ take 564s to finish with -j10000.

None of this is ideal, will summarize in next comment.

Current plan of action:
Introduce -g flag. Default is to not build any of the generated files, which results in a fast 20s build (I'd still like to improve this to sub-5s).

When builds change a lot or out dirs get cleaned, then devs can add the -g flag for a one-time re-build of all the generated files and go for coffee, but otherwise, they all stay in the gradle project directory and generate_gradle.py can be rerun as often as possible, so new files from sync and newly created files get picked up really fast (especially important to modify native targets since --all doesn't work well for 50k C++ files).

Thoughts?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ccbb2419379c8eb34bfc2bf262c5d29b995116c0

commit ccbb2419379c8eb34bfc2bf262c5d29b995116c0
Author: Peter Wen <wnwen@chromium.org>
Date: Mon Apr 30 19:13:55 2018

Android: Default no longer builds generated files

* Switch Android Studio's generate_gradle.py script to no longer build
  all the generated files by default. This reduces runtime for a clean
  build from 10 minutes to 20 seconds. Add a `--full` flag to explicitly
  build these generated files, which should not be necessary on a
  regular basis.

* Most of the benefit from generated files being present is fewer red
  underlines in Android Studio. Many red underlines are from lacking a
  R.java file, which takes a long time to generate.

* Fix bug so generate_gradle.py works even right after `gn clean`.

* Allow users to specify `-j` so generate_gradle.py works without goma.

* Speed up generating the `all` module (which is the default) by not
  creating each sub-project's build.gradle file when generating the
  information that it needs.

Bug:  799954 ,620034
Change-Id: Ie3c6ea0cdba198aede001332d64bec2eccffbe13
Reviewed-on: https://chromium-review.googlesource.com/1031052
Reviewed-by: Eric Stevenson <estevenson@chromium.org>
Commit-Queue: Peter Wen <wnwen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554838}
[modify] https://crrev.com/ccbb2419379c8eb34bfc2bf262c5d29b995116c0/build/android/gradle/generate_gradle.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff31875bec10a7fe0513e094483f79157b034347

commit ff31875bec10a7fe0513e094483f79157b034347
Author: Eric Stevenson <estevenson@chromium.org>
Date: Wed May 02 20:57:53 2018

Android: Set friendlier defaults for ninja jobs.

In diagnose_bloat.py and generate_gradle.py the defaults for max
jobs (-j) are too high for machines without a large amount of RAM.

This should help non-Googlers.

Bug:  799954 
Change-Id: I0f1480cb3bf93c17e9a182da821876b0d6f5f12c
Reviewed-on: https://chromium-review.googlesource.com/1038440
Reviewed-by: Samuel Huang <huangs@chromium.org>
Commit-Queue: Eric Stevenson <estevenson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555507}
[modify] https://crrev.com/ff31875bec10a7fe0513e094483f79157b034347/build/android/gradle/generate_gradle.py
[modify] https://crrev.com/ff31875bec10a7fe0513e094483f79157b034347/tools/binary_size/diagnose_bloat.py

Marking this fixed since the default path is fast now.