Skip to content

Xamarin.Android 9.4.0.17

Pre-release
Pre-release
Compare
Choose a tag to compare
@brendanzagaeski brendanzagaeski released this 11 Jun 21:34
xamarin-android-9.4.0.17
bce1291

Xamarin.Android 9.4.0.17 was released as part of Visual Studio 2019 version 16.2 Preview 2.

Corresponding Visual Studio 2019 Preview release notes

What's new

Build and deployment performance

  • GitHub PR 2536, with follow-up adjustments in GitHub PR 2870, GitHub PR 2878, GitHub PR 2916: Add a .jar file to the Xamarin.Android installer package that contains pre-built versions of a number of Java classes that are used by every Xamarin.Android project. That way the individual projects don't need to build the Java classes themselves. This reduced the total time for the Java compilation step on a clean build of a test app from about 2.7 seconds to about 2.5 seconds.
  • GitHub PR 2896: Adjust the Android resource compilation build step to avoid re-running AAPT (or AAPT2) individually for each library and to avoid generating many extra unused resource IDs. In apps that reference libraries containing many resources, such as the Xamarin.Android.Support and Xamarin.GooglePlayServices libraries, this will often dramatically decrease the total number of fields in the app. This means that those apps are now less likely to exceed the DEX 64K reference limit and less likely to require the Enable Multi-Dex setting in the Visual Studio project property pages. For example, in a test Xamarin.Forms application, the number of references in the .dex file dropped from about 30,000 to about 18,000, the .dex file size decreased from about 3.5 megabytes to about 3.4 megabytes, and the total time for the resource compilation step in a clean build dropped from approximately 3 seconds to about 20 milliseconds.
  • GitHub PR 2930: Revise the Inputs and Outputs for the _BuildLibraryImportsCache target, and adjust the GetImportedLibraries to take advantage of those adjustments. This allows incremental builds to skip the _BuildLibraryImportsCache target when appropriate. It also improves the performance of GetImportedLibraries for clean builds. For example, in a test Xamarin.Forms app, this change saved approximately 100 milliseconds for an incremental build after a XAML file change, and it reduced the clean build time for the GetImportedLibraries target from approximately 300 milliseconds to approximately 170 milliseconds in the same project.
  • GitHub PR 2934, with follow-up adjustments in GitHub PR 2958: Avoid running the Xamarin.Android-specific _BuildAdditionalResourcesCache or _ResolveLibraryProjectImports build steps on assembly types like .NET Standard assemblies that never contain Xamarin.Android library project features such as Android resources. This reduced the incremental build time for these steps from about 360 milliseconds to about 80 milliseconds in a test Xamarin.Forms app where only the .NET Standard project was modified between builds. This also reduced the clean build time for these steps in the same project from about 1.8 seconds to about 1.2 seconds.
  • GitHub PR 2935: Avoid copying extra .pdb or .mdb debugging symbol files to the bin output directory in cases where the corresponding .dll assembly files themselves are not copied to the output directory. Depending on the size and number of debugging symbols for a project and the speed of the drive where the output directory is stored, this change can potentially save a noticeable amount of time. In a smaller test project built on an SSD, this change saved roughly a few dozen milliseconds for an incremental build where an assembly changed.
  • GitHub PR 2952: Remove old debug logging messages from several of the build tasks. Since MSBuild prints this information automatically when building with diagnostic verbosity, these additional logging messages are no longer needed. In some cases this change can also reduce the total build time. For example, in a test app, it reduced the clean build time from roughly 25.5 seconds to about 25.0 seconds.
  • GitHub PR 2956: Expand on the previous improvement from GitHub PR 2643 that allowed the GenerateJavaStubs task to skip over .NET Standard assemblies by now also skipping the whole parent _GenerateJavaStubs target in cases where only .NET Standard assemblies have changed. This allowed a small test Xamarin.Forms project to skip the _GenerateJavaStubs target successfully, saving approximately 860 milliseconds for an incremental build in the case where only a XAML file was changed.

