Compartilhar via

Xamarin.Android 9.4 release notes

  • Artigo

System requirements | What's new | Blogs | Open source

Installing

What's new in Xamarin.Android 9.4

Xamarin.Android 9.4 releases

Corresponding Visual Studio 2019 release notes

September 5, 2019 — Xamarin.Android 9.4.1.1

This version is included in the Visual Studio 2019 version 16.2.4 release.

Issues fixed in Xamarin.Android 9.4.1.1

Application and library build process

  • GitHub 3454: Starting in Xamarin.Android 9.4.1.0, the fix for GitHub 3263 unintentionally preserved additional types during managed linking, resulting in APK files that were about 7 megabytes larger than expected, depending on which libraries the app used.

August 5, 2019 — Xamarin.Android 9.4.1.0

This version is included in the Visual Studio 2019 version 16.2.1 release and in the Stable updater channel of Visual Studio 2019 for Mac.

Issues fixed in Xamarin.Android 9.4.1.0

Application behavior on device and emulator

  • GitHub 3263: Errors similar to "System.TypeLoadException: Could not load type 'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android" would cause app execution to abort during calls to certain C# bindings for Android methods in apps built with the manager linker enabled.

Application and library build process

  • GitHub 3343: Errors similar to "error: cannot access ListenableFuture ... class file for com.google.common.util.concurrent.ListenableFuture not found" could cause the build to fail during the _CompileJava target when using certain libraries like Xamarin.Google.Guava.ListenableFuture that included an embedded .jar file and no public managed types.

Xamarin.Android SDK installation

  • GitHub PR 3350: "Package contains system volume install location content" error would prevent successful installation of the Xamarin.Android SDK on the macOS Catalina preview.

July 24, 2019 — Xamarin.Android 9.4.0.51

This version is included in the Visual Studio 2019 version 16.2 release and in the Stable updater channel of Visual Studio 2019 for Mac.

Summary of what's new in Xamarin.Android 9.4.0.51

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. 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.

App startup performance

Option to compile app startup methods to unmanaged code

Visual Studio Enterprise 2019 version 16.2 includes a new Enable Startup Tracing option that provides finer control over the trade-offs between Android APK size and startup time as compared to the existing AOT Compilation option.

Instead of compiling as much of the app as possible to unmanaged code, this new option compiles only a particular set of managed methods that represent the most expensive parts of application startup in a blank Xamarin.Forms app. This approach consumes less space in the APK compared to the AOT Compilation option while still providing similar app startup performance improvements. 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.

To try this feature in Visual Studio Enterprise, configure the project to use both AOT Compilation and Enable Startup Tracing in the Android Options section of the Visual Studio project property pages for the Release configuration. This sets the $(AndroidEnableProfiledAot) MSBuild property to true in your .csproj file:

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

Other improvements

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.

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.

Fewer DEX references, so fewer apps will need multidex

GitHub PR 2896: Improve the Android resource compilation build step to avoid generating as many unused resource IDs. This means that more apps will now fit within the DEX 64K reference limit.

If you have a project that is currently configured to use Enable Multi-Dex for the Release configuration in the Visual Studio project property pages, you can now try disabling multidex to see if it is still needed.

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 e6f5369c, adding about 1,800 new commits.

Preview bindings for Android Q Beta 2

Xamarin.Android 9.4 includes preview bindings for the Android Q Beta 2 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 for new projects

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 for new projects.

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. Authors of new projects are encouraged to follow the stricter AAPT2 rules when possible. Authors of existing projects are encouraged to migrate to AAPT2 at their convenience.

To enable AAPT2 for a particular project, enable the Use incremental packaging system (aapt2) setting in the Visual Studio project property pages, or set the $(AndroidUseAapt2) MSBuild property to true by hand in your .csproj file:

<PropertyGroup>
    <AndroidUseAapt2>true</AndroidUseAapt2>
</PropertyGroup>

To switch back from AAPT2 to AAPT for a particular project, 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".

  • GitHub 3237: Errors similar to "error CS0117: 'Resource' does not contain a definition for 'Layout'" can sometimes abort the build when attempting to build solutions with parallel builds enabled. Parallel builds are enabled by default in Visual Studio. The setting can be found in Tools > Options > Build and Run > maximum number of parallel project builds.

  • GitHub 3314: "Java.Lang.Exception: android.content.res.Resources$NotFoundException: File res/drawable/abc_vector_test.xml from drawable resource ID #0x7f080058" will abort app execution on Android 4.4 KitKat (API level 19) or lower for apps built with AAPT2 that use Android Support Libraries.

    Workaround:

    Add the --no-version-vectors option to the $(AndroidAapt2LinkExtraArgs) MSBuild property in your .csproj file:

    <PropertyGroup>
    <AndroidAapt2LinkExtraArgs>--no-version-vectors</AndroidAapt2LinkExtraArgs>
</PropertyGroup>

    Then clean and rebuild the project.

  • GitHub 3336: In projects configured to use AAPT2, invalid Android resource elements added after an initial successful design-time build do not produce errors during subsequent incremental builds.

  • GitHub 3344: In app projects configured to use AAPT2, builds show incorrect file paths for AAPT2 errors caused by existing library projects built with AAPT that have Android resource elements that are now invalid with AAPT2.

Initial support for Android App Bundle publishing format

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.

Limitation: For apps deployed to devices running Android versions between 6.0 Marshmallow (API level 23) and 8.1 Oreo (API level 28), this feature currently only works if the app has the android:installLocation attribute set to "internalOnly" in the Android manifest. This setting can be configured under Install location > Internal Only in the Android Manifest section of the Visual Studio project property pages. This limitation will be resolved in a future Xamarin.Android release.

