This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Download Microsoft Edge More info about Internet Explorer and Microsoft Edge

Visual Studio 2019 version 16.2 — Visual Studio Installer

Visual Studio 2019 for Mac version 8.2 — Visual Studio for Mac Installer with the Stable updater channel

What's new in Xamarin.Android 9.4

Xamarin.Android 9.4 releases

September 5, 2019 — Xamarin.Android 9.4.1.1 in Visual Studio 2019 version 16.2.4.

August 6, 2019 — Xamarin.Android 9.4.1.0 in Visual Studio 2019 version 16.2.1.

August 5, 2019 — Xamarin.Android 9.4.1.0 in the Stable updater channel of Visual Studio 2019 for Mac.

July 24, 2019 — Xamarin.Android 9.4.0.51 in Visual Studio 2019 version 16.2 and the Stable updater channel of Visual Studio 2019 for Mac.

Corresponding Visual Studio 2019 release notes

Visual Studio 2019

Visual Studio 2019 for Mac

September 5, 2019 — Xamarin.Android 9.4.1.1

This version is included in the Visual Studio 2019 version 16.2.4 release.

Issues fixed in Xamarin.Android 9.4.1.1

Application and library build process

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.

August 5, 2019 — Xamarin.Android 9.4.1.0

This version is included in the Visual Studio 2019 version 16.2.1 release and in the Stable updater channel of Visual Studio 2019 for Mac.

Issues fixed in Xamarin.Android 9.4.1.0

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.

July 24, 2019 — Xamarin.Android 9.4.0.51

This version is included in the Visual Studio 2019 version 16.2 release and in the Stable updater channel of Visual Studio 2019 for Mac.

Summary of what's new in Xamarin.Android 9.4.0.51

Build and deployment performance

App startup performance

Option to compile app startup methods to unmanaged code

Fewer DEX references, so fewer apps will need multidex

Mono Framework version update to 6.0

Preview bindings for Android Q Beta 2

AAPT2 enabled by default for new projects

Initial support for Android App Bundle publishing format

jit-times analysis tool

Issues fixed in Xamarin.Android 9.4.0.51

Known issues

Build and deployment performance

GitHub PR 2536 , with follow-up adjustments in GitHub PR 2870 , GitHub PR 2878 , GitHub PR 2916 : Add a .jar file to the Xamarin.Android installer package that contains pre-built versions of a number of Java classes that are used by every Xamarin.Android project. That way the individual projects don't need to build the Java classes themselves. This reduced the total time for the Java compilation step on a clean build of a test app from about 2.7 seconds to about 2.5 seconds.

GitHub PR 2896 : Adjust the Android resource compilation build step to avoid re-running AAPT (or AAPT2) individually for each library and to avoid generating many extra unused resource IDs. For example, in a test Xamarin.Forms application, the number of references in the .dex file dropped from about 30,000 to about 18,000, the .dex file size decreased from about 3.5 megabytes to about 3.4 megabytes, and the total time for the resource compilation step in a clean build dropped from approximately 3 seconds to about 20 milliseconds.

GitHub PR 2930 : Revise the Inputs and Outputs for the _BuildLibraryImportsCache target, and adjust the GetImportedLibraries to take advantage of those adjustments. This allows incremental builds to skip the _BuildLibraryImportsCache target when appropriate. It also improves the performance of GetImportedLibraries for clean builds. For example, in a test Xamarin.Forms app, this change saved approximately 100 milliseconds for an incremental build after a XAML file change, and it reduced the clean build time for the GetImportedLibraries target from approximately 300 milliseconds to approximately 170 milliseconds in the same project.

GitHub PR 2934 , with follow-up adjustments in GitHub PR 2958 : Avoid running the Xamarin.Android-specific _BuildAdditionalResourcesCache or _ResolveLibraryProjectImports build steps on assembly types like .NET Standard assemblies that never contain Xamarin.Android library project features such as Android resources. This reduced the incremental build time for these steps from about 360 milliseconds to about 80 milliseconds in a test Xamarin.Forms app where only the .NET Standard project was modified between builds. This also reduced the clean build time for these steps in the same project from about 1.8 seconds to about 1.2 seconds.

GitHub PR 2935 : Avoid copying extra .pdb or .mdb debugging symbol files to the bin output directory in cases where the corresponding .dll assembly files themselves are not copied to the output directory. Depending on the size and number of debugging symbols for a project and the speed of the drive where the output directory is stored, this change can potentially save a noticeable amount of time. In a smaller test project built on an SSD, this change saved roughly a few dozen milliseconds for an incremental build where an assembly changed.

