IssueTracker

Thank you for reporting the issue. This should be fixed in: Android Studio JellyFish Canary 2

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Jellyfish | 2023.3.1 Canary 1
• Android Gradle Plugin 8.4.0-alpha01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

It's also not possible to use build services with process isolation. How do we handle that?

Currently, it is not possible to use a build service with a worker API action that uses ClassLoader or process isolation modes.

WRT build services, why do we need it in the isolated/out-of-process worker action?

WRT options that AGP should expose, it is worth having a consistent set of options for all JVM workers launched from AGP. E.g we allow Lint out of process, so ideally the way to specify R8 and Lint options is the same.

Considering that we want to keep default to be in-process, just exposing raw jvmArgs sounds good to me. We should figure out how to expose this in our DSL. Chris, any thoughts about this?

Aisde: If we want to limit the number of out of process R8 invocations we can by implementing:

1. Task action -> passes build service through to launched non-isolated work action
2. Non-isolated Work action -> gets build service, runs and waits for process-isolated work action
3. Process isolated work action -> does the work

For the DSL I wonder if we should have a execution block (all names TBC) attached in various places

e.g.

android {
    lint {
        execution {
            launchInSeparateProcess = true
            jvmArgs += ...
        }
    }
}

although where to attach it for r8 is less clear as we don't have any global settings.

WRT limiting build service, it works at task action level, so I don't think we need to inject it into worker action.

I'd definitely be in favor of having a consistent way to specify jvmArgs, so somethign like execution block makes sense. This setting is very much tool-specific, so I'm leaning towards having r8.execution block, but I'm not sure where to put it :)

We don't need the build service in the worker at all. I've been limiting the task actions by using task.usesService during configuration here, and at that point the task doesn't yet know if it should use out of process workers or not. I think gradle injects the build service into all the workers spawned by the task.

WRT the execution block, can't we do the opposite?

android {
    execution {
        lint { ... }
        r8 { ... }
    }
}

+1 on the DSL attached to the location (cmw@ proposal). Optionally, I'd like to see the ability to reuse those definitions if possible so user's don't necessarily have to repeat themselves if using the same execution configuration.

Jean-Luc, can you please start a DSL proposal for this? Also, I'm wondering if we should allow values to be in gradle.properties, use those as default, and then have per-project option?

Sure thing. Do you have an example I can use?

Also, what should we do regarding the build service? Like I said, gradle tries to serialize it whether you use it in the worker or not. I don't know if Chris' solution of spawning the out of process worker from an in-process one would work but I could give it a try

I remember trying to use workers inside workers and that did not work, you could not pass the WorkerExecutor instance to the inner worker. Obviously, you can rely on some static field to have access to it, I believe there are precedents in the codebase (aapt2 related if my memory serves me well).

so if you want to try, you will need to think on how to make the WorkerExecutor instance available to the in-process work action.

WRT DSL proposal doc, take a look at "New DSL for ignoring keep rules from libraries" from Bingran.

Passing build services to in-process workers should always work. Also, if launching out of process worker action is not possible with a build service injected into task, we should file a Gradle issue.

I'll start working on the doc then. I can also file the gradle issue.

I've sent you the proposal and created an issue with gradle

https://github.com/gradle/gradle/issues/20319

As discussed in AGP weekly, here are 3 things that need to be implemented

• A global settings plugin to set execution options
• Have 3 settings for tools: Low, mid, high, instead of just giving access to jvm arguments
• Have agp decide what those settings are for each tool based on empirical evidence

I'm unsure what the exact nature of this plugin would be. Should it be used in settings.gradle like we do other global settings for the build?

For now should I just finish up the out of process R8 change with a boolean option to turn it on?

FYI I believe I found the issue with the out of process worker. It seems as if ProfileAwareWorkAction injects an analytics build service into the worker, which is why it's failing. I will switch to using pure gradle work action and see if it works.

(:):+63"!!""73+₺"-!*";;