Mono Framework version update to 6.0

This version of Xamarin.Android updates the Mono runtime and class libraries from Mono 5.18 to Mono 6.0 Commit 3dc72cfe, adding about 1,800 new commits.

Support for Android App Bundle publishing format

GitHub PR 2841, with follow-up adjustments in GitHub PR 2989: At Google I/O 2018, Android introduced a new Android App Bundle publishing format for Google Play. Xamarin.Android 9.4 includes a new build option to generate Android App Bundles for Xamarin.Android apps. To try this new output format with your project, set the $(AndroidPackageFormat) MSBuild property to aab in your .csproj file:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <AndroidPackageFormat>aab</AndroidPackageFormat>
</PropertyGroup>

When this property is set, the SignAndroidPackage MSBuild target will create an archive in the bin directory that follows the Android App Bundle format. But be aware that there is a known issue with the current preview where the build process does not yet automatically sign the bundle with an algorithm that Google Play will accept.

Known issues

  • GitHub PR 3146: Attempting to submit an Android App Bundle generated with $(AndroidPackageFormat) set to aab will currently result in a "The Android App Bundle was not signed." error on Google Play. A manual workaround is to re-sign the .aab archive by hand using jarsigner.exe in a command prompt, using a command similar to:

    "C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25\bin\jarsigner.exe" ^
    -digestalg SHA-256 ^
    -sigalg SHA256withRSA ^
    -keystore "C:\Users\WindowsUser\com.contoso.keystore" ^
    -storepass password ^
    -keypass password ^
    -signedjar bin\Release\com.contoso.app1-Signed.aab ^
    obj\Release\90\android\bin\com.contoso.app1.aab ^
    com.contoso

    The last 5 lines of this example command would all need to be adjusted to match your particular keystore information and application name.

  • Setting $(AndroidPackageFormat) to aab currently increases build times for the Use Fast Deployment Debug configuration setting, so it is recommended to set the new property only for the Release configuration for now.

App startup performance

  • GitHub PR 2718, with follow-up adjustments in GitHub PR 3010, GitHub PR 3026: Generate unmanaged native shared libraries to provide the per-application Java-to-managed and managed-to-Java type mappings and environment settings that Xamarin.Android applications use. Previously, this information was stored in data files within the APK that the applications would load and parse during startup, but now the application can directly run the unmanaged executable instructions instead. This reduced the startup time from about 240 milliseconds to about 230 milliseconds for a Release configuration build of a small test Xamarin.Forms app on a Google Pixel 3 XL device.

  • GitHub PR 2827, with follow-up adjustments in GitHub PR 2877, GitHub PR 2887, GitHub PR 2961, GitHub PR 2968, GitHub PR 2968, GitHub PR 3019, GitHub PR 3107: Add a new build option to provide finer control over APK size versus startup time trade-offs as compared to the existing AOT Compilation option. Rather than compiling as much of the app as possible to unmanaged code during the build process, this new option instead only compiles a particular set of managed methods to unmanaged code so that they do not need to be Just-in-Time compiled by the Mono runtime during application startup. In a test Xamarin.Form app, enabling this setting reduced the Mono runtime initialization step of application startup from approximately 370 milliseconds to approximately 250 milliseconds.

    At the moment, this option is not yet usable because the AOT Compilation infrastructure is temporarily nonfunctional in this version (see the known issues). Watch for additional news on this feature in a future preview.

    Once the AOT Compilation issue is resolved in a future preview, you can try this feature with your project by setting the $(AndroidEnableProfiledAot) MSBuild property to true in your .csproj file:

    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

Known issues

The GitHub PR 2718 feature that generates unmanaged native shared libraries for the type mappings and the environment settings currently depends on running the unmanaged native linker from the Android SDK toolchain. For 32-bit target ABIs such as armeabi-v7a and x86, the unmanaged linkers are themselves currently 32-bit executables. macOS will in some cases show a ""App" is not optimized for your Mac and needs to be updated" warning when these 32-bit executables run.

