[XABT] Split BuildArchive from BuildApk task.

[jpobst]

Break down the mega-task BuildApk into smaller separation of concerns:

• BuildApk - Generate files that need to be placed in the APK.
• BuildArchive - Place files in the APK.

This works via the @(FilesToAddToArchive) item group which is defined as:

<FilesToAddToArchive
    <!-- Path of file on disk to add -->
    Include="obj\Release\net9.0-android\app_shared_libraries\arm64-v8a\libxamarin-app.so"
    <!-- Path to place file in APK -->
    ArchivePath="lib/arm64-v8a/libxamarin-app.so"
    <!-- Compression level (optional) -->
    Compression="Store"
/>

The %(Compression) metadata is optional and is really only needed for handling the assembly compression information stored in RegisterTaskObject (source). The valid values are from here. Hopefully this will not be needed in the final version.

This change will allow future PR(s) to break down the BuildApk task into separate tasks for each type of files that belong in the APK, facilitating better incremental builds. For example, if only the Dalvik file changes we don't need to reprocess every managed assembly, etc.

Implementation

To keep the diff more manageable at this point, create the temporary ZipArchiveFileListBuilder as a drop-in replacement for ZipArchiveEx. Instead of adding files to the .apk it collects the file name and apk path so that the BuildArchive task can do the actual adding.

Additionally, there is code that looks in every referenced .jar file and copies non-code files into the final apk. This is currently handled by specifying the Include as path/to/my.jar#ExtraFile.txt. In a final future state we would probably unzip the .jars to disk and add the files from there. This would allow us to avoid unzipping the .jars on every build.

Performance

Although performance isn't the focus of this PR, there is a nice win from eliminating extraneous ZipArchiveEx.Flush () calls. (Note the AutoFlush logic still exists.)

_BuildApkEmbed target	.NET 9	This PR
Debug (FastDev - _BuildApkFastDev target)	2.684s	2.670s
Debug (EmbedAssembliesIntoApk = true)	79.981s	75.720s
Release	8.130s	6.121s

[dellis1972]

How does this impact Debug (EmbedAssembliesIntoApk = false) timings?

[Copilot]

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 suggestion.

Files not reviewed (1)

• src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets: Language not supported

[jpobst]

How does this impact Debug (EmbedAssembliesIntoApk = false) timings?

It is largely unchanged. Updated the PR description to include FastDev timing.

[jonpryor]

Don't we need to set ms.Position=0? Or is that somehow done automatically?

[jpobst]

It is copied from our existing code, so I assume it must be done automatically:

android/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs

Lines 198 to 201 in 2fa7954

	var ms = new MemoryStream ();
	entry.Extract (ms);
	Log.LogDebugMessage ($"Refreshing {entryName} from {apkInputPath}");
	apk.Archive.AddStream (ms, entryName, compressionMethod: entry.CompressionMethod);

[jonathanpeppers]

It's automatic when returned:

• https://github.com/dotnet/android-tools/blob/f62cd09f2104351edacaa4d74c83f374b4742add/src/Microsoft.Android.Build.BaseTasks/MemoryStreamPool.cs#L29

And then the MemoryStream should reuse its underlying byte[] when Length is set to 0.

[jpobst]

I think the concern is that we pass the MemoryStream to Archive.AddStream (libzip.zip_file_add) without rewinding it first. I assume the marshaling code that passes it to the native library as an IntPtr is automatically passing a pointer to the beginning of the MemoryStream's underlying byte[] and not pointing to the MemoryStream's current Position.