GitHub PR 2952 : Remove old debug logging messages from several of the build tasks. Since MSBuild prints this information automatically when building with diagnostic verbosity, these additional logging messages are no longer needed. In some cases this change can also reduce the total build time. For example, in a test app, it reduced the clean build time from roughly 25.5 seconds to about 25.0 seconds.

GitHub PR 2956 : Expand on the previous improvement from GitHub PR 2643 that allowed the GenerateJavaStubs task to skip over .NET Standard assemblies by now also skipping the whole parent _GenerateJavaStubs target in cases where only .NET Standard assemblies have changed. This allowed a small test Xamarin.Forms project to skip the _GenerateJavaStubs target successfully, saving approximately 860 milliseconds for an incremental build in the case where only a XAML file was changed.

App startup performance

Option to compile app startup methods to unmanaged code

Visual Studio Enterprise 2019 version 16.2 includes a new Enable Startup Tracing option that provides finer control over the trade-offs between Android APK size and startup time as compared to the existing AOT Compilation option.

Instead of compiling as much of the app as possible to unmanaged code, this new option compiles only a particular set of managed methods that represent the most expensive parts of application startup in a blank Xamarin.Forms app. This approach consumes less space in the APK compared to the AOT Compilation option while still providing similar app startup performance improvements. In a test Xamarin.Form app, enabling this setting reduced the Mono runtime initialization step of application startup from approximately 370 milliseconds to approximately 250 milliseconds.

To try this feature in Visual Studio Enterprise, configure the project to use both AOT Compilation and 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>
Other improvements
GitHub PR 2718, with
follow-up adjustments in GitHub PR
3010, GitHub PR
3026: Generate unmanaged
native shared libraries to provide the per-application Java-to-managed and
managed-to-Java type mappings and environment settings that Xamarin.Android
applications use.  Previously, this information was stored in data files within
the APK that the applications would load and parse during startup, but now the
application can directly run the unmanaged executable instructions instead.
This reduced the startup time from about 240 milliseconds to about 230
milliseconds for a Release configuration build of a small test Xamarin.Forms app
on a Google Pixel 3 XL device.
Known issues
The GitHub PR 2718
feature that generates unmanaged native shared libraries for the type mappings
and the environment settings currently depends on running the unmanaged native
linker from the Android SDK toolchain.  For 32-bit target ABIs such as
armeabi-v7a and x86, the unmanaged linkers are themselves currently 32-bit
executables.  macOS will in some cases show a ""App" is not optimized for your
Mac and needs to be updated" warning when these 32-bit executables run.
Fewer DEX references, so fewer apps will need multidex
GitHub PR 2896: Improve
the Android resource compilation build step to avoid generating as many unused
resource IDs.  This means that more apps will now fit within the DEX 64K
reference limit.
If you have a project that is currently configured to use Enable Multi-Dex
for the Release configuration in the Visual Studio project property pages, you
can now try disabling multidex to see if it is still needed.
Mono Framework version update to 6.0
This version of Xamarin.Android updates the Mono runtime and class libraries
from Mono 5.18 to
Mono 6.0
Commit e6f5369c,
adding about 1,800 new commits.
Preview bindings for Android Q Beta 2
Xamarin.Android 9.4 includes preview bindings for the Android Q Beta
2 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 new projects
Xamarin.Android has included an option to use the Android Asset Packaging Tool
2.0 (AAPT2) since Xamarin.Android 9.0, but is
has so far been disabled by default to provide a gradual path for finding and
addressing compatibility issues.  A number of issues have now been resolved, and
an up-to-date version of AAPT2 is now included as part of the Xamarin.Android
installation to avoid depending on the older version that is part of the Android
SDK, so the option is now enabled by default for new projects.




    

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.  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>
To switch back from AAPT2 to AAPT for a particular project, 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 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 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 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.
Initial support for Android App Bundle publishing format
At Google I/O 2018, Android introduced a new Android
App Bundle publishing format for Google Play.
Xamarin.Android 9.4 includes a new build option to generate Android App Bundles
for Xamarin.Android apps.
Limitation: For apps deployed to devices running Android versions between
6.0 Marshmallow (API level 23) and 8.1 Oreo (API level 28), this feature
currently only works if the app has the
android:installLocation attribute set to
"internalOnly" in the Android manifest.  This setting can be configured under
Install location > Internal Only in the Android Manifest section of the
Visual Studio project property pages.  This limitation will be resolved in a
future Xamarin.Android release.
To try the new format with your project, you can set the
$(AndroidPackageFormat) MSBuild property to aab for the Release
configuration in your .csproj file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <AndroidPackageFormat>aab</AndroidPackageFormat>
</PropertyGroup>
When this property is set, the SignAndroidPackage MSBuild target will create
an archive in the bin directory that uses the Android App Bundle format.
This new build option is not yet surfaced in the Visual Studio project property
pages.  Additionally, the Build > Archive command does not yet support this
feature.  To create a .aab file that is suitable for submission to Google
Play, you can instead run a command similar to the following in a Developer
Command Prompt:
msbuild -restore AndroidApp.csproj ^
  -t:SignAndroidPackage ^
  -p:Configuration=Release ^
  -p:AndroidKeyStore=True ^
  -p:AndroidSigningKeyStore=com.contoso.keystore ^
  -p:AndroidSigningStorePass=password ^
  -p:AndroidSigningKeyAlias=keyAlias ^
  -p:AndroidSigningKeyPass=password