Preview bindings for Android Q Beta

Xamarin.Android 9.4 includes preview bindings for the Android Q Beta release from Google. See the Android Q Beta documentation for additional information about the behavior and API changes in this new Android version. To try the bindings for the new APIs in a Xamarin.Android project, set Compile using Android version: (Target Framework) to Android 9.0.99 (Q) under the Application tab of the Visual Studio project property pages.

AAPT2 enabled by default

Xamarin.Android has included an option to use the Android Asset Packaging Tool 2.0 (AAPT2) since Xamarin.Android 9.0, but is has so far been disabled by default to provide a gradual path for finding and addressing compatibility issues. A number of issues have now been resolved, and an up-to-date version of AAPT2 is now included as part of the Xamarin.Android installation to avoid depending on the older version that is part of the Android SDK, so the option is now enabled by default. Note that AAPT2 will in some cases enforce stricter rules on resource files than the previous AAPT, so some adjustments might be needed if you see new error messages that come from AAPT2 itself rather than from the Xamarin.Android build tasks.

To switch back from AAPT2 to AAPT for a particular project, check and then re-uncheck the Use incremental packaging system (aapt2) setting in the Visual Studio project property pages, or set the $(AndroidUseAapt2) MSBuild property to false by hand in your .csproj file:

<PropertyGroup>
    <AndroidUseAapt2>false</AndroidUseAapt2>
</PropertyGroup>

Known issues

  • GitHub 3083: Projects that have both Use incremental packaging system (aapt2) and Generate one package (.apk) per selected ABI enabled and that have Compile using Android version: (Target Framework) set to Android 7.1 or lower will fail to build due to "The "BuildApk" task failed unexpectedly... Could not find file 'obj\Release\71\android\bin\packaged_resources-armeabi-v7a".

jit-times analysis tool

Xamarin.Android 9.4 includes a new command-line tool to help analyze JIT timing log information emitted by the Mono runtime for Xamarin.Android apps for users who might be curious to look at some details about how time is spent by the JIT. See the tool's README for additional information.

Issues fixed

Application and library build process

  • Developer Community 435034: Deployment to device or emulator would fail with "error MSB4018: The "CopyFileFromZipToZip" task failed unexpectedly." for projects that used the Assemblies:Dexes fast deployment mode in with the D8 Dex compiler.
  • GitHub 2680: Xamarin.Android projects that referenced Android libraries containing resource files could sometimes fail on "The process cannot access the file ... obj\Debug\90\lp\26\jl\manifest\AndroidManifest.xml' because it is being used by another process."
  • GitHub PR 2795, GitHub PR 2849, GitHub 1128: Several of the MSBuild targets were using BeforeTargets or AfterTargets in cases where they could be avoided. One consequence was that the LinkAssemblies task would still run in cases where the Compile target had failed. This resulted in misleading extra error messages about the failure of the LinkAssemblies task.
  • GitHub PR 2881: Xamarin.Android build tasks that used Parallel.ForEach() could produce non-descriptive "One or more errors occurred." errors when they failed. Several of those cases have now been improved to produce "XA0000" errors with more descriptive inner exception messages.
  • GitHub PR 2896: The Xamarin.Android build process would launch many aapt (or aapt2) processes for apps that referenced many Android libraries containing resource files. These builds now no longer launch as many separate processes.
  • GitHub PR 2896: The Android resource compilation build step was generating a large number of extra unused resource IDs for Xamarin.Android apps that referenced libraries containing many resources, such as the Xamarin.Android.Support and Xamarin.GooglePlayServices libraries. This meant that those applications were more likely to exceed the DEX 64K reference limit and more likely to require the Enable Multi-Dex setting compared to similar apps written in Java or Kotlin.
  • GitHub PR 2905: The error message from adb was not included as part of the MSBuild error message in cases where adb exited due to an error during deployment.
  • GitHub PR 2975: The ResolveAndroidTooling MSBuild task took roughly 80 milliseconds longer for incremental builds when projects enabled the Use incremental packaging system (aapt2) setting.
  • GitHub PR 2984: The diagnostic MSBuild log output for Xamarin.Android projects did not list the input file locations used to generate intermediate outputs like obj\Debug\90\lp\12\jl\res\drawable. This could make it more difficult to identify the responsible input file if one of the intermediate files caused a build error. The paths for the input files are now included as %(OriginalFile) metadata on the items so that the input file for each item will be recorded in the diagnostic log output.
  • GitHub PR 2969: Attempting to build a .aab archive using the new $(AndroidPackageFormat) setting would fail with an error similar to "[BT Module files can be only in pre-defined directories, but found 'protobuf.meta'." for projects referencing Google Play Services.
  • GitHub PR 3114: Projects that had Use incremental packaging system (aapt2) enabled could encounter relatively slower builds in apps that used custom subclasses of Android.View.View. In these cases, AAPT2 was being run on each of the available resource directories instead of only on the parent directories of layout files that contained custom views. This could potentially cost an extra 10 seconds for a medium sized project during both clean builds and incremental builds where a XAML file had changed.

