Skip to content

Xamarin.Android 10.1.0.1

Pre-release
Pre-release
Compare
Choose a tag to compare
@brendanzagaeski brendanzagaeski released this 15 Oct 19:54
v10.1.0.1
ee1dfb6

October 17, 2019 — Xamarin.Android 10.1.0.1 was released to the Preview updater channel of Visual Studio 2019 for Mac version 8.4 Preview 1.

October 15, 2019 — Xamarin.Android 10.1.0.1 was released as part of Visual Studio 2019 version 16.4 Preview 2.

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.

Corresponding Visual Studio 2019 Preview release notes

What's new

Breaking change for generated Java type names

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 this change is not relevant to projects using the initial support for the Android App Bundle publishing format because that 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 Preview 2 adds IDE compatibility for the Android App Bundle publishing format. 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

The Build > Archive command is 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.

Notes

IDE support for the Android App Bundle publishing format is not yet available in Visual Studio for Mac. It will be added in a future version of Visual Studio for Mac.

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. In Visual Studio 2019 version 16.3, 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.

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.

Build and deployment performance

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

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

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.

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.

Issues fixed in Xamarin.Android 10.1.0.1

Application and library build process

  • 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 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 3619: In Xamarin.Android 10.0.99.100, error XA3001: Could not AOT the assembly due to [aot-compiler stderr] '""C:\Program' is not recognized as an internal or external command prevented projects that used Enable Startup Tracing or AOT Compilation from building successfully on Windows if they had armeabi-v7a selected in Advanced > Supported architectures under the Android Options section of the Visual Studio project property pages.
  • GitHub 3635: The output .aab file was not removed from the bin directory by the Clean MSBuild target for projects configured to use the initial support for 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, which corresponds to the Leave the following resource extensions uncompressed setting in the Visual Studio project property pages.
  • GitHub 3700: Incorrect keystore password error prevented using the new file: prefix for package signing passwords in projects configured to use the initial support for the Android App Bundle publishing format, with the $(AndroidPackageFormat) MSBuild property set to aab in the Release configuration.
  • GitHub PR 3704: The new exception code prefixes added in GitHub PR 3609 did not yet distinguish among different subclasses of IOException. Now they do so that the Xamarin.Android team can monitor which subclasses of IOException most often cause build failures in user projects.
  • GitHub 3723: Errors similar to Failed to resolve System.Void System.Diagnostics.CodeAnalysis.DoesNotReturnIfAttribute::.ctor(System.Boolean) could prevent deploying or archiving successfully in the Release configuration for apps that referenced .NET Standard 2.1 libraries such as Microsoft.EntityFrameworkCore 3.0. This fix is also included in Xamarin.Android 10.0.3.0.

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.

Application Mono Framework behavior on device and emulator

This version of Xamarin.Android updates the Mono 6.6 runtime and class libraries from Commit 29b1ac19 to Commit 52810372, adding 49 new commits.

Fixes included for issues reported with Xamarin.Android applications:

  • 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.
  • Mono GitHub 17064, GitHub 3723: Errors similar to System.TypeLoadException: 'Could not resolve type with token 01000143 from typeref (expected class 'System.Diagnostics.CodeAnalysis.MaybeNullAttribute' in assembly 'netstandard, Version=2.1.0.0 could cause apps to abort when they tried to use types from .NET Standard 2.1 libraries such as Microsoft.EntityFrameworkCore 3.0. This fix is also included in Xamarin.Android 10.0.3.0.

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.

OSS core

The corresponding open-source build without commercial features is xamarin-android-d16-4 build #21.

Assets 2
Loading