Xamarin.Android 9.3.0.14
Pre-releaseXamarin.Android 9.3.0.14 was released as part of Visual Studio 2019 version 16.1 Preview 2 and Visual Studio 2019 for Mac.
What's new
- Build and deployment performance
- App startup performance
- Android NDK r19 compatibility
- Easier way to use
android:extractNativeLibs="false"
- arm64-v8a architecture enabled by default
- R8 version update to 1.3.52
- Mono.Data.Sqlite SQLite version update
- OpenTK version 0.9.9.3 warning
- Issues fixed
Build and deployment performance
- GitHub PR 2554: Skip the
_SetLatestTargetFrameworkVersionForPackageReference
MSBuild during NuGet restore unless$(AndroidUseLatestPlatformSdk)
istrue
. This saved roughly 600 milliseconds for NuGet restore on a test project that used an explicit$(TargetFrameworkVersion)
with$(AndroidUseLatestPlatformSdk)
set tofalse
. - GitHub PR 2561: Remove the old
_RegisterAndroidFilesWithFileWrites
target that is no longer needed. This trimmed about 80 milliseconds off the build time of a test project. - Java.Interop GitHub PR 405, GitHub PR 2576: Change some LINQ expressions to loops and remove some redundant assembly metadata retrieval steps. This reduced the time for the
GenerateJavaStubs
task in a test project from approximately 1414 milliseconds to 1355 milliseconds. - GitHub PR 2589: Change a few uses of temporary on-disk files to work all in memory instead.
- GitHub PR 2612: Switch the
ResolveAssemblies
task to use System.Reflection.Metadata instead of Mono.Cecil. This reduced the time for theResolveAssemblies
task in a test project from about 320 milliseconds to about 110 milliseconds. - GitHub PR 2624: Switch the
GetAdditionalResourcesFromAssemblies
task to use System.Reflection.Metadata instead of Mono.Cecil. This reduced the time for theGetAdditionalResourcesFromAssemblies
task in a test project from about 100 milliseconds to about 50 milliseconds. - GitHub PR 2626: Exclude the
Build
target from being a dependency of theSignAndroidPackage
when building inside the IDE. This reduced the time to re-launch an unchanged test application from roughly 6.5 seconds to roughly 4.5 seconds. - GitHub PR 2643: Skip over .NET Standard (and Portable Class Library) projects in the
GenerateJavaStubs
task because those project types never need to interact with Java. This reduced the total time for theGenerateJavaStubs
task from about 1 second to 870 milliseconds for incremental builds of a test Xamarin.Forms project. Projects that use more .NET Standard libraries could see a more noticeable time savings.
App startup performance
Java.Interop GitHub PR 416, GitHub PR 2716: Change the JNI runtime interop initialization to happen lazily, allowing the app to skip some parts during startup. This reduced the time for this initialization step from roughly 225 milliseconds to 216 milliseconds for a test application on a Pixel 2 XL device.
Android NDK r19 compatibility
Xamarin.Android version 9.3 adds compatibility for running clang
rather than gcc
for the Bundle assemblies into native code and AOT Compilation build options. This allows Xamarin.Android to use Android NDK version r18 and above, where GCC has been removed.
The native libraries that are part of Xamarin.Android are now also built against Android NDK r19. The updated Android NDK toolchain means that it is now recommended to use Xamarin.Android apps only with devices running Android 4.1 (API level 16) or higher. Warning XA4216 has been updated accordingly to help highlight this change for any projects that might still have an older version set for the minSdkVersion
in the AndroidManifest.xml file.
Easier way to use android:extractNativeLibs="false"
Xamarin.Android 9.2 added support for the android:extractNativeLibs="false"
setting, but enabling it required several manual steps. Xamarin.Android 9.3, makes this feature easier to work with by trimming down the number of steps to just one:
- Add the
android:extractNativeLibs="false"
attribute to the<application/>
element in the Properties\AndroidManifest.xml file
arm64-v8a architecture enabled by default
Starting August 1, 2019, Google Play will require all new apps and app updates that include native code to provide 64-bit versions in addition to 32-bit versions. To align with this upcoming requirement, Xamarin.Android version 9.3 now includes both armeabi-v7a and arm64-v8a in the default value of the $(AndroidSupportedAbis)
MSBuild property. This change will only affect existing build configurations if the property is blank for that configuration in the .csproj file. The change will not affect build customized configurations where the property already includes an architecture other than armeabi-v7a.
R8 version update to 1.3.52
The version of the R8 code shrinker included in Xamarin.Android has been updated from 1.2.52 to 1.3.52.
Mono.Data.Sqlite SQLite version update
The version of SQLite used by Mono.Data.Sqlite in Xamarin.Android has been updated from 3.26.0 to 3.27.1, bringing in several improvements and bug fixes.
OpenTK version 0.9.9.3 warning
As mentioned in the previous release notes, the assembly for OpenTK version 0.9.9.3 will be removed from Xamarin.Android in an upcoming release. To help prepare for this removal, Xamarin.Android 9.3 now provides a build warning for any project referencing OpenTK version 0.9.9.3:
warning XA1009: OpenTK 0.9.3 is Obsolete. Please upgrade to OpenTK 1.0
To resolve this warning in Visual Studio, ensure the selected reference for OpenTK is:
And in Visual Studio for Mac, ensure the selected reference is:
Issues fixed
Application and library build process
- Developer Community 330758: Projects that had indirect dependencies on version 4.3.0 of the System.Runtime.Loader NuGet package would fail to build with "XA0009: Error while loading assembly ... BadImageFormatException". Xamarin.Android 9.3 allows these projects to build without error. As a caution, the
System.Runtime.Loader.AssemblyLoadContext
class in Xamarin.Android currently only provides empty implementations, so although certain APIs from NuGet packages that depend on the System.Runtime.Loader NuGet package will work already, features that specifically depend onAssemblyLoadContext
will encounterNotImplementedException
errors. - Developer Community 346386: Attempting to cancel a build during the AOT Compilation step would only stop the build after the AOT step completed. In Xamarin.Android 9.3, canceling the build during the AOT step now aborts the step as expected.
- Developer Community 514955: Starting in Visual Studio 2019 for Mac, the References list in the Solution pad and the Edit References window showed error icons and missing entries for most of the base class libraries in Xamarin.Android projects.
- GitHub 1768: The build process did not yet provide warnings to guide projects toward the recommended best practice of keeping
minSdkVersion
less than or equal totargetSdkVersion
andtargetSdkVersion
equal tocompileSdkVersion
. - GitHub PR 2349: The build warnings and errors related to duplicate managed type names and Java type names for custom subclasses of
Java.Lang.Object
did not yet provide all of the available information about the conflicts. - GitHub PR 2529: Under certain conditions builds would sometimes generate a new updated APK but then incorrectly skip over the step of copying it to the final output directory.
- GitHub PR 2678: Updating NuGet packages could lead to AAPT errors and Java compilation errors if the project was not explicitly cleaned after the package update. This scenario now works as expected for an incremental build, with no need to clean the project after the package update.
- GitHub PR 2736: The
<uses-library/>
element in the AndroidManifest.xml file did not automatically add the library for consideration by ProGuard and R8. - GitHub PR 2760: F# Xamarin.Android projects were not yet compatible with the new install paths for F# 4.5.
- GitHub PR 2771: Projects configured to use AAPT2 could encounter
DirectoryNotFoundException
build errors if a referenced library included an empty Android resources directory. - GitHub PR 2781: The new D8 DEX compiler option introduced in Xamarin.Android 9.2 was not yet compatible with the new enhanced fast deployment mode.
- GitHub PR 2821: Updating libraries such as Xamarin.Android.Support.Annotations to new versions that used different embedded .jar files could lead to Java compilation errors if the obj directory was not manually cleaned before the next build.
- GitHub PR 2880: Projects configured to use AAPT could encounter "resource directory ... does not exist" build errors if a referenced library included an empty Android resources directory.
- GitHub PR 2882: The
CompileToDalvik
task could fail with a "no classes!" error when attempting to deploy a project that included a .jar file with no archived .class files in it. - GitHub PR 2883: Projects configured to use AAPT2 could sometimes fail to build with "One or more errors occurred" messages during the
Aapt2Compile
task, depending on the timing of the build. - GitHub PR 2914: Projects configured to use AAPT2 could sometimes fail to build with "Value cannot be null" messages during the
Aapt2Link
task, depending on the timing of the build. - Starting in Xamarin.Android 9.2, the default fast deployment setting was creating additional directories that were not needed, costing roughly an additional 120 milliseconds on each deployment. Those additional directories are only applicable for the new enhanced fast deployment mode, so the directory creation step is now skipped for the old default assemblies-only fast deployment mode.
Application behavior on device and emulator
- GitHub 2501: Custom subclasses of
Android.View.View
in Android XML layout files caused "Error inflating class" exceptions when running on device or emulator for projects configured to use AAPT2. - GitHub 2684: Xamarin.Android apps built with the new R8 code shrinker enabled would hit an exception during startup on devices running Android versions earlier than 8.0 Oreo (API level 26). Depending on how the application was launched, the app could get stuck in an error loop where the first layout would never appear.
- GitHub 2696: The new enhanced fast deployment mode could lead to unexpected exits on a native signal fault under certain conditions.
- GitHub 2931: Applications could exit due to unhandled exceptions similar to "Error inflating class android.support.v7.widget.ActionBarOverlayLayout" in projects configured to use the new R8 code shrinker. The updated R8 version 1.3.52 in Xamarin.Android 9.3 resolves this issue.
Application Mono Framework behavior on device and emulator
This version of Xamarin.Android updates the Mono 5.18 runtime and class libraries from Commit 5ac37ccd to Commit bf4e8d2a, adding 32 new commits and 4 previously backported commits.
Changes relevant to Xamarin.Android:
- Developer Community 522232, Mono GitHub 12307, GitHub 2521: Apps built with both AOT Compilation and Use LLVM Optimizing Compiler enabled would exit unexpectedly during startup when targeting 32-bit architectures due to a "Fatal signal 11 (SIGSEGV)" in
Android.Runtime.AndroidTypeManager.RegisterNativeMembers()
. - Mono GitHub PR 12588: Starting with Xamarin.Android 9.2, the internal Mono runtime functions that are used to log error messages for unexpected assembly load failures had some additional, unnecessary overhead.
- Mono GitHub 12843: The Debugger agent thread could abort unexpectedly on a "Fatal signal 11 (SIGSEGV), code 1" when the soft debugger was instructed to step into or step over code in certain conditions for multithreaded applications.
- Mono GitHub 13452: Some memory operations could in theory abort unexpectedly on a SIGSEGV on x86_64 devices or emulators.
- Mono GitHub PR 13532: Concurrent request completions on an
HttpRequestChannel
could cause an uncatchable "System.ArgumentOutOfRangeException: Index was out of range" error.
Design-time build process
- GitHub PR 2787: The
_BuildAdditionalResourcesCache
MSBuild target was being skipped during design-time builds, preventing the Android designer from showing IntelliSense for some dependencies unless the user performed a full build.
Known issues
- Mono GitHub 14170: When the debugger is attached on arm64-v8a devices, applications that hit an unhandled exception can exit on a "Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)" if the user continues through the unhandled exception in the debugger.
Contributors
A big Thank You! to contributors who made improvements in this release:
- Morten Nielsen: Skip the XA0113 compiler warning for Android library projects. The warning is only strictly relevant to Android application projects, and some library authors might wish to keep using an older
$(TargetFrameworkVersion)
if they have users who are still on older$(TargetFrameworkVersion)
s for apps that aren't published on Google Play. GitHub PR 2754 - vperus: Correct several links in the xamarin-android contributor documentation. GitHub PR 2748
OSS core
The commercial build for this version is based on the bundle from the open-source xamarin-android-d16-1 build #21.