IssueTracker

I have run onto this several times. Compilers are often used to find code dependent on a change you have just made. There is no easy way to recompile all sources in the project in Android Studio.

It makes sense that when you build to launch an app the IDE builds only sources required for the target, but since Ctrl+F9 already builds all modules it is clear that its intention is not to make the least possible number of targets and thus it seems reasonable to build all tests too. Moreover, IDEA usually builds all sources on Ctrl+F9 but only required targets on run/debug.

Alternatively, we can add another build action which can be bound to a custom keyboard shortcut if anyone wants to.

There are 3 options in the Build Menu:

1. Make Project
2. Make Module X
3. Recompile Y

The last 2 options are contextual, based on the currently active file opened in the editor, where X is the module, and Y is the file itself.

Option 1 will do:

• assemble<Variant> on the android app module, no matter which file is active in the editor. (It does this for all app modules currently in the project, and also all non-app modules that are not consumed by the current app modules).

Option 2 will do:

• On a java library: assemble and testClasses, even if the current active file is not a test file
• On an android module: assemble<Variant>, even if the current active file is a test file

Option 3 will do:

• On a java library: clean and testClasses, even if the current active file is not a test file
• On an android module: clean and assemble<Variant>, even if the current active file is a test file

Proposal

We need to at least have consistent behavior between option 1 and 2 since they should only differ in which modules get build, not how they build them. I would recommend to build:

• fully build the current production variant
• compile the unit-test, code if present
• compile the androidTest, code if present.

For option, 1 this will require manually listing the test and androidTest tasks for each module. This can become a really long list for very large project. We should try it and see if there are scalability issue anywhere.

For option 3, we need to:

• not call assemble. The menu item says Recompile Foo.kt, not assemble module. So we just need to call the compilation task.
• we should also only clean the compilation task itself, not the full module (ie if call testClasses we prepend with cleanTestClasses)
• actually run the compilation task that will compile the current file. Right now it seems to always run a specific one (that is even different for java and android modules), and therefore it can be wrong because it does not actually recompile the current file.

Juan, does this make sense to you?

Sergio, can you take this?

Not sure if some of this was already committed, but I have just upgraded to Studio 2020.3.1 Beta 2 + AGP 7.0.0-beta02, and getting the following errors when invoking "Make Project" (Ctrl + F9):

e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (5, 12): Unresolved reference: junit
e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (9, 4): Unresolved reference: Test
e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (13, 9): Cannot access 'junit.framework.TestCase' which is a supertype of 'com.android.tools.lint.checks.infrastructure.LintDetectorTest'. Check your module classpath for missing or conflicting dependencies
e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (26, 4): Unresolved reference: Test
e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (30, 9): Cannot access 'junit.framework.TestCase' which is a supertype of 'com.android.tools.lint.checks.infrastructure.LintDetectorTest'. Check your module classpath for missing or conflicting dependencies
e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (43, 4): Unresolved reference: Test
e: /path/to/project/lib/lint-checks/src/test/kotlin/ru/kode/base/lint/issue/LambdaTooLongForItTest.kt: (47, 9): Cannot access 'junit.framework.TestCase' which is a supertype of 'com.android.tools.lint.checks.infrastructure.LintDetectorTest'. Check your module classpath for missing or conflicting dependencies

The classes above are lint-based tests for my custom lint checks.

Here are deps from this module's build.gradle:

dependencies {
  compileOnly Deps.coreLibs

  compileOnly "com.android.tools.lint:lint-api:$lintVersion"
  compileOnly "com.android.tools.lint:lint-checks:$lintVersion"

  testCompileOnly "com.android.tools.lint:lint:$lintVersion"
  testCompileOnly "com.android.tools.lint:lint-tests:$lintVersion"
}

If I downgrade to Studio 4.2.1 and corresponding AGP version, compilation goes without an error.

Can you file a separate bug? This bug is about whether the make Project action even trigger a build. Your issues seems to be more about a project dependency setup issue. thank you.

We can now better control what tasks are invoked in which case, but we haven't come to agreement on that.

We agreed on a proposal on comment#6, assigning to Jerome to confirm.

make sense, assigning to Sergio.

Also related: https://issuetracker.google.com/229910761

Current state is different than one from #6. For Android app and lib (Java lib):

1. Build project: this step should select top-level apps and top-level modules (all of these are main), and for every top-level module it should also add its tests. Then it proceeds to run as option 2) below.
2. Build selected modules (app and lib holder modules): it runs [:app:assembleDebug, :app:assembleDebugUnitTest, :app:assembleDebugAndroidTest, :lib:assemble, :lib:testClasses] . Note: we always run all available assemble tasks on the holder module.
3. Recompile $SOURCE:
   • If source is in app: it runs [:app:clean, :app:assembleDebug, :app:assembleDebugUnitTest, :app:assembleDebugAndroidTest]
   • If source is in lib: it runs [:lib:clean, :lib:assemble, :lib:testClasses]

Similar to #6, I propose that 1) and 2) behave the same:

1. Build project: it runs [:app:assembleDebug, :app:assembleDebugUnitTest, :app:assembleDebugAndroidTest, :lib:assemble, :lib:testClasses]
2. Build selected module:
   • the set of modules to build is determined by: adding the "leaf" modules, and for every non-leaf modules we get it's children. E.g. for app we'd get app.main, app.test, app.androidTest. For MyApplication (root module), we'd get app.main, app.test, app.androidTest, lib.main, lib.test
   • for each of the modules from the 1st step we run assemble task
3. we recompile the module that contains the $SOURCE file. E.g. if it belongs to lib.test we run :lib:compileTestJava, if it belongs to app.testwe run compileDebugUnitTestJavaWithJavac.

Please let me know if you have any concerns with this approach, otherwise I'll start working on it next week.

Removing from G blocking bugs as it is not a regression.

Make Project now triggers assemble for all modules in the IDE, and so does "Rebuild project".

Fixed in ag/I2b36b8b05f80e10869b036f7a94e4f30f45a2e28, which will land in Studio I canary 2.