Xamarin.Android 10.1 release notes

  • Article

| GitHub | Developer Community | System requirements | Blogs |

Important

The default names for generated Java types are different in this release. Any project that explicitly uses one of the old default names that starts with md5 will need to be updated by hand to account for this change. See Breaking change for generated Java type names below for more details.

Installing

What's new in Xamarin.Android 10.1

Xamarin.Android 10.1 releases

Corresponding Visual Studio 2019 release notes

February 11, 2020 — Xamarin.Android 10.1.4.0

This version is included in the Visual Studio 2019 version 16.4.5 release. A corresponding version is not yet available in Visual Studio 2019 for Mac version 8.4. These notes will be updated when the corresponding version is available.

Issues fixed in Xamarin.Android 10.1.4.0

Application and library build and deployment

  • Developer Community 790804, Developer Community 854497: Starting in Xamarin.Android 10.1, Mono.AndroidTools.RequiresUninstallException: The installed package is incompatible. Please manually uninstall and try again. interrupted deployment if the keystore used to sign the app had changed compared to the previous deployment. Xamarin.Android 10.1.4.0 now automatically takes care of uninstalling the app in this case, like Xamarin.Android 10.0 did.

January 14, 2020 — Xamarin.Android 10.1.3.7

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

Issues fixed in Xamarin.Android 10.1.3.7

Application and library build and deployment

  • Developer Community 845978, GitHub 3993: Starting in Xamarin.Android 10.1, You uploaded an APK or Android App Bundle with invalid or missing signing information for some of its files. prevented uploading successfully to Google Play for apps built using the Android App Bundle publishing format.

Application Mono Framework behavior on device and emulator

This version of Xamarin.Android updates the Mono 6.6 runtime and class libraries from Commit bef1e633 to Commit fd9f379d, adding 3 new commits.

Fixes included for issues reported with Xamarin.Android applications:

  • Developer Community 756697: Starting in Xamarin.Android 10.0, NTLM authentication in Xamarin.Android apps no longer worked, resulting in server-side System.ComponentModel.Win32Exception exceptions.

December 10, 2019 and January 8, 2020 — Xamarin.Android 10.1.1.0

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

This version of Xamarin.Android updates the Mono 6.6 runtime and class libraries from Commit e1ef7743 to Commit bef1e633, adding 9 new commits.

This update does not contain any changes that affect Xamarin.Android. The update just keeps the Mono commit aligned with Xamarin.iOS, Xamarin.Mac, and Visual Studio for Mac.

December 3, 2019 — Xamarin.Android 10.1.0.30

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

Summary of what's new in Xamarin.Android 10.1.0.30

Breaking change for generated Java type names

Important

Any project that explicitly uses one of the old default Java type names that starts with md5 will break in Xamarin.Android 10.1.

To restore the previous behavior temporarily, you can set the $(AndroidPackageNamingPolicy) MSBuild property to LowercaseMD5 in your .csproj file:

<PropertyGroup>
    <AndroidPackageNamingPolicy>LowercaseMD5</AndroidPackageNamingPolicy>
</PropertyGroup>

This backward compatibility option will be removed in the upcoming Xamarin.Android 10.2 version, so authors of projects that currently include literal uses of these default names are encouraged to transition to alternatives like the [Register] attribute and the [Activity] attribute as soon as possible.

Example breakage for a custom view

For a custom view like:

namespace AndroidApp1
{
    public class View1 : View
    {
        /* ... */
    }
}

One scenario that will break is if the literal Java type name md559d7fc296fc238aa7bec92ba27f2cb33.View1 is used in a layout file:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <md559d7fc296fc238aa7bec92ba27f2cb33.View1
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</LinearLayout>

This will result in an error when the app tries to inflate the layout:

Android.Views.InflateException: Binary XML file line #1 in com.contoso.androidapp1:layout/layout1: Binary XML file line #1 in com.contoso.androidapp1:layout/layout1: Error inflating class md559d7fc296fc238aa7bec92ba27f2cb33.View1 ---> Android.Views.InflateException: Binary XML file line #1 in com.contoso.androidapp1:layout/layout1: Error inflating class md559d7fc296fc238aa7bec92ba27f2cb33.View1 ---> Java.Lang.ClassNotFoundException: md559d7fc296fc238aa7bec92ba27f2cb33.View1 ---> Java.Lang.ClassNotFoundException: Didn't find class "md559d7fc296fc238aa7bec92ba27f2cb33.View1" on path: DexPathList

