Context: https://developer.android.com/about/versions/13
Context: https://android-developers.googleblog.com/2022/06/android-13-beta-3-platform-stability.html
Android 13 Beta 3 has been released.
* [API diff vs. API-32][0]
* [API diff vs. API-Tiramisu Beta 2][1]
The Android 13 Developer Preview Program Overview
[Timeline and updates][2] section suggests the following timeline:
* May: Beta 2
* June: Beta 3: First Platform Stability milestone.
Final APIs and behaviors.
* July: Beta 4: Near-final build for final testing.
* ???: Final
In particular, Beta 3 has "Final APIs". We now have API-33!
Enumify API-33, and declare it stable.
API-33 will be available as:
* Classic Xamarin.Android: `$(TargetFrameworkVersion)`=v13.0
* .NET 6: `$(TargetFramework)`=net6.0-android33.0
* .NET 7: `$(TargetFramework)`=net7.0-android33.0
The default API-level for `net6.0-android` remains API-31.
The default API-level for `net7.0-android` will be API-33.
~~ Enumification Issue ~~
The following methods look like they should be enumified, however the
constants referenced by their [documentation][3] do not exist.
Perhaps this will be fixed later and we should revisit them? For now,
they are not enumified.
?,33,android/net/wifi/aware,PublishConfig,getInstantCommunicationBand,return,
?,33,android/net/wifi/aware,PublishConfig$Builder,setInstantCommunicationModeEnabled,band,
?,33,android/net/wifi/aware,SubscribeConfig,getInstantCommunicationBand,return,
?,33,android/net/wifi/aware,SubscribeConfig$Builder,setInstantCommunicationModeEnabled,band,
?,33,android/net/wifi,MloLink,getBand,return,
~~ API Compat Changes ~~
We now ignore `[Android.Runtime.StringDefAttribute]` and
`[Android.Runtime.IntDefAttribute]` in `<CheckApiCompatibility/>`.
These attributes frequently churn on each preview and release, causing
lots of noise in our `acceptable-breakages*` files. As we do not
consume these attributes, we don't really need to track changes.
Relevant existing entries from `acceptable-breakages*` files were removed.
~~ Update `CodeDiffGen` ~~
The logic for running `Microsoft.DotNet.GenAPI` was failing with:
/Users/builder/azdo/_work/1/s/xamarin-android/src/Mono.Android/Mono.Android.targets(270,5):
error MSB4018: System.ComponentModel.Win32Exception (8): An error occurred trying to start process
'/Users/builder/.nuget/packages/microsoft.dotnet.genapi/7.0.0-beta.22103.1/tools/net472/Microsoft.DotNet.GenAPI.exe'
with working directory '/Users/builder/azdo/_work/1/s/xamarin-android/src/Mono.Android'.
Exec format error
Fix this by using the `netcoreapp3.1/Microsoft.DotNet.GenAPI.dll`
version when running under `dotnet`.
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
[0]: https://developer.android.com/sdk/api_diff/33/changes
[1]: https://developer.android.com/sdk/api_diff/33-incr/changes
[2]: https://web.archive.org/web/20220627195145/https://developer.android.com/about/versions/13/overview#platform_stability
[3]: https://developer.android.com/reference/kotlin/android/net/wifi/aware/PublishConfig#getinstantcommunicationband
Context: https://developer.android.com/about/versions/12/12L
Context: https://android-developers.googleblog.com/2021/12/beta-1-update-for-12l-feature-drop.html
Android 12L Developer Beta 1 has been released.
* [API diff vs. API-31][0]
* [API diff vs. Sv2 DP1][1]
The Android 12L Developer Preview Program Overview
[Timeline and updates][2] section suggests the following timeline
(which differs from ef011213):
* October: Developer Preview 1
* December: Beta 1; Final APIs (previously expected in Beta 2)
* January: Beta 2; Incremental beta update
* February: Beta 3; Incremental beta update
* Q1 2022: Final release
In particular, Beta 1 has "Final APIs". We now have API-32!
Enumify API-32, and declare it stable.
As a change from "upstream Google", Classic Xamarin.Android uses
`$(TargetFrameworkVersion)`=v12.1 for API-32, as there is no way to
express "12L" in a `System.Version`. We have decreed 12.1 as 12L.
.NET SDK for Android uses `$(TargetFramework)`=net6.0-android32.0.
However, we don't want to change the default API level for .NET 6
projects; the default will remain `net6.0-android31.0` (API-31),
using the [31.0.101-preview.11.117 binaries on NuGet.org][3].
This requires various changes to the unit test infrastructure and
.NET SDK workflow package creation.
Additionally, `d8` doesn't appear to support API-32 yet (?!);
building an app with an `AndroidManifest.xml` containing:
<uses-sdk android:minSdkVersion="32" android:targetSdkVersion="32" />
would use `d8 --min-api 32`, which results in a warning:
D8 : warning : An API level of 32 is not supported by this compiler.
Please use an API level of 31 or earlier
Update the `XASdkTests.SupportedOSPlatformVersion()` test so that it
only uses API-31 and not API-32. This avoids the above warning.
Finally, we had to update xaprepare to install the new
Android SDK Build-tools version 32.0.0, as `aapt` from previous
Build-tools versions would emit a warning when building for API-32:
Xamarin.Android.Aapt2.targets(157,3): warning APT2000: aapt2 W 01-05 23:58:06 8352 43857 LoadedArsc.cpp:657] Unknown chunk type '200'.
Unfortunately, installing Build-tools 32.0.0 promptly broke unit
tests using `$(AndroidDexTool)`=dx, with:
COMPILETODALVIK : error : Unable to access jarfile C:\…\android-toolchain\sdk\build-tools\32.0.0\lib\dx.jar
as Build-tools 31 and later no longer contains `lib/dx.jar`. Update
xaprepare to install *both* Build-tools 30.0.3 *and* 32.0.0, so that
tests which require `dx.jar` continue to run, and we can get *some*
test coverage against Build-tools 32.
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
[0]: https://developer.android.com/sdk/api_diff/32/changes
[1]: https://developer.android.com/sdk/api_diff/32-incr/changes
[2]: https://web.archive.org/web/20220113142518/https://developer.android.com/about/versions/12/12L/overview
[3]: https://www.nuget.org/packages/Microsoft.Android.Ref.31/31.0.101-preview.11.117
Context: https://developer.android.com/about/versions/12
API-31 has been enumified (88438081, cf2a39b2, cf2a39b2).
Time to declare it stable!
Set API-S as API-31, `$(TargetFrameworkVersion)`=v12.0,
`$(AndroidPackVersion)`=31.0.100, and declare as stable.
Update unit test files so `$(TargetFrameworkVersion)`= v12.0 (API-31)
*or* `$(TargetFrameworkVersion)` isn't needed, a'la 8140991e.
Rename `src/Mono.Android/Profiles/api-S.params.txt` to
`api-31.params.txt`, to match the stable API-level ID.
Updated `tests/api-compatibility/acceptable-breakages-vReference.txt`
because the default API compare will now be against `API-31`, not
`API-30`, and we deliberately removed the `[Category]` custom attribute
(e5a4beef), remove `[DataContractAttribute]` (101fea2c), and fix the
value of `Android.OS.BuildVersionCodes.R` (1b1ec097).
Support `$(AndroidUseLatestPlatformSdk)` in binding projects: once
API-31 is stable, binding projects with
`$(TargetFrameworkVersion)`=v11.0 and
`$(AndroidUseLatestPlatformSdk)`=true fail to build with:
Task ResolveNuGetPackageAssets
...
Microsoft.NuGet.targets(198,5): Your project does not reference "MonoAndroid,Version=v12.0" framework. Add a reference to "MonoAndroid,Version=v12.0" in the "TargetFrameworks" property of your project file and then re-run NuGet restore.
What happened is that `$(TargetFrameworkVersion)` was changed to 12.0
during `Build`, but not during `Restore`. Thus NuGet restored with
`MonoAndroid,Version=v11.0` instead of `MonoAndroid,Version=v12.0`.
I found that we have this setup for other project types, but not
binding projects:
<!--
NOTE:
This target runs during Restore, and there is no $(RestoreDependsOn) property.
There appears to be no other way to do this other than use BeforeTargets.
-->
<Target Name="_SetLatestTargetFrameworkVersionForPackageReference"
Condition=" '$(AndroidUseLatestPlatformSdk)' == 'True' "
BeforeTargets="_GetRestoreTargetFrameworksOutput"
DependsOnTargets="_SetLatestTargetFrameworkVersion">
</Target>
If we move this target to `Xamarin.Android.Legacy.targets`, it will be
imported by binding projects.
We also get the added benefit of it not being in .NET 6.
`$(AndroidUseLatestPlatformSdk)` is not supported in .NET 6, so we
should not have this MSBuild target there.
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Context: https://developer.android.com/android11
Changes: 6d05c4929d...fb5542fa19
* xamarin/monodroid@fb5542fa1 [Make.config] Update API-R to API-30 (#1102)
API-30 has been enumified (8f9c6382). Time to declare it stable!
Set API-R as API-30, v11.0, and stable.
Update unit test files so `$(TargetFrameworkVersion)`= v11.0 (API-30).
Rename `src/Mono.Android/Profiles/api-R.params.txt` to
`api-30.params.txt`, to match the stable API-level ID.
Updated `tests/api-compatibility/acceptable-breakages-vReference.txt`
because the default API compare will now be against `API-30`, not
`API-29`, and we deliberately removed the `XxxConst` classes which
were `[Obsolete]`d 5+ years ago in API-30, resulting in an intentional
API break.
TODO:
* `jnimarshalmethod-gen.exe` tests were disabled as they ran into a
[runtime crash][0]. Once the runtime crash is fixed, we need to
update `src/Mono.Android/Test/Mono.Android-Tests.csproj` so that
`$(AndroidGenerateJniMarshalMethods)` is True when
`'$(HostOS)' == 'Darwin'`.
[0]: https://github.com/dotnet/runtime/issues/34389
API-29/v10.0 is now stable.
Bumps to xamarin/xamarin-android-api-compatibility/master@336eedaa.
Bump Targets/`$(TargetSdkVersion)` to v10.0 (API-29).
Add `src/Mono.Android/Profiles/api-29.params.txt` for parameter names.
Add new enums and fix method signatures (`map.csv`, `methodmap.csv`).
Fix metadata whitespace formatting.
Update Android Emulator to use 29 image
Bump test timeouts.
Fix test issues:
* [build-tools] Update the logcat timing patterns for API-29
* [logcat processing] Update activity displayed detection
* Fixing some deploy/undeploy apks to emulator
* Ignore exit code for `adb logcat -c`
* Allow BuildTest.BuildHasNoWarnings to have up to 1 warning due to
be incompatible with Api level 29
Remove `#if !ANDROID_29` condition from `StringBuffer.cs` and
`StringBuilder.cs`, added in 2cace0b3, to preserve API compatibility.
Android NDK r17 has dropped support for `armeabi` and any attempt to
build projects targeting this ABI fails with an error.
In preparation for NDK r17 this commit removes all the traces of
`armeabi` from xamarin-android tree.
In order to prevent confusion, all the instances where we used
`armeabi` but meant `armeabi-v7a` have been renamed to the latter
form.
Bump default `$(AndroidApiLevel)` to 24 (API-24) and default
`$(AndroidFrameworkVersion)` to v7.0.
Bump to Java.Interop/46e58ef6 to bring in new properties on
various Android-related custom attributes.
Add support for newly added custom attribute properties when
generating `AndroidManifest.xml`.
The commit implements building of LLVM and cross-compilers to support
Xamarin.Android/Mono AOT. LLVM and cross-compilers can be built for
both the host platform (Linux and OS/X at the moment) as well as
cross-compiled for 32-bit and 64-bit Windows platforms.
Windows builds are done with MXE toolchain on OS/X and with the packaged
mingw-w64 toolchain on Linux (tested on Ubuntu 16.04 ONLY).
Also introducing a new set of MSBuild properties that contain information
about the host system. Some of those properties (HostOS, HostCC, HostCXX
for instance) have been moved from Configuration.props to better support
auto-detection. A new script, build-tools/scripts/generate-os-info, is
invoked as part of `make prepare` to generate file that contains the
new properties. The generated file is required for the build to work and
is also host-specific (it mustn't be moved between different machines)
Cross compiler builds require access to a configured Mono build tree, in
order to generate C structure offsets header file that is used by the AOT
compilers to properly generate AOT-ed binaries. Therefore, even if a JIT
target is not enabled in the configuration, enabling a cross-compiler for
some target will configure Mono for that JIT target but it will NOT build
it, to save time. To facilitate this, the _MonoRuntimes items defined in
build-tools/mono-runtimes/mono-runtimes.projitems gain an additional metadata
item called `DoBuild` which will be set to `true` if the runtime actually needs
to be built, as opposed to just configured.
MXE builds are disabled on Linux as mingw-w64 works just fine.
A `make prepare` warning is issued for Linux hosts which have the binfmt_misc
module enabled and either Wine of Mono (cli) registered as PE32/PE32+ binary
interpreters. In such instance building of the Windows cross-compilers will
fail because Autotools determine whether software is being cross compiled by
building a test program and attempting to execute it. In normal circumstances
such an attempt will fail, but with Windows cross-compilation and either Wine
or Mono registered to handle the PE32 executables this attempt will succeed
thus causing the cross compilation detection to fail.
Currently to build cross compilers on Linux you need to generate the C structure
offsets header file on OS/X and copy the resulting headers to appropriate places
on Linux. The header files should be placed in
build-tools/mono-runtimes/obj/Debug/cross-*/
directories. The header files are:
{cross-arm,cross-arm-win}/aarch64-v8a-linux-android.h
{cross-arm64,cross-arm64-win}/armv5-none-linux-androideabi.h
{cross-x86,cross-x86-win}/i686-none-linux-android.h
{cross-x86_64,cross-x86_64-win}/x86_64-none-linux-android.h
Offsets header generation doesn't work on Linux atm because of missing support
for it in the Mono utility used to generate the offsets. Hopefully this limitation
will be removed in the near future and a start-to-end build of everything will be
possible on Linux.
It is now mandatory to run at least `make prepare-props` before Xamarin.Android
can be built. The target generates the OS-specific props file which is required
by the build. `make prepare` depends on the target.
Fix the solution and project files so that `msbuild` may be used to
build the solution instead of requiring `xbuild`.
There were a few issues that `msbuild` didn't like:
1. MSBuild doesn't like the "extra" configuration mappings in
Xamarin.Android.sln.
2. MSBuild doesn't like the presence of `.dll` within `@(Reference)`
entries. `<Reference Include="System.dll" />` is Bad™, so
Don't Do That™.™.
3. Turning `$(AndroidSupportedAbis)` into an item group is...broken.
(1) and (2) are straightforward fixes. (3) requires some explanation.
`src/monodroid` needs to *only* build `libmonodroid.so` for the
non-"host" ABIs within `$(AndroidSupportedAbis)`. It needs this
restriction because non-selected ABIs may not be configured in
`$(AndroidNdkDirectory)`, and thus can't be built.
This *could* be done by following
`build-tools/mono-runtimes/mono-runtimes.projitems` and doing lots of
`Condition`s on `$(AndroidSupportedAbisForConditionalChecks)`:
<_MonoRuntime Include="armeabi-v7a" Condition="$(AndroidSupportedAbisForConditionalChecks.Contains(':armeabi-v7a:'))" />
...
However, that's kinda ugly when *all* we need is the ABI name, so
`monodroid.projitems` was "cute":
<PropertyGroup>
<_SupportedAbis>$(AndroidSupportedAbis.Replace(':', ';'))</_SupportedAbis>
</PropertyGroup>
<ItemGroup>
<_MonoRuntime Include="$(_SupportedAbis)" Exclude="@(HostOSName)" />
</ItemGroup>
<!-- @(_MonoRuntime) is `armeabi-v7a` by default -->
This works...on xbuild, but *not* `msbuild`. Doh!
(`msbuild` is "smart" and doesn't treat the `;` as an item separator,
so if `$(AndroidSupportedAbis)` is `host-Darwin;armeabi-v7a` then
MSBuild treats the `;` as part of the filename -- NOT a filename
separator -- and `@(_MonoRuntime)` contains *one* item with
an `%(Identity)` of `host-Darwin;armeabi-v7a`. On the one hand, this
is kinda awesome and answers the question "how can you have a filename
that contains `;`?", but on the other hand it broke my project!)
The only fix I could think of was to use `.Split(':')`:
<_MonoRuntime Include="$(AndroidSupportedAbis.Split(':'))" Exclude="@(HostOSName)" />
That provides desired behavior with `msbuild`, but `xbuild` doesn't
support it and appears to either *ignore* it, or treat it literally,
in that `@(_MonoRuntime)` would contain a *single* item with the
literal value `$(AndroidSupportedAbis.Split(':'))` (argh!).
Fortunately, there's a "cute" workaround: using `.Split()` within an
item's `Include` attribute doesn't work, but using `.Split()` within a
property group declaration *does* work:
<PropertyGroup>
<_SupportedAbis>$(AndroidSupportedAbis.Split(':'))</_SupportedAbis>
</PropertyGroup>
<ItemGroup>
<_MonoRuntime Include="$(_SupportedAbis)" Exclude="@(HostOSName)" />
</ItemGroup>
<!-- @(_MonoRuntime) is `armeabi-v7a` by default -->
This implies that a property value isn't limited to string values, but
(as here) can be string *arrays*, which is interesting.
~~~
All that aside, while exploring the proper fix for (3) (it took a
remarkably long time to run across it), I decided to reconsider the
property and item arrangement here.
The prior approach was to have a single `$(AndroidSupportedAbis)`
MSBuild property which controlled *both* Android target ABIs and host
ABIs. This worked...but wasn't entirely scalable (separate moving
parts need to be kept in sync). Additionally, we need to add AOT
cross-compiler support, which logically would be controlled by the
same/similar mechanism, so a value of "build everything" would start
to look insane:
msbuild /p:AndroidSupportedAbis=armeabi:armeabi-v7a:arm64-v8a:x86:x86_64:host-Darwin:host-Win64:cross-Darwin-arm:cross-Darwin-arm64:cross-Darwin-x86:cross-Darwin-x86_64:cross-Win64-arm:cross-Win64-arm64:cross-Win64-x86:cross-Win64-x86_64
And that's assuming I'm not missing anything, or that we don't add
MIPS support in the future, or...
Blech.
Furthermore, Xamarin.Android *already* uses
[`$(AndroidSupportedAbis)` in its build system][0], which means a
top-level override of `$(AndroidSupportedAbis)` would also impact all
projects which build `.apk` files, e.g.
`src/Mono.Android/Test/Mono.Android-Tests.csproj`, which might not be
desirable.
In short, I think we're overloading "Android supported ABIs," and it
should be split up into smaller, easier to rationalize, chunks.
Thus, leave `$(AndroidSupportedAbis)` to Xamarin.Android's tasks, and
replace it with *two* new properties:
* `$(AndroidSupportedHostJitAbis)`: The "host" ABIs to build.
* `$(AndroidSupportedTargetJitAbis)`: The "target" ABIs to build.
AOT support, when added, would use a new
`$(AndroidSupportedHostAotAbis)` property, thus keeping the set of
acceptable values small and more easily rationalizable.
Finally, "split up" these new Abis properties into corresponding Abi
item groups, to allow consistent and reusable "mapping" of ABI names
to filesystem locations, etc. The new `@(AndroidSupportedHostAotAbi)`
and `@(AndroidSupportedTargetJitAbi)` item groups are derived from
their corresponding values. (Note singular from plural in naming.)
[0]: https://developer.xamarin.com/guides/android/under_the_hood/build_process/#AndroidSupportedAbis
Update `$(AndroidSupportedAbis)` and
`$(AndroidSupportedAbisForConditionalChecks)` to use `:` as the ABI
separator, not `,`.
`;` can't be used because xbuild and MSBuild don't like `;` as a
property value on the command-line.
Turns out, MSBuild doesn't like `,` within property values on the
command-line either, because it allows multiple MSBuild properties to
be specified via one `/p:` use:
$ msbuild -help
...
/property:<n>=<v> Set or override these project-level properties. <n> is
the property name, and <v> is the property value. Use a
semicolon or a comma to separate multiple properties, or
specify each property separately. (Short form: /p)
Example:
/property:WarningLevel=2;OutDir=bin\Debug\
This means that it's not possible to set `$(AndroidSupportedAbis)` to
e.g. `host-Darwin,armeabi-v8a` on the command-line *with MSBuild*.
(It is with xbuild, but this is arguably an xbuild compatibility bug!)
Since we want to be able to easily override the
`$(AndroidSupportedAbis)` value on the command-line for testing,
change the ABI separator character to `:` which is supported on both
xbuild and MSBuild:
$ xbuild /p:AndroidSupportedAbis=host-Darwin:armeabi-v7a
# works!
Certain Xamarin.Android features require that Mono be built for
Windows, e.g. the [AOT compilers][aot] require a build of mono that
executes on Windows to generate the AOT native libraries.
Unfortunately, building Mono on Windows continues to be a massive
PITA. (Autotools on Windows requires Cygwin/mingw, running shell
scripts on Windows is painfully slow, it's all brittle, etc.)
To work around this pain, we instead build the Mono/Windows binaries
on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler
which generates Windows binaries and is executable from Unix.
This in turn requires that we have MXE, so add a
`_CreateMxeToolchains` target to `android-toolchain.targets` which
will build MXE. The installation prefix for MXE can be overridden via
the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to
`$HOME/android-toolchain/mxe`.
Rework the `$(AndroidSupportedAbis)` MSBuild property so that it
must include the "host" ABI, and add support for a new `host-win64`
value which will use MXE to generate 64-bit Windows binaries for
libmonosgen-2.0.dll and libMonoPosixHelper.dll.
We can't always process `host-$(HostOS)` because of an xbuild bug.
The scenario is that if you want to just build `host-win64`, the
obvious thing to do is:
cd build-tools/mono-runtimes
xbuild /p:AndroidSupportedAbis=host-win64
Alas, if `host-$(HostOS)` is always processed, this inexplicably
causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of
time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target
because make(1) thinks that the configure flags have somehow changed,
which currently makes no sense at all. (When can we move to MSBuild?)
Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is
explicitly processed instead of implicitly processed allows working
around the above xbuild bug, as `host-$(HostOS)` won't be implicitly
processed on every build, but only when required.
Additionally, we add a new <Which/> MSBuild task so that we can
determine if a particular program is in `$PATH`. This is useful
because listing requirements within README.md is a road to pain --
e.g. xxd(1) is required to build `src/monodroid` but if it's missing
it'll still *build* but you'll instead get a *linker* failure because
the `monodroid_config` and `monodroid_machine_config` symbols aren't
present. Building MXE requires that even more programs be present
within $PATH, so explicitly check for these so that *useful* error
messages can be generated instead of obscure ones.
Finally, a note about autotools and generating Windows native
libraries: creation of `.dll` files *requires* that an appropriate
objdump be present so it can determine if e.g. `libkernel32.a` is an
import library or an archive. If `x86_64-w64-mingw32.static-objdump`
isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll`
files will be created, and much head scratching will occur.
To rectify this, override the OBJDUMP and DLLTOOL values when invoking
`configure` so that that full paths are used and `$PATH` use is
reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?)
[aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support
[mxe]: http://mxe.cc/
Commit 38dbfcaf mentions that commercial Xamarin.Android 6.0
provides Mono for five architectures, but "[i]n the interest of
expediency" only adds support to build *one* architecture:
armeabi-v7a (32-bit ARM v7).
It's time to fix that: add build system support for armeabi,
arm64-v8a, x86, and x86_64.
*However*, it takes *time* to build all those ABIs: on a 2013 6-core
Mac Pro, it takes ~29 minutes to build all five of those ABIs plus the
"host" ABI (for BCL assemblies), which is presumably 29 minutes that
very few people want to spend, and will be even longer in a variety of
build environments (virtual machines, slower hardware, etc.).
Which means we don't want to require that they all be built.
To better support this, add a new `$(AndroidSupportedAbis)` MSBuild
property which contains a comma-separated list of ABIs to support.
This allows manually overriding the ABIs on the command-line:
# build everything!
$ xbuild /p:AndroidSupportedAbis=armeabi,armeabi-v7a,arm64-v8a,x86,x86_64
or setting a value within `Configuration.Override.props`:
<PropertyGroup>
<!-- only build x86 -->
<AndroidSupportedAbis>x86,x86_64</AndroidSupportedAbis>
</PropertyGroup>
The *default* continues to be just armeabi-v7a.
`clang` isn't the C compiler everywhere, and `clang++` isn't the
C++ everywhere. For example, Ubuntu provides `clang-3.5`.
Allow the host-native C and C++ compilers to be specified/overridden
via the new $(HostCc) and $(HostCxx) MSBuild properties.
"Promote" $(ApiLevel), in src/Mono.Android.csproj, to
$(AndroidApiLevel), which can now be overridden within
Configuration.Override.props.
Promote $(XAFrameworkVersion) to $(AndroidFrameworkVersion) as well.
This allows easly altering the default Android API level which will be
bound without requiring uncommittible changes.
This might be a suspect idea, but lets see if we can make this work.
[The Joel Test: 12 Steps to Better Code][0] outlines 12 steps
to better code. The first two steps are:
1. Do you use source control?
2. Can you make a build in one step?
github is being used for source control, so (1) is handled, but how
simple can we make (2)? How easy can we make it to build
Xamarin.Android upon a fresh checkout?
The ideal to strive for is simple:
Load Xamarin.Android.sln into your IDE and Build the project.
I *know* we're not going to be able to do this, if only because we're
going to be using git submodules, which will require a separate
`git submodule init` invocation [1].
Knowing we can't reach that level of simplicitly doesn't mean we
shouldn't *try* to reach it for all other parts of the build system.
Which brings us to the Android NDK and SDK. The Android NDK will be
required in order to build native code, such as libmonodroid.so, while
the Android SDK will be required in order to compile
Java Callable Wrappers (née Android Callable Wrappers [2]) and
eventual samples and unit tests.
There are three ways we can deal with the Android NDK and SDK:
1. Complicate the "build" process by requiring that developers go to
the Android SDK Download Page [3], download and install
"somewhere" the required bits, and then configure the
Xamarin.Android build to use these bits.
2. Complicate the "build" process by requiring that developers run
the Xamarin Unified Installer [4], let it install everything
required, then configure the Xamarin.Android build to use those
bits.
3. Painstakingly determine which files are actually required, then
automatically download and extract those files into a "well-known"
location known by the Xamarin.Android build process.
(1) and (2) can be infuriating. Let's give (3) a try. :-)
Add a Xamarin.Android.Tools.BootstrapTasks project which contains
MSBuild tasks to facilitate downloading the Android SDK and NDK files.
Add an android-toolchain project which uses
Xamarin.Android.Tools.BootstrapTasks to download a painstakingly
determined set of files and install them "somewhere".
Unfortunately [5] the "somewhere" to download and install these files
needs to be in a known absolute path, so I've arbitrary decided to
download the files into $(HOME)\android-archives and install them into
$(HOME)\android-toolchain. On windows, this is
%HOMEDRIVE%%HOMEPATH%\android-archives and
%HOMEDRIVE%%HOMEPATH%\android-toolchain.
These locations may be modified by creating a
Configuration.Override.props file; see README.md for details.
TL;DR: This setup is able to magically download the Android NDK and
SDK files and install them for later use in a reasonably overridable
location, all within MSBuild.
[0]: http://www.joelonsoftware.com/articles/fog0000000043.html
[1]: Though maybe there's some MSBuild-fu we can use to address that.
[2]: https://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/android_callable_wrappers/
[3]: http://developer.android.com/sdk/index.html
[4]: https://www.xamarin.com/download
[5]: Because I couldn't find a reliable way to use $(SolutionDir) when
only building a project, and relative paths would require an
in-tree installation location, which might not work.
Jonathan Pobst
Gustavo Varo
Jonathan Pryor
Alexis Christoforides
Marek Habersack
Brendan Zagaeski
Atsushi Eno