Xamarin.Android 9.2 release notes
- Visual Studio 2019 — Visual Studio Installer
- Visual Studio 2019 for Mac — Visual Studio 2019 for Mac with the Stable updater channel
What's new in Xamarin.Android 9.2
Xamarin.Android 9.2 releases
- April 30, 2019 — Xamarin.Android 18.104.22.168 in Visual Studio 2019 version 16.0.3.
- April 18, 2019 — Xamarin.Android 22.214.171.124 in Visual Studio 2019 for Mac.
- April 2, 2019 — Xamarin.Android 126.96.36.199 in Visual Studio 2019 and Visual Studio 2019 for Mac
Corresponding Visual Studio 2019 release notes
April 18, 2019 — Xamarin.Android 188.8.131.52
This version is included in the Visual Studio 2019 version 16.0.3 release and in the Stable updater channel of Visual Studio 2019 for Mac.
Issues fixed in Xamarin.Android 184.108.40.206
Application Mono Framework behavior on device and emulator
- Developer Community 435502, Developer Community 515603, GitHub 2920: Xamarin.Android apps would crash during debugging when they called certain APIs. Applications affected by this issue would run successfully if launched without the debugger attached, but when launched with the debugger attached, the applications would exit unexpectedly after one of the problematic APIs was called. The debug output would show a "Fatal signal 11 (SIGSEGV)" after the crash.
- Mono GitHub 13610:
Xamarin.Android projects in which users had explicitly set a value for the
$(AndroidAotMode)MSBuild property could hit a problem where methods that returned
Taskobjects or generic types would lead to incorrect return values. This is not expected to be an issue for any current Xamarin.Android projects. The fix is included in this release to keep the Mono commit aligned with Xamarin.iOS.
April 2, 2019 — Xamarin.Android 220.127.116.11
This version is included in the Visual Studio 2019 and Visual Studio 2019 for Mac releases.
Summary of what's new in Xamarin.Android 18.104.22.168
- Build and deployment performance improvements
- App startup performance improvements
- Support for Android's D8 DEX compiler
- Support for Android's R8 code shrinker
- Enhanced fast deployment
- Support for
- Mono Framework version update to 5.18
- Mono.Data.Sqlite SQLite version update
- Deprecation of OpenTK version 0.9.9.3
- Removal of target framework versions below Android 4.4 (API level 19)
- Removal of support for armeabi CPU architecture
- Issues fixed
Build and deployment performance improvements
This release includes several more improvements to build and deployment times compared to Visual Studio 2017 version 15.9. For example, in a test development environment, the incremental build time after modifying one XAML page in the SmartHotel360 sample app has dropped from 8.5 seconds to 7.5 seconds and the corresponding deployment time has dropped from 5 seconds to 4.5 seconds.
- The Build Performance Results page on the project wiki for additional comparisons and updates about the on-going work to continue to improve performance.
- The latest numbers from the continuous integration builds.
- GitHub PR 2088:
_CopyIntermediateAssembliestarget to replace a couple uses of the
CopyIfChangedand avoid calling the
Touchtask. This improved the incremental build time for a test project from roughly 7 seconds to roughly 6.5 seconds.
- GitHub PR 2124:
Add conditions and correct item wildcards for the
_CreateAapt2VersionCachetarget to improve build times in projects configured to use AAPT2.
- GitHub PR 2129:
Split part of the
ConvertResourcesCasestask into a new
ConvertCustomViewtask to avoid repeating work later in the build. This saves roughly half the time spent in the
ConvertResourcesCasestask, which can be several seconds or more for an initial clean build.
- GitHub PR 2148:
AssemblyDefinitioninstances during the
BuildApktask. This improved the overall build time for a test project by about 5%.
- GitHub PR 2162:
StripEmbeddedLibrariestask to be a linker step to save one pass of loading the assemblies for writing and to avoid redundant work on assemblies that the linker would skip. This improved the combined time of stripping and linking for a test project in the Release configuration from 16.1 seconds to 15.4 seconds.
- GitHub PR 2168:
Remove some redundant work the
ResolveAssembliesbuild task was doing when iterating through assembly metadata.
- GitHub PR 2174:
CheckTargetFrameworkstask into the
ResolveAssembliestask to save one pass of reading through assembly metadata.
- GitHub PR 2223:
Optimize the default
$(AllowedReferenceAssemblyFileExtensions)MSBuild properties by removing locations and extension types that are never used for Xamarin.Android projects. This improved the incremental build time by approximately 0.5 seconds for a test project that references 7 other Xamarin.Android projects.
- GitHub PR 2308,
GitHub PR 2320,
GitHub PR 2326:
Correct how several targets handle and update the timestamps of their
Outputs. This prevents some scenarios where incremental builds could get stuck in a state where they would always rebuild the affected targets.
- GitHub PR 2309:
Outputsfrom several targets. This improved the total build time for those targets in a test project by a few dozen milliseconds.
- GitHub PR 2328:
RegexOptions.Compiledoption to a
Regexand change some LINQ expressions to loops in the
ConvertResourcesCasestask. This improved the total time for the task in a test project by a few hundred milliseconds.
- GitHub PR 2348:
ConvertResourcesCasestask to skip a specific set of "well-known" assemblies by name. For example, after this change,
ConvertResourcesCasesnow skips all of the Xamarin.Android.Support, Xamarin.GooglePlayServices, and Xamarin.Firebase assemblies because those assemblies are built by the Xamarin team and never contain resource names that need to be converted. This can save 1 second or more for both initial clean builds and incremental builds after resource changes. The time saved depends on how many of these assemblies are used by the project.
- GitHub PR 2384:
ResolveSdkstask to cache the detected location of the JVM. This improved the incremental build time for a test project by a few hundred milliseconds.
- GitHub PR 2394:
Improve the incremental build behavior of the
_CopyMdbFilestargets by correcting the
Outputsso the timestamps are only updated if the contents have changed and by fixing an issue where duplicate copies of items were being added to
@(FileWrites)on each build.
- GitHub PR 2428:
$(AdbOptions)MSBuild properties in their own file rather than in the build.props file to prevent the deployment process from re-running unnecessary build targets when the deployment target has just been changed from emulator to device or from one device to another.
- GitHub PR 2487:
LinkAssembliestask so that it checks for .mdb files with
File.Exists()before it tries to access them. This avoids some exception handling overhead, reducing the total time for the task by a couple dozen milliseconds.
- GitHub PR 2535:
GenerateResourceDesignertasks to perform generation and comparison in-memory rather than in temporary files, and make a few additional efficiency improvements in the
GenerateJavaStubstask. This improved the initial clean build time for a test project by a few hundred milliseconds.
- GitHub PR 2540:
ResolveLibraryProjectImportstask to avoid allocating an intermediate
byteand to avoid generating intermediate temporary files. This improved the total time for the task by a few dozen milliseconds.
App startup performance improvements
GitHub PR 1886, GitHub PR 2147: Avoid unnecessary string allocations during app startup. This reduced the time for the
GetJavaToManagedType()startup step in a test application from 10 milliseconds to 1 millisecond.
GitHub PR 2008, GitHub PR 2126: Use a faster approach to register managed methods with the Android runtime during app startup. This reduced the method registration time in a test application from 56 milliseconds to 18 milliseconds in the Release configuration and from 169 milliseconds to 33 milliseconds in the Debug configuration.
GitHub PR 2025: Slightly reduce the overhead of setting up managed method overrides and callback methods for types in or subclassed from Java bindings.
GitHub PR 2473: Avoid allocating or evaluating unused arguments in the primitive logging functions. This can reduce application startup time by a couple dozen milliseconds, depending on the target device.
GitHub PR 2500: Skip attempting to load the Java.Interop.Export.dll assembly during app startup because that part of the Java.Interop library is not used by Xamarin.Android. This can reduce application startup time by roughly 100 milliseconds, depending on the target device.
GitHub PR 2515: Optimize several application startup operations:
- Reduce Java class lookup.
- Don't lookup
- Review logging messages.
- Improve package name hash generation.
- Improve environment variable processing.
- Stop preloading all assemblies.
- Avoid using "system properties" to control Mono features.
- Desktop version is now a compile-time build option, not runtime.
xamarin_getifaddrs()on-demand, not at startup.
These optimizations reduced the average startup time for a test application from 0.7 seconds to 0.3 seconds in the Release configuration and from 1.4 seconds to 1.1 seconds in the Debug configuration.
These optimizations are all enabled by default except for the change to stop assembly preloading. Skipping assembly preloading can cause exceptions for C# code that uses
AppDomain.GetAssemblies()and doesn't yet explicitly call
Assembly.Load(). Current versions of certain libraries could be affected, including:
- Dependency injection libraries
- Certain Xamarin.Forms features
- Potentially other mobile frameworks (MVVM, etc.) that leverage
In the future, after Xamarin.Forms and other libraries have been updated for compatibility, Xamarin.Android release will likely change the default behavior to skip preloading the assemblies. If your app is already compatible with skipping the preload step, you can can apply the extra startup time improvement by setting the
$(AndroidEnablePreloadAssemblies)MSBuild property to
falsein your .csproj file:
<PropertyGroup> <AndroidEnablePreloadAssemblies>false</AndroidEnablePreloadAssemblies> </PropertyGroup>
Support for Android's D8 DEX compiler
The March 2018 release of the Android SDK introduced a new DEX compiler
D8 that improves both compile times and app performance compared
to the previous compiler DX. Xamarin.Android 9.2 updates the Xamarin.Android
build tasks to be compatible with D8. Because D8 is not yet widely used by
Xamarin.Android projects, it is not yet enabled by default. To try it with your
project, set the
$(AndroidDexTool) MSBuild property to
d8 in your .csproj
<PropertyGroup> <AndroidDexTool>d8</AndroidDexTool> </PropertyGroup>
For additional details about D8 in the context of Xamarin.Android, including a few comparisons of build speeds and sizes, see the integration specification notes.
Support for Android's R8 code shrinker
Recent versions of the Android SDK also include a preview of a new code
shrinker R8 that aims to produce smaller DEX files more quickly
than ProGuard. Xamarin.Android does not yet enable R8 by default. To try it
with your project, set the
$(AndroidLinkTool) MSBuild property to
r8 in your
<PropertyGroup> <AndroidLinkTool>r8</AndroidLinkTool> </PropertyGroup>
For additional details about R8 in the context of Xamarin.Android, including a few comparisons of build speeds and sizes, see the integration specification notes.
- GitHub 2684: Xamarin.Android apps built with R8 enabled are currently only compatible with devices running Android 8.0 Oreo (API level 26) or higher. On earlier Android versions, apps built with R8 enabled will get stuck in an infinite error loop during app initialization and never show the first layout.
Enhanced fast deployment
Fast deployment has historically provided faster incremental
deployment times by skipping rebuilding or redeploying the Android package (APK)
when there have been no changes to the AndroidManifest.xml file or to any
assets, resources, shared native libraries packaged within the app, or
user-defined classes that inherit from
Xamarin.Android 9.2 enhances fast deployment so that it now supports most of
those previously unsupported scenarios except for changes to the
AndroidManifest.xml file. For example, adding a new Android layout file or a
new user-defined class that inherits from
Java.Lang.Object now no longer
require the APK to be rebuilt or redeployed.
This new enhanced fast deployment mode is not yet enabled by default because it
has a few known issues. But it is already compatible with a number of
scenarios, so if you would like to try it with your project, set the
$(AndroidFastDeploymentType) MSBuild property to
Assemblies:Dexes in your
<PropertyGroup> <AndroidFastDeploymentType>Assemblies:Dexes</AndroidFastDeploymentType> </PropertyGroup>
For any users who might have tried the earlier experimental version of this
feature introduced in Xamarin.Android 7.0, note that at
the moment this new version still has an incompatibility with custom
Android.App.Application subclasses, but it does add new capabilities that
allow fast deployment of both shared native libraries as well as classes that
- Developer Community 435111,
Apps that use custom
Android.App.Applicationsubclasses are not yet supported.
- GitHub 2608: Changes to the AndroidManifest.xml file do not yet properly trigger a rebuild of the APK.
Android 6.0 (API level 23) introduced a new way to handle native shared
libraries that are packaged as part of APKs. Before that API level, the
libraries would always be extracted and placed in the application data
directory, consuming extra space on the file system. API level 23 added a new
<application> element attribute
android:extractNativeLibs to control whether the native libraries are
extracted during installation. If the attribute is set to
false, then Android
6.0 and higher will skip the extraction step and attempt to load the libraries
directly from the APK instead.
Xamarin.Android 9.2 adds compatibility support for this functionality. At the moment, enabling this mode requires a few manual steps:
android:extractNativeLibs="false"attribute to the
<application>element in the Properties\AndroidManifest.xml file
$(AndroidStoreUncompressedFileExtensions)MSBuild property to
.soin your .csproj file:
<PropertyGroup> <AndroidStoreUncompressedFileExtensions>.so</AndroidStoreUncompressedFileExtensions> </PropertyGroup>
Add an android environment file to the project with the following contents:
Mono Framework version update to 5.18
This version of Xamarin.Android updates the Mono runtime and class libraries from Mono 5.14 to Mono 5.18 Commit 5ad371da, Mono 5.18 resolves several issues in the runtime and base class libraries and imports more CoreFX implementations for types in the System.Reflection and System.Math namespaces.
Mono.Data.Sqlite SQLite version update
The version of SQLite used by Mono.Data.Sqlite in Xamarin.Android has been updated from 3.9.2 to 3.26.0, bringing in many improvements and bug fixes.
Deprecation of OpenTK version 0.9.9.3
The assembly for OpenTK version 0.9.9.3 will be removed from Xamarin.Android in an upcoming release. Xamarin.Android has for several years included assemblies for both OpenTK version 0.9.9.3 and OpenTK version 22.214.171.124 to allow a gradual transition to version 126.96.36.199. It is now time to finalize that transition by removing the old version from Xamarin.Android. Any projects that have not yet switched from OpenTK version 0.9.9.3 (OpenTK.dll) should now be updated to remove that old reference and add a reference to OpenTK version 188.8.131.52 (OpenTK-1.0.dll) instead.
In Visual Studio the selected reference for OpenTK should now be:
And in Visual Studio for Mac the selected reference should now be:
Removal of target framework versions below Android 4.4 (API level 19)
As cautioned by the related build warning that was added in the Xamarin.Android
9.1 release (see GitHub PR 2329), Xamarin.Android 9.2 removes
support for the
v4.3 values of the
$(TargetFrameworkVersion) MSBuild property. Projects that have one of these
old target framework versions selected will now need to change it to
$(TargetFrameworkVersion) setting can be found in the
Application section of the project properties in Visual Studio and the
Build > General section of the project properties in Visual Studio for
Projects that have an old target framework selected will see the following build
$(TargetFrameworkVersion) has been updated:
error XA0001: Unsupported or invalid $(TargetFrameworkVersion) value of 'v4.1'. Please update your Project Options.
Note that applications built against a target framework version of Android 4.4 (API level 19) or higher can still be deployed and run successfully on devices that are using Android 4.3 (API level 18) or lower. For more information, see the section about runtime checks in the guide on Android API levels.
Removal of support for armeabi CPU architecture
Due to the removal of armeabi support in Android NDK r17,
Xamarin.Android 9.2 no longer supports the armeabi architecture. Projects that
have this old ABI selected in the
$(AndroidSupportedAbis) MSBuild property
will now need to remove it. The newer armeabi-v7a ABI should be used instead.
$(AndroidSupportedAbis) setting can be found in the Advanced section
of the Android Options project properties in Visual Studio and the
Advanced tab of the Android Build project properties in Visual Studio
for Mac. The armeabi option is no longer listed in that properties page, so one
way to ensure that the old setting has been removed is to un-check and re-check
one of the other options and then save the project properties.
Projects that have the old ABI selected will see the following build error until
$(AndroidSupportedAbis) has been updated:
error XA0115: Invalid value 'armeabi' in $(AndroidSupportedAbis). This ABI is no longer supported. Please update your project properties.
Application and library build process
- GitHub 1879: Using version 4.5.0 or higher of the System.Threading.Tasks.Extensions NuGet package could lead to compile errors about missing types from that library. Xamarin.Android now includes a System.Threading.Tasks.Extensions.dll facade assembly that provides the appropriate type forwarders for those types.
- GitHub 2029,
Build errors could potentially occur in projects configured to use
AAPT2 if they also referenced NuGet packages that provided custom
values for the
- GitHub PR 2108: The built-in list of types, methods, and fields to preserve when linking mscorlib.dll included some redundant and outdated items.
- GitHub PR 2117: A few build tasks were generating warnings or errors that did not include numbered codes.
- GitHub 2141: App deployment could fail due to an "INSTALL_FAILED_CONFLICTING_PROVIDER" error when using certain recent Android libraries such as Crashlytics that contain their own AndroidManifest.xml file.
- GitHub 2143:
Desugarbuild task did not pass the
desugar_deploy.jar, resulting in build errors about missing types when desugaring certain .jar files.
- GitHub PR 2150:
CopyAndConvertResourcesbuild tasks contained redundant try/catch blocks.
- GitHub PR 2187:
CompileToDalvikbuild task was passing individual input item names on the command line to
dx.jarinstead of combining the names into a file and using the
--input-listoption. This could potentially cause issues with command line length limitations in cases where many inputs were given.
- GitHub 2200:
Builds could hit a new error in Xamarin.Android 9.1 instead of automatically
using the default detected location as expected in projects that had a
nonexistent custom path explicitly set in the
- GitHub PR 2251:
ResolveLibraryProjectImportstask encountered corrupt data, it would fail with an error similar to "error MSB4018: The "ResolveLibraryProjectImports" task failed unexpectedly ... Xamarin.Tools.Zip.ZipIOException" rather than a more instructive error.
- GitHub 2356:
ConvertResourcesCasestask was running many times during builds of projects configured to use AAPT2.
- GitHub 2360,
linterrors could appear because the
_LintCheckstarget was passing the whole
$(IntermediateOutputPath)MSBuild property to
lint. This caused
lintto check files from all referenced pre-built libraries in addition to the files from the current build. The
_LintCheckstarget now only passes the files from the current build.
- GitHub PR 2483: Build errors about missing resources could occur in application projects configured to use AAPT2 if any of the layout files used uppercase letters in a reference to a resource from a library project.
- GitHub 2534:
Using the Microsoft.EntityFrameworkCore version 2.2.0 NuGet package led to a
build error during the
_ResolveAssembliestarget with the message "error XA2002: Can not resolve reference:
System.Buffers, referenced by
System.Memory." Xamarin.Android now includes built-in System.Memory.dll and System.Buffers facade assemblies, and the
_ResolveAssembliestarget completes successfully.
- GitHub PR 2647:
Aapt2Linktask left behind some temporary files after builds of projects configured to use AAPT2.
- GitHub 2692: The build tasks and targets did not yet provide a warning for projects that have the minimum Android version set lower than Android 2.3 (API level 9). This warning is needed because the native parts of Xamarin.Android are built against Android NDK r14, so Xamarin.Android apps might not work correctly on devices running Android versions older than Android 2.3 (API level 9).
- GitHub 2708:
Projects that used Bundle assemblies into native code or AOT
Compilation (Experimental) would fail to build with different error
messages if the Android NDK could not be found. Neither message mentioned
how to resolve the problem. Both scenarios now produce the same message
that includes steps to resolve the error by installing the NDK or setting
Application behavior on device and emulator
- GitHub 1615:
AndroidClientHandlerdid not provide TLS 1.1 or TLS 1.2 support on Android versions 4.1 to 4.4.
- GitHub 1673:
Attempting to run large APKs on device or emulator could fail on startup if
the size of the APK exceeded the largest available contiguous block of free
memory. In Xamarin.Android 9.2, the app startup process now calls
mmap()separately for individual files from the APK instead of once for the whole APK. This allows larger APKs to run successfully.
- GitHub 2081:
Applications with the
android:directBootAwareattribute set to
truefor the whole application or for an activity, content provider, broadcast receiver, or service would quit unexpectedly when attempting to launch on a freshly rebooted, locked device running Android 7.0 Nougat or higher.
- GitHub 2123:
AndroidClientHandlerdid not yet support HTTP proxy server configuration.
- GitHub PR 2192: Apps could fail to run on Android 6.0 (API level 23) devices if built with Bundle assemblies into native code enabled.
- GitHub 2193: Building, adding a new view to a .axml layout file, and then deploying an application could lead to an "Android.Views.InflateException... Attempt to invoke virtual method on a null object reference" error when running the app because the layout file updates were not deployed as expected.
- GitHub 2202:
[IntentFilter]attribute was being ignored on classes decorated with a
- GitHub PR 2480:
Android assets located within subdirectories were missing from APKs in
projects configured to use AAPT2 when building on Windows to due an
upstream issue in
aapt2. The Xamarin.Android build tasks now fix up the output from
aapt2to work around this issue.
Android API bindings
- Developer Community 399276:
Android.Hardware.Biometrics.BiometricErrorCodewas incorrectly bound as
BiometricErrorCode, resulting in a missing binding for
Android.Hardware.Biometrics.BiometricPrompt.AuthenticationCallback.OnAuthenticationError(). Both types are now bound correctly.
- GitHub 1891:
[Android.App.Activity]attribute did not include properties for all of the XML attributes for which Android Studio offers autocompletion in AndroidManifest.xml
<activity/>elements. The list of properties has now been updated to include the missing items.
Design-time build process
- Developer Community 335298: Binding projects that used .aar files could cause IntelliSense errors similar to "error CS0234: The type or namespace name ... does not exist in the namespace ... (are you missing an assembly reference?)" to appear in the consuming application projects.
- GitHub 2410:
ValidateJavaVersiontask was being run during design-time builds when it did not need to run, decreasing the responsiveness of working interactively in Visual Studio.
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:
- Tim Wanders: Tidy up the Makefile used to build Xamarin.Android from source on macOS and Linux. GitHub PR 1870.
- Tim Wanders: Improve compatibility for building Xamarin.Android from source on Arch Linux. GitHub PR 1871.
- Nathan Westfall:
Fix GitHub 1891 by
adding some properties to
[Android.App.Activity]so that the corresponding XML attributes of
<activity/>elements can now be set using
[Android.App.Activity]. GitHub PR 2109
- eric liu:
Fix GitHub 2143 by
Desugarbuild task to pass the
desugar_deploy.jar. GitHub PR 2158
- Yusuke Yamada: Correct mismatched XML elements in the comments of the EnumFields.xml files for several of the tests in tests/CodeGen-Binding and tests/ResolveImports. GitHub PR 2311
Fix GitHub 1673 by
changing the app startup process to call
mmap()separately for individual files from the APK instead of once for the whole APK. GitHub PR 2570
Xamarin.Android 9.2 is based on the open-source Xamarin.Android repositories: