AndroidToolTask should capture all tool output

[jonpryor]

Context: dotnet/android@b002dc3
Context: dotnet/maui#14531

Once Upon A Time™ (about a year ago), if we got a java failure, the cause of the error could be unscrutable:

error : java.lang.RuntimeException: com.android.tools.r8.CompilationFailedException:
Compilation failed to complete, origin: obj/Debug/net7.0-android/lp/59/jl/classes.jar :
android/support/v4/app/INotificationSideChannel$Stub.class

Why did it fail? To find out we'd invariably have to ask for a diagnostic build log, because only the diagnostic build log contained the full output of r8.jar, which would contain the "root" error:

Type android.support.v4.app.INotificationSideChannel$Stub is defined multiple times:

java invocations are not the only place this "inscrutable error messaging" scenario comes up. Enter XA3006 (via dotnet/maui#14531):

error XA3006: Could not compile native assembly file: environment.arm64-v8a.ll
error XA3006: 
error XA3006: 

How helpful! How actionable!

Yet again, we need to ask for diagnostic build log information (which became a problem on its own right…).

Enough!

Update AndroidToolTask so that it provides output logging infrastructure, a'la dotnet/android@b002dc38, such that all tool output is always captured (as well as logged via LogDebugMessage()), and when an error occurs, all captured output is part of the error message.

We can then update JavaToolTask and other subclasses to use this common infrastructure.

[pjcollins]

I've been looking into this, but haven't found any immediate areas that need improvement. With respect to AndroidToolTask:

• AndroidToolTask extends ToolTask, which already prints all output as Normal importance messages when tool execution does not complete successfully.
• Our AndroidRunToolTask provides a common regex that can be used to capture and report issues when running an Android SDK tool.
• As mentioned, the JavaToolTask already works in a similar manner to AndroidRunToolTask.

With respect to maui#14531, it doesn't appear that any of the provided diagnostic build logs contained additional stdout/stderr from the llc tool invocation that failed. The error messaging in the CompileNativeAssembly task was already improved in commit 77584e02 to log stdout from the tool when a failure occurs.

We could consider adding a common System.Diagnostic.Process wrapper with log on error logic that could be re-used by tasks that inherit from AndroidAsyncTask (abstract out this piece of CompileNativeAssembly for instance), and while that would be useful for the future it wouldn't immediately improve the task.

@dellis1972 do you have any other thoughts here? Maybe I am overlooking something?

[jonpryor]

@pjcollins: ran across an instance where I think this applies: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1875239

The scenario: the <AndroidAdb/> task fails. What gets reported to the end-user is:

MSB6006: "adb.exe" exited with code 1.

To your earlier point

• […ToolTask] already prints all output as Normal importance messages when tool execution does not complete successfully.

"Normal" message importance doesn't help us when issues are filed and the only "useful" output is the warning or error message contents. In order to obtain "Normal" message importance we would need to request that the customer (possibly) increase build verbosity (e.g. if it's "quiet" verbosity, "Normal" won't be logged!) and then re-run their build. This is extra complexity and customer interaction that would be nice to avoid.

[jonpryor]

Alternatively, the issue with https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1875239 is that <Exec/> is used and not <AndroidAdb/>. The underlying point remains, though: <AndroidAdb/> doesn't capture tool output, so if (when) adb errors out, there is no "trivial" way to present the adb output to the user.

This in turn implies that we should replace all <Exec Command="…adb…"/> usage with <AndroidAdb/> usage, e.g.:

• https://github.com/xamarin/xamarin-android/blob/a48a9c564c3ad5e18f1076c7521379fbfe6d669d/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Application.targets#L22

[pjcollins]

Good point about Normal message priority, I overlooked the fact that Minimal verbosity is likely commonly used. I agree that there are a couple of clear areas of improvement highlighted with this latest issue. I'll try to revisit this in the near-ish future.

[pjcollins]

I think we can close this as fixed via:

1ea4e35
dotnet/android@771ee1d