Xamarin.Android 9.4 release notes
- Visual Studio 2019 version 16.2 — Visual Studio Installer
- Visual Studio 2019 for Mac version 8.2 — Visual Studio for Mac Installer with the Stable updater channel
What's new in Xamarin.Android 9.4
Xamarin.Android 9.4 releases
- September 5, 2019 — Xamarin.Android 188.8.131.52 in Visual Studio 2019 version 16.2.4.
- August 6, 2019 — Xamarin.Android 184.108.40.206 in Visual Studio 2019 version 16.2.1.
- August 5, 2019 — Xamarin.Android 220.127.116.11 in the Stable updater channel of Visual Studio 2019 for Mac.
- July 24, 2019 — Xamarin.Android 18.104.22.168 in Visual Studio 2019 version 16.2 and the Stable updater channel of Visual Studio 2019 for Mac.
Corresponding Visual Studio 2019 release notes
September 5, 2019 — Xamarin.Android 22.214.171.124
This version is included in the Visual Studio 2019 version 16.2.4 release.
Issues fixed in Xamarin.Android 126.96.36.199
Application and library build process
- GitHub 3454: Starting in Xamarin.Android 188.8.131.52, 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 184.108.40.206
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 220.127.116.11
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
_CompileJavatarget 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 18.104.22.168
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 22.214.171.124
- Build and deployment performance
- App startup performance
- Option to compile app startup methods to unmanaged code
- Fewer DEX references, so fewer apps will need multidex
- Mono Framework version update to 6.0
- Preview bindings for Android Q Beta 2
- AAPT2 enabled by default for new projects
- Initial support for Android App Bundle publishing format
- Issues fixed in Xamarin.Android 126.96.36.199
- Known issues
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:
_BuildLibraryImportsCachetarget, and adjust the
GetImportedLibrariesto take advantage of those adjustments. This allows incremental builds to skip the
_BuildLibraryImportsCachetarget when appropriate. It also improves the performance of
GetImportedLibrariesfor 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
GetImportedLibrariestarget 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
_ResolveLibraryProjectImportsbuild 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
GenerateJavaStubstask to skip over .NET Standard assemblies by now also skipping the whole parent
_GenerateJavaStubstarget in cases where only .NET Standard assemblies have changed. This allowed a small test Xamarin.Forms project to skip the
_GenerateJavaStubstarget 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>
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.
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
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
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
hand in your .csproj file:
<PropertyGroup> <AndroidUseAapt2>false</AndroidUseAapt2> </PropertyGroup>
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.
--no-version-vectorsoption 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
- 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).
aabcurrently 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 188.8.131.52
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:Dexesfast 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,
Several of the MSBuild targets were using
AfterTargetsin cases where they could be avoided. One consequence was that the
LinkAssembliestask would still run in cases where the
Compiletarget had failed. This resulted in misleading extra error messages about the failure of the
- 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
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
adbwas not included as part of the MSBuild error message in cases where
adbexited due to an error during deployment.
- GitHub PR 2975:
ResolveAndroidToolingMSBuild 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
%(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 184.108.40.206 updates the included
aapt2executable 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
_CreateBaseApkwould 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
ResolveXamarinAndroidToolstask 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
ResolveXamarinAndroidToolstask relative to the
@(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,
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:
Android.Security.Keystore.KeyStorePurposetype 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 220.127.116.11
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.
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
ITextWatcherInvokererror, 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
_CompileJavatarget when using certain libraries like Xamarin.Google.Guava.ListenableFuture that include an embedded .jar file and no public managed types.
Add the following lines to the bottom of your app project's .csproj file (just before the closing
<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.
In your .csproj file, conditionally set the
$(DesignTimeBuild)MSBuild property to a placeholder value of
falsewhen it is empty:
<PropertyGroup> <DesignTimeBuild Condition="'$(DesignTimeBuild)' == ''">false</DesignTimeBuild> </PropertyGroup>
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.
A big Thank You! to contributors who made improvements in this release:
- Atsushi Eno (@atsushieno), GitHub PR 2829: Add initial preview bindings for Android Q Beta.
- Atsushi Eno (@atsushieno), GitHub PR 2830: Remove unneeded api*.xml.in files from the xamarin-android repository because those files are now generated.
- Evgeniy Stepanov (@xtmq),
GitHub PR 2905:
Include the error message from
adbas part of the MSBuild error message in cases where
adbexits due to an error during deployment.
- Atsushi Eno (@atsushieno), GitHub PR 2965: Add preview bindings for Android Q Beta 2.
- Atsushi Eno (@atsushieno), GitHub Java.Interop PR 419: Update the Android API bindings generator tools to support additional Java language constructs that are used by the Android Q Beta stub .jar files.
Xamarin.Android 9.4 is based on the open-source Xamarin.Android repositories: