[Xamarin.Android.Build.Tasks] Add @(AndroidGradleProject) action

[pjcollins]

Context: https://github.com/CommunityToolkit/Maui.NativeLibraryInterop

Introduces an @(AndroidGradleProject) build action which can be used
to build and consume the outputs of Android Gradle projects.

The following metadata is supported on this item:

<AndroidGradleProject Include="path/to/projectdir">
  <Bind></Bind>
  <Configuration>Release</Configuration>
  <ModuleName></ModuleName>
  <OutputPath>$(IntermediateOutputPath)gradle/{ModuleName}-{Hash}</OutputPath>
  <Pack></Pack>
  <CreateAndroidLibrary>true</CreateAndroidLibrary>
</AndroidGradleProject>

The ItemSpec or Include attribute should be the path to the root
build.gradle file of the project, next to gradlew wrapper scripts.

If the @(AndroidGradleProject) declares a library module that produces
an AAR, that AAR will be added as an @(AndroidLibrary) item
automatically.

The Bind, Pack, and Visible metadata will be applied to the
@(AndroidLibrary) item if it is created, using the defaults outlined
above.

A new $(AndroidPrepareForBuildDependsOn) build extension point has
been added to allow customer projects to more easily hook into the
beginning of the build process.

[pjcollins]

Opening this up for some initial feedback, though I am still working on issues related to dotnet pack.

[dellis1972]

Will this include the gradle equivelents of obj in the search ? becuase gradle does produce allot of intermediate files, it might cause some slow evaluations?

[pjcollins]

Only if the OutputPath metadata is set by the customer to a path under the Gradle project. The default build path is in the output path of the .NET project, but I think I can update this to exclude content in %(AndroidGradleProjectReference.OutputPath) in case it's overridden.

[jonathanpeppers]

All the wildcards seem like they could be slow like I saw in:

• [resizetizer] fix a build performance issue maui#24453

If you have a .binlog, I wonder how much time it takes as it would run these on every build.

The current code looks like it would run ** in that folder 6 times. Is there a way it could be nonrecursive, or have less wildcards?

[pjcollins]

I've updated this to do the following instead, but still need to do some perf measuring:

<_AllGradleFiles Include="$([System.IO.Directory]::GetFiles('%(AndroidGradleProjectReference.FullPath)', '*.*', System.IO.SearchOption.AllDirectories))"
    Condition= " Exists('%(AndroidGradleProjectReference.FullPath)') "/>
<_GradleInputs Include="@(_AllGradleFiles)"
    Condition="  '%(Extension)' == '.java'
              or '%(Extension)' == '.kt'
              or '%(Extension)' == '.kts'
              or '%(Extension)' == '.gradle'
              or '%(Extension)' == '.properties'
              or '%(Extension)' == '.xml' " />

[pjcollins]

I've updated this again to use a single wildcard glob which is then filtered. The initial glob is conditional based on the existence of the directory being searched so we don't accidentally or arbitrarily scan a bunch of directories.

[dellis1972]

Looks nice 😄 It might be worth doing a blog post for this to show people how to use it 😄

[jpobst]

How does this handle dependencies? Let's say my gradle project depends on org.jetbrains.kotlin:kotlin-stdlib:2.0.0.

Is this:

• Dependency is left entirely up to the user, in this case they would need to add our NuGet package to their project.
• Native dependency is automatically included, which would conflict with any usage of our NuGet package.
• Something else?

[pjcollins]

How does this handle dependencies? Let's say my gradle project depends on org.jetbrains.kotlin:kotlin-stdlib:2.0.0.

Is this:

• Dependency is left entirely up to the user, in this case they would need to add our NuGet package to their project.
• Native dependency is automatically included, which would conflict with any usage of our NuGet package.
• Something else?

There is currently no dependency management functionality, it's left up to the user to figure out what is needed and what is best. This is a scenario I am hoping we can try to improve in the future, perhaps through recommending some combination of NuGet or AndroidMavenLibrary references. There are also likely different use cases for application vs library projects where we could potentially try to do some automatic dependency inclusion in the former case.

[pjcollins]

Looks nice 😄 It might be worth doing a blog post for this to show people how to use it 😄

We have a "v1" of sorts out in https://github.com/CommunityToolkit/Maui.NativeLibraryInterop and https://learn.microsoft.com/en-us/dotnet/communitytoolkit/maui/native-library-interop , and will be planning to update these with this functionality when it's available

[jonathanpeppers]

All the wildcards seem like they could be slow like I saw in:

• [resizetizer] fix a build performance issue maui#24453

If you have a .binlog, I wonder how much time it takes as it would run these on every build.

The current code looks like it would run ** in that folder 6 times. Is there a way it could be nonrecursive, or have less wildcards?

[jonathanpeppers]

One thought is if we can build these in parallel. Batching like %(AndroidGradleProjectReference) would just run it N times one after another. We can think about this in a future PR.

[jpobst]

There is currently no dependency management functionality, it's left up to the user to figure out what is needed and what is best. This is a scenario I am hoping we can try to improve in the future, perhaps through recommending some combination of NuGet or AndroidMavenLibrary references.

If a .pom file is produced by the gradle project, adding it to the AndroidLibrary with the Manifest attribute will opt-into our Java dependency verification which would provide dependency enforcement and NuGet package suggestions:

https://review.learn.microsoft.com/en-us/dotnet/android/binding-libs/advanced-concepts/java-dependency-verification?branch=binding-docs

[pjcollins]

There is currently no dependency management functionality, it's left up to the user to figure out what is needed and what is best. This is a scenario I am hoping we can try to improve in the future, perhaps through recommending some combination of NuGet or AndroidMavenLibrary references.

If a .pom file is produced by the gradle project, adding it to the AndroidLibrary with the Manifest attribute will opt-into our Java dependency verification which would provide dependency enforcement and NuGet package suggestions:

https://review.learn.microsoft.com/en-us/dotnet/android/binding-libs/advanced-concepts/java-dependency-verification?branch=binding-docs

Excellent, I will try to look into this after the initial work lands.

[jonpryor]

The problem with this is that if a project contains multiple @(AndroidGradleProjectReference)s, each build will take longer.

A "better" / alternative idea may be to have the <Gradle/> task take all of the projects, and build them in parallel:

<Gradle Projects="@(AndroidGradleProject) … />

and then use have Gradle inherit from AsyncTask a'la <MavenDownload/>/<Aapt/>/etc., execute gradlew from all of the projects in parallel, and then at the end finish with gradlew --stop.

A problem with this idea is that it assumes that each gradlew is "the same", which might not be true. (…and then what? Run gradlew --stop for each project separately?)

This also assumes that gradlew is located alongside each build.gradle separately. That might be true for some customers, but that certainly isn't true for us; look at git grep GradleWPath, and see that it's used from three separate projects, so that we have only one gradlew in the repo, not N.

[pjcollins]

The "safe" approach for now in my mind would be to keep builds running in sequence in isolated processes. I think we can look at a performance pass in a future PR as Peppers also mentioned, where we can support building in parallel and/or potentially re-using the daemon as well.