Skip to content

Xamarin.Android 10.2.0.84

Pre-release
Pre-release
Compare
Choose a tag to compare
@brendanzagaeski brendanzagaeski released this 11 Feb 20:13
v10.2.0.84
ac3f71f

January 22, 2020 — Xamarin.Android 10.2.0.84 was released as part of Visual Studio 2019 version 16.5 Preview 2.

January 14, 2020 — Xamarin.Android 10.2.0.84 was released as part of Visual Studio 2019 for Mac version 8.5 Preview 1 in the Preview updater channel.

Corresponding Visual Studio 2019 Preview release notes

What's new

Mono Framework version update to 6.8

Xamarin.Android now uses the Mono 6.8 runtime and class libraries at Commit df42020f, bringing in about 800 new commits.

Build and deployment performance

  • GitHub PR 3907: Adjust GenerateResourceDesigner to use System.Reflection.Metadata rather than Cecil, use loops instead of LINQ expressions, and skip over .NET Standard libraries. This reduced the time for the GenerateResourceDesigner task during an incremental build from about 470 milliseconds to about 370 milliseconds for a small app on a test system. The GenerateResourceDesigner task also runs in the foreground each time an Android resource is saved, so this makes Visual Studio more responsive when working on Android resources.
  • GitHub PR 3913: Skip the _GenerateJavaStubs target for builds where only Android resources have changed. This makes Visual Studio more responsive when working with Android resources. For example, it reduced the design-time build by about 400 milliseconds for a scenario where an Android resource was edited and saved in a moderately large app on a test system.
  • GitHub PR 4020: Skip a managed linker step for assemblies that have no references to Java.Lang.Object, such as .NET Standard libraries. This reduced the time for the _LinkAssembliesNoShrink target on a test system from about 160 milliseconds to about 50 milliseconds for an incremental build after a one-line change to the MainActivity class.

App startup performance

  • GitHub PR 3951: Avoid searching for unmanaged compiled assemblies generated by Enable Startup Tracing or AOT Compilation unless the app was built with one of those options enabled. This reduced the Runtime.init() phase of application startup for a small test app from about 172 milliseconds to about 168 milliseconds.

Improved Android manifest merging

Xamarin.Android now includes an option to use the same Android manifest merger tool that Android Studio uses to merge AndroidManifest.xml files. This provides new capabilities and improves compatibility with Android Studio. See the documentation for details about the available merge rules.

To enable the new behavior for your project, set the $(AndroidManifestMerger) MSBuild property to manifestmerger.jar in your .csproj file:

<PropertyGroup>
  <AndroidManifestMerger>manifestmerger.jar</AndroidManifestMerger>
</PropertyGroup>

Any project authors who were previously using the Xamarin.Android.ManifestMerger NuGet package can remove that package after adding this setting.

Bindings projects support for Kotlin libraries

This release adds better support for creating bindings for Kotlin libraries, including:

  • Hiding Kotlin internal types and members
  • Using Kotlin provided metadata to properly name method parameters
  • Hiding Kotlin generated methods like foo-impl that aren't intended for public use
  • Restoring Kotlin-mangled method names to their original names, such as changing foo-V5j3Lk8 back to foo
  • Adding support for Kotlin's native unsigned types (UInt, ULong, UShort, UByte)

Although it was technically possible to bind a Kotlin library previously, these changes greatly reduce the number of custom rules needed in the Transforms\Metadata.xml file to produce expected bindings.

No additional steps are needed to enable this. The binding process will detect if a .jar file was produced from Kotlin and will apply the needed fixes.

Important: Some of these changes required adding new APIs to Java.Interop.dll. This means that like the binding projects themselves, Xamarin.Android application projects that consume one of these new Kotlin library bindings must also be built using Xamarin.Android 10.2 or higher.

New build errors and warnings XA0121, XA2000

XA0121 error for old Xamarin.Android.Support library versions

The XA0121 warning from Xamarin.Android 10.1 is now an error because compatibility with the old GetAdditionalResourcesFromAssemblies MSBuild task has been removed.

Any project that uses one of the affected Xamarin.Android.Support libraries from version 26 or earlier will now see errors like:

error XA0121: Assembly 'Xamarin.Android.Support.Animated.Vector.Drawable' is using '[assembly: Java.Interop.JavaLibraryReferenceAttribute]', which is no longer supported. Use a newer version of this NuGet package or notify the library author.

