-
Notifications
You must be signed in to change notification settings - Fork 535
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Xamarin.Android.Build.Tasks] fix for UseLatest when API level not in…
…stalled (#2018) Fixes: #2007 Apparently there is a situation we aren't doing the right thing for: - `$(TargetFrameworkVersion)`=v9.0 - `$(AndroidUseLatestPlatformSdk)`=True - API 28 is not installed In this case, we *should* be downgrading `$(TargetFrameworkVersion)` to `v8.1`. Instead we get: ResolveSdksTask Outputs: AndroidApiLevel: 27 AndroidApiLevelName: 27 TargetFrameworkVersion: v9.0 This puts us in a weird state, since we would use `.jar` files for different API levels: - `platforms/android-27/android.jar` - `xbuild-frameworks/MonoAndroid/v9.0/mono.android.jar` This in turn causes `proguard` (and likely other things) to fail: PROGUARD : warning : there were 38 unresolved references to classes or interfaces. You may need to add missing library jars or update their versions. If your code works fine without the missing classes, you can suppress the warnings with '-dontwarn' options. (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass) The fix here is somewhat complicated: 1. Starting at `maxSupported` API level, check to see if: 2. An Android API directory corresponding to `maxSupported` exists, e.g. `platforms/android-28`, and 3. A `$(TargetFrameworkVersion)` directory corresponding to (2) exists such as `MonoAndroid/v9.0`. 4. Decrement `maxSupported` until a value which satisfies *both* (2) and (3) is found. Add a parameterized test cases verifying that the right thing is happening when `$(AndroidUseLatestPlatformSdk)`=True and different API levels are actually installed. Other changes: - Refactored a bit to not call `int.TryParse()` when not needed. We could just use the `int` value and call `ToString()` in a better order. - One existing test case had an incorrect failure message; fixed. Finally, remove `$(_SupportedApiLevel)`. This MSBuild property appears to be vestigial, and was causing confusion but had no real benefit, i.e. as `$(_SupportedApiLevel)` is used to generate the `ANDROID_X` values in `<GetAndroidDefineConstants/>`, what possible value is there in allowing it to be *higher* than `$(TargetFrameworkVersion)`, which controls which `Mono.Android.dll` the source code is compiled against? It appears that we can just remove `$(_SupportedApiLevel)`, and use `$(_AndroidApiLevel)` in its place. I also checked private repos, and could find nothing that is using this property.
- Loading branch information
1 parent
7ef79b7
commit 414538b
Showing
4 changed files
with
155 additions
and
22 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters