The only distribution we haved support for right now is Ubuntu but it's
trivial to add support for your distro of choice. To do so, run on
command line:
lsb_release -i -s
and take note of the printed string - this is your distribution name as
known to LSB. If the installation commands work for all releases of your
distribution, add the following target to the Makefile:
linux-prepare-YOUR_DISTRO_NAME::
and provide commands to install the dependencies using your package
manager below that line.
If, however, some releases of your distribution require different
commands or a different set of packages to install, run on command line:
lsb_release -r -s
And take note of the printed distribution release string. Then add the
following target to the Makefile:
linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE::
And omit the first target above. That's it!
`make distclean` will not only run `make clean` but it will also
run `git clean -xdff` for the main project as well as the submodules
thus giving you a pristine tree.
Note that it will remove *all* of the files not in the git index
as well as all the build artifacts! Use with care!
Proper execution of Xamarin.Android.Build.Tasks requires that
`$prefix/lib/mandroid/class-parse.exe` exist. Unfortunately, nothing
*created* that file, which means a default build didn't work. :-(
Bump to Java.Interop/b6431ac8, which adds support for
`Java.Interop/Configuration.Override.props`, update the `make prepare`
target to create `external/Java.Interop/Configuration.Override.props`,
and add Java.Interop's `class-parse` and `logcat-parse` to
`Xamarin.Android.sln`. This causes `class-parse` to (1) be built, and
(2) place its output into `bin/$(Configuration)/lib/mandroid`, as
required by `Xamarin.Android.Build.Tasks.dll`.
Import monodroid/tests/runtime from monodroid/9c5b3712.
Add a toplevel `make run-apk-tests` target to "full stack" tests, in
which a .apk is created, installed, and executed on an attached
Android device. `make run-apk-tests` requires that `adb` be in $PATH,
and uses GNU make(1) features, and...
Additionally, tools/scripts/xabuild *must* be used to execute the
`SignAndroidPackage` target, to ensure that the local/"in tree"
assemblies are used. There is no "within xbuild" facility to alter
where target framework assemblies are resolved from, i.e no MSBuild
properties currently control the resolution order, only environment
variables, and MSBuild can't *set* environment variables...
The $(ADB_TARGET) variable can be used to control on which target
Android device the tests will be installed and executed on:
# Install & run tests on *only* connected USB device
$ make run-apk-tests ADB_TARGET=-d
# Install & run tests on *only* connected emulator
$ make run-apk-tests ADB_TARGET=-e
# Install & run tests on specified device, listed via `adb devices`.
$ make run-apk-tests ADB_TARGET="-s 036533824381cfcb"
Sorry potential/future Windows developers. *Running* tests will
require manual testing or running on OS X or Linux for now...
Note: These tests DO NOT PASS. In fact, they *crash*:
$ make run-apk-tests
...
Target RunTests:
Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation
INSTRUMENTATION_RESULT: shortMsg=Process crashed.
INSTRUMENTATION_CODE: 0
$ adb logcat
...
E mono : Unhandled Exception:
E mono : System.ObjectDisposedException: Cannot access a disposed object.
E mono : Object name: 'System.Net.Sockets.Socket'.
E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0
E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0
E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0
E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0
E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0
E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0
E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0
E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0
E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0
E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0
E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0
E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0
Looks like a Socket and/or ThreadPool bug in mono.
This commit adds basic support for the MSBuild Unit Tests. The goal
of these tests is to ensure that the build of an android applicaition
works consistently on all the supported platforms.
The basic layout of a Unit test is as follows
[Test]
public void BuildReleaseApplication ()
{
var proj = new XamarinAndroidApplicationProject () {
IsRelease = true,
};
using (var b = CreateApkBuilder (Path.Combine ("temp", TestContext.CurrentContext.Test.Name))) {
Assert.IsTrue (b.Build (proj), "Build should have succeeded.");
}
}
It is a standard Unit test. First we create a XamarinAndroidApplicatonProject
and set its properties. You can use the proj to add new source files,
references, assets, resources and nuget packages. By default you will get
a standard "HelloWorld" android application.
Once you have the project you will need to create either a Apk or Dll builder
via the helper methods
CreateApkBuilder
CreateDllBuilder
CreateApkBuilder will create an apk and by default will execute the
`SignAndroidPackage` build target. the CreateDllBuilder will produce
a dll. The source files are created in a temp directory relative to
the build output of the unit tests. By default this is
src/Xamarin.Android.Build.Tasks/UnitTests/Xamarin.Android.Build.Tests/bin/$(Configuraiton)/temp
Once you have a builder you can then call Build passing in the project. There are
also methods available for Clean and Save. Running any of these will cause
the Unit test to shell out to xbuild/msbuild and attempt to build the project.
Test results are written to a build.log file.
If a unit test passes then the test directory is removed. If a test fails
the directory and the build.log will be left in place for investigation.
* Add the V make parameter to enable verbose logging
Setting V to anything than 0 (zero) enables verbose logging for
{ms,x}build as well as exports MONO_OPTIONS=--debug to enable
stack traces should an exception be thrown when running mono.
To add/override MONO_OPTIONS simply set it on the command line when
invoking make, for instance:
make V=1 MONO_OPTIONS="--trace"
* File.Move doesn't overwrite targets
File.Move will throw an exception whenever the target file exists.
Assuming that the task should overwrite the existing target files
for smooth operation, this change checks whether the target file
exists and, if so, deletes it prior to calling File.Move
Commit 5777337e noted a SNAFU:
> One SNAFU: currently, Mono.Android.csproj conditinally <Import/>s a
> Mono.Android.projitems file generated by Java.Interop's generator
> tool, which contains a list of all the generated files.
>
> When the project is first loaded, Mono.Android.projitems will not
> exist, so on that initial build, source code will be generated but
> xbuild won't re-read Mono.Android.projitems (once it exists). This
> will result in a failing build.
The fix? Update @(Compile) and $(DefineConstants) after code
generation. This allows everything to compile after a single build,
without requiring two builds.
(*Now* things are starting to come together...)
One of the important infrastructural pieces of Xamarin.Android is
Mono.Android.dll, a "binding" for the Android SDK `android.jar` file.
Bindings are generated by using the `generator` tool from
Java.Interop, along with tools/jnienv-gen, and various other programs.
This in turn requires adding a git submodule for Java.Interop.
Stitch all these pieces together so that we can take an
*API description* (stored in Profiles\api-*.xml.in) and generate a
binding for that API description.
The generated files are located in
obj\$(Configuration)\android-$(ApiLevel), and the resulting
Mono.Android.dll is copied to
$(topdir)\bin\$(Configuration)\xbuild-frameworks\MonoAndroid\$(XAFrameworkVersion).
One SNAFU: currently, Mono.Android.csproj conditinally <Import/>s a
Mono.Android.projitems file generated by Java.Interop's generator
tool, which contains a list of all the generated files.
When the project is first loaded, Mono.Android.projitems will not
exist, so on that initial build, source code will be generated but
xbuild won't re-read Mono.Android.projitems (once it exists). This
will result in a failing build.
Simply rebuild the project to get a valid build, or use the `make all`
Makefile target.
- fix Android SDK Tools location.
- add SDK/NDK items for Linux.
- xbuild condition did not work and downloaded all the items. It was because
condition by metadata didn't work with the complicated expression.
So, split filtering and transformation into different tasks.
- xbuild aborts when the specified metadata %(HostOS) does not exist, so
specify dummy HostOS metadata (which is ugly but not too annoying).
(Linux build verification is still ongoing, not assuring that this fixes
all the possible existing issues.)
Add a new build-tools/mono-runtimes project to build the required Mono
runtimes for Xamarin.Android app execution on Android devices.
Xamarin.Android 6.0 ("cycle 6") includes Mono runtimes compiled for
five architectures:
* armeabi (armv5)
* armeabi-v7a (armv7)
* arm64-v8a (aarch64)
* x86
* x86_64
An additional "host" architecture is also built to build the
"monodroid" profile assemblies such as mscorlib.dll.
In the interest of expediency and not requiring that *six* different
runtimes be built -- which can greatly increase build times and
storage requirements -- the initial xamarin-android open-source build
will only build the armeabi-v7a (armv7) and "host" architectures.
Additionally, the <UnzipDirectoryChildren/> task needed to be altered
to use unzip(1) on OS X instead of using
System.IO.Compression.ZipFile, because the ZipFile implementation
included with Mono 4.4 doesn't respect file attributes such as the +x,
causing all files to be extracted as 644 (rw-r--r--), resulting
in an NDK toolchain which wouldn't work. To resolve this issue,
execution on OS X and Linux now uses unzip(1).
~~ Adding new architectures ~~
To build Mono for a new architecture, edit
build-tools/mono-runtimes/mono-runtimes.projitems and add a new
@(_MonoRuntime) entry for the desired architecture.
TODO: Figure out if there's a reasonable way to "opt-in" or "opt-out"
of CPU architectures so that it isn't an "all or nothing" prospect.
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.
Marek Habersack
Jonathan Pryor
Dean Ellis
Ankit Jain
Atsushi Eno