To try the new format with your project, you can set the $(AndroidPackageFormat) MSBuild property to aab for the Release configuration 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 uses the Android App Bundle format.

This new build option is not yet surfaced in the Visual Studio project property pages. Additionally, the Build > Archive command does not yet support this feature. To create a .aab file that is suitable for submission to Google Play, you can instead run a command similar to the following in a Developer Command Prompt:

msbuild -restore AndroidApp.csproj ^
  -t:SignAndroidPackage ^
  -p:Configuration=Release ^
  -p:AndroidKeyStore=True ^
  -p:AndroidSigningKeyStore=com.contoso.keystore ^
  -p:AndroidSigningStorePass=password ^
  -p:AndroidSigningKeyAlias=keyAlias ^
  -p:AndroidSigningKeyPass=password

Replace the values for the signing properties with the appropriate key store file name, key alias, and passwords for your distribution key. See the documentation for additional information about these properties.

After running the msbuild command, locate the signed .aab file in the bin output directory.

Known issues

  • GitHub 3298: "JNI DETECTED ERROR IN APPLICATION: mid == null" or "CallStaticIntMethodV received NULL jclass" "... in call to CallStaticIntMethodV ... from void mono.android.Runtime.init" will prevent apps built using an Install location other than Internal Only from running successfully when installed via Google Play on devices running Android versions between 6.0 Marshmallow (API level 23) and 8.1 Oreo (API level 28).
  • 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.

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 in Xamarin.Android 9.4.0.51

Application and library build process

  • Developer Community 396678: Bindings library projects could fail to build because they failed to generate corresponding C# constructors for certain Java constructors.
  • 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 combination 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 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.
  • GitHub PR 3174: Builds could fail due to "error APT0000: failed parsing overlays." for projects with Use incremental packaging system (aapt2) enabled. Xamarin.Android 9.4.0.34 updates the included aapt2 executable to version 3.4.1-5326820 to resolve this issue.
  • GitHub PR 3196: In certain build scenarios for projects that used AAR files, some of the Xamarin.Android MSBuild targets including _ConvertLibraryResourcesCases, _UpdateAndroidResgen, and _CreateBaseApk would always run.
  • GitHub xamarin-android-tools PR 72: In some environments, antivirus software could block access to the registry, preventing the Xamarin.Android build process from locating the default JDK installation as expected.
  • Builds could occasionally fail during the ResolveXamarinAndroidTools task with "Did not find Xamarin.Android at path ... warning XA5300: Unable to determine Xamarin.Android version" due to the order in which MSBuild ran the ResolveXamarinAndroidTools task relative to the DetectIfAppWasUninstalled task.
  • @(AndroidAsset) MSBuild items that used %(LogicalName) metadata with relative paths were not copied to the correct intermediate output location during the build.

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.
  • GitHub 3123: Apps built with Use incremental packaging system (aapt2) enabled could hit an error similar to "Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred" after an incremental build where a custom view defined in a library project had been updated.
  • GitHub 3169: Applications could hit an exception similar to "Failed resolution of: Landroid/support/v7/appcompat/R$drawable; ---> Java.Lang.ClassNotFoundException: Didn't find class "android.support.v7.appcompat.R$drawable" on path: DexPathList" in projects that had Use incremental packaging system (aapt2) enabled.

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.51

  • GitHub 3263: Errors similar to "System.TypeLoadException: Could not load type 'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android" cause app execution to abort during calls to certain C# bindings for Android methods in apps built with the manager linker enabled.

    Workaround:

    Use a custom linker configuration to preserve the missing types. To do that, add a new linker.xml file to the project, set the Build Action to LinkDescription, and add the XML lines to preserve the missing types. For example, for the ITextWatcherInvoker error, add the following lines to the file:

    <linker>
  <assembly fullname="Mono.Android">
    <type fullname="Android.Text.ITextWatcherInvoker" preserve="all" />
  </assembly>
</linker>

  • GitHub 3322: Errors similar to "error MSB4018: The "LinkAssemblies" task failed unexpectedly. ... System.IO.FileNotFoundException: Could not load assembly" prevent successful completion of the build when attempting to use the old Run Code Analysis static style of code analysis that runs binary analyzers.

  • GitHub 3343: Errors similar to "error: cannot access ListenableFuture ... class file for com.google.common.util.concurrent.ListenableFuture not found" can cause the build to fail during the _CompileJava target when using certain libraries like Xamarin.Google.Guava.ListenableFuture that include an embedded .jar file and no public managed types.

    Workaround:

    Add the following lines to the bottom of your app project's .csproj file (just before the closing </Project> tag):

    <Target Name="FixGuava" AfterTargets="_AddAndroidCustomMetaData">
  <ItemGroup>
    <_MonoAndroidReferencePath Include="@(_ReferencePath);@(_ReferenceDependencyPaths)" Condition=" '%(Filename)' == 'Xamarin.Google.Guava.ListenableFuture' " />
  </ItemGroup>
</Target>

  • GitHub PR 3350: The Xamarin.Android SDK installer .pkg file for macOS is not yet compatible with the macOS Catalina preview.

  • GitHub PR 3379: "The "FilterAssemblies" task was not given a value for the required parameter "DesignTimeBuild"." error prevents projects from building successfully when they use certain additional MSBuild targets, such as the targets from the NuGet.Build.Packaging NuGet package.

    Workaround:

    In your .csproj file, conditionally set the $(DesignTimeBuild) MSBuild property to a placeholder value of false when it is empty:

    <PropertyGroup>
    <DesignTimeBuild Condition="'$(DesignTimeBuild)' == ''">false</DesignTimeBuild>
</PropertyGroup>

Feedback welcome

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

Xamarin.Android 9.4 is based on the open-source Xamarin.Android repositories: