IssueTracker

Would setting system properties on the javac JVM (whether local or forked) be an option here?

As you may be well aware, Gradle tasks need to have well-defined inputs and outputs for the build to work correctly and optimally. While passing info through side channels using a global state sounds tempting, I'm afraid that it will open doors for build flakiness and irreproducibility, with hard-to-debug errors.

How about publishing a library which exposes something like

package com.android.tools.build.info;

interface AndroidBuildInfo {
  static Optional<AndroidBuildInfo> get() {
    Throwable failure;
    try {
      return Optional.of(
          Class.forName("com.android.tools.build.info.AndroidBuildInfoImpl")
              .getConstructor()
              .newInstance());
    } catch (NoClassDefFoundError ignored) {
      return Optional.empty();
    } catch (InvocationTargetException e) {
      failure = e.getCause();
    } catch (ReflectiveOperationException e) {
      failure = e;
    }
    if (failure instanceof Error) throw (Error) failure;
    if (failure instanceof RuntimeException) throw (RuntimeException) failure;
    throw new RuntimeException(failure);
  }

  int minSdk()
  String compileSdk();
  boolean debuggable();
  String applicationId();
  // etc..
}

and then having AGP spin a classfile for AndroidBuildInfoImpl which implements AndroidBuildInfo and put that on the processor path. Then any processor wanting info could depend on this client library to optionally access build info.

Users of other build systems could then spin the classfile themselves to provide such info.

That's still using side channels, it addresses problem #1 but not #2 in comment #12. But let me consider it. Thanks for the suggestions!

Ah, do you mean because while the generated class would be on the processor path and part of the inputs, the actual values are not exposed for Gradle to see and so any changes would not invalidate the task? I suppose a workaround for that would to be to have the values also declared as properties on the task, but that's definitely error-prone since you could forget to keep them in sync.

Yes, we need to ensure anything that's passed to annotation processors is registered as an input to Gradle. On the other hand, if all of the properties are registered as inputs but some of them are unused, it could trigger unnecessary task execution (problem #2).

(We'll revisit this issue in a future release, so decreasing priority to P2.)