Application behavior on device and emulator

  • GitHub 3049: Projects with Use incremental packaging system (aapt2) enabled could encounter "java.lang.ArrayIndexOutOfBoundsException" errors when running on device because incorrect resource IDs were being generated in the Resource.designer.cs file for resources that referenced android: resource names either directly or indirectly.

Design-time build process

  • Developer Community 461522, GitHub 3007: Xamarin.Android's built-in managed parser for Android resource files was generating resource ID fields that used the . character as a name separator for certain resource file inputs, resulting in "A const field requires a value to be provided" and "Syntax error, ',' expected" IntelliSense errors.

Android API bindings

  • GitHub 2864: The Android.Security.Keystore.KeyStorePurpose type did not include a [Flags] attribute, so using bitwise operators on it would produce warnings in static analysis tools.

Xamarin.Android SDK installation

  • GitHub 2686, GitHub PR 2733, with follow-up adjustments in GitHub PR 2826: The .vsix installer package for Windows contained a few unnecessary files that were not present in the .pkg installer package for macOS. Additionally, the .pkg installer for macOS did not automatically remove the previous version during installation, so unused old versions could accumulate under /Library/Frameworks/Xamarin.Android.framework/Versions.

Known issues in Xamarin.Android 9.4.0.17

  • GitHub 3120: Projects with AOT Compilation enabled will fail to build with "error XA3001: Could not AOT the assembly".
  • GitHub 3250: New "warning XA0106: Skipping MobileAppMasterDetail.Droid.Resource.Id.fixed" message when building a Xamarin.Forms project in Visual Studio 2019 version 16.2 Preview. This issue also causes errors at run time similar to "Android.Content.Res.Resources+NotFoundException: String resource ID #0x7f0a0028" if C# code attempts to use an Android resource with a name that overlaps with a C# keyword.
  • GitHub PR 3273: The build time improvements for the ConvertResourcesCases task that were added in Xamarin.Android 9.2 (GitHub PR 2348) are at the moment unintentionally disabled in Xamarin.Android 9.4.
  • Building a project with Xamarin.Android 9.3 and then building the same project with Xamarin.Android 9.4 without cleaning the project between the builds fails with "error: duplicate class: mono.MonoPackageManager_Resources ... public class MonoPackageManager_Resources {". To resolve the error, clean the project after switching between the Visual Studio 2019 versions.

Feedback

Your feedback is important to us. If there are any problems with this release, check our GitHub Issues, Xamarin.Android Community Forums and Visual Studio Developer Community for existing issues. For new issues within the Xamarin.Android SDK, please report a GitHub Issue. For general Xamarin.Android experience issues, let us know via the Report a Problem option found in your favorite IDE under Help > Report a Problem.

Contributors

A big Thank You! to contributors who made improvements in this release:

OSS core

The commercial build for this version is based on the bundle from the open-source xamarin-android-d16-2 build #19.

Assets 2
Loading