Try xamarin/xamarin-android-tools#169 #7073
Merged
Conversation
This file contains hidden or 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
Contributor
Author
|
The Which is: #6774 (comment)
Use of As .NET 6 is now GA, and Classic Xamarin.Android has been emitting an XA1023 warning regarding We will remove support for This is a change that customers will need to do anyway in order to migrate to .NET 6, and it will allow us to use a newer build-tools version. |
Contributor
Author
|
Dropping support for |
jonpryor
force-pushed
the
jonp-try-xat-169
branch
6 times, most recently
from
2c6be0d to
24a4781
Compare
Contributor
Author
|
The It confuses me because I don't understand how this works on main! The failure in this PR: Note that the input parameter The test asserts that The reason this confuses me is because the
It tries the
Windows is the same but different: instead of Thus, my question: how does this work on main? How does it not always fail because of "Even Better", when I try to use @dellis1972: what am I missing? And how does this PR impact |
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 9, 2022
Context: dotnet#7073 Context: dotnet#7073 (comment) How does `InstallAndroidDependenciesTest()` pass?! Let's Find Out?
Contributor
Author
|
I wondered 🤔 :
Enter PR #7081, which updates var _configPath = Path.Combine (Environment.GetFolderPath (Environment.SpecialFolder.ApplicationData), "xbuild", "monodroid-config.xml");
bool haveConfigPath = File.Exists (_configPath);
// …
throw new Exception ($"# jonp: deliberate test failure! File.Exist(\"{_configPath}\")? {haveConfigPath}");It works on main+macOS because I'm not sure why it works on Windows; I would have to assume that it lacks the Registry entries which specify where the Android SDK is located. TODO: update this PR to verify that it does have |
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 9, 2022
Context: dotnet#7081 Context: dotnet#7073 (comment) Trying to figure out why the `InstallAndroidDependenciesTest()` is failing. My *guess* is that `monodroid-config.xml` exists, causing the `$(_AndroidSdkPath)` output property to use a *system-wide* installation path, instead of the desired `$(AndoridSdkDirectory)` input value. PR dotnet#7081 tested behavior against main, and determined that `monodroid-config.xml` doesn't exist, which may be why this test passes on main. Update dotnet#7073 to also assert the (non-?)existence of `monodroid-config.xml`. If it *does* exist, this would explain why it's failing. *If* it's failing because of `monodroid-config.xml`, the next question becomes *why* it exists. Update `BaseTest.TestSetup()` to assert that it doesn't exist; when it does exist, tests will begin failing.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 10, 2022
Context: dotnet#7081 Context: dotnet#7073 (comment) Trying to figure out why the `InstallAndroidDependenciesTest()` is failing. My *guess* is that `monodroid-config.xml` exists, causing the `$(_AndroidSdkPath)` output property to use a *system-wide* installation path, instead of the desired `$(AndoridSdkDirectory)` input value. PR dotnet#7081 tested behavior against main, and determined that `monodroid-config.xml` doesn't exist, which may be why this test passes on main. Update dotnet#7073 to also assert the (non-?)existence of `monodroid-config.xml`. If it *does* exist, this would explain why it's failing. *If* it's failing because of `monodroid-config.xml`, the next question becomes *why* it exists. Update `BaseTest.TestSetup()` to assert that it doesn't exist; when it does exist, tests will begin failing.
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
2e31b9d to
95abe16
Compare
Contributor
Author
|
Followup on my earlier comment, I should have looked at the build log of the success build: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6266673&view=ms.vss-test-web.build-test-results-tab&runId=43411452&resultId=100168&paneView=attachments Of note is: Meaning it never gets around to looking for Compare to this PR: Why doesn't This is the validation logic: https://github.com/xamarin/xamarin-android-tools/blob/20f611202bef0fc7c1659366dd38865eb119dde5/src/Xamarin.Android.Tools.AndroidSdk/Sdks/AndroidSdkBase.cs#L258-L263 public bool ValidateAndroidSdkLocation ([NotNullWhen (true)] string? loc)
{
bool result = !string.IsNullOrEmpty (loc) && ProcessUtils.FindExecutablesInDirectory (Path.Combine (loc, "platform-tools"), Adb).Any ();
Logger (TraceLevel.Verbose, $"{nameof (ValidateAndroidSdkLocation)}: `{loc}`, result={result}");
return result;
}meaning it wants a How would Would something else be creating the |
Contributor
|
This is very weird. It might be that some logic in xamarin-androidt-tools changed since we last bumped. Given we provide an empty directory for the sdk for the test, it suggests that we didn't used to validate it. But now we are.... 🤷 |
Contributor
Author
|
@dellis1972: the only change is a change to I'm having trouble wrapping my head around how a property value change would cause |
Contributor
Author
From the build log: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6268031&view=logs&j=28e101f7-a5d4-5072-d882-1de9b1157eea&t=013f663a-211c-5fb0-6deb-0fdb51486b69 meaning that |
Contributor
Author
|
I'm starting to think its the cmdline-tools bump (?!). "Good" run (with extra newlines): "Bad" run: The --- GOOD.txt 2022-06-10 09:06:36.000000000 -0400
+++ BAD.txt 2022-06-10 09:06:03.000000000 -0400
@@ -1,26 +1,29 @@
Task "ResolveSdks"
- Task Parameter:CommandLineToolsVersion=5.0
+ Task Parameter:CommandLineToolsVersion=7.0
Task Parameter:ReferenceAssemblyPaths=/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/
Task Parameter:AndroidSdkPath=/Users/runner/work/1/a/TestRelease/DATE/temp/InstallAndroidDependenciesTest/android-sdk
Task Parameter:JavaSdkPath=/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.15-10/x64/Contents/Home/
Task Parameter:LatestSupportedJavaVersion=11.0.99
Task Parameter:MinimumSupportedJavaVersion=1.6.0
- ValidateAndroidSdkLocation: `/Users/runner/work/1/a/TestRelease/DATE/temp/InstallAndroidDependenciesTest/android-sdk`, result=True
+ ValidateAndroidSdkLocation: `/Users/runner/work/1/a/TestRelease/DATE/temp/InstallAndroidDependenciesTest/android-sdk`, result=False
+ ValidateAndroidSdkLocation: ``, result=False
+ ValidateAndroidSdkLocation: `/Users/runner/Library/Android/sdk`, result=True
ValidateJavaSdkLocation: `/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.15-10/x64/Contents/Home/`, result=True
ValidateAndroidNdkLocation: ``, result=False
- ValidateAndroidNdkLocation: ``, result=False
- ValidateAndroidNdkLocation: `/Users/runner/Library/Android/sdk/ndk-bundle`, result=True
+ Skipping NDK in '/Users/runner/Library/Android/sdk/ndk/24.0.8215888': version 24.0.8215888 is out of the accepted range (major version must be between 16 and 23
+ Best NDK selected: v23.2.8568313 in /Users/runner/Library/Android/sdk/ndk/23.2.8568313
+ ValidateAndroidNdkLocation: `/Users/runner/Library/Android/sdk/ndk/23.2.8568313`, result=True
ResolveSdks Outputs:
- AndroidSdkPath: /Users/runner/work/1/a/TestRelease/DATE/temp/InstallAndroidDependenciesTest/android-sdk
- AndroidNdkPath: /Users/runner/Library/Android/sdk/ndk-bundle
+ AndroidSdkPath: /Users/runner/Library/Android/sdk
+ AndroidNdkPath: /Users/runner/Library/Android/sdk/ndk/23.2.8568313
JavaSdkPath: /Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.15-10/x64/Contents/Home/
MonoAndroidBinPath: /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/
MonoAndroidToolsPath: /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android
AndroidBinUtilsPath: /Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/binutils/bin/
- Output Property: _AndroidToolsDirectory=/Users/runner/work/1/a/TestRelease/DATE/temp/InstallAndroidDependenciesTest/android-sdk/cmdline-tools/5.0
- Output Property: AndroidNdkDirectory=/Users/runner/Library/Android/sdk/ndk-bundle
- Output Property: _AndroidNdkDirectory=/Users/runner/Library/Android/sdk/ndk-bundle
- Output Property: _AndroidSdkDirectory=/Users/runner/work/1/a/TestRelease/DATE/temp/InstallAndroidDependenciesTest/android-sdk
+ Output Property: _AndroidToolsDirectory=/Users/runner/Library/Android/sdk/cmdline-tools/7.0
+ Output Property: AndroidNdkDirectory=/Users/runner/Library/Android/sdk/ndk/23.2.8568313
+ Output Property: _AndroidNdkDirectory=/Users/runner/Library/Android/sdk/ndk/23.2.8568313
+ Output Property: _AndroidSdkDirectory=/Users/runner/Library/Android/sdk
Output Property: _JavaSdkDirectory=/Users/runner/hostedtoolcache/Java_Temurin-Hotspot_jdk/11.0.15-10/x64/Contents/Home/
Output Property: MonoAndroidToolsDirectory=/Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android
Output Property: MonoAndroidBinDirectory=/Library/Frameworks/Xamarin.Android.framework/Libraries/xbuild/Xamarin/Android/Darwin/ |
jonpryor
added a commit
to dotnet/android-tools
that referenced
this pull request
Jun 10, 2022
Context: dotnet/android#7073 (comment) I *suspect* that bumping `$(AndroidCommandLineToolsVersion)`=7.0 is causing the `InstallAndroidDependenciesTest()` unit test to fail, though I don't understand why. Reset `$(AndroidCommandLineToolsVersion)`=5.0, and see if that fixes things.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 10, 2022
Context: dotnet#7073 (comment) I suspect that `$(AndroidCommandLineToolsVersion)`=7.0 is causing the `InstallAndroidDependenciesTest()` unit test to fail. Bump to a xamarin-android-tools commit which resets `$(AndroidCommandLineToolsVersion)`=5.0. Does that help?
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
95abe16 to
b72b613
Compare
Contributor
Author
How does it work, and why does it fail? |
jonpryor
added a commit
to dotnet/android-tools
that referenced
this pull request
Jun 10, 2022
Context: dotnet/android#7073 Context: https://github.com/xamarin/xamarin-android/blob/fdfc4c44ba65fcff9caf809bcf2d1f1a6837b1e3/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/AndroidDependenciesTests.cs#L19-L50 Trying to figure out how xamarin-android's `AndroidDependenciesTests.InstallAndroidDependenciesTest()` *passes*; it creates an empty "SDK" directory, then builds with the `InstallAndroidDependencies` target, and on main this works, *even though* it implies that it's creating an `AndroidSdkInfo` instance with an *empty* SDK directory: if (Directory.Exists (sdkPath)) Directory.Delete (sdkPath, true); Directory.CreateDirectory (sdkPath); // `sdkPath` is not otherwise populated Yet it *passes* `ValidateAndroidSdkLocation()`: ValidateAndroidSdkLocation: `/Users/runner/work/1/a/TestRelease/06-09_22.00.22/temp/InstallAndroidDependenciesTest/android-sdk`, result=True I do not understand *how* this can be the case, as `ValidateAndroidSdkLocation()` wants a `platform-tools/adb` program, *which should not exist*, yet it validates I am thus very confused. Expand the log messages provided by `AndroidSdkBase` & co. so that we also log "where" the `loc` parameter is coming from, via a new `locator` parameter (similar to the `locator` parameter in `JdkInfo`), and update the "file check" logic so that we log the path of the detected files. This way, hopefully, I can verify that it *is* finding an `adb`, and *where that file is located*.
Contributor
Author
|
In the continuing front of wait, what?:
Behold! The result of which is… Which contains a typo (doh!), as it's traversing At least we have the Build log: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6270405&view=ms.vss-test-web.build-test-results-tab&runId=43504898&resultId=100035&paneView=attachments The constructor parameter path contains |
Contributor
Author
After fixing that, things seem more reasonable: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6270985&view=logs&j=0c842711-95d4-557a-1ed2-7d41f084dcd8&t=fec3f8b3-86d0-50bb-f604-0b1ef7bd29c7 i.e. the empty directory is empty (yay), and then isn't empty after running the So something else is going on, so I updated commit 0e29341d256edd3d2c855cbc5cb09104910e8570
Author: Jonathan Pryor <[email protected]>
Date: Fri Jun 10 13:08:37 2022 -0400
MOAR LOGGING
How does `ValidateAndroidSdkLocation()` accept a (what should be)
empty directory?
diff --git a/src/Xamarin.Android.Build.Tasks/Tasks/ResolveSdksTask.cs b/src/Xamarin.Android.Build.Tasks/Tasks/ResolveSdksTask.cs
index a93bdb235..f59997431 100644
--- a/src/Xamarin.Android.Build.Tasks/Tasks/ResolveSdksTask.cs
+++ b/src/Xamarin.Android.Build.Tasks/Tasks/ResolveSdksTask.cs
@@ -96,6 +96,13 @@ namespace Xamarin.Android.Tasks
JavaSdkPath = MonoAndroidHelper.GetJdkInfo (this.CreateTaskLogger (), JavaSdkPath, minVersion, maxVersion)?.HomePath;
+ if (Directory.Exists (AndroidSdkPath)) {
+ Log.LogDebugMessage ($"# jonp: AndroidSdkPath={AndroidSdkPath}; contents");
+ foreach (var p in Directory.EnumerateFileSystemEntries (AndroidSdkPath, "*", SearchOption.AllDirectories)) {
+ Log.LogDebugMessage ("# jonp: {p}");
+ }
+ }
+
MonoAndroidHelper.RefreshSupportedVersions (ReferenceAssemblyPaths);
try {and the build log contains: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6270985&view=ms.vss-test-web.build-test-results-tab&runId=43530374&resultId=100035&paneView=attachments (Yet another typo; I forgot to use There are lots of those Why/How? And now I think we get to the crux of the problem: we're not preserving all of the build logs.
A careful reading shows two Meaning the only Oof. |
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 10, 2022
Context: dotnet#7073 (comment) The story so far… Why does `InstallAndroidDependenciesTest()` fail? We still don't know. However, we know that the unit test fails because the `Build` step is using the wrong SDK directory, and it's using the wrong SDK directory because the `InstallAndroidDependencies` target failed! Worse, we don't know *why* it failed, because the log file for the `InstallAndroidDependencies` target is *overwritten* by the `Build` target on the next run! Update `InstallAndroidDependenciesTest()` so that a different log file is used for the `InstallAndroidDependencies` target. Maybe then we can get some useful details?
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 11, 2022
Context: dotnet#7073 (comment) I *think* `InstallAndroidDependenciesTest()` should pass now.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 11, 2022
Context: dotnet#7073 (comment) The story so far… Why does `InstallAndroidDependenciesTest()` fail? We still don't know. However, we know that the unit test fails because the `Build` step is using the wrong SDK directory, and it's using the wrong SDK directory because the `InstallAndroidDependencies` target failed! Worse, we don't know *why* it failed, because the log file for the `InstallAndroidDependencies` target is *overwritten* by the `Build` target on the next run! Update `InstallAndroidDependenciesTest()` so that a different log file is used for the `InstallAndroidDependencies` target. Maybe then we can get some useful details?
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 11, 2022
Context: dotnet#7073 (comment) I *think* `InstallAndroidDependenciesTest()` should pass now.
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
9d5c35e to
1d5aa8d
Compare
jonpryor
added a commit
to dotnet/android-tools
that referenced
this pull request
Jun 13, 2022
…170) Context: dotnet/android#7073 Context: https://github.com/xamarin/xamarin-android/blob/fdfc4c44ba65fcff9caf809bcf2d1f1a6837b1e3/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/AndroidDependenciesTests.cs#L19-L50 I was trying to figure out how xamarin-android's `AndroidDependenciesTests.InstallAndroidDependenciesTest()` *passes*; the test creates an empty "SDK" directory, then builds with the `InstallAndroidDependencies` target, then builds the `Build` target, then asserts that the used SDK directory matches the "temp" directory. The cause of the confusion was twofold: 1. Two targets were run, but they both wrote to the same log file, and thus any output from the `InstallAndroidDependencies` target was *lost*, which meant 2. When reviewing the output of the `Build` target -- the *only* output for quite some time -- I started searching for "other possibilities" for why it would work, e.g. "it's not using the constructor parameter, but rather `monodroid-config.xml`", which needed to be separately investigated and discarded. The investigation is done -- the problems were that the log file needed to understand what was going wrong didn't exist, and that the `platform-tools` 32.0.0 package didn't exist in the GoogleV2 manifest, and thus `platform-tools` wasn't installed, and thus `adb` wasn't found, causing `ValidateAndroidSdkLocation()` to skip it -- but the additional contextual log information could be useful for future investigations. Expand the log messages provided by `AndroidSdkBase` & co. so that we also log "where" the `loc` parameter is coming from, via a new `locator` parameter (similar to the `locator` parameter in `JdkInfo`), and update the "file check" logic so that we log the path of the detected files.
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
1d5aa8d to
8f28c75
Compare
Contributor
Author
In fact, it did work; the Unfortunately, now ~everything dealing with the NDK on Windows is failing (?), via two separate "patterns". Pattern 1: Not sure why one has the path to Pattern 2: I've seen this scenario with three different NDK versions specified in xamarin-android-tools, so I'm starting to suspect it's not related to I'm not sure what to look into, though. |
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 13, 2022
Context: dotnet#7073 (comment) Dump out the NDK dir structure, see if `readelf` exists.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 13, 2022
Context: dotnet#7073 (comment) The story so far… Why does `InstallAndroidDependenciesTest()` fail? We still don't know. However, we know that the unit test fails because the `Build` step is using the wrong SDK directory, and it's using the wrong SDK directory because the `InstallAndroidDependencies` target failed! Worse, we don't know *why* it failed, because the log file for the `InstallAndroidDependencies` target is *overwritten* by the `Build` target on the next run! Update `InstallAndroidDependenciesTest()` so that a different log file is used for the `InstallAndroidDependencies` target. Maybe then we can get some useful details?
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 13, 2022
Context: dotnet#7073 (comment) I *think* `InstallAndroidDependenciesTest()` should pass now.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 13, 2022
Context: dotnet#7073 (comment) Dump out the NDK dir structure, see if `readelf` exists.
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
794a3fc to
63fa39c
Compare
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 14, 2022
Context: dotnet#7073 (comment) The story so far… Why does `InstallAndroidDependenciesTest()` fail? We still don't know. However, we know that the unit test fails because the `Build` step is using the wrong SDK directory, and it's using the wrong SDK directory because the `InstallAndroidDependencies` target failed! Worse, we don't know *why* it failed, because the log file for the `InstallAndroidDependencies` target is *overwritten* by the `Build` target on the next run! Update `InstallAndroidDependenciesTest()` so that a different log file is used for the `InstallAndroidDependencies` target. Maybe then we can get some useful details?
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 14, 2022
Context: dotnet#7073 (comment) I *think* `InstallAndroidDependenciesTest()` should pass now.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 14, 2022
Context: dotnet#7073 (comment) Dump out the NDK dir structure, see if `readelf` exists.
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
63fa39c to
723077c
Compare
jonpryor
added a commit
to dotnet/android-tools
that referenced
this pull request
Jun 15, 2022
Context: dotnet/android#7073 (comment) I *think* this will fix `InstallAndroidDependenciesTest()`.
Context: dotnet/android-tools#169 Context: https://dl-ssl.google.com/android/repository/repository2-3.xml Context: 22bc14b Turn XA1023 into an error. Commit xamarin/xamarin-android-tools@TODO_HASH bumps `$(AndroidSdkBuildToolsVersion)` to 32.0.0, which was the latest non- preview `build-tools` package version on 2022-06-06. The "problem" is that [build-tools 31.0.0 *removed* `dx`][0], and thus Classic Xamarin.Android has stuck with build-tools 30.0.0 as the default version for years. Commit 22bc14b introduced warning XA1023 (an *error* in .NET 5+), as we saw no reason to support `dx` in .NET 5 when it was already deprecated. Warning XA1023 has been emitted in Classic Xamarin.Android since Visual Studio 16.9 (released 2021-Mar); we feel there has been ample time to migrate away from `dx` and to the replacement of `d8`. Turn XA1023 into an *error* for Classic Xamarin.Android builds, ensuring things are consistent between Classic Xamarin.Android and .NET 6+. Commit xamarin/xamarin-android-tools@TODO_HASH *also* bumps `$(AndroidCommandLineToolsVersion)` to 7.0. Update `$(CommandLineToolsVersion)` in `Configuration.props` accordingly. The `cmdline-tools` package v7.0 contains contains [`lint` 7.2][1], which introduces a new `lint` check called `RedundantLabel`: > Redundant label on activity in manifest meaning that the `//actviity/@android:label` value is identical to the `//application/@android:label` value, and thus isn't needed. This causes a warning from `BuildTest.CheckLintErrorsAndWarnings()`: obj/Debug/android/AndroidManifest.xml(12,44): warning XA0102: Redundant label can be removed [RedundantLabel] For now, update `BuildTest.CheckLintErrorsAndWarnings()` to ignore `RedundantLabel` warnings. TODO: Remove support for `dx` and ProGuard. [0]: https://android-developers.googleblog.com/2020/02/the-path-to-dx-deprecation.html [1]: http://googlesamples.github.io/android-custom-lint-rules/usage/changes.md.html
jonpryor
force-pushed
the
jonp-try-xat-169
branch
from
723077c to
bb93422
Compare
Need to make use of `mainDexClasses.rules` conditional, as it
does not exist in build-tools 33.0.0, resulting in:
java.lang.RuntimeException: com.android.tools.r8.internal.f: Failed to read file: C:\Android\android-sdk\build-tools\33.0.0\mainDexClasses.rules
This reverts commit f86fedc. Build-tools 33.0.0 causes unit test failures, e.g. Error: Cannot fit requested classes in a single dex file (# methods: 68000 > 65536) This appears to be because build-tools 33.0.0 no longer contains `mainDexClasses.rules`, so linking doesn't *do* as much. Revert to build-tools 32.0.0.
jonathanpeppers
approved these changes
Jun 15, 2022
Comment on lines
202
to
207
| protected static void AssertDexToolSupported (string dexTool) | ||
| { | ||
| if (Builder.UseDotNet && dexTool == "dx") { | ||
| Assert.Ignore ("dx is not supported in .NET 5+"); | ||
| if (dexTool == "dx") { | ||
| Assert.Ignore ("dx is not supported"); | ||
| } | ||
| } |
Member
There was a problem hiding this comment.
We could delete this method instead and test parameters for dx, but I can do that after this goes in.
pjcollins
approved these changes
Jun 15, 2022
Contributor
Author
Bump to xamarin/xamarin-android-tools/main@9c641b3e
Context: https://github.com/xamarin/xamarin-android-tools/pull/169
Context: https://dl-ssl.google.com/android/repository/repository2-3.xml
Context: 22bc14b1a89352824d2a54f6e12a4dbeaa6fe679
Changes: https://github.com/xamarin/xamarin-android-tools/compare/ec346d07cf3ac7fc74d08eae4f19043b51485724...9c641b3e08e56db37467a64a2c5de2c7f7ddb3ef
* xamarin/xamarin-android-tools@9c641b3 [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-32 (#169)
Commit xamarin/xamarin-android-tools@9c641b3 bumps
`$(AndroidSdkBuildToolsVersion)` to 32.0.0. (We looked at bumping
to 33.0.0, but that broke various unit tests; we will investigate
supporting build-tools 33.0.0 later.)
The "problem" is that [build-tools 31.0.0 *removed* `dx`][0], and
thus Classic Xamarin.Android has stuck with build-tools 30.0.0 as the
default version for years.
Commit 22bc14b1 introduced warning XA1023 (an *error* in .NET 5+),
as we saw no reason to support `dx` in .NET 5 when it was already
deprecated.
Warning XA1023 has been emitted in Classic Xamarin.Android since
Visual Studio 16.9 (released 2021-Mar); we feel there has been ample
time to migrate away from `dx` and to the replacement of `d8`.
Turn XA1023 into an *error* for Classic Xamarin.Android builds,
ensuring things are consistent between Classic Xamarin.Android and
.NET 6+.
Commit xamarin/xamarin-android-tools@9c641b3 *also* bumps
`$(AndroidCommandLineToolsVersion)` to 7.0. Update
`$(CommandLineToolsVersion)` in `Configuration.props` accordingly.
The `cmdline-tools` package v7.0 contains contains [`lint` 7.2][1],
which introduces a new `lint` check called `RedundantLabel`:
> Redundant label on activity in manifest
meaning that the `//actviity/@android:label` value is identical to
the `//application/@android:label` value, and thus isn't needed.
This causes a warning from `BuildTest.CheckLintErrorsAndWarnings()`:
obj/Debug/android/AndroidManifest.xml(12,44): warning XA0102:
Redundant label can be removed [RedundantLabel]
For now, update `BuildTest.CheckLintErrorsAndWarnings()` to ignore
`RedundantLabel` warnings.
TODO:
Remove support for `dx` and ProGuard.
[0]: https://android-developers.googleblog.com/2020/02/the-path-to-dx-deprecation.html
[1]: http://googlesamples.github.io/android-custom-lint-rules/usage/changes.md.html |
jonathanpeppers
pushed a commit
that referenced
this pull request
Jun 30, 2022
Context: https://dl-ssl.google.com/android/repository/repository2-3.xml Context: 22bc14b Changes: dotnet/android-tools@ec346d0...9c641b3 * dotnet/android-tools@9c641b3 [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-32 (#169) Commit dotnet/android-tools@9c641b3 bumps `$(AndroidSdkBuildToolsVersion)` to 32.0.0. (We looked at bumping to 33.0.0, but that broke various unit tests; we will investigate supporting build-tools 33.0.0 later.) The "problem" is that [build-tools 31.0.0 *removed* `dx`][0], and thus Classic Xamarin.Android has stuck with build-tools 30.0.0 as the default version for years. Commit 22bc14b introduced warning XA1023 (an *error* in .NET 5+), as we saw no reason to support `dx` in .NET 5 when it was already deprecated. Warning XA1023 has been emitted in Classic Xamarin.Android since Visual Studio 16.9 (released 2021-Mar); we feel there has been ample time to migrate away from `dx` and to the replacement of `d8`. Turn XA1023 into an *error* for Classic Xamarin.Android builds, ensuring things are consistent between Classic Xamarin.Android and .NET 6+. Commit dotnet/android-tools@9c641b3 *also* bumps `$(AndroidCommandLineToolsVersion)` to 7.0. Update `$(CommandLineToolsVersion)` in `Configuration.props` accordingly. The `cmdline-tools` package v7.0 contains contains [`lint` 7.2][1], which introduces a new `lint` check called `RedundantLabel`: > Redundant label on activity in manifest meaning that the `//actviity/@android:label` value is identical to the `//application/@android:label` value, and thus isn't needed. This causes a warning from `BuildTest.CheckLintErrorsAndWarnings()`: obj/Debug/android/AndroidManifest.xml(12,44): warning XA0102: Redundant label can be removed [RedundantLabel] For now, update `BuildTest.CheckLintErrorsAndWarnings()` to ignore `RedundantLabel` warnings. TODO: Remove support for `dx` and ProGuard. [0]: https://android-developers.googleblog.com/2020/02/the-path-to-dx-deprecation.html [1]: http://googlesamples.github.io/android-custom-lint-rules/usage/changes.md.html
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: dotnet/android-tools#169
Does It Build™?