To resolve these errors, update the project to use version 27 or higher of the Xamarin.Android.Support libraries.

XA2000 warning for use of AppDomain.CreateDomain()

The new XA2000 build warning identifies cases where projects are using the AppDomain.CreateDomain() API:

warning XA2000: Warning: Use of AppDomain::CreateDomain detected in assembly: AndroidApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. The AppDomain's will not be part of .NET 5 and therefore will be missing in newer Xamarin.Android releases.

Because AppDomain in .NET 5 will follow the .NET Core semantics, where there is only exactly one AppDomain and AppDomain.CreateDomain() throws PlatformNotSupportedException, any projects currently using AppDomain.CreateDomain() will need to switch to a different API like AssemblyLoadContext. Project authors are encouraged to begin this transition as soon as they can to prepare for the behavior change.

AndroidEnableDesugar now requires D8

Xamarin.Android now always use the D8 DEX compiler for projects that have the $(AndroidEnableDesugar) MSBuild property set to true:

<PropertyGroup>
  <AndroidEnableDesugar>true</AndroidEnableDesugar>
</PropertyGroup>

Similarly, Xamarin.Android now always uses the R8 code shrinker for projects that have $(AndroidEnableDesugar) set to true and that have the Code shrinker ($(AndroidLinkTool)) set to ProGuard or r8.

Note: $(AndroidEnableDesugar) does not correspond to any setting in the project properties pages in Visual Studio, so this change only affects project authors who have added the property to their .csproj files by hand.

Background information

This change allows Xamarin.Android to remove support for the old desugar_deploy.jar mechanism from the Android Jack toolchain that was deprecated in 2017.

Option for .NET exceptions from certain Android APIs

Several methods in Xamarin.Android override or implement .NET base class library methods but do not throw the expected exception types for those methods. For example, Android.Runtime.InputStreamInvoker is a subclass of System.IO.Stream where the Read() method throws Java.IO.IOException instead of System.IO.IOException.

Xamarin.Android 10.2 includes a new option to throw the expected exceptions from these methods. In some cases, like InputStreamInvoker.Read(), this means that the new exception type is thrown instead of the original exception type. In those cases, the original exception can be found in the InnerException property of the new exception.

Important: Be careful about enabling this option in an existing application. It will break any existing code that attempts to catch one of the original Java namespace exception types from one of these methods.

To enable the new behavior in your app, set the $(AndroidBoundExceptionType) MSBuild property to System in your .csproj file:

<PropertyGroup>
  <AndroidBoundExceptionType>System</AndroidBoundExceptionType>
</PropertyGroup>

Known issues

GitHub 4127: Even when the $(AndroidBoundExceptionType) MSBuild property is set to System, some of the methods in the Mono.Android.dll assembly do not throw all of the exceptions that are documented for the .NET base class library methods they override or implement.

Custom profiles for Enable Startup Tracing

The Enable Startup Tracing feature compiles a set of managed methods to unmanaged code to improve startup times. By default, only the common methods used during the startup of a basic Xamarin.Android app are compiled. For some apps, this default might not provide the optimum trade-offs between app size and startup times.

Xamarin.Android 10.2 includes new MSBuild targets to help create custom startup tracing profiles based on the actual methods that a particular app calls during startup.

Watch for future release notes updates with more information about how to use this feature.

Known issues

GitHub 4152: aotprofile-tool: Unable to read profile through local port: 9999 prevents the FinishAotProfiling target from completing successfully.

Mono debugger loglevel passthrough

The Mono soft debugger agent has an option to change the level of diagnostic information it logs. In the past, this log level was always 0 for Xamarin.Android apps. In Xamarin.Android 10.2, the log level can now be adjusted by setting the debugger-log-level option in the debug.mono.log Android system property. For example, the following command sets the log level to 10:

adb shell setprop debug.mono.log debugger-log-level=10

Mono compiler option passthrough

The new $(AndroidExtraAotOptions) MSBuild property allows passing options to the Mono compiler in projects that have either Enable Startup Tracing or AOT Compilation enabled.

In general, this property should be left blank, but in certain special scenarios it might provide useful flexibility.

Note that this property is different from the related $(AndroidAotAdditionalArguments) property. That property places comma-separated arguments into the --aot option of the Mono compiler. $(AndroidExtraAotOptions) instead passes full standalone space-separated options like --verbose or --debug to the compiler.

An example use would be to set the --verbose option to get additional diagnostic information during a command line build:

