- Needed to `nuget restore Xamarin.Android-Tests.sln`
- Added `$(XAIntegratedTests)` property which defaults to True.
Windows will need to set this property in order to build
`Xamarin.Android-Tests.sln`
- Some project references in `Mono.Android-Tests.csproj` should
be conditional against `$(XAIntegratedTests)`==True
- Usage of `zip -r` is replaced with `jar cf` using `$(JarPath)`
(Windows doesn't have `zip`)
- `Xamarin.Android.Build.Tasks.csproj` had a file-locking issue
similar to `create-vsix.csproj` (2bca09d1): the
`_GenerateXACommonProps` target needs to depend on `ResolveReferences`
Other changes:
- Update README
- Update .gitignore for `.gradle/` and `*.user` files
Windows machines do not include `java` in their path by default, so it is
a better experience to not require it for the build.
Changes to make this happen:
- `$(JavaCPath)` and `$(JarPath)` are configured in
`Configuration.OperatingSystem.props`
- Usage of `javac` and `jar` across the repo use appropriate
variables now
- `generate-os-info` needs to set `$(JavaCPath)` and `$(JarPath)`
- Created a new `<Ant>` MSBuild task
- A couple places, Windows needs `%JAVA_HOME%` to be set, so we
are doing this via `Environment.SetEnvironmentVariable()` in the
`<AcceptAndroidSdkLicenses/>` and `<Ant/>` tasks.
- `Configuration.OperatingSystem.props` is conditional, so it is
possible to build xa-prep-tasks without it
- `<Which/>` needs to accept files without extensions last for
Windows; `$PATHEXT` should be empty on Unix
Add `tests/Xamarin.Forms-Performance-Integration` to measure UI app
startup times.
Add a new `<RunUITests/>` task to start an app/activity.
Rename `@(UnitTestApk)` to `@(TestApk)`, as it also handles UI tests.
Update `<ProcessLogcatTiming/>` to be able to process the
`adb logcat` output of started Android Activity processes.
Checks for `Exists ('$(AndroidNdkDirectory)\ndk-build')` will not work
on Windows, since the file is named `ndk-build.cmd`.
To fix this, I created a new `NdkBuildPath` property to be used
throughout the build, which will have the correct value on Windows.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58303
Background: It is possible for a Java type to have
"aliasing bindings": two or more managed types which claim to bind
the same Java type:
// C#
namespace Android.Runtime {
[Register ("java/util/HashMap", DoNotRegisterAcw=true)]
partial class JavaDictionary {
}
}
namespace Java.Util {
[Register ("java/util/HashMap", DoNotRegisterAcw=true)]
partial class HashMap {
}
}
These can't be realistically forbidden.
Enter a new-to-bind Java type:
// Java
public class Bxc58383 extends java.util.HashMap implements java.util.Map {
}
In order to bind the above `Bxc58383` type, `generator` needs to
determine the appropriate binding type to use for `java.util.HashMap`.
`generator`'s approach to supporting aliasing types is (largely) to
ignore the problem (almost) entirely: There Can Be Only One™ mapping
from a Java type to a managed type, so `generator` needs to pick one.
It does so by using the *last* definition encountered in the assembly.
Consequently, for the above set of C# declarations, when `generator`
needs to find the managed type which binds `java.util.HashMap`,
`Java.Util.HashMap` will be chosen, as it is the last declared type.
Unfortunately, "real life" is a bit more complicated:
`Mono.Android.dll` is made up of *thousands* of files, and the order
of types within an assembly is a compiler implementation detail.
As such...the current `Mono.Android.dll` has `JavaDictionary` defined
*after* `HashMap`:
# output truncated for relevance
$ monodis --typedef bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.dll | grep 'Dictionary\|HashMap'
1270: Java.Util.Dictionary (flist=12611, mlist=29569, flags=0x100081, extends=0x20b8)
1287: Java.Util.HashMap (flist=12662, mlist=29806, flags=0x100001, extends=0x1388)
3992: Android.Runtime.JavaDictionary (flist=32135, mlist=85344, flags=0x100001, extends=0x20b8)
Because `JavaDictionary` is defined *after* `HashMap`, and both of
those types have `[Register]` attributes which declare that they bind
the *same* Java type, the result is that the binding of `Bxc58383` is
horrifically broken:
// C#
partial class Bxc58383 : global::Android.Runtime.JavaDictionary, global::Java.Util.IMap {
}
Unfortunately, `JavaDictionary` doesn't itself implement `IMap`, so:
error CS0535: 'Bxc58383' does not implement interface member 'IMap.ContainsKey(Object)'
along with 10 other related errors.
Update the `src/Mono.Android` build process so that `JavaDictionary`
and related types will be defined within `Mono.Android.dll` *before*
all the generated types. This allows `HashMap` to be defined last,
allowing `Bxc58383` to be bound without error:
# output truncated
$ monodis --typedef bin/Debug/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v7.1/Mono.Android.dll | grep 'Dictionary\|HashMap'
3703: Android.Runtime.JavaDictionary (flist=34089, mlist=78134, flags=0x100001, extends=0x4e08)
4170: Java.Util.Dictionary (flist=39685, mlist=91737, flags=0x100081, extends=0x4e08)
4187: Java.Util.HashMap (flist=39736, mlist=91974, flags=0x100001, extends=0x40d8)
This fixes a 'gradlew' failure which is encountered on Windows only. Unfortunately, the 'gradlew' invocation prefixes the 'sdk.dir' value read from 'local.properties' with the path of the working directory.
As a result, we encounter a failure along the following lines on Windows:
```
* What went wrong:
A problem occurred configuring project ':library'.
> The SDK directory 'C:\Users\xamarinqa\git\xamarin-android\tests\CodeGen-Binding\Xamarin.Android.LibraryProjectZip-LibBinding\java\JavaLib\C:Program Files (x86)Androidandroid-sdk' does not exist
```
This can be avoided by exporting ANDROID_HOME in the Exec portion of the BuildJavaLibs target, rather than writing this information to a file and expecting 'gradlew' to process it correctly.
Fix a [build][0] [break][1]:
Executing: ./gradlew assembleDebug --stacktrace
...
The android gradle plugin version 2.4.0-alpha3 is too old, please update to the latest version.
To override this check from the command line please set the ANDROID_DAILY_OVERRIDE environment variable to "ea6ce2cbbbfb0e0a68b85eb08916733d4367c4dd"
FAILURE: Build failed with an exception
For a change, this break on Jenkins wasn't *directly* caused by a
commit; it was *indirectly* caused by commit 571546a1, which specified
`com.android.tools.build:gradle:2.4.0-alpha3`.
Turns Out™, `gradle:2.4.0-alpha3` has a builtin "expiration date",
*presumably* of 2017-Apr-30, meaning that when you build after the
expiration date, it doesn't actually build.
The result is the above error from `gradlew assembleDebug`.
The fix? Don't use preview packages if they can be avoided. The
`gradle:2.3.0` package appears to work Just Fine™, with the added
benefit that it's *not* a preview package.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/371/
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/371/consoleText
First step towards support for Android-O Preview API.
The changes are big due to the structural changes in Android SDK,
particularly that "android" command line tool is gone and they had to
be rewritten. Samples that depended on "create" or "update" command
had to be checked in as already-created state so that they don't have
to bring further dependencies.
Changes in the library (Mono.Android) itself is not very big at all.
`src/Mono.Android/Profiles/api-O.xml.in` comes from API-O DP 1's
`android.jar`.
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=45203
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=47582
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=48588
In an ideal world, we'd use `class-parse` to parse `.jar` files when
producing binding assemblies, as `class-parse` is significantly better
and more reliable that `jar2xml`.
...then we hit the problem of "compatibility": there is a reasonable
expectation that currently existing projects will continue to build in
new product versions. It would anger developers if they upgraded
Xamarin.Android and then their binding projects no longer built.
Which is precisely what *will* happen if we change the default
`$(AndroidClassParser)` value to `class-parse`, as per
Bugs #45203, #47582, and #48588: `class-parse` does a much better job
at finding Java types and members, which means *more* types and
members are present in `class-parse` output (compared to `jar2xml`),
which means there's a higher likelihood of encountering `generator`
bugs. These bugs were likely previously worked around when using
`jar2xml`, but *requiring* that those same projects be fixed *again*
is a bridge too far.
Meaning `class-parse` needs to be an "opt-in" feature, not an
"opt-out" feature.
Change the default `$(AndroidClassParser)` value to `jar2xml` so that
existing projects continue to use `jar2xml` when binding.
We will update the default template for *new* projects to use
`class-parse` in the IDEs, so *new* projects will get improved
behavior.
Add a new `AndroidPrepareForBuild` target for unit test use.
Some of our unit tests dont need to build but do need to resolve
the android SDK and other properties. We did us the `_ValidateAndroidPackageProperties`
target to make sure all of the required properties were in place.
However commit 8337d21e altered the build process so that target is
run earlier in the build process. As a result the required properties
are not initialised.
This commit adds a new `AndroidPrepareForBuild` target which ensures that
the correct targets are run for tests.
A "funny thing" happened with commit 6e48bca5:
[it built on the PR builder][0], but
[not on the main builder][1].
The cause of the breakage? The PR builders have `ant` installed and
available in `$PATH`; the main builder did not:
.../xamarin-android/tests/CodeGen-Binding/Xamarin.Android.LibraryProjectZip-LibBinding/Xamarin.Android.LibraryProjectZip-LibBinding.targets:
error : Command 'ant debug' exited with code: 127.
Exit code 127 means "This program cannot be found."
This was fixed by installing `ant` on the build machine, but this
isn't a great answer, in part because README.md doesn't mention the
fact that `ant` is required for the build.
Extend the `android-toolchain` mechanism so that Apache Ant 1.9.7 is
downloaded and installed into the `$(AndroidToolchain)` directory.
This allows the build system to "know" and maintain it going forward.
Update `Xamarin.Android.LibraryProjectZip-LibBinding.targets` to use
`$(AndroidToolchain)\ant\bin\ant` instead of `ant` for builds.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/331/
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/167/
`tests/CodeGen-Binding` is a full-stack integration jack for JNI
bindings, ensuring that `generator.exe` and company work as expected.
It is *somewhat* duplicative of the Java.Interop `generator` unit
tests, except these are actually executed, while the `generator` tests
are *not* executed.
`tests/CodeGen-MkBundle` is a test for the "Bundle assemblies into
native code" feature, but isn't part of the "proper" unit test
infrastructure, as it doesn't yet contain an `Instrumentation` type.
TODO: Add an `Instrumentation` type to `tests/CodeGen-MkBundle`.
Jonathan Peppers
Radek Doulik
Jonathan Pryor
Peter Collins
Atsushi Eno
Dean Ellis