You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commit 8e7d37b 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 8e7d37b; 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: #599 (comment)
Split the difference here by introducing `$(_SLN_BUILD)`: use
`xabuild` when building with `xbuild`, and continue using `msbuild`
when building with `msbuild`.
message:"AndroidManifest.xml //uses-sdk/@android:targetSdkVersion '{0}' is less than $(TargetFrameworkVersion) '{1}'. Using API-{2} for ACW compilation.",
Log.LogError("Could not find android.jar for API Level {0}. This means the Android SDK platform for API Level {0} is not installed. Either install it in the Android SDK Manager, or change your Android Bindings project to target an API version that is installed. ({1} missing.)",AndroidApiLevel,jarpath);
0 commit comments