Repository navigation
AndroidToolTask should capture all tool output #208
Description
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.
Activity
pjcollins commentedon Jun 16, 2023
I've been looking into this, but haven't found any immediate areas that need improvement. With respect to
AndroidToolTask:AndroidToolTaskextendsToolTask, which already prints all output asNormalimportance messages when tool execution does not complete successfully.AndroidRunToolTaskprovides a common regex that can be used to capture and report issues when running an Android SDK tool.JavaToolTaskalready works in a similar manner toAndroidRunToolTask.With respect to maui#14531, it doesn't appear that any of the provided diagnostic build logs contained additional stdout/stderr from the
llctool invocation that failed. The error messaging in theCompileNativeAssemblytask was already improved in commit 77584e02 to log stdout from the tool when a failure occurs.We could consider adding a common
System.Diagnostic.Processwrapper with log on error logic that could be re-used by tasks that inherit fromAndroidAsyncTask(abstract out this piece ofCompileNativeAssemblyfor 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 commentedon Aug 29, 2023
@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:To your earlier point
"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 commentedon Aug 29, 2023
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)adberrors out, there is no "trivial" way to present theadboutput to the user.This in turn implies that we should replace all
<Exec Command="…adb…"/>usage with<AndroidAdb/>usage, e.g.:pjcollins commentedon Aug 29, 2023
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.
[AndroidToolTask] Log tool output as error
[AndroidToolTask] Log tool output as error (#229)
[AndroidToolTask] Log tool output as error (#8861)
pjcollins commentedon Apr 30, 2024
I think we can close this as fixed via:
1ea4e35
dotnet/android@771ee1d