msbuild -p:AndroidAotAdditionalArguments=verbose

Issues fixed

Application and library build process

  • Developer Community 797093, GitHub PR 3945: warning XA5302: Two processes may be building this project at once. Lock file exists at path: ... obj\Debug\100\.__lock often appeared unnecessarily when deploying to an emulator or device from within Visual Studio.
  • GitHub 3428: Xamarin.Android did not yet provide an option to use the AndroidManifest.xml merge tool that Android Studio uses.
  • GitHub 3622: Warnings similar to R8 : warning : Resource 'META-INF/MANIFEST.MF' already exists. could appear in the Error List window when building apps in the Release configuration with Code shrinker set to r8. These warnings from the upstream R8 tool are not currently relevant for Xamarin.Android users, so Xamarin.Android 10.2 now logs them as plain messages instead of warnings.
  • GitHub 3808: The type or namespace name ... could not be found in the global namespace prevented using %(Aliases) MSBuild item metadata on Xamarin.Android library project references.
  • GitHub 3852: The LinkAssemblies task could get stuck in an infinite loop in projects referencing certain libraries when the $(Nullable) MSBuild property was set to enable.
  • GitHub 3911: The managed linker did not yet remove the custom attribute metadata that C# 8.0 nullable reference types use. That metadata is only needed at build time.
  • GitHub 3920: If a NuGet package included a library without a [assembly:ReferenceAssemblyAttribute] attribute under a ref directory, then Xamarin.Android apps could unexpectedly use that ref version of the library instead of the expected version from the appropriate lib directory.
  • GitHub PR 3937: message ANDKT0000: Warning: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format could appear in the diagnostic Xamarin.Android build output from Java's keytool.exe because Xamarin.Android did not yet specify a -storetype argument to keytool.exe when generating the debug.keystore file that is used by default for deployment to local Android devices and emulators.
  • GitHub PR 3968: 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 had to start with a . dot character to behave as expected. Now the . dot character is optional.
  • GitHub 3996: error XA5300: The Android SDK Directory could not be found. Please set via /p:AndroidSdkDirectory. could occur even after running the InstallAndroidDependencies MSBuild target on a newly configured build environment.
  • GitHub PR 4016: Unclear warning XA0110: Disabling true as it is not supported by `aapt2`. If you wish to use true please set true to false. appeared if the $(AndroidExplicitCrunch) MSBuild property was set to true in a project that was also configured to use AAPT2.
  • GitHub 4182: Errors similar to error XA2002: Can not resolve reference: `System.Diagnostics.EventLog`, referenced by `Microsoft.Extensions.Logging.EventLog`. could prevent building if the NuGet package path was set to a custom location, for example via the NUGET_PACKAGES environment variable.

Application behavior on device and emulator

  • Developer Community 788217: Exceptions similar to Android.Content.Res.Resources+NotFoundException: Resource ID #0x7f09001cv could cause apps to abort when trying to use Android resources if the [Activity(MainLauncher = true)] activity was in a library project.
  • GitHub PR 3862: If an app referenced multiple libraries that each provided a different version of an Android resource, then the final selected version of the resource in the app was different when the app was built using AAPT2 instead of AAPT.
  • GitHub PR 3927: Starting in Xamarin.Android 10.1, native libraries did not load as expected for apps deployed in the Debug configuration using the Assemblies:Dexes fast deployment mode.
  • GitHub PR 3940: Starting in Xamarin.Android 9.4, Unknown Mono AOT mode could appear incorrectly in the app log output depending on the AOT mode.
  • GitHub PR 3943: In Xamarin.Android 10.2.0.16, Unknown Mono AOT mode appeared incorrectly in the app log output for any app with Enable Startup Tracing or AOT Compilation enabled.
  • GitHub PR 3952: In Xamarin.Android 10.2.0.16, apps built in the Debug configuration took about 2 seconds longer to start than they had previously.

Android API bindings

  • GitHub 3712: The [Service] attribute did not yet include a property to set the new foregroundServiceType attribute that was added in Android 10 (API level 29).

Thank you

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

  • @mathieubourgeois, GitHub PR 3940: Correct the way the MSBuild tasks save the $(AndroidAotMode) property into the app, so that Unknown Mono AOT mode does not appear in the app log output incorrectly.

Installing

To get the new version in Visual Studio, update Visual Studio:

For other scenarios, the latest commercial .vsix and .pkg installer packages can be found in the project README.

Open source

Assets 2
Loading