Releases: dotnet/android
Xamarin.Android 10.1.0.1
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
- SHA-256 by default for APK signing and digest algorithms
- IDE support for Android App Bundle publishing format
- App startup performance
- Build and deployment performance
- XA0119 warning for non-ideal Debug build configurations
- XA0121 deprecation warning for old Xamarin.Android.Support library versions
- R8 version update to 1.5.68
- bundletool version update to 0.10.2
- aprofutil analysis tool
- Issues fixed
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
][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</AndroidApkSigningAl...
Xamarin.Android 10.0.99.100
Xamarin.Android 10.0.99.100 was released as part of Visual Studio 2019 version 16.4 Preview 1.
Corresponding Visual Studio 2019 Preview release notes
What's new
- Build and deployment performance
- Mono Framework version update to 6.6
- Binding project improvements with C# 8.0 for Java interface members
- Environment variables and files for package signing passwords
- Mono.Data.Sqlite SQLite version update
- Issues fixed
- Known issues
Build and deployment performance
- GitHub PR 3296: Remove an unneeded LINQ
Distinct()
call from theResolveLibraryProjectImports
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
andOutputs
for theSetupDependenciesForDesigner
and_ResolveLibraryProjectImports
targets, and add an option for theJavac
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 fromJava.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.
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 29b1ac19, adding about 700 new commits.
Binding project improvements with C# 8.0 for Java interface members
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.
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.
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.0.99.100
Application and library build process
- 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 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 f...
Xamarin.Android 10.0.0.43
Update September 23, 2019: Xamarin.Android 10.0.0.43 was released as part of Visual Studio 2019 version 16.3 and to the Stable updater channel of Visual 2019 Studio for Mac version 8.3.
See the Xamarin.Android 10.0 release notes for the full list of changes compared to Xamarin.Android 9.4.
Earlier information from the Xamarin.Android 10.0.0.43 pre-release
September 16, 2019: Xamarin.Android 10.0.0.43 was released as part of Visual Studio 2019 version 16.3 Preview 4 and to the Preview updater channel of Visual Studio 2019 for Mac version 8.3 Preview.
Issues fixed
Application and library build process
- GitHub 3564: "error XA3001: Could not link native shared library: libxamarin-app.so" prevented projects from building successfully on the macOS Catalina preview.
Application Mono Framework behavior on device and emulator
This version of Xamarin.Android updates the Mono 6.4 runtime and class libraries from Commit 6434153d to Commit 7af64d1e, adding 15 new commits.
Fixes included for issues reported with Xamarin.Android applications:
- Developer Community 697733: Starting in the Xamarin.Android 10.0 Preview, "System.ArgumentException: Only 'http' and 'https' schemes are allowed." prevented making
HttpClient
requests using relative URIs that started with/
. - GitHub 3397: Starting in Xamarin.Android 9.4, "NotImplementedException" prevented using
Stream.CopyToAsync()
to copy into aGzipStream
. - GitHub 3580: The Hebrew locale was incorrectly assigned to use the Gregorian calendar, and leap months in the Hebrew calendar did not have the expected names.
- Mono GitHub 16369: Starting in Xamarin.Android 9.4, apps that contained large managed assemblies could fail to run on Android 6.0 Marshmallow (API level 23) or higher devices and emulators when built with AOT Compilation enabled.
OSS core
The corresponding open-source build without commercial features is xamarin-android-d16-3 build #54.
Xamarin.Android 10.0.0.40
Xamarin.Android 10.0.0.40 was released as part of Visual Studio 2019 version 16.3 Preview 3 and to the Preview updater channel of Visual Studio 2019 for Mac version 8.3 Preview.
Corresponding Visual Studio 2019 Preview release notes
What's new
Enable Startup Tracing no longer requires the Android NDK
The new Enable Startup Tracing option introduced in Visual Studio Enterprise 2019 version 16.2 no longer requires an Android NDK installation. Xamarin.Android now includes its own versions of the as
, ld
, and strip
utilities that it uses to compile the startup methods to unmanaged code when Enable Startup Tracing is enabled. Additionally, the Enable Startup Tracing option is now available in the project property pages for all editions of Visual Studio.
To try this feature, configure the project to use Enable Startup Tracing in the Android Options section of the Visual Studio project property pages for the Release configuration. This sets the $(AndroidEnableProfiledAot)
MSBuild property to true
in your .csproj file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>
For Visual Studio Enterprise users, note that this change also means the AOT Compilation option no longer requires the Android NDK. In contrast, the Use LLVM Optimizing Compiler option still does require the Android NDK.
Issues fixed in Xamarin.Android 10.0.0.40
Application and library build process
- GitHub 2584: Starting in Xamarin.Android 9.2, "Error processing method: 'System.Void BatchStepSensor.BatchStepSensorFragment::OnSaveInstanceState(Android.OS.Bundle)'" could occur if the Compile using Android version: (Target Framework) setting had been changed between two successive builds.
- GitHub 3083: Projects that had both Use incremental packaging system (aapt2) and Generate one package (.apk) per selected ABI enabled and that had Compile using Android version: (Target Framework) set to Android 7.1 or lower would fail to build due to "The "BuildApk" task failed unexpectedly... Could not find file 'obj\Release\71\android\bin\packaged_resources-armeabi-v7a."
- GitHub 3276: "The "GenerateJavaStubs" task failed unexpectedly. System.ArgumentNullException ... at Mono.Cecil.AssemblyNameReference.Parse(String fullName)" prevented projects from building successfully if they tried to use an
ApplicationAttribute.NetworkSecurityConfig
property on a customAndroid.App.Application
subclass. - GitHub 3322: Starting in the Xamarin.Android 9.5 preview, errors similar to "error MSB4018: The "LinkAssemblies" task failed unexpectedly. ... System.IO.FileNotFoundException: Could not load assembly" prevented successful completion of the build when attempting to use the old Run Code Analysis static style of code analysis.
- GitHub PR 3327: Errors similar to "APT0000: Invalid file name: It must contain only [^a-zA-Z0-9_.-]+" could prevent projects from building successfully if they used
LogicalName
metadata on Android resources and had Use incremental packaging system (aapt2) enabled. - GitHub PR 3430: The Xamarin.Android build process added a trailing
\
to certain properties such as$(AndroidNdkDirectory)
and$(AndroidSdkDirectory)
even when they were set to the empty string. This was a compatibility issue for upcoming IDE features. - GitHub PR 3445: The Java compilation build step did not yet have a dedicated error code for failures when running
javac
. - GitHub 3454: In Xamarin.Android 9.4.1.0 and Xamarin.Android 10.0.0.4, the fix for GitHub 3263 unintentionally preserved additional types during managed linking, resulting in APK files that were about 7 megabytes larger than expected, depending on which libraries the app used.
- GitHub PR 3463: Errors similar to "error: class Class1 is public, should be declared in a file named Class1.java" prevented incremental builds from completing successfully if a custom subclass of
Java.Lang.Object
was changed by capitalizing or lowercasing some letters of the class name between builds. - GitHub 3494: Errors similar to "error APT0000: resource ... not found." could prevent builds from completing successfully until the project was cleaned if a build was started shortly after a layout file was changed.
Application Mono Framework behavior on device and emulator
This version of Xamarin.Android updates the Mono 6.4 runtime and class libraries from Commit 17ac7dcf to Commit 6434153d, adding 32 new commits.
Fixes included for issues reported with Xamarin.Android applications:
- Developer Community 668413, GitHub 3426: Starting in Xamarin.Android 9.4, errors similar to "System.UnauthorizedAccessException: Access to the path is denied. ---> System.IO.IOException: Operation not permitted" could prevent copying files successfully or reading from one file stream while writing to another.
- GitHub 3388: Starting in Xamarin.Android 9.4,
DllImport
could fail for certain unmanaged libraries, resulting inDllNotFoundException
exceptions.
Application behavior on device and emulator
- GitHub 3395: In apps built using AAPT2, managed Resource.Styleable IDs were incorrect when a
<declare-styleable>
contained more than ten<attr>
elements. This could result in absent or incorrect resource content in running apps.
Android API bindings
- GitHub 3313: The Xamarin.Android API bindings for
AudioRecord
did not yet inherit fromAudioRouting
, so theAudioRouting.OnRoutingChangedListener
API introduced in Android 7.0 Nougat (API level 24) was not yet available viaAudioRecord
. Starting with the Xamarin.Android bindings for Android 10.0 (API level 29), theAudioRouting.OnRoutingChangedListener
API is now available viaAudioRecord
.
Xamarin.Android SDK installation
- GitHub 3457: Starting in Xamarin.Android 9.4, the Xamarin.Android SDK .pkg installer package for macOS changed how it created symlinks in the /Library/Frameworks/Xamarin.Android.framework/ install location. This broke a special usage scenario where some users might have occasionally installed two versions of the Xamarin.Android SDK into the Xamarin.Android.framework/ directory and switched between the versions by changing the Versions/Custom symlink. That special usage now behaves as before.
OSS core
The corresponding open-source build without commercial features is xamarin-android-d16-3 build #51.
Both the commercial build and the open-source build use the Mono and libzip artifacts from the bundle*.7z archive generated by the earlier open-source build: xamarin-android-d16-3 build #49.
Xamarin.Android 9.4.1.1
Xamarin.Android 9.4.1.1 was released as part of Visual Studio 2019 version 16.2.4.
Issues fixed
- GitHub 3454: Starting in Xamarin.Android 9.4.1.0, the fix for GitHub 3263 unintentionally preserved additional types during managed linking, resulting in APK files that were about 7 megabytes larger than expected, depending on which libraries the app used.
Xamarin.Android 10.0.0.4
Xamarin.Android 10.0.0.4 was released as part of Visual Studio 2019 version 16.3 Preview 2 and to the Preview updater channel of Visual Studio 2019 for Mac.
Corresponding Visual Studio 2019 Preview release notes
What's new
- Bindings for Android Q Beta 4 with final APIs
- Improved support for Android App Bundle publishing format
- Mono Framework version update to 6.4
- Issues fixed
- Known issues
Bindings for Android Q Beta 4 with final APIs
Xamarin.Android 10.0 updates the bindings for Android Q to match the Android Q Beta 4 release from Google, which includes the final APIs for Android Q. See the Android Q Beta documentation for additional information about the behavior and API changes in this new Android version. To use the bindings for the new APIs in a Xamarin.Android project, set Compile using Android version: (Target Framework) to Android 10.0 (Q) under the Application tab of the Visual Studio project property pages.
Improved support for Android App Bundle publishing format
The previous limitation with the Install location when using the Android App Bundle Bundle publishing format is now resolved. Projects that have the $(AndroidPackageFormat)
MSBuild property to aab
that are built on the command line using the SignAndroidPackage
MSBuild target now produce .aab packages compatible with any Install location. This resolves the following issue:
- GitHub 3298: "JNI DETECTED ERROR IN APPLICATION: mid == null" or "CallStaticIntMethodV received NULL jclass" "... in call to CallStaticIntMethodV ... from void mono.android.Runtime.init" prevented apps packaged using the Android App Bundle publishing format and an Install location other than Internal Only from running successfully when installed via Google Play on devices running Android versions between 6.0 Marshmallow (API level 23) and 8.1 Oreo (API level 27).
The version of the bundletool
executable included in Xamarin.Android has also been updated from 0.8.0 to 0.10.0, bringing in several improvements and bug fixes.
Mono Framework version update to 6.4
This version of Xamarin.Android updates the Mono runtime and class libraries from Mono 6.0 to Mono 6.4 Commit 17ac7dcf, adding about 1,500 new commits.
Issues fixed in Xamarin.Android 10.0.0.4
Application behavior on device and emulator
- GitHub 3263: Errors similar to "System.TypeLoadException: Could not load type 'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android" would cause app execution to abort during calls to certain C# bindings for Android methods in apps built with the manager linker enabled.
- GitHub 3314: "Java.Lang.Exception: android.content.res.Resources$NotFoundException: File res/drawable/abc_vector_test.xml from drawable resource ID #0x7f080058" error would abort app execution on Android 4.4 KitKat (API level 19) or lower for apps built with AAPT2 that uses Android Support Libraries.
Application and library build process
- GitHub 3237: In projects configured to use AAPT2, errors similar to "error CS0117: 'Resource' does not contain a definition for 'Layout'" could sometimes abort the build when attempting to build solutions with parallel builds enabled.
- GitHub PR 3243: Warnings similar to "warning XA0106: Skipping AndroidApp.Resource.Drawable.avd_hide_password_1. Please check that your Nuget Package versions are compatible." appeared during builds when libraries referenced Android resources in certain ways. These items are now logged as informational messages instead of warnings.
- GitHub 3336: In projects configured to use AAPT2, invalid Android resource elements added after an initial successful design-time build did not produce errors during subsequent incremental builds.
- GitHub 3343: Errors similar to "error: cannot access ListenableFuture ... class file for com.google.common.util.concurrent.ListenableFuture not found" could cause the build to fail during the
_CompileJava
target when using certain libraries like Xamarin.Google.Guava.ListenableFuture that included an embedded .jar file and no public managed types. - GitHub PR 3379: Starting in Xamarin.Android 9.4.0.52, "The "FilterAssemblies" task was not given a value for the required parameter "DesignTimeBuild"." error prevented projects from building successfully when they uses certain additional MSBuild targets, such as the targets from the NuGet.Build.Packaging NuGet package.
Xamarin.Android SDK installation
- GitHub PR 3350: "Package contains system volume install location content" error would prevent successful installation of the Xamarin.Android SDK on the macOS Catalina preview.
Known issues in Xamarin.Android 10.0.0.4
- GitHub 3454: The fix for GitHub 3263 unintentionally preserves additional types during managed linking, resulting in APK files that are about 7 megabytes larger than expected, depending on which libraries the app uses.
OSS core
The corresponding open-source build without commercial features is xamarin-android-d16-3 build #27.
Both the commercial build and the open-source build use the Mono and libzip artifacts from the bundle*.7z archive generated by the previous open-source build: xamarin-android-d16-3 build #26.
Xamarin.Android 9.4.1.0
August 5, 2019 — Xamarin.Android 9.4.1.0 was released to the Stable updater channel of Visual Studio for Mac.
August 6, 2019 — Xamarin.Android 9.4.1.0 is now also available as part of Visual Studio 2019 version 16.2.1.
Issues fixed
Application behavior on device and emulator
- GitHub 3263: Errors similar to "System.TypeLoadException: Could not load type 'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android" would cause app execution to abort during calls to certain C# bindings for Android methods in apps built with the manager linker enabled.
Application and library build process
- GitHub 3343: Errors similar to "error: cannot access ListenableFuture ... class file for com.google.common.util.concurrent.ListenableFuture not found" could cause the build to fail during the
_CompileJava
target when using certain libraries like Xamarin.Google.Guava.ListenableFuture that included an embedded .jar file and no public managed types.
Xamarin.Android SDK installation
- GitHub PR 3350: "Package contains system volume install location content" error would prevent successful installation of the Xamarin.Android SDK on the macOS Catalina preview.
OSS core
The commercial build for this version is based on the bundle from the open-source xamarin-android-d16-2 build #51.
Mono version for continuous build environments
For users installing Xamarin.Android on macOS continuous build environments, the corresponding version of the Mono Framework MDK to use is Mono Framework MDK 6.0.0.334.
Xamarin.Android 9.4.0.51
Update July 24, 2019: Xamarin.Android 9.4.0.51 was released as part of Visual Studio 2019 version 16.2 and to the Stable updater channel of Visual Studio for Mac.
See the Xamarin.Android 9.4 release notes for the full list of changes compared to Xamarin.Android 9.3.
Earlier information from the Xamarin.Android 9.4.0.51 pre-release
July 16, 2019: Xamarin.Android 9.4.0.51 was released as part of Visual Studio 2019 version 16.2 Preview 4.
Update July 17, 2019: Xamarin.Android 9.4.0.51 is now also available in the Preview updater channel of Visual Studio 2019 for Mac.
Corresponding Visual Studio 2019 Preview release notes
What's new in Xamarin.Android 9.4.0.51 compared to Xamarin.Android 9.4.0.34
AAPT2 disabled by default except in new projects
Because AAPT2 enforces stricter rules on resource files than the previous AAPT, some projects that built successfully with Xamarin.Android 9.3 could encounter build errors from AAPT2 after upgrading to one of the previous Xamarin.Android 9.4 previews. To allow a more gradual transition to AAPT2, the behavior of Xamarin.Android 9.4 has now been changed back to leave AAPT as the default for existing projects. Instead, now only the new project templates are set to use AAPT2 by default. Authors of new projects are encouraged to follow the stricter AAPT2 rules when possible. Authors of existing projects are encouraged to migrate to AAPT2 at their convenience.
To enable AAPT2 for a particular project, enable the Use incremental packaging system (aapt2) setting in the Visual Studio project property pages, or set the $(AndroidUseAapt2)
MSBuild property to true
by hand in your .csproj file:
<PropertyGroup>
<AndroidUseAapt2>true</AndroidUseAapt2>
</PropertyGroup>
Issues fixed in Xamarin.Android 9.4.0.51
Application Mono Framework behavior on device and emulator and AOT compilation
This version of Xamarin.Android updates the Mono 6.0 runtime and class libraries from Commit c6edaa62 to Commit e6f5369c, adding 25 new commits.
Changes relevant to Xamarin.Android:
- GitHub 3168: Xamarin.Android projects configured to use the new
$(AndroidEnableProfiledAot)
option would fail to build on Windows with "Assertion at ... /mono/mini/aot-compiler.c:11933, condition `res == 1' not met". - Mono GitHub 9664:
DateTime
values were switching out of daylight savings time at incorrect hours for certain time zones. - Mono GitHub 12577: Setting
HttpClient.Timeout
to a value greater than the default 100 seconds would not increase the timeout beyond 100 seconds. - Mono GitHub 14809: Starting in Xamarin.Android 9.4.0.17, apps using ref structs in combination with AppDomains would trigger a "System.BadImageFormatException : Cannot box IsByRefLike type 'System.ReadOnlySpan`1'" error.
- Mono GitHub 14871: Starting in Xamarin.Android 9.4.0.17, apps that used the new
Unsafe.Unbox()
method either directly or indirectly via library like System.Text.Json could hit "System.MissingMethodException: Method not found: !!0& System.Runtime.CompilerServices.Unsafe.Unbox<!0>(object)".
Application behavior on device and emulator
- GitHub 3123: Apps built with Use incremental packaging system (aapt2) enabled could hit an error similar to "Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred" after an incremental build where a custom view defined in a library project had been updated.
- GitHub 3250: Starting in Xamarin.Android 9.4.0.17, apps that used C# keywords as Android resource names would encounter errors similar to "Android.Content.Res.Resources+NotFoundException: String resource ID #0x7f0a0028" when trying to access the resources via C#.
Application and library build process
- Developer Community 396678: Bindings library projects could fail to build because they failed to generate corresponding C# constructors for certain Java constructors.
- GitHub PR 3196: In certain build scenarios for projects that used AAR files, some of the Xamarin.Android MSBuild targets including
_ConvertLibraryResourcesCases
,_UpdateAndroidResgen
, and_CreateBaseApk
would always run. - GitHub PR 3217: Starting in Xamarin.Android 9.4.0.17, projects that used
,
or%3b
as delimiters between values in the$(AndroidSupportedAbis)
MSBuild property would fail to build. Those delimiters now work as expected again. - GitHub 3250: Starting in Xamarin.Android 9.4.0.17, Xamarin.Android projects using Xamarin.Forms showed a new "warning XA0106: Skipping MobileAppMasterDetail.Droid.Resource.Id.fixed" message during builds.
- GitHub 3273: Starting in Xamarin.Android 9.4.0.17, the build time improvement from GitHub PR 2348 that allowed the
ConvertResourcesCases
build task to skip "well-known" assemblies was unintentionally disabled. It is now re-enabled. - GitHub xamarin-android-tools PR 72: In some environments, antivirus software could block access to the registry, preventing the Xamarin.Android build process from locating the default JDK installation as expected.
Xamarin.Android SDK installation
- GitHub 3197: Starting in Xamarin.Android 9.4.0.17, the XML documentation files for the Mono and Xamarin.Android class libraries were missing from the Xamarin.Android SDK installer packages, so IntelliSense tooltips for types from those libraries did not include the expected documentation comments.
OSS core
The commercial build for this version is based on the bundle from the open-source xamarin-android-d16-2 build #47.
Xamarin.Android 9.5.0.27
Xamarin.Android 9.5.0.27 was released as part of Visual Studio 2019 version 16.3 Preview 1 and to the Preview updater channel of Visual Studio 2019 for Mac.
Corresponding Visual Studio 2019 Preview release notes
What's new
- Build and deployment performance
- Preview bindings for Android Q Beta 3
- AAPT2 enabled by default for all projects
- R8 version update to 1.4.93
- Issues fixed
- Known issues
Build and deployment performance
- GitHub PR 3068: Change the two build tasks that were using
%(HintPath)
to useItemSpec
instead. With the way MSBuild currently works,%(HintPath)
can sometimes contain incorrect leftover metadata from unrelated items, whereasItemSpec
is always correct. Also change some LINQ expressions to loops. This reduced the time forGenerateResourceDesigner
from about 200 milliseconds to about 150 milliseconds in a clean build of a test project.
Preview bindings for Android Q Beta 3
GitHub PR 3208: Xamarin.Android 9.5 updates the preview bindings for Android Q Beta to match the Android Q Beta 3 release from Google. See the Android Q Beta documentation for additional information about the behavior and API changes in this new Android version. To try the bindings for the new APIs in a Xamarin.Android project, set Compile using Android version: (Target Framework) to Android 9.0.99 (Q) under the Application tab of the Visual Studio project property pages.
AAPT2 enabled by default for all projects
The previous release enabled AAPT2 by default for new projects. This Xamarin.Android 9.5 preview now enables AAPT2 by default for existing projects as well. Note that AAPT2 will in some cases enforce stricter rules on resource files than the previous AAPT, so some adjustments might be needed if you see new error messages that come from AAPT2 itself rather than from the Xamarin.Android build tasks.
To switch back from AAPT2 to AAPT for a particular project, check and then re-uncheck the Use incremental packaging system (aapt2) setting in the Visual Studio project property pages, or set the $(AndroidUseAapt2)
MSBuild property to false
by hand in your .csproj file:
<PropertyGroup>
<AndroidUseAapt2>false</AndroidUseAapt2>
</PropertyGroup>
Known issues
-
GitHub 3083: Projects that have both Use incremental packaging system (aapt2) and Generate one package (.apk) per selected ABI enabled and that have Compile using Android version: (Target Framework) set to Android 7.1 or lower will fail to build due to "The "BuildApk" task failed unexpectedly... Could not find file 'obj\Release\71\android\bin\packaged_resources-armeabi-v7a".
-
GitHub 3314: "Java.Lang.Exception: android.content.res.Resources$NotFoundException: File res/drawable/abc_vector_test.xml from drawable resource ID #0x7f080058" will abort app execution on Android 4.4 KitKat (API level 19) or lower for apps built with AAPT2 that use Android Support Libraries.
Workaround:
Add the
--no-version-vectors
option to the$(AndroidAapt2LinkExtraArgs)
MSBuild property in your .csproj file:<PropertyGroup> <AndroidAapt2LinkExtraArgs>--no-version-vectors</AndroidAapt2LinkExtraArgs> </PropertyGroup>
Then clean and rebuild the project.
-
GitHub 3237: Errors similar to "error CS0117: 'Resource' does not contain a definition for 'Layout'" can sometimes abort the build when attempting to build solutions with parallel builds enabled. Parallel builds are enabled by default in Visual Studio. The setting can be found in Tools > Options > Build and Run > maximum number of parallel project builds.
-
GitHub 3336: In projects configured to use AAPT2, invalid Android resource elements added after an initial successful design-time build do not produce errors during subsequent incremental builds.
-
GitHub 3344: In app projects configured to use AAPT2, builds show incorrect file paths for AAPT2 errors caused by existing library projects built with AAPT that have Android resource elements that are now invalid with AAPT2.
R8 version update to 1.4.93
GitHub PR 3121: The version of the R8 code shrinker included in Xamarin.Android has been updated from 1.3.52 to 1.4.93.
Important change
Existing Xamarin.Android projects that have the Code shrinker set to r8
and that have the Minimum Android version set to at least Android 5.0 Lollipop (API level 21) will now ignore any custom class lists provided via the MultiDexMainDexList
build action. The build will output a new warning in this case:
warning XA4306: R8 does not support `MultiDexMainDexList` files when android:minSdkVersion >= 21
This change was introduced to improve compatibility with R8 version 1.4.93, which now only allows customizing the list of classes in the primary DEX file for apps with minimum Android versions lower than API level 21. For apps with higher minimum Android versions, R8 determines the list of classes automatically.
Known issues
- GitHub 3370: In the current preview version, "warning XA4306: R8 does not support `MultiDexMainDexList` files" is shown for builds of any project that is configured to use Enable Multi-Dex, even if no
@(MultiDexMainDexList)
items are set. This will be corrected in a future update.
Issues fixed
Application and library build process
- GitHub PR 2967: The "error XA0115: invalid value 'armeabi'" error message did not suggest how to remove the invalid value in cases where the value did not appear in the Visual Studio property pages.
- GitHub PR 3115: One of the steps in the
BuildApk
build task did not yet log a diagnostic MSBuild message to record the outcome of the step. - GitHub Java.Interop PR 425:
JniFieldInfo.ToString()
andJniMethodInfo.ToString()
threwNotSupportedException
. These methods now return strings as expected. - "warning XA5300: Unable to determing Xamarin.Android version" could appear during one build and then disappear on the next build because the `ResolveXamarinAndroidTools` build task was not always running before the `GetPrimaryCpuAbi` task.
- Some of the steps in the `DetectIfAppWasUninstalled` and `GetPrimaryCpuAbi` build tasks did not yet log diagnostic MSBuild messages to record their outcomes.
Application behavior on device and emulator
- GitHub 3058: Starting in Xamarin.Android 9.2,
HttpClient
no longer respected the system-wide proxy settings when configured to use the defaultAndroidClientHandler
. It would only use a proxy if the app explicitly configured one on theHttpClient
instance.
Known issues in Xamarin.Android 9.5.0.27
-
GitHub 3263: Errors similar to "System.TypeLoadException: Could not load type 'Android.Text.ITextWatcherInvoker' from assembly 'Mono.Android" cause app execution to abort during calls to certain C# bindings for Android methods in apps built with the manager linker enabled.
Workaround:
Use a [custom linker configuration][linker-configuration] to preserve the missing types. To do that, add a new linker.xml file to the project, set the Build Action to LinkDescription, and add the XML lines to preserve the missing types. For example, for the
ITextWatcherInvoker
error, add the following lines to the file:<linker> <assembly fullname="Mono.Android"> <type fullname="Android.Text.ITextWatcherInvoker" preserve="all" /> </assembly> </linker>
-
GitHub 3322: Errors similar to "error MSB4018: The "LinkAssemblies" task failed unexpectedly. ... System.IO.FileNotFoundException: Could not load assembly" prevent successful completion of the build when attempting to use the old Run Code Analysis static style of code analysis that ru...
Xamarin.Android 9.3.0.23
Xamarin.Android 9.3.0.23 was released to the Stable updater channel of Visual Studio for Mac.
Update June 25, 2019: Xamarin.Android 9.3.0.23 is now also available as part of Visual Studio 2019 version 16.1.4.
Issues fixed
Application Mono Framework behavior on device and emulator
This version of Xamarin.Android updates the Mono 5.18 runtime and class libraries from Commit 3cb36842 to Commit 3a07bd42, adding 9 new commits.
Changes relevant to Xamarin.Android:
- GitHub 3112, Mono GitHub 14170: "Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)" native fault during C# exception handling in 64-bit arm64-v8a applications.
- Mono GitHub PR 14346: "error XA2006: Could not resolve reference to 'System.Buffers.StandardFormat' (defined in assembly 'Microsoft.Extensions.Configuration.Json ..." when attempting to build Xamarin.Android projects in the Release configuration, for projects that used certain NuGet packages, such as the Microsoft.Extensions.Http.Polly version 3.0.0 preview. Xamarin.Android 9.3.0.23 now includes this type, so the Android Options > Linking setting that is used by default in the Release configuration will now be able to resolve the reference successfully during the build.
- Mono GitHub PR 14392: In certain debugging scenarios, the debugger could get stuck due when trying to suspend the running process.
OSS core
The commercial build for this version is based on the bundle from the open-source xamarin-android-d16-1 build #29.