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`.
What do we want? Execution of unit tests!
When do we want it? Uh...4 months ago?
The `Xamarin.Android.NUnitLite` assembly allows writing NUnit-based
unit tests that execute on-device, and the `Mono.Android-Tests.csproj`
project contains a number of such unit tests.
The problem is that these unit tests aren't executed as part of the
Jenkins build process, so there's no way to know if a given commit
actually breaks anything.
In short, the existence of those unit tests is meaningless.
The task, then, is to fix the `make run-all-tests` target so that it
runs on-device unit tests...on an Android device.
Which raises all manner of problems. :-) (Hence 4+ months!)
For starters, our internal tooling is a horrible mish-mash of make(1),
ruby(1), bash(1), which creates an emulator, launches it, installs the
test .apk onto the emulator, and runs the tests. I don't want all of
that "cruft" in this repo, which means it needs to be rewritten in a
form more amenable to this repo: MSBuild tasks....and some make(1).
:-)
Add a new `build-tools/scripts/UnitTestApks.targets` file, which will
process an `@(UnitTestApk)` Item Group to permit deploying, running,
and undeploying test .apks from an attached Android device.
Add a slew of MSBuild tasks to support `@(UnitTestApk)`.
Update the default `$(AndroidSupportedTargetJitAbis)` value to be
`armeabi-v7a:x86`. The created Android emulator is x86.
Jonathan Pryor
Dean Ellis