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.
Change the default `HttpClientHandler` type from
`AndroidClientHandler` (back?) to `System.Net.Http.HttpClientHandler`.
**Background**: Mono contains a fully managed SSL support stack, but
this stack only supports TLS 1.0.
TLS 1.2 is increasingly becoming required.
There are three "high level" solutions to getting TLS 1.2 support:
1. Write a fully managed TLS 1.2 stack.
2. Use the "native" Android/Java APIs for TLS 1.2 support.
3. Use a native library for TLS 1.2 support.
(1), writing a fully managed TLS 1.2 stack, [has been done][0].
However, [this code hasn't been audited][1], and we're not confident
about the long term maintenance ramifications and security
implications. We thus don't plan on using this library.
(2) lives in [`AndroidClientHandler`][2]. Back in 2016-May, this is
how we thought we would be providing TLS 1.2 support "by default", and
the `<BuildApk/>` task was setting the `$XA_HTTP_CLIENT_HANDLER_TYPE`
environment variable so that `AndroidClientHandler` would be used,
unless overridden by the `$(AndroidHttpClientHandlerType)` MSBuild
property.
This default change didn't make it into the released commercial
offerings; Xamarin.Android 7.0 ("Cycle 8") used
`System.Net.Http.HttpClientHandler` as the default handler type.
(3) is [Boring SSL][3] ([previously mentioned][1]), and we currently
intend it to become the preferred default in the future. Boring SSL
uses the existing `HttpClientHandler`, and changes the internals of
how `HttpWebRequest` works.
`AndroidClientHandler` (2) thus will *not* become a default.
We see no point in changing the default `HttpClientHandler` type from
`HttpClientHandler` to `AndroidClientHandler` for one release, only to
change it back in the following release.
Revert the default `$XA_HTTP_CLIENT_HANDLER_TYPE` value to use
`System.Net.Http.HttpClientHandler`.
[0]: https://github.com/mono/mono-tls
[1]: http://tirania.org/blog/archive/2016/Sep-30.html
[2]: https://github.com/xamarin/xamarin-android/blob/d198cfd/src/Mono.Android/Xamarin.Android.Net/AndroidClientHandler.cs
[3]: https://boringssl.googlesource.com/boringssl/
The path to config.guess is dependent on distributions, so don't use
config.guess and use "$HOST_CC -dumpmachine" instead. It is also better
in point that it gives the result consistent with the compiler target. This
change is based on the following assumptions:
* $HOST_CC provides -dumpmachine option.
GCC and clang provide the option. Some dependencies such as LLVM expect
either will be used for compiling and it is likely to be safe to assume
that.
* $HOST_CC -dumpmachine and config.guess returns the same result.
It is likely because it won't build if the target architecture is
inconsistent.
* If the host architecture is 64-bit, it is compatible with i686.
It is likely to be safe to assume because `i386`, a command used before,
also assumes the same condition.
The `<DownloadUri/>` Task had two problems:
1. It used `HttpClient.GetAsync()`, not `HttpClient.GetStreamAsync()`.
It *looks* like a minor difference, but the former would
apparently attempt to store the *entire* source URI contents
*in memory*, which would fail if the URI contents are "big".
2. Exceptions leaving `Task.Execute()` are "uglier" than exceptions
logged via `TaskLoggingHelper.LogErrorFromException()`.
Improve the `<DownloadUri/>` task so that
`HttpClient.GetStreamAsync()` is used, removing the "download to
in-memory" behavior, and use
`TaskLoggingHelper.LogErrorFromException()` so that error messages are
nicer.
Additionally, `xa-prep-tasks.targets`
*wasn't supposed to surface errors* from the `_DownloadBundle` target.
The bundle which is downloaded *may not exist*. The build shouldn't
fail if the specified URI can't be found.
What's odd is that this *used* to work for me, in that if the target
URI -- the bundle -- didn't exist, `<DownloadTask/>` wouldn't report
an error, and execution would continue.
I suspect, but have not tested or verified, that Azure had changed
it's handling here: previously, it would return an XML document
containing a "404" error, even when the URL didn't exist.
This is *still the case* now [^0], so I'm not sure why I was *ever*
getting an error in the first place! (Very odd...)
"Sanitize" the behavior here: since the `_DownloadBundle` task can be
expected to "fail" -- in that the target URI may not exist, even if
Azure/etc. doesn't give a 404 for it -- then the `<DownloadUri/>` task
invocation should contain a `ContinueOnError="True"` attribute so that
errors are ignored.
Additionally, there is no need for the `_ExtractBundle` target to
execute unless the downloaded file exists, so make `_ExtractBundle`
conditional on the file existing, and update the
`_DownloadAndExtractBundle` target so that it explicitly orders the
dependent targets, so that `_ExtractBundle` doesn't need to depend on
the `_DownloadBundle` target.
[^0]: For example:
$ curl -o x.txt https://xamjenkinsartifact.blob.core.windows.net/xamarin-android/xamarin-android/bin/does-not-exist
$ $ cat x.txt
<?xml version="1.0" encoding="utf-8"?><Error><Code>BlobNotFound</Code><Message>The specified blob does not exist.
RequestId:d54a8d4a-0001-007d-1a0e-415487000000
Time:2016-11-17T20:12:32.8482654Z</Message></Error>
When running tests via `TestSuiteInstrumentation`, e.g. as is done
in [`Mono.Android-Tests`][0], write the test results to an
NUnit 2-formatted XML file and add the path to the XML file as a
`nunit2-results-path` bundle key:
$ adb shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation
...
INSTRUMENTATION_RESULT: nunit2-results-path=/storage/emulated/0/Android/data/Mono.Android_Tests/files/Documents/TestResults.xml
The value of the `nunit2-results-path` bundle key is the path to a
file that can be retrieved from the target device:
$ adb pull /storage/emulated/0/Android/data/Mono.Android_Tests/files/Documents/TestResults.xml
Note that the app on-device may need to modify the `TestResults.xml`
path so that it *can* be `adb pull`ed; on pre-Android 6.0 devices, the
on-device paths may not match the off-device/`adb shell` paths.
The `$EMULATED_STORAGE_SOURCE` and `$EMULATED_STORAGE_TARGET`
environment variables can be u sed to determine the common root for
off-device vs. on-device paths:
http://source.android.com/devices/storage/config.htmlhttp://source.android.com/devices/storage/config-example.html#android_5_x_emulated
[0]: https://github.com/xamarin/xamarin-android/blob/1b3a76c/src/Mono.Android/Test/Mono.Android-Tests.targets#L27
* [Xamarin.Android.Build.Tasks] Look in the AndroidSdk/extras folder for .aar files
The current Task always downloads data from google. This is regardless
of whether the files exist in the Android sdk directory already.
This commit changes the GetAdditionalResourcesFromAssemblies task
to look in the "extras" folder in the android sdk for the required
.aar file. This will mean if a user has an up to date sdk, there will
be almost no need to download the files from the internet.
* Rewoked code in prvious commit to allow Google Play Services to use the AndroidSdk directory.
The prvious commit only added support for getting .aar files from the
`extras\android` directory. So if a user was using GPS it would still
download the files.
This commit reworks the system to make use of the known `extras` directories
when searching for files. This allows GPS to use this system as well.
* Fixed the logging based on review feedback
* Fixed code format
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=32457
The Aot Task was NOT using the stripped assemblies for the AOT process.
This would probably result in code which had been removed being AOT'd.
This bug highlighted a few problems with the current system. Firstly
Java.Interop was NOT part of the SharedRumtime list. As a result it
was being picked up as a UserAssembly not a FrameworkAssembly. This
caused problems during the AoT task when it could not find the
Java.Interop.dll.
Secondly. The AoT Task itself was not making use of the
@(_ShrunkFrameworkAssemblies)
ItemGroup. This group is updated with the list of framework
assemblies the app is using. Depending on whether the dll's are
shrunk or not this list is the one that contains the final files
that need to be used.
Thirdy there was an issue in the IsFrameworkAssembly Helper method
in MonoAndroidHelper. This issue ment that if an assembly was in one
of the framework directories but NOT in the SharedRuntimeAssemblies list
it would NOT be picked up as a framework assembly. This bug is what
highlighted that fact that Java.Interop was missing in the first place.
Validation of downloaded files in the
GetAdditionalResourcesFromAssemblies build task is currently rehashing
the same file several times during a build leading to increased build
times.
By storing the computed hash and reusing it in subsequent invocations
validation can be speed up drastically:
$ tail -n1 build_{orig,patched}.log
==> build_orig.log <==
Time Elapsed 00:07:50.9875230
==> build_patched.log <==
Time Elapsed 00:02:41.3661180
Fix a [Build][0] [Break][1]:
Executing: ".../mxe/bin/x86_64-w64-mingw32.static-strip" "../host-mxe-Win64/.dll"
.../x86_64-w64-mingw32.static-strip: '.../host-mxe-Win64/.dll': No such file
This was a typeo introduced in commit a5b324d1 -- among others :-(:
<Exec
Condition=" '$(Configuration)' != 'Debug' And '%(_MonoRuntime.DoBuild)' == 'true' And '%(_MonoRuntime.OutputMonoPosixHelperFilename)' != '' "
Command=""%(_MonoRuntime.Strip)" %(_MonoRuntime.StripFlags) "$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)\%(_MonoRuntime.OutputMonoBtlsFilename).%(_MonoRuntime.NativeLibraryExtension)""
/>
One of these values is not like the other, and that's the problem.
`Condition` checks that
`%(_MonoRuntime.OutputMonoPosixHelperFilename)` isn't empty, but the
file we **strip** is `%(_MonoRuntime.OutputMonoBtlsFilename)`. When
building for `mxe-Win64`, `%(OutputMonoPosixHelperFilename)` is set,
but `%(OutputMonoBtlsFilename)` isn't, so we interpolate an empty
string, resulting in a filename which doesn't exist.
Fix the error by updating the `Condition` to check that
`%(OutputMonoBtlsFilename)` isn't empty.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/140/
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/140/consoleText
Previously we would simply call `Dispose` on each object surfaced to the runtime before shutdown so that no finalizer code could be run into a dead appdomain.
Unfortunately, because `Dispose` naturally calls `Dispose(bool)` before doing any low-level cleanup, user code can potentially throw exceptions which prevent the operation from happening correcly and (currently) triggers a process crash because of the unhandled exception.
This is the case when in the context of the Xamarin.Forms previewer where XF objects usually implement their own Dispose mechanism. Due to the "flat" nature of our cleanup loop, it may happen that we call `Dispose` on a XF object that in its own `Dispose(bool)` implementation also tries to invoke `Dispose` on an underlying object. The issue is that we may have already disposed it previously in our loop (since we have no clue on objects relationship with each other) causing an ObjectDisposedException to be thrown:
Unhandled Exception:
System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'Android.Widget.ListView'.
at Java.Interop.JniPeerMembers.AssertSelf (Java.Interop.IJavaPeerable self) [0x00036] in /Users/builder/data/lanes/1196/cf38796b/source/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.cs:166
at Java.Interop.JniPeerMembers+JniInstanceMethods.InvokeVirtualVoidMethod (System.String encodedMember, Java.Interop.IJavaPeerable self, Java.Interop.JniArgumentValue* parameters) [0x00002] in /Users/builder/data/lanes/1196/cf38796b/source/Java.Interop/src/Java.Interop/Java.Interop/JniPeerMembers.JniInstanceMethods_Invoke.cs:21
at Android.Widget.AdapterView.set_OnItemClickListener (Android.Widget.AdapterView+IOnItemClickListener value) [0x00031] in /Users/builder/data/lanes/1196/cf38796b/source/monodroid/src/Mono.Android/platforms/android-24/src/generated/Android.Widget.AdapterView.cs:946
at Xamarin.Forms.Platform.Android.ListViewAdapter.Dispose (System.Boolean disposing) [0x00050] in C:\BuildAgent3\work\82141f6bfad29a4c\Xamarin.Forms.Platform.Android\Renderers\ListViewAdapter.cs:332
at Java.Lang.Object.Dispose () [0x00000] in /Users/builder/data/lanes/1196/cf38796b/source/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:203
at Android.Runtime.JNIEnv.Exit () [0x00051] in /Users/builder/data/lanes/1196/cf38796b/source/xamarin-android/src/Mono.Android/Android.Runtime/JNIEnv.cs:309
This commit adds a workaround for now that catches all exception on calling `Dispose` and log them. If an exception did happen, it then proceed onto trying to manually clean up the JLO instance by reproducing the second part of `Java.Lang.Object.Dispose` to clear the object's GREF and suppress its finalizer. This is far from "nice" but until a better integration with `Java.Interop.Runtime` can be devised it's the less intrusive method.
Fix a [Build][0] [Break][1]:
monodroid.targets: error : Command '"/Users/builder/android-toolchain/mxe/bin/x86_64-w64-mingw32.static-gcc"
-o "../../bin/Debug/lib/xbuild/Xamarin/Android/lib/host-win/libmono-android.debug.dll"
...'
exited with code: 1.
The cause of the break is the `x86_64-w64-mingw32.static-gcc -o`
value: the `.../host-win` directory doesn't exist, because the
`<MakeDir/>` invocation in `_BuildHostRuntimes` was wrong:
<!-- Bad! -->
<MakeDir Directories="%(_HostRuntime.OutputPath)" />
Commit a9bd478a broke things; `%(_HostRuntime.OutputPath)` was a prior
version of the patch -- which didn't work (argh!) -- hence the use
elsewhere of `$(OutputPath)%(_HostRuntime.OutputDirectory)`.
Unfortunately, the `<MakeDir/>` was overlooked in the cleanup.
Fix the `<MakeDir/>` invocation to create the correct directory.
Additionally, place the mxe-Win64 binaries into
`bin/$(Configuration)/lib/xbuild/Xamarin/Android/lib/host-mxe-Win64`,
instead of `.../host-win`. This increases consistency with
`build-tools/mono-runtimes`, and provides a sensible way to provide
32-bit Windows binaries in the future, should we need to.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/139/
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/139/console
Fix a [Build][0] [Break][1]:
mono-runtimes.targets: error : Cannot copy
.../xamarin-android/build-tools/mono-runtimes/obj/Debug//host-mxe-Win64/mono/mini/.libs/libmonosgen-2.0.dll
to
.../xamarin-android/bin/Debug/lib/xbuild/Xamarin/Android/lib/host-mxe-Win64/libmonosgen-2.0.dll,
as the source file doesn't exist.
This is caused by an earlier *warning* in the build log:
*** Warning: linker path does not have real file for library -ldl.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /Users/jon/android-toolchain/mxe/x86_64-w64-mingw32.static/lib/libdl.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
Which means that when attempting to link `libmonosgen-2.0.dll`,
`-ldl` was provided. The problem there is that our MXE build provides
a `libdl.a` archive, but not exports for a `DL.DLL` Windows library.
What was *really* puzzling, to me, was that our internal system
builds, using the "same" setup: an MXE cross compiler.
Deeper investigation showed that our internal system and the public
system are *not* the same, in one crucial way. The internal setup has
*two* MXE builds, `mxe` and `mxe-full`. The difference between them is
that `mxe` is used to build `libmonosgen-2.0.dll`, while `mxe-full`
(1) adds the `dlfcn-win32` MXE "package", and (2) is used to build
`libmono-android*.dll`.
Thus the cause of the breakage is commit a9bd478a, which added
`dlfcn-win32` to the MXE build, but we *want* this change so that we
can build `src/monodroid` for Windows.
How do we split this difference?
There are two plausible solutions:
1. Have *two* MXE environments, just like we do internally. One would
include the `dlfcn-win32` files, the other wouldn't.
2. Tell `configure` to *not* use `-ldl` on Windows.
(2) is far easier, and involves augmenting the Windows configure with:
ac_cv_search_dlopen=no
This prevents the `-ldl` check from being done in the first place,
allowing xamarin-android to have a *single* MXE installation that is
usable for both `build-tools/mono-runtimes` and `src/monodroid`.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/135/
[1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/135/consoleText
Currently we loop through ALL the files in a directory and check
them all to see if they are writeable. What this commit does is
change it so we only do that IF we error the first time we try to
delete the directory.
If we can delete the directory first we just do. If not we make sure
everything is writable, and then of we fail we throw the error as usual.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44217
There is a slight oversight when we added the code to add the
default XA_HTTP_CLIENT_HANDLER_TYPE. If not environment files
were provided the default that was used did NOT include the
default XA_HTTP_CLIENT_HANDLER_TYPE.
In fact there were two code paths which dealt with defaults.
This commit removes the first code path which checks for a null
Environment array in favour of using the defaults which are added
at the end of the method. This means we maintain the defaults in
on place.
This commit adds a unit test for the AndroidTlsProvider. It
makes sure that we include/exclude the libmono-btls-shared.so
depending on the setting provided.
Fixes a stack overflow:
Adding assembly reference for Xamarin.AsyncTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3bd78831b6502434, recursively...
Adding assembly reference for System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, recursively...
Adding assembly reference for mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, recursively...
...
Adding assembly reference for System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, recursively...
Adding assembly reference for mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, recursively...
We never should have hit the second
`Adding assembly reference for System.Runtime` message, as we'd
already processed the dependencies for `System.Runtime`; seeing
`mscorlib` listed more than once is a bug.
The cause of the overflow was that
`ResolveAssemblies.AddAssemblyReferences()` was using two different
values to check for whether an assembly had been previously
processed: `assembly.MainModule.FullyQualifiedName` and
`Path.GetFullPath(assembly.MainModule.FullyQualifiedName)`,
*which may differ* (see e2dfa9f2).
Use the same `Path.GetFullPath()` in `.Contains()` and `.Add()` to
fix the stack overflow.
It is very important that the `<ResolveAssemblies/>` task *not* return
duplicate assembly names. Unfortunately, this can occasionally happen,
because paths aren't always canonicalized:
Task "ResolveAssemblies"
Assemblies:
.../lib/xbuild-frameworks/MonoAndroid/v1.0/Java.Interop.dll
.../lib/xbuild-frameworks/MonoAndroid/v1.0//Facades/System.Runtime.dll
...
[Output] ResolvedAssemblies
.../lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.dll
.../lib/xbuild-frameworks/MonoAndroid/v1.0//Facades/System.Runtime.dll
The paths aren't canonicalized, resulting in *two*
`System.Runtime.dll` entries, which can cause issues later.
Fix the `<ResolveAssemblies/>` task to Use `Path.GetFullPath()` to
canonicalize all paths returned from the task.
Commit 53bcf69f added `$(AndroidTlsProvider)` and related
`*TlsProvider` terminology.
Commit bc9d5ad1 added `$(AndroidTlsProviderType)` and related
`*TlsProviderType` terminology.
There's one "minor" problem: these are supposed to be the same
thing: a value to specify which TLS implementation
`System.Net.WebRequest` will use on-device, with values of `btls`,
`legacy`, and `default`.
We need to unify `$(AndroidTlsProvider) and
`$(AndroidTlsProviderType)`.
Next question: what do we unify them *to*? Look again at the possible
values: those are *not* types, at least not in the .NET sense, so a
`Type` suffix is inappropriate. We should thus unify on
`$(AndroidTlsProvider).`
Update `Xamarin.Android.Common.targets` and the various source files
so that `*TlsProviderType` naming is replaced with `*TlsProvider`
naming, allowing things to be more consistent.
* Bump to mono/mono-4.8.0-branch/9f4abcc3
[mono/085b653a][0] splits out the BTLS code into a new, separate,
`libmono-btls-shared.so` native library. This allows BTLS inclusion to
be *optional*, so that the size increase is only paid when it's used.
Bump to mono/9f4abcc3 so that we can use this new feature.
[0]: 085b653a74
* [mono-runtimes, Xamarin.Android.Build.Tasks] Use separate BTLS lib
There was an unintended side effect of commit cebc6c83, which added
`--with-btls-android-ndk` to the mono runtime configure command:
BTLS was compiled into `libmonosgen-2.0.so`, greatly increasing size:
$ ls -lh bin/Release/lib/xbuild/Xamarin/Android/lib/arm64-v8a/libmonosgen-2.0.so /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/lib/arm64-v8a/libmonosgen-2.0.so
-rwxr-xr-x 1 root wheel 2.8M Sep 23 18:34 /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/lib/arm64-v8a/libmonosgen-2.0.so
-rwxr-xr-x 1 jon staff 4.6M Oct 5 17:02 bin/Release/lib/xbuild/Xamarin/Android/lib/arm64-v8a/libmonosgen-2.0.so
The `/Library/Frameworks/...` is the Xamarin.Android 7.0 file size;
the `bin/Release/...` is the size when BTLS is included.
BTLS inclusion into `libmonosgen-2.0.so` increases the file size by
1.8 MB. **1.8 MB**
That's a ~64% increase in file size, for *all* apps.
[mono/085b653a][0] splits out the BTLS code into a new, separate,
`libmono-btls-shared.so` native library. This allows BTLS inclusion to
be *optional*, so that the size increase is only paid when it's used.
Update `build-tools/mono-runtimes` to use
`configure --enable-dynamic-btls` for the Android and host builds so
that BTLS is placed into the new `libmono-btls-shared.so` library and
installed into
`bin/$(Configuration)/lib/xbuild/Xamarin/Android/lib/ABI/libmono-btls-shared.so`.
(The host needs `--enable-dynamic-btls` so that the monodroid-profile
`System.dll` properly P/Invokes `libmono-btls-shared.so`, instead of
P/Invoking `__Internal`.)
Update the `<BuildApk/>` task so that when `$(AndroidTlsProvider)` has the
value `btls`, `libmono-btls-shared.so` is embedded into the `app.apk`.
[0]: 085b653a74
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44193
Recent changes to support .Net Standard resulted in builds
producing the following warnings
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(2113,3): warning MSB3247: Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: (MSB3247)
This is a result of Facade assemblies having different (lower)
version numbers to the ones which are used in the final app. It also
effects situations where the assemblies are picked out of the GAC rather
than the local framework directory (Mandroid/vX.0).
This commit adds code similar to what is used in the iOS/Mac
projects (xamarin-macios/3fcb2ed8) to remove the GAC search from the
search path for assemblies. This will ensure that we never pick out
a reference from the GAC for Android based projects.
It also adds the AutoUnify property to the ResolveAssemblyReferences
task to get rid of the warning when resolving _ResolveSatellitePaths.
Supersedes: https://github.com/xamarin/xamarin-android/pull/269
When running within a Linux FlatPak runtime environment, native
libraries such as `libmonosgen-2.0.so` and `libmonodroid.so` should be
searched for within `/app/lib/mono`.
Context: https://github.com/xamarin/xamarin-android/pull/269#issuecomment-254540565
Various features such as the Xamarin Studio Android Designer require a
`libmono-android.debug.dylib` file, built for the *host* OS, not for
an Android target device.
Add build system support to build `libmono-android.*` for the host OS,
including an MXE-cross-compiled Windows host version.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=45137
This is a weird bug. When building from the commandline using
xbuild/msbuild or from VS the system behaves as it should do.
But when building from XS it seems the DesignTimeBuild value
is being reset to ''. This results in the required target
GetAdditionalResourcesFromAssemblies from being run when it should,
which results in the following errors
error APT0000: No resource identifier found for attribute 'foo.foo'
This commit is part of another one which will be included in the
monodroid repo. It alters the condition of for the GetAdditionalResourcesFromAssemblies
target to let it run when $(DesignTimeBuild) is 'false' or ''.
Which means it will not run when the IDE's pass $(DesignTimeBuild) = 'true'
(which they currently do).
* [Mono.Android] update API description with the latest class-parse output.
It seems to add java.util.Hashmap#put() override, which does not affect
the public API.
* [Mono.Android] add API Level 25 description.
Since there is no documentation component yet, it is actually generated
with API Level 24 docs, so it lacks parameter names for newly added
abstract methods that class-parse cannnot extract. But there is only one
method that falls to the issue.
* [msbuild] add new droiddoc related arguments in ClassParse task.
Note that this task is not functional enough to support javadocs correctly
as it does not distinguish doclet type while it pretends to be able to.
- removed unused methods
- process only System assembly, because we are looking just for
Mono.Net.Security.MonoTlsProviderFactory.CreateDefaultProviderImpl
method
Commit 25663510 overlooked adding the `TileState` enum type to the
`Mono.Android.dll` build, meaning that the
`Android.Service.Quicksettings.TileState` type wasn't present in the
resulting assembly.
Add the `Android.Service.Quicksettings.TileState` enum to the build.
We had ProguardToolPath and it could be used for custom proguard tools,
which should be useful if we want to support Java8 based libraries which
doesn't work with the one in Android SDK. In theory.
In fact, it was not sufficient because proguard is also used by multidex.
To support multidex, we have to generate correct mainDexClasses rules
that should depend on Android SDK path, not proguard.
To support custom proguard, we need PROGUARD_HOME environment variable
in mainDexClasses(.bat). That actually uncovered another issue we had:
we were using ToolTask.EnvironmentOverride which is [Obsolete] and
converts every entry to lowercase, which can work on Windows but not
elsewhere i.e. even if we had PROGUARD_HOME, it became proguard_home(!)
Therefore we use ToolTask.EnvironmentVariables instead from now on.
Due to xbuild property parser issue, it differentiates MSBuild on
Windows and xbuild elsewhere to give some additional env. variables.
There were non-breaking API definition files changes caused by
https://github.com/xamarin/java.interop/pull/94
This update reflects the changes.
Additionally, the pre-API-24 API descriptions were generated by
`jar2xml`, not `class-parse`, which generated extraneous
generic constraints. Update all API descriptions to be generated by
`class-parse` and `api-xml-adjuster`.
With Android 7.0 (Nougat) it is no longer possible to read some
information about network interfaces from the /sys filesystem. Google
placed restrictions on two files used by the Mono BCL to read
information about the interface:
/sys/class/net/[DEVICE]/flags
/sys/class/net/[DEVICE]/operstate
The information we used to read from `flags` let us determine whether
the interface supports multicast and the `operstate` file provided us
with detailed information on the current device state.
Additionally, it is now impossible to read the hardware MAC address used
by any interface. This bit of information is also unavailable when using
the Java APIs and therefore applications running on devices with API
24 (and possibly newer) will not be able to access this information.
More details about the issue are available from the upstream Android
bug:
https://code.google.com/p/android/issues/detail?id=205565
In order to obtain the required information, we now need to use the Java
APIs on devices with API 24+ and this commit implements the backend to
retrieve this information. It is done in C in order to avoid overhead of
creating mirror .NET objects when calling Java, thus saving time and
memory during an operation which may be performed by some applications
quite frequently.
Part of fix for https://bugzilla.xamarin.com/show_bug.cgi?id=44296
The Bridgeless SCC support (commit 70807523) requires the
`mono.android.GCUserPeer` type to work, which is a type located within
`classes.dex`.
On the main/UI/startup thread, `JNIEnv::FindClass()` uses a
`ClassLoader` that will find types located within `classes.dex`. Other
threads do *not*. Other threads...such as mono's GC thread.
Unfortunately, this means that the `JNIEnv::FindClass()` use within
`gc_prepare_for_java_collection()` -- called from the mono GC thread
-- would always return `NULL`, with a pending exception, which would
cause the process to exit with an untimely death:
F/art : art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION:
JNI GetMethodID called with pending exception java.lang.ClassNotFoundException:
Didn't find class "mono.android.GCUserPeer" on path: DexPathList[[directory "."],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
Move the `JNIEnv::FindClass()` lookup for `mono.android.GCUserPeer`
into `JNI_OnLoad()`, which *is* invoked on the UI thread, and thus
*can* find the `mono.android.GCUserPeer` type. This avoids the error.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44528
Something changed between C6 and the current master of xbuild or mono.
Before adding a reference like so
<Reference Include="Foo.dll" />
used to work without any issues. Now we get the following
Error executing task ResolveAssemblyReference: Path is empty
This is because xbuild seems to interogate the path from the reference
and it gets an empty string. But apprarently this is a problem.
This commit adds a call to Path.GetFullPath when resolving the assemblies
to work around this problem.
* Bump Mono to mono-4.8.0-branch commit 90699022b6fed7fd273ba3379a2e3696bbd8956f.
* Add new PreserveTlsProvider step, which rewrites MonoTlsProviderFactory.CreateDefaultProviderImpl()
to only include the selected TLS Provider.
* Added 'TlsProviderType' to <LinkAssemblies>.
Jonathan Pryor
Akihiko Odaki
Radek Doulik
Ludovic Henry
Atsushi Eno
Dean Ellis
Peter Collins
zappolowski
Jérémie Laval
Martin Baulig
Marek Habersack
Jo Shields
Bernhard Urban