The typical fix is to use the type name of C# class in the layout file instead:

 <?xml version="1.0" encoding="utf-8"?>
 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
     android:orientation="vertical"
     android:layout_width="match_parent"
     android:layout_height="match_parent">
-    <md559d7fc296fc238aa7bec92ba27f2cb33.View1
+    <AndroidApp1.View1
         android:layout_width="match_parent"
         android:layout_height="match_parent" />
 </LinearLayout>

Another option is to use a [Register] attribute to customize the generated Java type name:

 namespace AndroidApp1
 {
+    [Register("com.contoso.androidapp1.view1")]
     public class View1 : View
     {

And then use that customized name in the layout file:

 <?xml version="1.0" encoding="utf-8"?>
 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
     android:orientation="vertical"
     android:layout_width="match_parent"
     android:layout_height="match_parent">
-    <md559d7fc296fc238aa7bec92ba27f2cb33.View1
+    <com.contoso.androidapp1.view1
         android:layout_width="match_parent"
         android:layout_height="match_parent" />
 </LinearLayout>

Example breakage for an activity

For an activity like:

namespace AndroidApp1
{
    public class MainActivity : Activity
    {
        /* ... */
    }
}

One scenario that will break is if the literal Java type name md559d7fc296fc238aa7bec92ba27f2cb33.MainActivity is used in the AndroidManifest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          android:versionCode="1"
          android:versionName="1.0"
          package="com.contoso.androidapp1">
  <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="28" />
  <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme">
    <activity android:label="@string/app_name" android:name="md559d7fc296fc238aa7bec92ba27f2cb33.MainActivity">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
</manifest>

This will result in an error when the app tries to start the activity:

java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.contoso.androidapp1/md559d7fc296fc238aa7bec92ba27f2cb33.MainActivity}: java.lang.ClassNotFoundException: Didn't find class "md559d7fc296fc238aa7bec92ba27f2cb33.MainActivity" on path: DexPathList

The typical fix is to add an [Activity] attribute on the C# class to generate the <activity> manifest element automatically:

 namespace AndroidApp1
 {
+    [Activity(Label = "@string/app_name", MainLauncher = true)]
     public class MainActivity : Activity
     {

And then remove the handwritten <activity> element from AndroidManifest.xml:

  <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme">
-   <activity android:label="@string/app_name" android:name="md559d7fc296fc238aa7bec92ba27f2cb33.MainActivity">
-     <intent-filter>
-       <action android:name="android.intent.action.MAIN" />
-       <category android:name="android.intent.category.LAUNCHER" />
-     </intent-filter>
-   </activity>
 </application>

Background information

This change comes from GitHub PR 3649, which switched the checksum algorithm used to create names for generated Java types from MD5 to CRC-64 to improve compatibility with build environments that have FIPS compliance enforced.

The use of MD5 checksums for these names was originally introduced in Xamarin.Android 5 to reduce the chance of conflicts among the names. See the release notes from that version and the related documentation for additional examples of how to resolve issues related to this change.

SHA-256 by default for APK signing and digest algorithms

Xamarin.Android 10.1 switches the default value of the $(AndroidApkSigningAlgorithm) MSBuild property from md5withRSA to SHA256withRSA and the default value of the $(AndroidApkDigestAlgorithm) MSBuild property from SHA1 to SHA-256. The $(AndroidApkSigningAlgorithm) property corresponds to the -sigalg option of the jarsigner command, and the $(AndroidApkDigestAlgorithm) corresponds to the -digestalg option.

This change is not expected to cause complications for existing apps, but if needed, existing projects can restore the previous behavior by setting the MSBuild properties back to the previous values in the .csproj file:

<PropertyGroup>
  <AndroidApkSigningAlgorithm>md5withRSA</AndroidApkSigningAlgorithm>
  <AndroidApkDigestAlgorithm>SHA1</AndroidApkDigestAlgorithm>
</PropertyGroup>

Note that for projects configured to use the Android App Bundle publishing format, the older options are not relevant because the Android App Bundle publishing format already required the SHA256withRSA and SHA-256 algorithms in Xamarin.Android 10.0 and earlier.

Background information

This change comes from GitHub PR 3649. The reason for the change is to improve compatibility with build environments that have FIPS compliance enforced.

IDE support for Android App Bundle publishing format

Visual Studio 2019 version 16.4 and Visual Studio 2019 for Mac version 8.4 add IDE compatibility for the Android App Bundle publishing format. On Windows, this publishing format can now be enabled by setting Android Package Format to bundle in the Android Options section of the project property pages:

Visual Studio project property pages with bundle Android Package Format selected

On macOS, this publishing format can be enabled by setting Android Package Format to aab in the Android Build section of the project property pages:

Visual Studio for Mac project property pages with aab Android Package Format selected

The Build > Archive and Build > Archive for Publishing commands are now also compatible with the new publishing format. This resolves the following issue:

  • Developer Community 669333: Failed to create App archive, Invalid Android Archive (no .APK files) when attempting to use new Android App Bundle publishing format with the Build > Archive command.

Background information

Xamarin.Android 9.4 introduced initial command line support for the Android App Bundle publishing format. Xamarin.Android 10.0 in Visual Studio 2019 version 16.3 expanded on that support by addressing a limitation related to the on-device Install location. But the option for the Android App Bundle publishing format was not yet available in the Visual Studio project property pages, and the Build > Archive command in the IDE did not yet support the new publishing format.

Mono Framework version update to 6.6

This version of Xamarin.Android updates the Mono runtime and class libraries from Mono 6.4 to Mono 6.6 Commit e1ef7743, adding about 800 new commits.

Build and deployment performance

  • GitHub PR 3296: Remove an unneeded LINQ Distinct() call from the ResolveLibraryProjectImports task. This saved about 25 milliseconds for each run of the task in a test environment.
  • GitHub PR 3354: Improve the behavior of the _GenerateJavaStubs task so that it is skipped as expected during an incremental build of a Xamarin.Android bindings library project when no files have changed.
  • GitHub PR 3359: Allow the managed linker to read the input assemblies from their original locations instead of copying them to an intermediate obj\Debug\*\linksrc directory beforehand. This removes the _CopyMdbFiles, _CopyPdbFiles, and _CopyIntermediateAssemblies targets. Those targets previously took approximately 150 milliseconds for a test Xamarin.Forms app when only one XAML file was changed between builds. Depending on system speed and antivirus settings, the total savings can be greater. For example, for one tested example project and environment, the overall build time decreased from about 33 seconds to about 30 seconds.
  • GitHub PR 3528: Correct the Inputs and Outputs for the SetupDependenciesForDesigner and _ResolveLibraryProjectImports targets, and add an option for the Javac task to skip creating a classes.zip file when running for the designer. In addition to improving the designer responsiveness, this also allows projects to skip the _CompileToDalvikWithDx or _CompileToDalvikWithD8 target in incremental builds when only an Android XML layout file has changed. For example, in one test of an example project, the _CompileToDalvikWithD8 target previously took roughly 4.6 seconds for this scenario, and now it is skipped completely.
  • GitHub PR 3535, GitHub PR 3600: Add and switch to a new specialized LinkAssembliesNoShrink MSBuild task for Debug builds. In the Debug scenario, where the managed linker is not set to remove any types, the managed linker only needs to run a quick step to adjust abstract methods in Xamarin.Android assemblies. The new specialized task reduced the time for the _LinkAssembliesNoShrink target from about 340 milliseconds to about 10 milliseconds for a test Xamarin.Forms app when one line of a XAML file was changed between builds.
  • GitHub PR 3555: Improve the behavior around the _BuildApkFastDev target so it is skipped correctly when a Xamarin.Android app project has changes that do not require building a new APK. For example, changes to user-defined classes do not require a new APK unless they inherit from Java.Lang.Object, but the target was running if any class in the app project changed. Correcting this behavior saved roughly 2.5 seconds for the deployment time of a small test Xamarin.Android app on a fast build machine.
  • GitHub PR 3640: Use System.Reflection.Metadata rather than Cecil for ResolveLibraryProjectImports. This reduced the time for the ResolveLibraryProjectImports task from about 4.8 seconds to about 4.5 seconds for a small test Xamarin.Forms app on an initial clean build.
  • Java.Interop GitHub PR 440, Java.Interop GitHub PR 441, Java.Interop GitHub PR 442, Java.Interop GitHub PR 448, Java.Interop GitHub PR 449, Java.Interop GitHub PR 452: Optimize several of the build steps for bindings projects. For a large binding like Mono.Android.dll itself, this reduced the total build time in a test environment by about 50 seconds.
  • GitHub PR 3592: When Use Fast Deployment is enabled, cache some of the information that is retrieved from the device during the first deployment so that it can be reused on subsequent deployments of the same app until Visual Studio is restarted. This reduced the time for the InstallPackageAssemblies task during the second deployment of a Xamarin.Forms app where one line of a XAML file was changed from about 500 milliseconds to about 375 milliseconds in a test environment.

App startup performance

GitHub PR 3660: Switch from unzip to a custom minimal .zip file format reader to load managed assemblies from the APK during startup. This reduced the Runtime.init() phase of application startup for a small Xamarin.Forms test app targeting the arm64-v8a ABI from about 230 milliseconds to about 170 milliseconds on a Google Pixel 3 device running Android 10.

Environment variables and files for package signing passwords

Until now, the Keystore Password and Alias Password settings in the Android Package Signing section of the Visual Studio project property pages only supported literal password values. Starting in Xamarin.Android 10.1, these settings now support a new syntax that allows entering environment variable names or file names instead. These options provide a way to prevent the passwords from appearing in build logs.

To use an environment variable name, prefix the name with env:. To use a local file path, prefix the path with file:.

For example, to use an environment variable named AndroidSigningPassword for both settings, enter env:AndroidSigningPassword under both the Keystore Password and Alias Password settings. This sets the corresponding $(AndroidSigningStorePass) and $(AndroidSigningKeyPass) MSBuild properties in your .csproj file:

<PropertyGroup>
  <AndroidSigningStorePass>env:AndroidSigningPassword</AndroidSigningStorePass>
  <AndroidSigningKeyPass>env:AndroidSigningPassword</AndroidSigningKeyPass>
</PropertyGroup>

To use a file located at C:\Users\Windows User\AndroidSigningPassword.txt for both settings, enter file:C:\Users\Windows User\AndroidSigningPassword.txt. This again sets the corresponding $(AndroidSigningStorePass) and $(AndroidSigningKeyPass) MSBuild properties in your .csproj file:

<PropertyGroup>
  <AndroidSigningStorePass>file:C:\Users\Windows User\AndroidSigningPassword.txt</AndroidSigningStorePass>
  <AndroidSigningKeyPass>file:C:\Users\Windows User\AndroidSigningPassword.txt</AndroidSigningKeyPass>
</PropertyGroup>

Note that if the same file is specified for both settings, the file must contain two lines. The first line must be the keystore password, and the second line must be the alias password.

This resolves the following issue:

  • GitHub 3513: The only way to provide package signing passwords to the SignAndroidPackage target was to place the literal passwords directly in the $(AndroidSigningStorePass) and $(AndroidSigningKeyPass) properties, meaning that the passwords would be logged to the build output.

C# 8.0 default interface members for bindings projects

In Android 7.0 Nougat (API level 24) and higher, some Android libraries started using new Java 8 language features, including:

  • Default interface methods
  • Static interface methods
  • Interface constants

C# 8.0 introduces a similar default interface members language feature. Starting in Xamarin.Android 10.1, Xamarin.Android bindings projects can now take advantage of this new capability to surface C# APIs that more closely match the original APIs in the Java libraries.

To try this functionality with your bindings project, set the $(LangVersion) MSBuild property to preview and the $(_EnableInterfaceMembers) MSBuild property to true in your .csproj file:

<PropertyGroup>
  <LangVersion>preview</LangVersion>
  <_EnableInterfaceMembers>true</_EnableInterfaceMembers>
</PropertyGroup>

Note that enabling this new option only adds members. It does not remove the previous style of C# bindings for these kinds of Java APIs.

New build warnings XA0119, XA0121, XA5302

XA0119 warning for non-ideal Debug build configurations

Xamarin.Android 10.1 adds a new XA0119 build warning to identify cases where projects might have unintentionally enabled settings that slow down deployments in the Debug configuration. For the best Debug configuration deployment performance, first ensure that Use Shared Runtime is enabled in the Visual Studio project property pages. This sets the $(AndroidUseSharedRuntime) MSBuild property to true in your .csproj file:

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

When Use Shared Runtime is enabled, an XA0119 warning will appear if any of the following settings are enabled:

  • Android Package Format set to bundle
  • Code shrinker
  • AOT Compilation
  • Enable Startup Tracing
  • Linking

Be sure to disable these settings for the best Debug configuration deployment performance.

XA0121 deprecation warning for old Xamarin.Android.Support library versions

Xamarin.Android 10.1 adds a new XA0121 build warning to identify cases where projects are still using certain Xamarin.Android.Support libraries version 26 or earlier that depend on the old GetAdditionalResourcesFromAssemblies MSBuild task to download dependencies from Google during the build process:

warning XA0121: Assembly 'Xamarin.Android.Support.Animated.Vector.Drawable.dll' is using a deprecated attribute '[assembly: Android.IncludeAndroidResourcesFromAttribute]'. Use a newer version of this NuGet package or notify the library author.

Current versions of the Xamarin.Android.Support libraries instead use the Xamarin.Build.Download library to handle the downloads. That new mechanism improves the behavior in the IDE. Depending on user feedback about the XA0121 warning, the plan is that a future version of Xamarin.Android will remove the old GetAdditionalResourcesFromAssemblies MSBuild task completely to improve build performance

This warning will also identify other libraries from the Xamarin community that might be using the old download mechanism. Library authors are encouraged to transition to Xamarin.Build.Download at their earliest convenience to resolve this warning.

XA5302 warning when multiple MSBuild targets are invoked in parallel

Xamarin.Android did not yet produce a warning if Visual Studio invoked one of the Xamarin.Android MSBuild targets while another target was already running in parallel. Xamarin.Android 10.1 now emits a XA5302 warning in this case so that the Xamarin.Android team can monitor how often this happens and how often it is associated with other build issues. Example:

If you need to suppress this warning, you can add it to the $(MSBuildWarningsAsMessages) MSBuild property in your .csproj file:

<PropertyGroup>
  <MSBuildWarningsAsMessages>XA5302</MSBuildWarningsAsMessages>
</PropertyGroup>
Known issues

GitHub PR 3945: warning XA5302: Two processes may be building this project at once. Lock file exists at path: ... obj\Debug\100\.__lock often appears unnecessarily when deploying to an emulator or device from within Visual Studio. For now, it can be suppressed via the $(MSBuildWarningsAsMessages) MSBuild property or ignored. GitHub PR 3945 will improve the behavior in a future release.

aprofutil analysis tool

Xamarin.Android 10.1 includes a new aprofutil command-line tool to help analyze AOT performance. See the README for additional information.

External tool version updates

R8 version update to 1.5.68

The version of the R8 code shrinker included in Xamarin.Android has been updated from 1.4.93 to 1.5.68.

bundletool version update to 0.10.2

The version of the bundletool executable included in Xamarin.Android has been updated from 0.10.0 to 0.10.2, bringing in several improvements and bug fixes.

Mono.Data.Sqlite SQLite version update

The version of SQLite used by Mono.Data.Sqlite in Xamarin.Android has been updated from 3.27.1 to 3.28.0, bringing in several improvements and bug fixes.

Issues fixed in Xamarin.Android 10.1.0.30

Application and library build and deployment

  • Developer Community 237753, Developer Community 554407, GitHub 3407: Errors similar to [aot-compiler stderr] Cannot open assembly 'Files': No such file or directory. or Illegal characters in path ... at Xamarin.Android.Tasks.Aot could prevent projects using Enable Startup Tracing or AOT Compilation from building successfully on volumes where Windows 8.3 file name creation was disabled. Xamarin.Android 10.1 now uses a response file to pass command line parameters to the tooling for these steps, so having 8.3 file name creation enabled is no longer required.
  • Developer Community 446584, GitHub 2711: In some scenarios, the deployment process could get stuck during the the Detecting installed packages... step.
  • Developer Community 576975, GitHub 3091: The Removing old runtime and Installing shared runtime deployment steps were repeated during every incremental deployment on certain devices.
  • Developer Community 618007, GitHub 3294: Could not find android.jar for API Level 28. ... Either install it in the Android SDK Manager (Tools > Open Android SDK Manager...) error message did not indicate the correct menu location for the Android SDK Manager on Windows.
  • Developer Community 679868: Errors like error APT0000: resource layout/headerLayout (aka com.contoso.androidapp:layout/headerLayout) not found. or error APT0000: No resource found that matches the given name (at 'headerLayout' with value '@layout/headerLayout'). prevented projects from building successfully if an Android layout used the capitalized suffix Layout in a reference to another layout, unless the name was rectLayout, roundLayout, or actionLayout. Xamarin.Android 10.1 now automatically lowercases any value that ends with Layout when used with attributes from the http://schemas.android.com/apk/res-auto XML namespace.
  • GitHub 1240: error XA3001: System.IO.IOException: Cannot create a file when that file already exists prevented projects from building successfully if they had a value explicitly set for the undocumented, experimental $(AndroidAotMode) MSBuild property.
  • GitHub 2023: Imprecise error XA0000: Unhandled exception: System.FormatException: Input string was not in a correct format. was shown if the Version number in the Android Manifest (or Android Application on macOS) section of the Visual Studio project property pages was set to a value that could not be parsed as an integer. Xamarin.Android 10.1 now shows a more specific error message for this scenario.
  • GitHub 2848: Unclear messages similar to Unable to remove directory "obj\Debug\90\android\bin\classes". Could not find a part of the path 'AccessibilityManagerCompat_AccessibilityStateChangeListenerImplementor.class' and Failed to create JavaTypeInfo for class: Android.Support.V4.View.AsyncLayoutInflater/IOnInflateFinishedListenerImplementor due to System.IO.DirectoryNotFoundException: Could not find a part of the path '... AsyncLayoutInflater_OnInflateFinishedListenerImplementor.java'. were shown when attempting clean or build projects where one of the build steps used a path length close to the Windows API maximum path length limitation of 260 characters. Xamarin.Android 10.1 will now retry certain failing steps using the \\?\ prefix and provide a more specific error message about the path length limitation if that also fails.
  • GitHub 2957: Setting the $(Deterministic) MSBuild property to true in Xamarin.Android projects did not yet result in a constant MVID for the resulting output assemblies. Xamarin.Android projects will now produce a constant MVID and byte-identical outputs as expected when $(Deterministic) is set to true. One caution is that this setting is not compatible with having a wildcard like [assembly: AssemblyVersion("1.0.*")] in the AssemblyVersion attribute.
  • GitHub PR 3368: Messages from the lint tool when the $(AndroidLintEnabled) MSBuild was set to true would include paths to intermediate build versions of Android resource files rather than paths to the original resource files.
  • GitHub 3370: Starting in Xamarin.Android 10.0, warning XA4306: R8 does not support `MultiDexMainDexList` files was shown when building projects that had the Code shrinker set to r8, Enable Multi-Dex enabled, and Minimum Android version set to at least Android 5.0 Lollipop (API level 21), even if no @(MultiDexMainDexList) items were set.
  • GitHub 3477: error MSB4018: The "ConvertCustomView" task failed unexpectedly. ... System.NullReferenceException incorrectly prevented building in some scenarios where the ConvertCustomView task could in fact just skip over the null object.
  • GitHub PR 3523: Libraries that used the MSBuild.Sdk.Extras NuGet package for the project SDK and that targeted a Xamarin.Android target framework like MonoAndroid90 would by default add an unexpected extra subdirectory for the version number in the output path: bin\Debug\monoandroid90\90\Library.dll.
  • GitHub 3547: error ANDKT0000: keytool error: java.lang.Exception: Key pair not generated, alias <androiddebugkey> already exists could prevent projects from building successfully under system accounts, such as when building in certain continuous build environments. Xamarin.Android 10.1 now skips the attempt to create a debug keystore in Release configurations if the Sign the .APK file using the following keystore details. setting is enabled in the Android Package Signing section of the Visual Studio project properties pages. This setting corresponds to the $(AndroidKeyStore) MSBuild property in the .csproj file.
  • GitHub PR 3561: Starting in Xamarin.Android 10.0, the _GenerateJavaStubs target could run during builds where it wasn't needed if any of the previous builds had involved a change to a class that inherited from Java.Lang.Object.
  • GitHub 3562: Starting in Xamarin.Android 10.0, building a Xamarin.Android app that included an embedded Android Wear app would rerun a number of expensive MSBuild tasks even when the outputs were already up-to-date.
  • GitHub 3571: Errors returned by the ProGuard tool were all surfaced under an unspecific and misleading error MSB6006: "java.exe" exited with code 1. build error. Xamarin.Android 10.1 now includes the more specific error text from ProGuard in the build error.
  • GitHub PR 3577, GitHub PR 3599: Xamarin.Android used one generic APT0000 code for the majority of the errors and warnings that could occur when running the Android AAPT and AAPT2 command line tools. Xamarin.Android 10.1 now checks for a large list of warning and error message fragments from AAPT and AAPT2 and assigns them to unique APT message codes so that the Xamarin.Android team can monitor how often users encounter each of the messages when building Xamarin.Android projects.
  • GitHub PR 3584: error XA5300: Error finding Xamarin.Android SDK could sometimes intermittently prevent building Xamarin.Android projects successfully in certain environments.
  • GitHub PR 3609, GitHub PR 3704, GitHub PR 3766: The Xamarin.Android MSBuild tasks allowed unhandled exceptions to propagate to MSBuild by default, meaning that any build failure caused by an unhandled exception in a task was assigned to the generic MSB4018 error code. Xamarin.Android 10.1 now uses unique error code prefixes for each of its MSBuild tasks and several unique error code numbers for different exception types so that the Xamarin.Android team can monitor which exception types and tasks most often cause build failures in user projects.
  • GitHub PR 3609: Xamarin.Android used one generic ADB0000 code for the majority of the errors and warnings that could occur when running the Android ADB command line tool. Xamarin.Android 10.1 now checks for a large list of error message fragments from ADB and assigns them to unique ADB message codes so that the Xamarin.Android team can monitor how often users encounter each of the messages when building Xamarin.Android projects.
  • GitHub 3635: The output .aab file was not removed from the bin directory by the Clean MSBuild target for projects configured to use the Android App Bundle publishing format, with the $(AndroidPackageFormat) MSBuild property set to aab in the Release configuration.
  • GitHub 3675: Android resources and assets were all stored compressed in projects configured to use AAPT2, regardless of any file extensions set in the $(AndroidStoreUncompressedFileExtensions) MSBuild property or in the corresponding Leave the following resource extensions uncompressed setting in the Visual Studio project property pages.
  • GitHub PR 3685: warning ANDJS0000 was always shown for the jarsigner warnings The signer's certificate is self-signed. and No -tsa or -tsacert is provided and this jar is not timestamped. Those messages were not relevant for Xamarin.Android users, so Xamarin.Android 10.1 now reports them as informational messages rather than warnings.
  • GitHub 3779: In projects configured to use AAPT2, the second build could incorrectly succeed without errors if the first build failed due to an error in an Android resource file.
  • GitHub 3807: Xamarin.Android projects did not yet enable C# 8 features by default for projects that left the $(MaxSupportedLangVersion) MSBuild property at the default empty value.
  • Java.Interop GitHub PR 458: Bindings projects did not yet automatically generate event handlers for Java listener interfaces where the add or set method of the interface took two arguments instead of just one.
  • Java.Interop GitHub PR 471: error CS0234: The type or namespace name ... does not exist in the namespace appeared in bindings projects if a public Java interface or class from the input library inherited from a package-private interface. Xamarin.Android 10.1 now handles this pattern automatically so that no additional rules are needed for it in the Transforms/Metadata.xml file.
  • Java.Interop GitHub 466: NullReferenceException ... at JavaApiXmlGeneratorExtensions.Save prevented bindings projects for Kotlin libraries from completing the code generation build step. Xamarin.Android 10.1 now allows these projects to complete the code generation step. Note that at the moment, additional manual fixes via the Transforms\Metadata.xml file will usually be required. Further improvements for binding Kotlin libraries will be added in future releases.
  • Java.Interop GitHub 496: Bindings projects for Kotlin libraries could fail to build due to hyphen characters in method names generated by Kotlin.
  • Java.Interop GitHub PR 498: Bindings projects for Kotlin libraries did not always transform Kotlin method names to valid C# method names when generating the C# bindings types.
  • xamarin-android-tools PR 74: error XA5300: The Java SDK Directory could not be found could appear in some command line build environments on Windows even though the JAVA_HOME environment variable contained a valid Java JDK path.

Application behavior on device and emulator

  • Developer Community 743965, GitHub 3626: Starting in Xamarin.Android 10.0, Newtonsoft.Json.JsonReaderException: Unexpected character encountered caused JsonConvert.DeserializeObject() to fail in apps built in the Release configuration.
  • GitHub 3348: FATAL EXCEPTION: main ... java.lang.IllegalStateException: Module with the Main dispatcher is missing. could prevent apps from running if they referenced Kotlin libraries.
  • GitHub 3373: Errors similar to 'dlopen failed: "/data/app/com.contoso.androidapp-AAAAAAAAAAAAAAAAAAAAAA==/lib/x86/libe_sqlite3.so" has unexpected e_machine: 40 (EM_ARM)' ... System.DllNotFoundException: e_sqlite3 could prevent using unmanaged libraries successfully in apps that had an Android ABI name like x86 in one of the intermediate build paths such as $(IntermediateOutputPath).
  • GitHub PR 3458: Java.Lang.AbstractMethodError was thrown if an app attempted to invoke a C# 8.0 default interface member on a subclass of Java.Lang.Object.
  • GitHub 3498: Writing to the System.IO.Stream returned by Application.Context.ContentResolver.OpenOutputStream() completed without error but did not write any bytes to the output location.
  • GitHub 3596: Strings from .resx files were not localized in apps built with $(AndroidPackageFormat) set to aab.
  • GitHub 3598: Errors similar to Java.IO.IOException: This file can not be opened as a file descriptor; it is probably compressed could occur when attempting to use binary assets in apps built with $(AndroidPackageFormat) set to aab.
  • GitHub PR 3664: Debugging into the Mono or Xamarin.Android base class libraries did not work as expected for projects with Use Shared Runtime enabled because the shared runtime did not include the debug symbols for those libraries.
  • GitHub 3751: More Java bytecode than expected was being optimized and stripped out in apps built with the D8 Dex compiler in combination with Enable Multi-Dex. This could cause unexpected behaviors where callback methods would not be called as expected.

Android API bindings

  • GitHub PR 3102: Android.Views.Accessibility.Action did not include the [Flags] attribute, so using bitwise operators on it would produce warnings in static analysis tools.
  • GitHub 3180: Android.Views.MetaKeyStates did not yet include an enum member for 0.
  • GitHub 3508: Android.Bluetooth.ProfileType did not yet include an enum member for the new HearingAid value introduced in Android 10 (API level 29).

Design-time build process

  • Developer Community 325734: IntelliSense errors similar to 'Resource' does not contain a definition for 'CustomId' appeared in projects that used non-standard namespaces for resource IDs defined in resource files, like android:id="@+idCustom/textView1". AAPT2 does not currently support non-standard namespaces for resource IDs, so this issue only applies to projects configured to use the older AAPT.

Application Mono Framework behavior on device and emulator

  • Developer Community 668413, GitHub 3426, Mono GitHub 17133: Starting in Xamarin.Android 9.4, System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted prevented using File.Copy() to copy files to the Android external storage directory.
  • GitHub 3726: System.NotSupportedException: 'TypeConverter cannot convert from System.String. prevented apps from using TypeConverter.ConvertFromString() to create an instance of System.Drawing.Color.
  • Mono GitHub 14772: Fatal signal 11 (SIGSEGV), code 1, fault addr ... in tid ... (Debugger agent) caused Android applications to abort if the managed debugger agent tried to perform a Step Over command while paused on an unhandled exception.
  • Mono GitHub 16918: Starting in Xamarin.Android 9.4, XmlSerializer.Deserialize() did not successfully deserialize properties where the name of the property matched the name of the type of the property.

Known issues in Xamarin.Android 10.1.0.30

  • GitHub PR 3945: warning XA5302: Two processes may be building this project at once. Lock file exists at path: ... obj\Debug\100\.__lock often appears unnecessarily when deploying to an emulator or device from within Visual Studio. For now, it can be suppressed via the $(MSBuildWarningsAsMessages) MSBuild property or ignored. GitHub PR 3945 will improve the behavior in a future release.

Thank you

A big Thank You! to community members who contributed improvements in this release:

  • Alexander Gayko (@AdmiralSnyder), GitHub PR 3102: Add the [Flags] attribute to Android.Views.Accessibility.Action, so that using bitwise operators on it does not produce warnings in static analysis tools.
  • GitHub PR 3518: Fix the mingw-w64 Homebrew dependency version constraint for the xamarin-android make prepare source build step on macOS so that make prepare can be run more than once on the same development environment.

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.

Open source

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