Commit ff28d572 updated some of the Java source code that is included
into `mono.android.jar`, which needs to be kept synchronized with the
`libmono-android*` ("libmonodroid")` native libraries.
Unfortunately, the build system didn't know about this dependency; the
`GenerateJavaCallableWrappers` target only executes when
`Mono.Android.dll` is updated, but commit ff28d572 didn't have
anything which would cause `Mono.Android.dll` to be updated.
As a result, *pre-existing build trees* that had `Mono.Android.dll`
and `mono.android.jar` files from *before* commit ff28d572, when
updated to be at ff28d572 or later, would rebuild
`src/Xamarin.Android.Build.Tasks` -- which contains
`MonoPackageManager.java` -- but would *not* rebuild
`mono.android.jar`. This would result in build-time failures when
building the unit tests:
obj/Release/android/src/mono/MonoPackageManager.java(59,7): error : error: incompatible types: String[] cannot be converted to String
Update the `GenerateJavaCallableWrappers` target to include
`@(JavaCallableWrapperSource)` as an input dependency, and update
`Mono.Android.targets` to include `src/Mono.Android/java/**` into
`@(JavaCallableWrapperSource)`. This will ensure that the next time
the Mono.Android-related Java sources are updated, we properly rebuild
`mono.android.jar`.
The `BuildAotApplication()` test additions from commit a953d3f1 don't
work when `supportedAbis` is a 64-bit platform such as `x86_64` or
`arm64-v8a`, because the test checks for `android-9`, which is only
going to be valid for 32-bit architectures. (64-bit architecture
support requires API-21, iirc.)
Update the minSdkVersion path check to only execute when dealing with
32-bit architectures.
We made an assumption when the test was written that the
old `Resource.designer.cs` was going to be deleted in
projects when using `$(AndroidUseIntermediateDesignerFile)`.
The decision was changed so it would jsut be ignored.
So the existing check that is should not exist was wrong.
That said it did not fail because we did not include the `Root`
proeprty in the path so it always passed because that file
did not exist in the location we were checking.
The change to nunit3 changed that as because of the way the
working directory is set that check now failed. Because
the old incorrect path was not correct.. doh.
So a better check is to make sure that the old file is
just emtpy. We almost empty since the the project tools
write the file we end up with a Unicode marker.
We also update the XamarinAndroidApplicationProject so that
we can override the `$(EmbedAssembliesIntoApk)`. This is
required for various unit tests. The way it currently worked
was that no matter what you set.. you always got the default.
This worked for the OSS repo as we don't use the shared-runtime.
But for the monodroid stuff, we need to be able to change that
value. This was stopping the test projects doing that.
When the VSSDK builds the VSIX container, it generates a manifest
(`catalog.json`) placed inside it that has the resulting filename in
it. This manifest is used in alpha pack generation (by XVS) to
determine the payloads to include. This is done by invoking the VSMAN
tool (manifest generation thing) uses the contents of the catalog.
If the filename inside the catalog doesn't match the actual filename
included in the alpha pack manifest, installation fails, so we need
to ensure the filename is changed early enough in the process so that
it's consistent in the embedded manifest.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59115
`monodroid_create_appdomain()` requires that the
`AppDomainSetup.set_ShadowCopyDirectories` property exist, so that
it can be called.
Unfortunately, the linker may remove this property, which results in
a SIGSEGV if it's been removed:
C [libmonosgen-2.0.dylib+0x20bc9c] mono_property_set_value+0xc
C [libmono-android.debug.dylib+0x154fe] monodroid_property_set+0xbe
C [libmono-android.debug.dylib+0x15268] monodroid_create_appdomain+0x248
C [libmono-android.debug.dylib+0xf159] create_domain+0x149
C [libmono-android.debug.dylib+0xe439] create_and_initialize_domain+0x69
C [libmono-android.debug.dylib+0xe89d] Java_mono_android_Runtime_createNewContext+0x7d
Add `AppDomainSetup.set_ShadowCopyDirectories` to the linker's
preserve list, so that the Android Designer can work as intended.
macOS uses *BSD command-line tools which often take different parameters
than the Linux ones. This is the case with **stat**(1) which not only expects
different command line parameters but also has different meaning of various
format placeholders (in this case `%z` means "file size in bytes" on macOS
but "file time stamp timezone in human readable format").
This fixes **stat**(1) invocation on Linux.
We (try to) base Xamarin.Android product versions on the latest
Android versions. Android 8.0 Oreo™ [has been announced][0], and since
the xamarin-android/d15-4 branch includes an API-26/v8.0 binding, the
overall product version for d15-4 should *also* be bumped to v8.0.
[0]: https://www.android.com/versions/oreo-8-0/
As xamarin-android/master is tracking the *next* Xamarin.Android
version, bump `$(ProductVersion)` to v8.0.99 for eventual release as
v8.1.0.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58029
Scenario: Build a project with:
* `$(Configuration)`=Release
* `$(AotAssemblies)`=True
* `$(EnableLLVM)`=True
* `$(TargetFrameworkVersion)`=v7.1 (API-25)
* `//uses-sdk/@android:minSdkVersion`=10 (in `AndroidManifest.xml`)
* with Android NDK r12b or later
* on particular hardware devices, e.g. a Nexus 5.
Actual results: the app runs, but the AOT'd images aren't used:
AOT: image 'Xamarin.Android.Support.v7.AppCompat.dll.so' not found: dlopen failed: cannot locate symbol "__aeabi_memset" referenced by "/data/app/com.companyname.App1-1/lib/arm/libaot-Xamarin.Android.Support.v7.AppCompat.dll.so"...
The `__aeabi_memset` symbol can't be found, preventing e.g.
`Xamarin.Android.Support.v7.AppCompat.dll.so` from being used. Meaning
the app pays the build overhead and size penalty of AOT+LLVM, but
doesn't get anything out of it; only the JIT is used.
The [cause of the missing `__aeabi_memset` symbol][0] is that we're
using the NDK paths which corresponds with `$(TargetFrameworkVersion)`,
*not* the NDK paths which correspond with
`//uses-sdk/@android:minSdkVersion`. Because of this, if you use the
`.apk` on a platform which is >= `minSdkVersion` but less than
`$(TargetFrameworkVersion)`, the AOT images won't be used.
[0]: https://github.com/android-ndk/ndk/issues/126
Fix this by updating the `<Aot/>` task to instead use the
`//uses-sdk/@android:minSdkVersion` value. This ensures that we use
NDK paths which correspond to the app's minimum supported API level,
which should allow the AOT images to be loaded on downlevel devices.
Commit 9d131af4 introduced a [unit test failure][m573] on
xamarin-android/master:
[m573]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/573/
Xamarin.Android.Build.Tests.BuildTest.XA4212
Expected: String containing "warning XA4"
But was: <log file contents...>
Aside: The XA4212 test creates a project with a bad `IJavaObject`
type, builds the project -- which triggers an XA4212 error, which *is*
observed in the unit test -- then *rebuilds* the project, but this
time with `$(AndroidErrorOnCustomJavaObject)`=False.
The intention is that the second build should instead elicit an XA4212
*warning*, but otherwise continue just fine.
What's interesting about the log file contents is that it shows that
the `<GenerateJavaStubs/>` task isn't executed *at all*, but it's the
`<GenerateJavaStubs/>` task which is supposed to emit the warning!
Skipping target "_GenerateJavaStubs" because its outputs are up-to-date.
Update the `<GenerateJavaStubs/>` task so that if it errors out, it
*removes* any `<GenerateJavaStubs/>` output files. This will ensure
that on subsequent builds, the `_GenerateJavaStubs` target won't be
inadvertently skipped.
(This issue *should* have been caught during the
[**macOS+xbuild PR builder** build for PR #797][pr1491]. It *wasn't*,
because the `Xamarin.Android.Build.Tests` tests weren't reported. For
example, PR #1491 ran 869 tests, while PR #1492 ran 1085! I'm not sure
what can be done to better detect and prevent this in the future.)
[pr1491]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/1491/
When opening Xamarin.Android.sln in Visual Studio 2017, you are
presented with a dialog box saying `.NETFramework,v8.0` is not
installed.
The fix is to setup the project like OpenTK's csproj: make it an Android
Library project with the appropriate `ProjectTypeGuids` and import
`Xamarin.Android.CSharp.targets`. These changes allow VS to load the
project.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56819
Bumps to Java.Interop/master/ab3c2b26.
Nothing *prevents* "anybody" from custom implementing `IJavaObject`:
class MyBadClass : Android.Runtime.IJavaObject {
public IntPtr Handle {
get {return IntPtr.Zero;}
}
public void Dispose () {}
}
The problem is that the above doesn't actually work: the
`IJavaObject.Handle` value contains the JNI Object Reference to pass
into JNI. The above code will thus result in always passing `null`
into Java code, which could result in a `NullPointerException`, but
will always result in *not* doing what was intended.
While it is *theoretically* possible to manually implement
`IJavaObject`, it's not something *I* would want to contemplate, nor
is it for the faint of heart, so long ago we decided to emit a warning
if we encounter a type which:
1. Implements `Android.Runtime.IJavaObject`, and
2. Does *not* also inherit `Java.Lang.Object` or
`Java.Lang.Throwable`.
As such, the above `MyBadClass` elicits the warning:
Type 'MyBadClass' implements Android.Runtime.IJavaObject but does not inherit from Java.Lang.Object. It is not supported.
This is all well and good, but (effectively) *nobody* reads warnings,
*especially* since our toolchain emits so many warnings that enabling
`/warnaserror` is for the truly foolhardy, so *lots* of warnings is,
unfortunately, normal.
Which brings us to Bug #56819: Could we make this an error?
Answer: Of course we can. That said, I have no idea how much existing
code this will *break* if we turned it into an error. That might be
good and useful, but if there's no way to *disable* the error,
existing apps which (appear to) work will no longer build.
That's not desirable.
Add a new `$(AndroidErrorOnCustomJavaObject)` MSBuild property to
control what happens when such custom `IJavaObject` implementations
are found. When True, the default, emit a new XA4212 *error*.
The error can be turned back into a warning by setting
`$(AndroidErrorOnCustomJavaObject)` within the `App.csproj`:
<!-- Within App.csproj -->
<PropertyGroup>
<AndroidErrorOnCustomJavaObject>False</AndroidErrorOnCustomJavaObject>
</PropertyGroup>
I discovered this target failing when building with VS Community
edition instead of Enterprise.
It is calling:
chmod +x [output]\Windows\mono-symbolicate
It turns out we can skip this target completely on Windows.
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58682
Seeing a new seemingly DesignTimeBuild-related build failure when
invoking the `Rebuild` msbuild target.
The `$(DesignTimeBuild)` value was empty when running under mac.
This cuases the error
error MSB4044: The "GetAdditionalResourcesFromAssemblies" task was not given a value for the required parameter "DesignTimeBuild".
So we need to make sure that the value is set before we get to
`GetAdditionalResourcesFromAssemblies`. The reason we got the error
is before we used `$(DesignTimeBuild)` only in conditionals. However
when moving to use it as a property of a task it cannot be empty.
So we need to make sure we call `_SetupDesignTimeBuildForBuild`
early in the build process.
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58580
Unable to locate assemblies when running projects when
`$(Configuration)`=Release and `$(Optimize)` != True.
Commit edabe8ac reworked the build logic so that `$(Optimize)`
controls the deployment of the debug or release runtimes.
Input Property: || Output Property
DebugSymbols | DebugType | EmbedAssembliesIntoApk | Optimize || AndroidIncludeDebugSymbols
================+============+==========================+============++===========================
True *any* True True False (Release runtime)
True *any* True False True (Debug runtime)
True *any* False True True (Debug runtime)
True *any* False False True (Debug runtime)
True *empty* True True True (Debug runtime)
True *empty* True False True (Debug runtime)
True *empty* False True True (Debug runtime)
True *empty* False False True (Debug runtime)
False - - - False (Release runtime)
*empty* *any* *empty* False True (Debug runtime)
In this scenario, `$(DebugSymols)` and `$(EmbedAssembliesIntoApk)` are both empty.
As a result `$(EmbedAssembliesIntoApk)` gets a default value of 'False'.
But because `$(DebugSymols)` is empty we fall through the MSBuild case statement
and end up with `$(AndroidIncludeDebugSymbols)` = `True`. Which is NOT what we want in this case.
So if `$(EmbedAssembliesIntoApk)` we should always default `$(AndroidIncludeDebugSymbols)`
to false.
In addition there was a weird issue with the way we install debug apps.
If the app is using the Shared Runtime the deployment process sends a
broadcast to the Shared Runtime app which returns the external storage
directory. This tends to be something like
/mnt/shell/emulated/0/
So when we deploy our debug assemblies we do so to a directory like
/mnt/shell/emulated/0/Android/data/$(PackageName)/files/.__override__
This works as expected. Now if we try to debug an app without using the Shared
Runtime it will work as expected.. unless the Shared Runtime was not installed.
In this case the broadcast fails and we fall back to getting the external storage
using
adb shell echo -b ${EXTERNAL_STORAGE}
This returns
/mnt/shell/emulated/legacy
so we end up deploying the debug assemblies to
/mnt/shell/emulated/legacy/Android/data/$(PackageName)/files/.__override__
So all is well and good. However problems start in our runtime and the
MonoPackageManager. We use
android.os.Environment.getExternalStorageDirectory ();
to get the external storage directory. In this case it ALWAYS returns
/mnt/shell/emulated/0/
So if we are debugging without the Shared Runtime being installed, we will
NEVER find the fast deployed assebmies. So the app will crash. The fix in
this case is to check both directories when we are running the debug
runtime.
- extracted parts of `ProcessLogcatTiming` into new base class called
`ProcessPlotInput`
- we measure and process the apk sizes now to observe the changes and
possible regressions on Jenkins CI
- it is now possible to add results to cvs plot files, so we can
merge values from multiple test runs. we do that with apk size
values and we will do it with startup times in future
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59036
When building a project with `$(AndroidEnableMultiDex)`=True, an
`obj/$(Configuration)/multidex.keep` file is generated, which is a
list of Java classes, one per line, which should be placed into the
"main" `.dex` file for the application.
Unfortunately, commit 6829b7d1 results in a `multidex.keep` file which
places all types onto a single line, instead of one class per line.
This results in *breaking* multidex, as when this happens, nothing
ensures that the required types are in the main `.dex` file, which
could prevent the app from launching on the target device.
Fix the `<CreateMultiDexMainDexClassList/>` task by always appending a
newline after every type which should be preserved.
This commit is inspired by the known issue of finding a compatible
MSBuild given that VS 2017 has SxS support and additionally installs
various versions of MSBuild (such as MSBuild 15 and MSBuild 4
depending on payloads installed).
People may try to build using an incompatible MSBuild version that
lacks proper C# feature support.
Update `README.md` to explicitly specify that MSBuild 15+ is required.
On Windows you can now do:
msbuild build-tools\scripts\PrepareWindows.targets
Using `PrepareWindows.targets` does the following:
- `git submodule update --init --recursive`
- Sets up the required `.props` files for your system
- Downloads `.nuget/NuGet.exe`
- Runs `nuget restore`
The [most recent xamarin-android/master build is not green][xa564],
because of a failure in the `api-compatibility` tests:
[xa564]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/564/
ABI BREAK IN: mscorlib.dll
<!-- start namespace System.Collections.Generic --> <div>
<h2>Namespace System.Collections.Generic</h2>
<h3>Removed Type <span class='breaking' data-is-breaking>System.Collections.Generic.CollectionExtensions</span></h3>
</div> <!-- end namespace System.Collections.Generic -->
The cause for the breakage is that
[xamarin-andorid-api-compatibility was updated for mono/2017-06][0],
and `mscorlib.dll` is incompatible between mono/2017-04 and
mono/2017-06.
[0]: ed8d914d08
Since Xamarin.Android d15-4 and current master are both using
mono/2017-04, the result is the above "ABI BREAK" message...
*all the time*.
Update xamarin-android/master to use
[xamarin-android-api-compatibility/d15-4][1], fixing the ABI BREAK
build error.
[1]: https://github.com/xamarin/xamarin-android-api-compatibility/tree/d15-4
In-tree XA builds should always override the `$ANDROID_NDK_PATH` and
`$ANDROID_SDK_PATH` environment variables because code that handles
Android SDK components installation (in `build/android-toolchain`)
is destructive in that it first removes the entire SDK/NDK trees and
installs everything from scratch. This has bad effects if the
developer's machine has a separate SDK/NDK tree not managed by XA
build system: build removes the directories but it requires tools
that were in them and, in effect, crashes.
LibZipSharp is pulling `libzip.dll` and `zlib.dll` from NuGet on
Windows, so we can use these in favor of building
`libzip-windows.mdproj`.
We also need to add a `@(ProjectReference)` to `libzip-windows.mdproj` in
`Xamarin.Android.Tools.BootstrapTasks`.
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58994
When loading `Xamarin.Android.sln` into Visual Studio for Mac, the
Solution Panel indicates an error on the `Mono.Android` and
`Mono.Android.Export` projects:
Project does not support framework 'MonoAndroid,v1.0'.
Fix this warning by adding `$(ProjectTypeGuids)` to
`Mono.Android.csproj` and `Mono.Android.Export.csproj`.
Additionally, some projects such as
`src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.csproj`
*do not build* within Visual Studio for Mac, because Visual Studio for
Mac doesn't appear to support the use of MSBuild properties within
`<Import/>`s -- at least not *our* property use. Specifically, this:
<Import
Project="$(JavaInteropFullPath)\src\Java.Interop.Tools.TypeNameMappings\Java.Interop.Tools.TypeNameMappings.projitems"
Label="Shared"
Condition="Exists('$(JavaInteropFullPath)\src\Java.Interop.Tools.TypeNameMappings\Java.Interop.Tools.TypeNameMappings.projitems')"
/>
is *completely ignored*, which results in multiple C# compiler errors
as types which are provided by that shared project cannot be found.
Appease Visual Studio for Mac by *removing* use of such properties
within `.csproj` files, and instead hardcoding relative paths.
Unfortunately this kills the idea from commit d205cab2:
> Allow the Java.Interop checkout directory to be specified by
> overriding the `$(JavaInteropSourceDirectory)` MSBuild property.
> ...
> Normally `$(JavaInteropSourceDirectory)` wouldn't need to be
> overridden; the current use case is to allow a CI-like environment
> which grabs the latest commit of every referenced module to make sure
> they all work together. (Note: such a "CI-like environment"
> DOES NOT (yet) EXIST. This commit is to help *permit* such a thing.)
Such a "CI-like environment" still doesn't exist, and is arguably
moot/silly, as Jenkins has an option to
**Update tracking submodules to tip of branch**, which is more-or-
less what was being advocated for here.
Using e.g. `$(JavaInteropFullPath)` -- the value of which was based
off of `$(JavaInteropSourceDirectory)` -- actively prevents
Visual Studio for Mac from building projects, so remove that use.
Finally, Visual Studio for Mac is *still* unable to do a toplevel
Build, even after all of these changes: Visual Studio for Mac doesn't
like `@(ProjectReference)` items which are `Condition`al, and we have
those all over the place (for now).
The changes in this commit *improve*, but **do not** "fix",
Visual Studio for Mac use.
Just build projects individually, with Command+K. :-)
Linux doesn't need to build MXE since the distributions we support at
this point have mingw packaged and we rely on the packages to provide
cross-compilation environment for Windows. Neither does Linux build
require the Mono Windows environments to be built.
Previously, when one enable the Windows LLVM build the Mono Windows
runtime was attempted to build as well. The attempt would fail since
some Windows-only libraries required by Mono/libmonodroid aren't available
as packages on Linux.
This commit disables building of Mono Windows runtimes while making it
possible to build the LLVM Windows cross compiler.
If we hit a PathToLongException when extracting embedded resources
we currently do not get any information about the file where
actually caused the problem.
This commit adds handling for that case so that the error message
includes the file and path of the file that was being extracted.
Commit 8942eca0 broke the build. Commit a1bf2deb attempted to fix it,
but was incomplete; [we now get][xa556]:
[xa556]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/556/
error XA0000: Could not determine $(TargetFrameworkVersion) for API level '10.'
Commit a1bf2deb had the right idea -- we got further in the build! --
but didn't go far enough: as soon as we use `$(MSBUILD)`, we
incorrectly use the system libraries -- which cannot work -- and
re-introduce the XA0000 error.
The fix: expunge `$(MSBUILD)` from `BuildEverything.mk`, and use
`$(_SLN_BUILD)` instead. This ensures that we use the in-tree
`bin/Debug/lib/xamarin.android/xbuild*` directories and not the
pre-installed system equivalents.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58865
Consider a project with an `App.csproj` and a referenced
`Lib.csproj`. Not all changes to C# sources within `Lib.csproj`
should require rebuilding and redeploying the `.apk` when
Fast Deployment is enabled; only those that result in changes
to Java Callable Wrappers should require rebuilding and
redeploying the `.apk`.
Unfortunately, that wasn't the case: *any* change to `Lib.csproj`
would result rebuilding and redeploying the `.apk`, because
`AndroidManifest.xml` was constantly being modified, which would
cause the `_CompileToDalvikWithDx` target to be invoked, resulting
in a `.apk` rebuild + redeploy.
The item
<meta-data android:name="android.support.VERSION" android:value="25.4.0" />
was constantly being duplicated in the manifest. As a result it
was always newer and was triggering a change of build targets.
So we need to double check we are NOT adding 100% duplicate
values to the manifest.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id= 58740
- the commit:
commit 07b07ef75fa1858253af45af6fe30812a5a1655c
Author: Marek Safar <marek.safar@gmail.com>
Date: Wed Aug 23 00:44:47 2017 +0200
Don't crash on any wrong type forwader reference
Commit 8942eca0 [broke the build][xa554]:
[xa554]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/554/
error XA0000: Could not determine $(TargetFrameworkVersion) for API level '26.'
The cause of the failure is that we're using `xbuild` within the
`make leeroy-all` target, but [we need to use `xabuild`][xbuild-paths]:
[xbuild-paths]: https://github.com/xamarin/xamarin-android/pull/599#issuecomment-319543023
Task "GetReferenceAssemblyPaths"
Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Looking for framework 'MonoAndroid,Version=v1.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0'
Done executing task "GetReferenceAssemblyPaths"
`xbuild` is trying to use the *system-wide*
`/Library/Frameworks/Mono.framework/External/xbuild-frameworks`
directory, which *cannot* contain the now-required
`AndroidApiInfo.xml` files which are needed for probing.
Fix the `make leeroy-all` target to use `$(_SLN_BUILD)`, just as the
`make all` target does, so that the correct paths are used.
* Bump LibZipSharp for Windows fixes
Problems fixed on Windows:
- Many `RequiredPrograms` are n/a on Windows
- Setup `AndroidSdkItem` for Windows downloads
- `AcceptAndroidSdkLicenses` should run `.bat` file on Windows
- `UnzipDirectoryChildren` was running `/bin/mv` and hitting
`PathTooLongException` while using `ZipFile.ExtractToDirectory`
- references to `libzip.mdproj` are conditional on Windows, will be
getting `libzip` from NuGet in the future
UnzipDirectoryChildren:
- on Windows we are using `System.IO.Compression` to extract
directly into the destination and avoid `%TEMP%` to
workaround `MAX_PATH`
- Other platforms continue to use `unzip`, in order to preserve
file attributes
General changes:
- gitignore for VS 2017
We were not using UTC for allot of the date time comparisons in
the `<ResolveLibraryProjectImports/>` task. We really should be
since it means we should not hit any issues with LocalTimes.
Commit 8e7d37bb is a sign of duplication: in order to use a
`Mono.Android.dll` binding assembly, not only do we need to *build*
the binding assembly, but we *also* need to update
`Xamarin.Android.Build.Utilities.dll` to "know" about the new binding
version (to map API level to `$(TargetFrameworkVersion)`).
Even "better" (worse), if the new API level is a *preview*, there is
no *consistent* API level. For example, with API-O, `android.jar`
isn't at
`$(AndroidSdkDirectory)\platforms\android-@API_LEVEL@\android.jar`,
where `@API_LEVEL@` is 26 (because various codepaths require that the
"api level" be an integer). Instead, it's installed at
`$(AndroidSdkDirectory)\platforms\android-O\android.jar`, where
`O` is the "id" of the preview API level.
This "id" is "leaky", in turn requiring that
`Xamarin.Android.Build.Tasks.dll` *also* be updated to deal with the
mappings.
Even "better" (worse), if we *forget* to cross all our our 't's and
dot all of our 'i's, we'll have a binding assembly which can't be
used. (Which is why we needed commit 8e7d37bb; without it, the API-O
binding can't be used!)
This is all obviously madness. ;-)
Clean this mess up:
1. Update `src/Mono.Android` to create a new `AndroidApiInfo.xml`
file within the `$(TargetFrameworkVersion)` directory.
This will contain all the information needed to map Android API
levels to Ids and Android OS versions and
`$(TargetFrameworkVersion)` values.
```xml
<AndroidApiInfo>
<Id>10</Id>
<Level>10</Level>
<Name>Gingerbread</Name>
<Version>v2.3</Version>
</AndroidApiInfo>
```
2. Add a new `Xamarin.Android.Build.Utilities.AndroidVersions` type
which looks for and parses these new `AndroidApiInfo.xml` files.
3. Fixup all the other places using `AndroidVersion.KnownVersions`
and related members to instead use `AndroidVersions`.
4. Remove all the old APIs which rely on hardcoded data.
The advantage to all this is that we can support new API level
bindings by just building a new `Mono.Android.dll` and placing an
`AndroidApiInfo.xml` into the appropriate location (next to
`Mono.Android.dll`). No further code changes would be required.
Related: The build system still has a nasy habit of using system-wide
directories to resolve files we'd really rather it not, e.g. in
[xamarin-android/master build #503][m503]:
[m503]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/503/consoleText
Building target "_GetReferenceAssemblyPaths" in project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj" ("/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets"); "_SetLatestTargetFrameworkVersion" depends on it.
Target _GetReferenceAssemblyPaths:
Task "GetReferenceAssemblyPaths"
Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Looking for framework 'MonoAndroid,Version=v1.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0'
Done executing task "GetReferenceAssemblyPaths"
Done building target "_GetReferenceAssemblyPaths" in project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj".
Done building target "_GetReferenceAssemblyPaths" in project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj" ("/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets"); "_SetLatestTargetFrameworkVersion" depends on it.
Target _SetLatestTargetFrameworkVersion:
Task "ResolveSdks"
ReferenceAssemblyPaths:
/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/
Note the use of the path
`/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0`.
This *was* "fine" -- if undesirable -- but with the introduction of
`AndroidVersions` and `AndroidApiInfo.xml` files within the frameworks
directory, everything falls apart, becuase the system install
*does not have* the `AndroidApiInfo.xml` files, so
*NO API LEVELS ARE FOUND*.
Oops.
The only way to fix this is to use `$XBUILD_FRAMEWORK_FOLDERS_PATH`,
and the sanest way to do *that* is to use `tools/scripts/xabuild` for
the primary build.
Unfortunately, using `xabuild` for the primary build breaks the
`msbuild`-based build, as it can't resolve the
`.NETFramework,Version=v4.6.1` framework.
Context: https://github.com/xamarin/xamarin-android/pull/599#issuecomment-319801330
Split the difference here by introducing `$(_SLN_BUILD)`: use
`xabuild` when building with `xbuild`, and continue using `msbuild`
when building with `msbuild`.
When running `<Exec>` on Windows, a trailing slash on the end of a path
before a quote can actually escape the quote. This breaks a call to
`jcw-gen.exe` where a proper list of directories wasn’t getting passed
in.
There were also some failing `javac` calls on Windows. `javac` uses a
semi-colon to delimit jar files on Windows and a colon on Linux/MacOS.
Changes:
- `$(_LibDirs)` needs to ensure there aren’t trailing slashes on
directories passed to `jcw-gen`
- Added a `$(PathSeparator)` property in `Configuration.props` to
use the right path separator on each platform.
When running the build on Windows you see:
FrameworkPathOverride = \bin\Debug\lib\xamarin.android\xbuild-frameworksMonoAndroid\v1.0
set during the build. Turns out we need to set `$(NoStdLib)`=true since we
are using a custom `mscorlib.dll`. This prevents the path getting messed
up on Windows.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58889
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=58890
Commit 0667a2b6 and ea6b9b45 added support for short path names.
However during the rework we added code to replace
library_project_imports/
with an empty string. Some of the Nuget Support packages seem
to include a `__AndroidLibraryProjects__.zip` which uses
windows path sepatators rather than unix ones. So the code
to strip off the `library_project_imports/` does not work.
We end up with a directory structure like
__library_projects__/[dllname]/library_project_imports/library_project_imports
which a) does not get picked up by our tasks and b) takes up
a bunch of additional characters in our already long path..
The result is the two errors above... one to do with missing resources
the other a PathToLong error.
Because the nuget packages have already shipped and will be in use,
we need to handle BOTH cases.
We are going to add a bunch of new targets for the designer.
This is so if we make changes to the file structure there will
be no need for the designer to alter code.
However we do need to alter the targets a bit. In this case we
only want to pass the `$(OutDir)$(TargetFileName)` if it exists.
Otherwise the task will error. In the case of the designer this
will happen quite allot because the project might not have been
built yet.
The Jenkins emulator-based tests are hanging -- again (see also
db668ba) -- this time with a new message:
[emulator stderr] Unknown hax vcpu return 1
I don't know what it means, other than "nothing is going to happen for
hours on end." Add an `emulator` stderr check for the above message,
and bail out early if it's seen so that we don't lose hours waiting
for a Job timeout to occur...
`monodroid.mdproj` was generating `jni/config.include` and
`jni/machine.config.include` using the `xxd` and `sed` commands,
which will not work on Windows.
Changes:
* Added a new MSBuild task, `GenerateMonoDroidIncludes` that
replicates the `xxd` output in C#
* Cleaned up the `<ItemGroup>` to have `@(_EmbeddedBlobSource)` and
`@(_EmbeddedBlobDestination)`
* We are no longer using `xxd` anywhere so this can be removed from
`dependencies.projitems`, `linux-prepare-Arch.sh`, and `README.md`
Jonathan Pryor
Dean Ellis
Daniel Cazzulino
Nathan Westfall
Bret Johnson
Marek Habersack
Jonathan Peppers
Radek Doulik
Jon Douglas
Atsushi Eno
Jérémie Laval