Граф коммитов

46 Коммитов

Автор SHA1 Сообщение Дата
Alexander Köplinger c0ad00894d Build netstandard.dll and System.Drawing.Primitives.dll facades (#572)
Build `netstandard.dll` and `System.Drawing.Primitives.dll` facades

The old project for `System.Drawing.Primitives` was removed in favor
of building the assembly with the existing logic in Mono.

Also add them to the bundle since we can't rebuild them if we just
have the bundle.

Update facades list in `MobileProfile.cs`;
`netstandard.dll` and `System.ValueTuple.dll` were missing.
2017-04-21 16:06:08 -04:00
Jonathan Pryor a08cd80a05 [create-vsix] Create `.vsix` files (#541)
Visual Studio 2017 uses `.vsix` files for Xamarin.Android SDK support.
A `.vsix` file is [ZIP container with additional metadata][0], and the
[Microsoft.VSSDK.BuildTools NuGet package][1] contains various MSBuild
targets and tools to assist in creating `.vsix` files.

Add a new `build-tools/create-vsix/create-vsix.csproj` project to
create the `bin/Build$(Configuration)/Xamarin.Android.Sdk*.vsix` file,
so that we can plausibly provide per-build OSS Xamarin.Android
releases that work with Visual Studio 2017.

Unfortunately those tools were written on Windows, and not really well
tested on macOS or Linux... In particular, there are case-sensitivity
and directory-separator-char issues with the tooling, necessitating
that `MONO_IOMAP=all` be exported in order to run them:

	MONO_IOMAP=all MONO_OPTIONS=--arch=64 msbuild \
		build-tools/create-vsix/create-vsix.csproj /p:CreateVsixContainer=True

Meanwhile, we're still attempting to allow things to be built with
`xbuild` [^3]. Thread this needle by "special-casing" the
`$(BuildDependsOn)`, `$(CopyVsixManifestFileDependsOn)`, and
`$(DetokenizeVsixManifestFileDependsOn)` MSBuild properties so that
when the `$(CreateVsixContainer)` MSBuild property is False -- the
default -- no `.vsix` package will be created, and `xbuild` will be
able to build the project.

Similar needle threading is needed to "support" building on Linux: the
Microsoft.VSSDK.BuildTools NuGet package uses case in an inconsistent
fashion -- or is it `nuget`? -- which results in
[failures when building on Linux][2] because `nuget` extracts e.g.:

	packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/vssdk/Microsoft.VsSDK.targets

while Microsoft.VSSDK.BuildTools attempts to `<Import/>` the file:

	packages/Microsoft.VSSDK.BuildTools.15.0.26201/tools/VSSDK/Microsoft.VsSDK.targets

`vssdk` != `VSSDK` on case-sensitive filesystems, so this results in
an error on Ubuntu (and presumably case-senstive macOS as well).

Handle the Linux case by extending the `xbuild` case: *even when*
`$(CreateVsixContainer)` is True, we won't actually build the `.vsix`
unless the `$(VsSDKInstall)` directory exists, which is the
`tools/VSSDK` path.

Building with `$(CreateVsixContainer)` set to True will require using
`msbuild` with `MONO_IOMAP=all` and `MONO_OPPTIONS=--arch=64`
exported, while using a case-insensitive filesystem.

The new `make create-vsix CONFIGURATIONS=Debug` target can be used to
explicitly create the `Xamarin.Android.Sdk*.vsix` file.

One problem with creating `.vsix` files: macOS still defaults to using
a 32-bit process for `mono`, and `make create-vsix` regularly fails
for me with an `OutOfMemoryException` when attempting to generate a
`.vsix` file ~600-700+MB in size. (Why so large? In part because for
Debug configuration we're including un-`strip`'d native libraries;
`libmonosgen-2.0.dll` is *237MB* in size (!); it's closer to 5MB when
`strip`'d, but any un-`strip`'d MXE-generated native libraries to the
`.vsix` file quickly results in `OutOfMemoryException`s.)

A 64-bit mono can be used by using `mono64` -- which isn't easily done
with `msbuild` -- or by using `mono --arch=64`, which *can* be done
with `msbuild` by exporting `MONO_OPTIONS=--arch=64`.
The `make create-vsix` target does this.

Finally, once we have a `.visx` being created, we then examine the
*contents* of the `.vsix` file, which is...weird:

	$MSBuild/Xamarin/Android/Xamarin.Android.CSharp.targets	                                          # Desirable
	$ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Xamarin.Android.CSharp.targets          # wat?
	$ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v1.0/Facades/Xamarin.Android.CSharp.targets  # really?!
	$ReferenceAssemblies/Microsoft/Framework/MonoAndroid/v7.1/Xamarin.Android.CSharp.targets          # !!!!

Turns Out™, the problem was due to `@(ProjectReference)`. We're
(ab)using `@(ProjectReference)` to explicitly specify project
dependencies, and the (implicit) project build order.

Unexpectedly (forgetten?), MSBuild *also* copies the *outputs* of
`@(ProjectReference)`s into the `$(OutputPath)` of the current
project.

Since e.g. `Mono.Posix.csproj` had a reference on
`Xamarin.Android.Build.Tasks.csproj`, the result of this is that the
`$(OutputPath)` of `Mono.Posix.csproj` --
`$prefix/lib/xbuild-frameworks/MonoAndroid/v1.0` -- also contained the
`%(None.CopyToOutputDirectory)` items from
`Xamarin.Android.Build.Tasks.csproj`.

Oops.

The fix is to set `%(ProjectReference.Private)` to False, which
disables this copying of additional and undesirable files.

[0]: https://msdn.microsoft.com/en-us/library/dd997148.aspx
[1]: https://www.nuget.org/packages/Microsoft.VSSDK.BuildTools/
[2]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-anroid-linux-pr-builder/297/consoleText
[^3]: But for how much longer?
2017-04-05 11:49:37 -04:00
Dean Ellis 44374e5161 [Xamarin.Android.Build.Tests] Move tests into a Shared Project so they can be reused upstream. (#506)
Rather than have all the msbuild tests in an assembly this commit
moves them into a shared project. This means the source code for
the tests can be easily reused upstream. It also means we can make
use of things like partial classes to change the tests depending on
which repo we are running them from. For example having tests in this
repo only run in Release mode but have both Release and Debug upstream.
2017-03-20 12:05:23 -04:00
Atsushi Eno f36ddd0023 [javadoc2mdoc] import javadoc-to-mdoc from monodroid/fbb0c9d (#500)
... with some changes:

- It turned out that we don't have Ionic.Zip, so it is replaced with
  LibZipSharp (with new entry removal methods thanks to grendel).
- We don't import README.samples that indicates some internals.

javadoc-to-mdoc is a tool that converts Javadocs or DroidDocs into
monodoc format. Then it can be converted to C# docs (csc /doc) or HTML
using "mdoc" tool in mono (we also build and ship it within `lib/mandroid`).
2017-03-17 14:18:55 -04:00
Atsushi Eno 762f313759 [api-xml-adjuster] move from tools to build-tools (#485)
It is build-time tool and should not be used in any production environment.
2017-03-15 09:46:20 -04:00
Jonathan Pryor 59aff45628 [Xamarin.Android.Build.Tasks] Use GPL'd ProGuard (#386)
**Background**: many Android SDK features rely on [ProGuard][0], a
Java bytecode manipulation library. Some of these features include
linking (shrinking) bytecode and [multidex][1].

Xamarin.Android has historically relied on the version of ProGuard
bundled with the Android SDK, which is how the `<Proguard/>` task and
`@(ProguardConfiguration)` build actions work.

Unfortunately, the version of ProGuard bundled with the Android SDK
is, at this point, *ancient* (ProGuard v4.7; current version is v5.3),
and (more importantly) ProGuard v4.7 doesn't support JDK 1.8 bytecode.

Meaning if the end-developer references a Java library targeting
JDK 1.8 -- e.g. the Android Support Library v25 -- then the version of
ProGuard bundled with the Android SDK *cannot process that library*.
This in turn means that the `<Proguard/>` task and
`@(ProguardConfiguration)` build actions don't work/are useless.

Native Java development "works around" this problem by using Gradle as
the build system, and Java projects are configured to download and
install a newer version of ProGuard via Gradle.

Xamarin.Android projects do not use Gradle, nor will they.
(At least not in the foreseeable future.)

**Solution**: We have communicated with Eric Lafortune, maintainer of
ProGuard, about distributing a newer ProGuard with Xamarin.Android.
He replied:

> From a licensing point of view, you shouldn't need an exception to
> the GPL in many practical configurations:
>
> * if you indeed run ProGuard in a separate JVM

The `<Proguard/>` task is a [`ToolTask`][2], which operates by
creating a new process to invoke the specified tool. We thus are
*already* using ProGuard within a "separate JVM", and no architectural
change is required to comply with ProGuard's licensing without
altering Xamarin.Android's licensing.

The current ProGuard sources (v5.3.2) have been imported into the
[xamarin/proguard][3] module, and we will be using the
`xamarin/proguard` module as a git submodule for build purposes.

[0]: https://www.guardsquare.com/en/proguard
[1]: https://developer.android.com/studio/build/multidex.html
[2]: https://msdn.microsoft.com/en-us/library/microsoft.build.utilities.tooltask.aspx
[3]: http://github.com/xamarin/proguard/
2017-03-07 00:00:36 +09:00
Jonathan Pryor 54a7a0299e [build] Auto-Provision Dependencies (#447)
The #runtime team is requesting that Xamarin.Android support
"auto-provisioning": the ability to track dependency *versions*, and
if there is a "version mismatch", *install* a dependency that
satisfies the minimum.

The primary use case is Mono itself: there is a desire to build
xamarin-android *itself* against mono/master, to see what breaks.
(Does the C# compiler break things? Does the JIT hang? etc.)

Extend the existing `@(RequiredProgram)` infrastructure to attempt to
support this:

* `%(RequiredProgram.MinimumVersion)`: The minimum program version
    that is supported.
* `%(RequiredProgram.MaximumVersion)`: The maximum program version
    that is supported.
* `%(RequiredProgram.CurrentVersionCommand)`: A command to execute to
    obtain the current program version.
    Defaults to `%(RequiredProgram.Identity) --version`.
* `%(RequiredProgram.MinimumUrl)`: URL to download "something" to use
    to obtain a version of the program that satisfies
    `%(MinimumVersion)`.
* `%(RequiredProgram.Install)`: Command to execute which installs the
    minimum version of the program.

`%(RequiredProgram.CurrentVersionCommand)`,
`%(RequiredProgram.MinimumUrl)`, and `%(RequiredProgram.Install)` can
all be "overridden" for platform-specific values by prefixing the
value with `$(HostOSName)` and/or `$(HostOS)`. Thus, macOS-specific
values can be stored into e.g. `%(RequiredProgram.DarwinMinimumUrl)`
and `%(RequiredProgram.DarwinInstall)`.

Auto-Provisioning is controlled by the new `$(AutoProvision)`
property, which can be provided in `Configuration.Override.props`.
It defaults to `False`.

If the `$(AutoProvisionUsesSudo)` MSBuild property is True, then
`sudo` is used to invoke all install commands.
2017-02-16 17:37:28 +01:00
Radek Doulik 1f22353504 [remap-assembly-ref] Properly add to the XA solution (#351)
- the platform was set to x86 only

 - the project was defined, but not added to the solution tree
2017-01-05 13:20:50 -05:00
Radek Doulik 5a8e48eba8 Import remap-assembly-ref tool from monodroid/9c345513 (#348)
Context: https://github.com/xamarin/xamarin-android/pull/341

`remap-assembly-ref` is utility which changes assembly references.
For example, consider `mdoc.exe`:

	$ monodis --assemblyref bin/Debug/lib/mandroid-internal/mdoc.exe
	AssemblyRef Table
	...
	4: Version=0.10.0.0
		Name=Mono.Cecil
		Flags=0x00000000
		Public Key:
	...

By policy, we *don't* want to reference `Mono.Cecil.dll`, because in
times past all IDE add-ins would be loaded into the same process, and
if an assembly wasn't strong-named -- `Mono.Cecil.dll` isn't --
then all references to `Mono.Cecil.dll` would resolve to the same
file, even if used from different add-ins which expected different
Cecil versions, and things would break in horrific ways.

Lots of hair-pulling ensued, and our response was to "vendorize"
Cecil into [`Xamarin.Android.Cecil`][0], which is just Mono.Cecil
with a different assembly name.

However, we didn't want to have to rebuild everything from source
"just because" the assembly name changed, and `mdoc.exe` is such an
assembly. It's built as part of mono, references `Mono.Cecil.dll`,
and we need it to instead reference `Xamarin.Android.Cecil.dll`.

Enter `remap-assembly-ref.exe`:

	$ mono bin/BuildDebug/remap-assembly-ref.exe
	Usage: <input assembly filename> <output assembly filename> <source assembly ref> <target assembly>

`remap-assembly-ref.exe` will read `<input assembly filename>`, alter
all references to `<source assembly ref>` to the name and version
information contained in `<target assembly>`, and write the modified
assembly to `<output assembly filename>`:

	$ mono bin/BuildDebug/remap-assembly-ref.exe  \
		bin/Debug/lib/mandroid-internal/mdoc.exe    \
		bin/Debug/lib/mandroid/mdoc.exe             \
		"Mono.Cecil"                                \
		bin/Debug/lib/mandroid/Xamarin.Android.Cecil.dll
	
	# Behold, altered assembly name reference!
	$ monodis --assemblyref bin/Debug/lib/mandroid/mdoc.exe
	...
	4: Version=0.10.0.0
		Name=Xamarin.Android.Cecil
		Flags=0x00000001
		Public Key:
	0x00000000: 00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00 
	...

*Note*: `remap-assembly-ref.exe` is *brittle*. It does no validation
that the types and members referenced from `<source assembly ref>`
actually exist in `<target assembly>`, so it's entirely possible
that the resulting assembly *will not work*.

[0]: https://github.com/xamarin/java.interop/tree/master/src/Xamarin.Android.Cecil
2017-01-04 12:45:58 -05:00
Radek Doulik cdb6ab112c Bump to Java.Interop/f44a11f6 and use its Cecil library (#303)
Updated all the projects to use the `Xamarin.Android.Cecil` library
instead of `Mono.Cecil` nuget package.
2016-11-18 10:04:49 -05:00
Jonathan Pryor 2956811709 [xa-prep-tasks] Use the Mono bundle (#162)
Context: fbfd676c10

Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.

This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:

What should download the mono bundle?

There are two plausible answers:

1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.

Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)

Which brings us to MSBuild (2): can it handle the task?

To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.

The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`

Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.

With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.

Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.

One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.

Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 16:02:48 -04:00
Jonathan Pryor fbfd676c10 [bundle] Add `CreateBundle` target. (#140)
Building Mono on Windows is a PITA, and commit 0c073f67 added support
to cross-compile Mono for Windows so that Mono could be built from
macOS or Linux.

The unstated goal of that work was to -- eventually -- build the Mono
runtimes *for Windows* on e.g. macOS, *bundle* those runtimes, and
then we could update the build process to *download* a pre-built
bundle of mono runtimes so that we can ~sanely build xamarin-android
on Windows without building *Mono* on Windows.

Part Two of this cunning plan involves creating the bundle of built
mono runtimes. This in turn got rather complicated because instead of
doing the *simple* thing of invoking **zip**(1), I instead wanted to
create and use a `<Zip/>` MSBuild task, as this would allow us to
specify in one place -- `mono-runtimes.targets` -- which files should
be bundled, instead of bundling e.g. everything in `bin/Debug`, which
would grab considerably more than just the mono bits.

Adding a `<Zip/>` task in turn involves determining which Zip
implementation to use, and what assembly to put it in; the obvious
answer is to use `libzip`/`libZipSharp.dll` and place it into
`Xamarin.Android.Tools.BootstrapTasks.dll` -- which is how we did it
-- but this answer was tricky, due to a circular dependency problem:
`libzip.mdproj` depends on `android-runtimes.mdproj` which depends on
`Xamarin.Android.Tools.BootstrapTasks.dll`. Consequently, adding
`libzip.mdproj` as a dependency to
`Xamarin.Android.Tools.BootstrapTasks.dll` *doesn't work*.

(Question: Why use libzip? Why not use System.IO.Compression?
Answer: Because I'd like to be able to update the
`<UnzipDirectoryChildren/>` task to use `libzip` instead of
"shelling out" to **zip**(1) *like an animal*.)

Step 1 is removing the circular dependency. `libzip.mdproj` depends on
`android-runtimes.mdproj` because of MXE: `android-runtimes.mdproj`
configures the MXE build environment to generate a Windows
`libzip.dll` native library, if needed.

The fix: introduce a new `libzip-windows.mdproj` project which
performs the MXE-based build. This allows `libzip.mdproj` to no longer
depend on `android-runtimes.mdproj`; `libzip-windows.mdproj` does.
This also involves "refactoring" `libzip.mdproj` so that the build
logic can be shared with `libzip-windows.mdproj`.

Additionally, improve `libzip.mdproj` so that the native libraries are
also set as a `@(Content)` build action. This allows e.g.
`libzip.3.0.dylib` to be properly copied into `bin/BuildDebug`, as
that's the `$(OutputPath)` of
`Xamarin.Android.Tools.BootstrapTasks.csproj`.

Step 2 is adding `libZipSharp.csproj` as a `@(ProjectReference)` to
`Xamarin.Android.Tools.BootstrapTasks.csproj`. This requires bumping
`Xamarin.Android.Tools.BootstrapTasks.csproj` to target .NET 4.5.1,
which allows us to add the new `<Zip/>` task, as well as a new
`<GitCommit/>` task (so we can determine the abbreviated commit hash
of the mono checkout, for encoding into the filename).

Step 3 is updating `mono-runtimes.targets` so that the Windows
cross-compilers are built into `bin/$(Configuration)/lib/mandroid`,
as this matches what is currently done internally.

Step 4 is adding a new `build-tools/bundle.mdproj` project with a
`CreateBundle` targtet, which will create the file:

	$(OutputPath)\bundle-$(Configuration)-libzip=$(libzip-hash),llvm=$(llvm-hash),mono=$(mono-hash).zip`.

Uploading the `bundle-*.zip` files will be handled by Jenkins as a
post-build task.

Not yet done: *using* `bundle-*.zip` so that mono/etc. builds can be
skipped, *greatly* improving build times.
2016-08-10 22:28:53 +01:00
Jonathan Pryor 6805d2042c [Xamarin.Android-Tests] Split out "full" apps (#146)
We're trying to get [`make jenkins`][0] working on Jenkins, and
[it's failing][1], as one might expect when a particular repo and
associated build system has never been run on Jenkins before:

	Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference?

This error occurs while building
`src/Mono.Android/Test/Mono.Android-Tests.csproj`, and happens because
the `Xamarin.Android.NUnitLite.dll` assembly isn't referenced...
because it isn't *found*:

	Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved

This returns us to a long-standing issue which I thought was mentioned
in a commit somewhere, but I can't find at present:

MSBuild doesn't support updating the assembly resolution directories
*while MSBuild is running*.

For example, we build `Xamarin.Android.NUniteLite.dll` into
`bin/$(Configuration/lib/xbuild-frameworks/MonoAndroid/v1.0`,
but "normal Xamarin.Android referencing projects" don't use a
`@(ProjectReference)` to `Xamarin.Android.NUnitLite.csproj`, but
instead a `@(Reference)` to the assembly:

	<!-- src/Mono.Android/Test/Mono.Android-Tests.csproj -->
	<Reference Include="Xamarin.Android.NUnitLite" />

The *requirement* for a "proper" Xamarin.Android SDK install is that
`Xamarin.Android.NUnitLite.dll` can be found through a normal
`@(Reference)`. In order to satisfy this requirement, we need to tell
MSBuild where to find it, which can be with `xbuild` via the
`$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH`
*environment variables*.

*Environment variables*.

MSBuild doesn't provide a way to update environment variables, short
of writing a new Task which calls
`Environment.SetEnvironmentVariable()`, and while [this works][2], it
doesn't *actually* work [^3].

The short of all this is that it isn't possible,
*within a single `xbuild` invocation*, to both build the
Xamarin.Android SDK "environment" *and use that environment* as
intended for "normal" apps.

The fix, as is often the case, is to bend with the wind. Instead of
requiring the impossible, move
`src/Mono.Android/Test/Mono.Android-Tests.csproj` into a *new*
`Xamarin.Android-Tests.sln` solution, *out of* `Xamarin.Android.sln`.
This allows building `Xamarin.Android.sln` without error in a pristine
environment -- that is, one that doesn't already have a system-wide
Xamarin.Android install -- and separately building the tests by using
`tools/scripts/xabuild`, which *can* export environment variables to
manipulate `xbuild` behavior so that things Just Work™.

Building `Mono.Android-Tests.csproj` and similar projects
(`HelloWorld.csproj`!) can be done by using the new `make all-tests`
make target.

[0]: a16673d3eb
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/20/console
[2]: https://github.com/xamarin/xamarin-android/pull/147
[^3]: [PR #147][2] isn't viable because of [xbuild's `AsssemblyResolver`][4].
    There's no way to clear/invalidate `target_framework_cache`.

    The idea of PR #147 was to "hack things up" so that
    `Xamarin.Android.NuniteLite.dll` would be properly resolved during
    the build of `Mono.Android-Tests.csproj` *when building everything*.

    The problem is *this can't work*, because `xbuild` has a
    "target framework cache," with no way to invalidate it, and the
    cache is populated the first time the target framework is used.
    Due to build ordering issues, this first use is *before*
    `Xamarin.Android.NunitLite.dll` was built, and thus it doesn't
    exist in the cache. The result:

        Task "ResolveAssemblyReference"
            ....
            TargetFrameworkDirectories:
                /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0
                /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0
                /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/
            ...
            Primary Reference System.Xml
                Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False
            ...
            Primary Reference Xamarin.Android.NUnitLite
        Microsoft.Common.targets:  warning : Reference 'Xamarin.Android.NUnitLite' not resolved
            For searchpath {TargetFrameworkDirectory}
            Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found.
            Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found.
            Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found.
        ...

    Consequently, the `mcs` invocation is missing a
    `/reference:path/to/Xamarin.Android.NUniteLite.dll`, and
    compilation fails:

        Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference?
        ...plus 29 others...

[4]: https://github.com/mono/mono/blob/dd8aadf/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/AssemblyResolver.cs#L131
2016-08-08 16:46:13 -04:00
Atsushi Eno ff1c80d296 Reorganize Xamarin.Android.NamingCustomAttributes. (#139)
context: https://github.com/xamarin/java.interop/issues/58
dependent on: https://github.com/atsushieno/java.interop/commit/5583d26

Copypasting the changes on Java.Interop

	We have complicated module interdependency between this and xamarin-android,
	so this set of changes is to fix the situation.

	So far, here is the changeset summary:

	- Xamarin.Android.NamingCustomAttributes.shproj is moved to xamarin-android
	- there will be new Java.Interop.NamingCustomAttributes.shproj which is for
	  use in this repository. It will be shrinked in the later commits to have
	  only required bits in Java/Interop.

Now Xamarin.Android.sln has two NamingCustomAttributes.shproj: one for
imported and then slightly stripped version of the original shared project
in xamarin-android, and renamed and then significantly stripped version
in Java.Interop.

Build adjustment comes next.
2016-08-08 10:50:37 -04:00
Jonathan Pryor a16673d3eb [build] Add `make jenkins` target. (#116)
The `make jenkins` [^0] target is for use by Continuous Integration
machines, to build *everything* [^1].

This is expected to take an eternity. Think *hours*.

	$ time make jenkins
	...
	real	130m11.608s
	user	97m22.220s
	sys	18m20.522s

Of particular note is that the above "everything" includes
*Release configuration builds* of everything, which is something that
didn't actually work before. (Oops.)

Bump Java.Interop so that it supports building the Release
configuration, update Xamarin.Android.sln so that all required
projects are part of the Release configuration, and update
Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't
defined, as this was preventing compilation.

Fix **strip**(1) use: `mono-runtimes.targets` was trying to use
`strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was
quoted, and thus attempted to execute `"strip -S" ...`, which failed.
Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value.

Fixup `mono-runtimes.targets` and related files so that
`$(MonoSourceFullPath)` is used instead of a relative path. This helps
alleviate the "mental math" of determining the relative path to the
Mono checkout. Plus, the Mono checkout is supposed to be overridable,
e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that.

Download and install `android.jar` for all supported API levels.

Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is
stored in a per-API-level intermediate directory. Otherwise, if e.g.
API-10 is built after API-23, the API-23 version will be installed,
but the JCW build will fail. Additionally, API-24 requires using
`javac -source 1.8 -target 1.8`, not 1.6.

Fix `Mono.Android/metadata` to use the correct `merge.SourceFile`
filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't
build because `NumericShaper.GetContextualShaper()` is emitted twice,
and the C# compiler doesn't like that.

Disable use of `-lz` when building for Windows. Windows doesn't
contain a `Z.DLL` to link against.

[^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins
[^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 14:42:39 +02:00
Jonathan Pryor f48e55563b [System.Drawing.Primitives] Add System.Drawing.Primitives.dll Facade (#121)
Xamarin.Android needs to support [.NET Standard 1.6][0], which
mentions a [`System.Drawing.Primitives.dll` assembly][1] which has not
previously been supported or shipped.

`System.Drawing.Primitives.dll` contains `System.Drawing.Point` and
related typees, which Xamarin.Android places into `Mono.Android.dll`.

Add a new `System.Drawing.Primitives.dll` assembly to use as a
*facade assembly*, which contains [type forwarders][2] to
"redirect" the types from `System.Drawing.Primitives.dll` to the
corresponding types within `Mono.Android.dll`.

[0]: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries
[1]: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version
[2]: https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx
2016-07-15 16:42:03 -04:00
Marek Habersack 5bb1cfbb18 Fix line endings 2016-07-06 17:09:45 +02:00
Dean Ellis f3d62b6168 [Xamarin.Android.Build.Tasks] Use libZipSharp to build the .apk (#89)
Commit 4ec06ac9 *broke* generation of `.apk` files when migrating
from `Ionic.Zip.dll` to `System.IO.Compression` because this:

	apk.AddFile (assembly.ItemSpec, "assemblies", compressionLevel: CompressionLevel.NoCompression);

doesn't work the way we thought/hoped it would.

Specifically, we require that assemblies be *stored*, uncompressed,
within the `.apk`, as we **mmap**(2) the `.apk` and hand off the
memory addresses of the loaded assemblies to mono for execution.

`CompressionLevel.NoCompression`, despite saying "no compression",
does *not* mean "store". It means "add the file 'normally', but tell
`DeflateStream` to use 'no compression'."

The result is that the zip entry doesn't say it's stored:

	$ unzip -lv bin/Debug/*-Signed.apk | grep assemblies/
		 64512  Defl:N    64512  67%  06-16-16 10:38  6d65706b  assemblies/Scratch.DebugRelease.dll

Which in turn means that the resulting `.apk` is *unusable*.

The fix? `System.IO.Compression` can't be used for this, and
`Ionic.Zip.dll` had other problems (why we tried to use
`System.IO.Compression` in the first place!), so instead we'll
use [libZip][0] and [LibZipSharp][1] to handle `.apk` files.
libzip is a well-maintained OSS library for manipulating zip files,
and LibZipSharp is a C# wrapper around libzip.

Add libzip and LibZipSharp to the build system so that they're
available on required paltforms, and update the `BuildApk` and
related tasks to use LibZipSharp instead of System.IO.Compression.
This allows assemblies to be properly stored in the `.apk`,
allowing apps to execute as intended.

	$ unzip -lv bin/Debug/*-Signed.apk | grep assembl
		 64512  Stored    64512   0%  06-29-16 08:31  6d65706b  assemblies/Scratch.DebugRelease.dll

[0]: http://www.nih.at/libzip/
[1]: https://github.com/grendello/LibZipSharp/
2016-06-29 08:33:38 -04:00
Marek Habersack 4c464d6211 [OpenTK-1.0] Add OpenTK 1.0 to the build (#85)
OpenTK sources are built using our own project file in order to leave
the upstream sources untouched. Only OpenTK 1.0 is provided in hope that
nobody is interested in 0.9 anymore :) For this reason compilation items
are placed in a separate project file. It also makes it easier to share
the "wrapper" project file for different versions of the library.

A new configuration property is added, $(OpenTKSourceDirectory), which,
surprisingly, points to the OpenTK submodule directory.
2016-06-20 11:06:58 -04:00
Jonathan Pryor 6bb10160fb [build] Allow building with `msbuild`. (#74)
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
2016-06-15 13:05:59 +02:00
Jonathan Pryor 09b4ca39e2 [Mono.Data.Sqlite] Import from monodroid/6a8eb978. (#70)
Import `Mono.Data.Sqlite.dll` from monodroid/6a8eb978.

`Mono.Data.Sqlite.dll` needs to embed a version of SQLite because
Android N will only support allow using native libraries which are
[part of the Android NDK or are distributed with the application][0].
Consequently, the only way that `Mono.Data.Sqlite.dll` can be used is
if SQLite is "somehow" included within all apps which use
`Mono.Data.Sqlite.dll`, and the easiest way to do that is to compile
SQLite, naming the library `libsqlite3_xamarin.so` (for uniqueness),
and making use of the [`@(EmbeddedNativeLibrary)` build action][1].

[0]: https://web.archive.org/web/20160401151536/http://developer.android.com/preview/behavior-changes.html?utm_campaign=android_launch_n_030916&utm_source=anddev&utm_medium=blog#ndk
[1]: https://developer.xamarin.com/guides/android/under_the_hood/build_process/#AndroidNativeLibrary
2016-06-09 17:03:31 -04:00
Jonathan Pryor daddcdf34f [Xamarin.Android.Build.Tasks] Ensure `class-parse` is built first (#66)
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`.
2016-06-09 18:55:44 +08:00
Atsushi Eno 41bbf80aac [Xamarin.Android.Build.Utilities] Check for generator (#49)
Fix monodroid SDK detection that depended on non-existent file.
We don't build DebugRuntime apk in this new source set anymore, so
do not look for the file in our SDK sanity checker.

Additional warning logs are added because, we should do that.
(Otherwise we will keep ignorant of the actual cause of the
problem forever.)
2016-06-02 22:34:58 -04:00
Jonathan Pryor 877d88da7f [System.EnterpriseServices] Import from monodroid/84a3e6cb (#53)
System.EnterpriseServices.dll is an empty shell. It contains no types.
It isn't *directly* used by *anything*.

The entire reason it exists is so that Visual Studio (2010?)-
generated Web Services would compile, as the generated project would
contain an assembly reference to System.EnterpriseServices.dll, even
though that assembly wasn't actually *used*.

I suspect that this thread is relevant:

	http://lists.ximian.com/pipermail/monodroid/2010-October/001398.html

> I had the same problem, I fixed it by removing the reference to
> System.EnterpriseServices.dll.  That assembly isn't in MonoDroid P5
> and it falls back to your GAC to find it which causes chaos later.
2016-06-01 23:35:10 +02:00
Marek Habersack d1bf26459c [Mono.Posix] Import from monodroid/8974297a (#51)
Import monodroid/src/Mono.Posix from monodroid/8974297a
2016-05-30 11:57:48 -04:00
Jonathan Pryor 1b3a76c687 [Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32)
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.
2016-05-16 19:55:13 +01:00
Dean Ellis 7634c6d4dc [Xamarin.Android.Build.Tasks] First Pass at adding Unit tests for the MSBuild Tasks (#26)
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.
2016-05-12 14:54:03 -04:00
Jonathan Pryor 8b0d145b6e [Xamarin.Android.NUnitLite] Import from monodroid/ae417a99 (#13)
Xamarin.Android.NUnitLite is a copy of NUnitLite, modified for use
with Xamarin.Android and to provide a Xamarin.Android test runner GUI.
2016-05-10 14:27:12 +01:00
Marek Habersack e9754b854c Remove the sample from solution for now
It breaks Linux build currently. It will be restored once we figure
out what happens
2016-05-06 21:19:23 +02:00
Jonathan Pryor 461cc83d99 [samples/HelloWorld] Add Hello World sample. (#19)
Update README.md to describe how to build, install, and run the sample.
2016-05-04 19:40:41 +01:00
Jonathan Pryor b064237634 [Xamarin.Android.Tools.Aidl] Rename from Xamarin.AndroidTools.Aidl
Rename Xamarin.AndroidTools.Aidl to Xamarin.Android.Tools.Aidl, for
consistency with the other assemblies.
2016-04-26 23:03:52 -04:00
Ankit Jain ff1fc7c2c2 Fix top level build
- Xamarin.Android.sln: Disable Java.Interop build from here. It is built
  from _BuildJavaInterop target

- Mono.Android.csproj: Add a ProjectReference to mono-runtimes project,
  but don't *use* the reference. We just need it be built before
  Mono.Android, so that we can resolve against the built mscorlib and
  friends here.

- Mono.Android.targets: Mono.Android build was failing because it could
  not find the referenced Java.Interop.dll in ResolveAssemblyReferences.
  This was because _BuildJavaInterop was set to build
  `BeforeTargets=ResolveReferences`. But the *real* resolution of
  references is done in targets defined in `ResolveReferencesDependsOn`.
  And that runs *before* the `BeforeTargets`! Which means that
  _BuildJavaInterop was running too late!

  Solution: `BeforeTargets=BeforeResolveReferences` - JonP !
2016-04-25 12:51:44 -04:00
Dean Ellis 59ec488b40 [Xamarin.Android.Build.Tasks] Import from monodroid/301e7238
Added Xamarin.Android.Build.Tasks and its supporting Libraries.
Code has also been updated to make uses of the new libraries in
the Java.Interop repository

Note : Xamarin.Android.Build.Tasks has a compile time code
generation step which generates Profile.g.cs. This file contains
the list of SharedRuntimeAssemblies. If building manually you will
need to make sure that Xamarin.Android.Tools.BootstrapTasks is
built first.
2016-04-25 17:06:36 +01:00
Jonathan Pryor a549be3404 [api-xml-adjuster] Import from monodroid/301e7238
api-xml-adjuster is a tool to update API XML descriptions.
2016-04-24 18:58:57 -04:00
Jonathan Pryor 77702e220c [monodroid] Properly add the project to Xamarin.Android.sln. 2016-04-24 18:34:04 -04:00
Jonathan Pryor b6782e4071 [monodroid] Import from monodroid/301e7238
Import libmonodroid.so source.

libmonodroid.so is responsible for initializing the mono runtime and
assisting in glueing Android and mono together.
2016-04-24 18:26:49 -04:00
Jonathan Pryor 6defb3f128 Add the projects in cd6a777f to a Tools solution folder 2016-04-23 08:09:27 -04:00
Ankit Jain cd6a777f68 Xamarin.Android.sln: Add required projects from external/Java.Interop
This is required because of a bug in xbuild. It tries to look for the
Java.Interop projects which are referenced from the other projects, in
the sln itself, because it needs to figure out a build order for *all*
the projects. It should probably allow projects not being present in sln
and build them via the reference.
2016-04-22 18:03:20 -04:00
Jonathan Pryor d92a49d56a [Mono.Android.Export] Import from monodroid/d393f359
Mono.Android.Export.dll is used at runtime to support `[Export]
methods, allowing the declaration of methods in C# code that Java code
can invoke that *doesn't* involve using bindings of pre-existing
Java types.

See also:

https://developer.xamarin.com/releases/android/mono_for_android_4/mono_for_android_4.2/#Exporting_arbitrary_Java_member_for_better_Java_integration
https://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/working_with_jni/#ExportAttribute_and_ExportFieldAttribute
2016-04-21 17:39:36 -04:00
Jonathan Pryor cbcb9037da Remove the 'Debug|x86' and 'Release|x86' configurations.
These configurations aren't necessary.
2016-04-21 14:20:05 -04:00
Jonathan Pryor a073d99a83 [api-merge] Import from monodroid/3e934261.
`api-merge` is a tool to support emitting *forward compatible*
binding assemblies.

Way back in the dark days before Mono for Android 4.2, a binding
assembly was only backward compatible: if Mono.Android.dll was
targeting API-8, the resulting app could run on API-8 *and later*.

The opposite was *not* true: you *might not* be able to use
Mono.Android.dll for API-10 and run it on an API-8 device.
This is *forward compatibility*, the ability for "a system" to accept
"input" intended for a later version [0].

*Java* apps were forward compatible. Mono for Android prior to 4.2
did *not* generate forward compatible apps.

The reason why was that a binding assembly directly bound what was in
the specified API level [1], so if a member "moved" in a
*backward compatible* manner -- moving
android.view.MotionEvent.getDeviceId() to the newly introduced
android.view.InputEvent base class -- it would not be
*forward compatible* for the binding assemblies we emitted, as the
e.g. API-10 binding assembly would attempt to resolve the type
android.view.InputEvent, which didn't exist in API-8, and would result
in an exception.

`api-merge` was the fix: instead of a Mono.Android.dll targeting a
*specific* API level, it would instead take the API descriptions for
the target API level *and all prior API levels*. It would thus have
enough information to track member "movements", and with a bit of
Java.Interop/tools/generator "magic" forward compatibility was
provided starting in Mono for Android 4.2 [2].

[0]: https://en.wikipedia.org/wiki/Forward_compatibility
[1]: http://lists.ximian.com/pipermail/monodroid/2011-November/007350.html
[2]: https://developer.xamarin.com/releases/android/mono_for_android_4/mono_for_android_4.2/#Improved_API_level_support
2016-04-20 22:09:19 -04:00
Jonathan Pryor 5777337e78 [Mono.Android] Import from monodroid/3e934261
(*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.
2016-04-20 21:32:05 -04:00
Jonathan Pryor b3dca00062 [jnienv-gen] Import jnienv-gen from monodroid/c3f7a887
jnienv-gen.exe is used to generate a partial class declaration for
Android.Runtime.JNIEnv.

It will be needed to generate and build Mono.Android.dll.
2016-04-19 22:28:16 -04:00
Jonathan Pryor 38dbfcaf4c [mono-runtimes] Build required mono runtimes.
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.
2016-04-19 21:41:36 -04:00
Jonathan Pryor 6fd330dfdd [android-toolchain] Permit zero-configuration builds.
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.
2016-04-18 21:08:18 -04:00
Jonathan Pryor 7ecbb12008 Initial commit. 2016-04-15 16:56:25 -04:00