You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Xamarin.Android.Build.Tasks] Extract BuildArchive from BuildApk (#9556)
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 `%(FilesToAddToArchive.Compression)` metadata is optional and is
really only needed for handling the assembly compression information
[stored in `RegisterTaskObject()`][0]. The valid values are in
[`CompressionMethod.cs`][1]. Hopefully this will not be needed in
the final version.
This change will allow future PRs 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)=path/to/my.jar#ExtraFile.txt`.
In a final future state we would probably unzip the `.jar`s to disk
and add the files from there. This would allow us to avoid unzipping
the `.jar`s 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 that 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 |
[0]: https://github.com/dotnet/android/blob/e98d20f08ef1a3521a35749754a3ae6a61314d0b/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs#L355-L361
[1]: https://github.com/dotnet/android-libzipsharp/blob/57558e9e9b5e6e460fcbaca663de1ca80ca467a0/LibZipSharp/Xamarin.Tools.Zip/CompressionMethod.cs
// We will place rc.bin in the `lib` directory next to the blob, to make startup slightly faster, as we will find the config file right after we encounter
409
335
// our assembly store. Not only that, but also we'll be able to skip scanning the `base.apk` archive when split configs are enabled (which they are in 99%
0 commit comments