Replace the values for the signing properties with the appropriate key store
file name, key alias, and passwords for your distribution key.  See the
documentation for additional information about these
properties.
After running the msbuild command, locate the signed .aab file in the bin
output directory.
Known issues
GitHub 3298:
"JNI DETECTED ERROR IN APPLICATION: mid == null" or "CallStaticIntMethodV
received NULL jclass" "... in call to CallStaticIntMethodV ... from void
mono.android.Runtime.init" will prevent apps built using 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 28).
Setting $(AndroidPackageFormat) to aab currently increases build times
for the Use Fast Deployment Debug configuration setting, so it is
recommended to set the new property only for the Release configuration for
jit-times analysis tool
Xamarin.Android 9.4 includes a new command-line tool to help analyze JIT timing
log information emitted by the Mono runtime for Xamarin.Android apps for users
who might be curious to look at some details about how time is spent by the JIT.
See the tool's README for additional information.
Issues fixed in Xamarin.Android 9.4.0.51
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.
Developer Community 435034:
Deployment to device or emulator would fail with "error MSB4018: The
"CopyFileFromZipToZip" task failed unexpectedly." for projects that used the
Assemblies:Dexes fast deployment mode in
combination with the D8 Dex compiler.
GitHub 2680:
Xamarin.Android projects that referenced Android libraries containing
resource files could sometimes fail on "The process cannot access the file
...  obj\Debug\90\lp\26\jl\manifest\AndroidManifest.xml' because it
is being used by another process."
GitHub PR 2795,
GitHub PR 2849,
GitHub 1128:
Several of the MSBuild targets were using BeforeTargets or AfterTargets
in cases where they could be avoided.  One consequence was that the
LinkAssemblies task would still run in cases where the Compile target
had failed.  This resulted in misleading extra error messages about the
failure of the LinkAssemblies task.
GitHub PR 2881:
Xamarin.Android build tasks that used Parallel.ForEach() could produce
non-descriptive "One or more errors occurred." errors when they failed.
Several of those cases have now been improved to produce "XA0000" errors
with more descriptive inner exception messages.
GitHub PR 2896:
The Xamarin.Android build process would launch many aapt (or aapt2)
processes for apps that referenced many Android libraries containing
resource files.  These builds now no longer launch as many separate
processes.
GitHub PR 2896:
The Android resource compilation build step was generating a large number of
extra unused resource IDs for Xamarin.Android apps that referenced libraries
containing many resources, such as the Xamarin.Android.Support and
Xamarin.GooglePlayServices libraries.  This meant that those applications
were more likely to exceed the DEX 64K reference limit and more
likely to require the Enable Multi-Dex setting compared to similar apps
written in Java or Kotlin.
GitHub PR 2905:
The error message from adb was not included as part of the MSBuild error
message in cases where adb exited due to an error during deployment.
GitHub PR 2975:
The ResolveAndroidTooling MSBuild task took roughly 80 milliseconds longer
for incremental builds when projects enabled the Use incremental packaging
system (aapt2) setting.
GitHub PR 2984:
The diagnostic MSBuild log output for Xamarin.Android projects did not list
the input file locations used to generate intermediate outputs like
obj\Debug\90\lp\12\jl\res\drawable.  This could make it more
difficult to identify the responsible input file if one of the intermediate
files caused a build error.  The paths for the input files are now included
as %(OriginalFile) metadata on the items so that the input file for each
item will be recorded in the diagnostic log output.
GitHub PR 3114:
Projects that had Use incremental packaging system (aapt2) enabled could
encounter relatively slower builds in apps that used custom subclasses of
Android.View.View.  In these cases, AAPT2 was being run on each of the
available resource directories instead of only on the parent directories of
layout files that contained custom views.  This could potentially cost an
extra 10 seconds for a medium sized project during both clean builds and
incremental builds where a XAML file had changed.
GitHub PR 3174:
Builds could fail due to "error APT0000: failed parsing overlays." for
projects with Use incremental packaging system (aapt2) enabled.
Xamarin.Android 9.4.0.34 updates the included aapt2 executable to version
3.4.1-5326820 to resolve this issue.
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 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.
Builds could occasionally fail during the ResolveXamarinAndroidTools task
with "Did not find Xamarin.Android at path ...  warning XA5300:  Unable to
determine Xamarin.Android version" due to the order in which MSBuild ran the
ResolveXamarinAndroidTools task relative to the
DetectIfAppWasUninstalled task.
@(AndroidAsset) MSBuild items that used %(LogicalName) metadata with
relative paths were not copied to the correct intermediate output location
during the build.
Application behavior on device and emulator
GitHub 3049:
Projects with Use incremental packaging system (aapt2) enabled could
encounter "java.lang.ArrayIndexOutOfBoundsException" errors when running on
device because incorrect resource IDs were being generated in the
Resource.designer.cs file for resources that referenced android:
resource names either directly or indirectly.
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 3169:
Applications could hit an exception similar to "Failed resolution of:
Landroid/support/v7/appcompat/R$drawable; --->
Java.Lang.ClassNotFoundException: Didn't find class
"android.support.v7.appcompat.R$drawable" on path: DexPathList" in projects
that had Use incremental packaging system (aapt2) enabled.
Design-time build process
Developer Community 461522,
GitHub 3007:
Xamarin.Android's built-in managed parser for Android resource files was
generating resource ID fields that used the . character as a name
separator for certain resource file inputs, resulting in "A const field
requires a value to be provided" and "Syntax error, ',' expected"
IntelliSense errors.
Android API bindings
GitHub 2864:
The Android.Security.Keystore.KeyStorePurpose type did not include a
[Flags] attribute, so using bitwise operators on it would produce warnings
in static analysis tools.
Xamarin.Android SDK installation
GitHub 2686,
GitHub PR 2733,
with follow-up adjustments in
GitHub PR 2826:
The .vsix installer package for Windows contained a few unnecessary files
that were not present in the .pkg installer package for macOS.
Additionally, the .pkg installer for macOS did not automatically remove
the previous version during installation, so unused old versions could
accumulate under /Library/Frameworks/Xamarin.Android.framework/Versions.
Known issues in Xamarin.Android 9.4.0.51
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 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 runs binary
analyzers.
GitHub 3343:
Errors similar to "error: cannot access ListenableFuture ... class file for
com.google.common.util.concurrent.ListenableFuture not found" can cause the
build to fail during the _CompileJava target when using certain libraries
like Xamarin.Google.Guava.ListenableFuture that include an embedded .jar
file and no public managed types.
Workaround:
Add the following lines to the bottom of your app project's .csproj file (just before the closing </Project> tag):
<Target Name="FixGuava" AfterTargets="_AddAndroidCustomMetaData">
  <ItemGroup>
    <_MonoAndroidReferencePath Include="@(_ReferencePath);@(_ReferenceDependencyPaths)" Condition=" '%(Filename)' == 'Xamarin.Google.Guava.ListenableFuture' " />
  </ItemGroup>
</Target>
GitHub PR 3350:
The Xamarin.Android SDK installer .pkg file for macOS is not yet
compatible with the macOS Catalina preview.
GitHub PR 3379:
"The "FilterAssemblies" task was not given a value for the required
parameter "DesignTimeBuild"." error prevents projects from building
successfully when they use certain additional MSBuild targets, such as the
targets from the NuGet.Build.Packaging NuGet package.
Workaround:
In your .csproj file, conditionally set the $(DesignTimeBuild) MSBuild
property to a placeholder value of false when it is empty:
<PropertyGroup>
    <DesignTimeBuild Condition="'$(DesignTimeBuild)' == ''">false</DesignTimeBuild>
</PropertyGroup>
Feedback welcome
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.
Contributors
A big Thank You! to contributors who made improvements in this release:
Atsushi Eno (@atsushieno),
GitHub PR 2829:
Add initial preview bindings for Android Q Beta.
Atsushi Eno (@atsushieno),
GitHub PR 2830:
Remove unneeded api*.xml.in files from the xamarin-android repository
because those files are now generated.
Evgeniy Stepanov (@xtmq),
GitHub PR 2905:
Include the error message from adb as part of the MSBuild error message in
cases where adb exits due to an error during deployment.
Atsushi Eno (@atsushieno),
GitHub PR 2965:
Add preview bindings for Android Q Beta 2.
Atsushi Eno (@atsushieno),
GitHub Java.Interop PR 419:
Update the Android API bindings generator tools to support additional Java
language constructs that are used by the Android Q Beta stub .jar files.
OSS core
Xamarin.Android 9.4 is based on the open-source Xamarin.Android repositories:
Core JNI interaction logic is in the Java.Interop repo.
Android bindings and MSBuild tooling are in the xamarin-android repo.
Chat is in the xamarin/xamarin-android Gitter channel.