[Xamarin.Android.Build.Tasks] Dont clean the designtime folder #1074
Conversation
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
Context https://bugzilla.xamarin.com/show_bug.cgi?id=60880 Turns out the design time build in Visual Studio does not clean up after itself.. ever. So we really should not be deleting the directory on a `Clean`. This commit move that code into is own internal target and updates the tests to reflect the changes.
luhenry
pushed a commit
to luhenry/xamarin-android
that referenced
this pull request
Feb 16, 2018
The Android emulator is a "wonderful" beast. Case in point: [PR Build dotnet#1074][0], which *hung* during emulator startup, for *5 hours*: 09:13:49 Hax is enabled 09:13:49 Hax ram_size 0x0 09:13:49 HAX is working and emulator runs in fast virt mode. ... 09:13:56 adb I 06-21 09:13:56 47148 21294922 adb_io.cpp:75] readx: fd=3 wanted=4 ... # 5.5 hours later... 14:47:17 Tool /Users/builder/android-toolchain/sdk/platform-tools/adb execution finished. It "finished" because I manually killed the Job, as it had take over 6 *hours*, cumulative, to do nothing. (*Arguably* we shouldn't have a 10 hour timeout on Jenkins jobs, but Mono bumps can take upwards of 6 hours to build, so a 6 hour time isn't necessarily unusual...) This also isn't our first attempt at improving emulator reliability. See also commits c089267, bc6440b, 3fa9e9e, b54f8cd, 3b893cd, 7450efc, and 6358a64. (Is that enough? Likely not. Is that all of them? Probably not.) Take yet another stab at improving things: in this case, improving error checking, so that *when* an error occurs we can *fail early*, as opposed to waiting for hours on end for a Jenkins timeout to occur *or* for me to get annoyed at general Jenkins build slowness enough to track down the hung job and manually kill it... Update the `emulator` process launch so that we have event handlers for stdout and stderr messages, so that we can look for currently known error conditions, which fall into two categories: 1. HAXM needs reinstallation, or 2. Another VM is in use. HAXM appears to need reinstallation when no memory is allocated: Hax ram_size 0x0 I don't know *why* HAXM would require *re*-installation in these circumstances, but that generally appears to fix the problem. When another VM is in use, e.g. when I'm running a Veertu VM on macOS, `emulator` also fails to launch, writing the following to stderr: Failed to sync vcpu reg Failed to sync HAX vcpu contextInternal error: Initial hax sync failed If either of these conditions occur, the `<StartAndroidEmulator/>` task should *fail*, with a (hopefully) relevant error message. With these changes in place, remove the `<Sleep/>` task invocations from the `AcquireAndroidTarget` target, as the new 20 *second* timeout in `<StartAndroidEmulator/>` removes the need for the first Sleep, and the 2nd sleep doesn't appear to do any good. Followup to c089267! > in case the added sleep doesn't help, we might at least get some > more useful information We do get more information. It's not entirely *useful*: `adb` is waiting for `adbd` to provide it information, and that information never arrives: adb I 06-21 09:13:56 47148 21294922 adb_io.cpp:75] readx: fd=3 wanted=4 ...and there it waits, seemingly forever, until Job timeout or Job death occurs. [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/1074/
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Feb 1, 2020
Changes: xamarin/monodroid@017b361...01a4e0a Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1033784 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1035905 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/946984 Context: icsharpcode/SharpZipLib#356 * xamarin/monodroid@01a4e0a0c: Bump to xamarin/androidtools@2ffbfcb7 (dotnet#1074) * xamarin/monodroid@987ce4d1b: Remove external/debugger-libs (dotnet#1072) * xamarin/monodroid@7ded15051: Bump to mono/debugger-libs@5e5b5efb (dotnet#1071) * xamarin/monodroid@072746460: Bump to xamarin/android-sdk-installer@c694d0da (dotnet#1070)
jonpryor
added a commit
that referenced
this pull request
Feb 1, 2020
Changes: xamarin/monodroid@017b361...01a4e0a Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1033784 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1035905 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/946984 Context: icsharpcode/SharpZipLib#356 * xamarin/monodroid@01a4e0a0c: Bump to xamarin/androidtools@2ffbfcb7 (#1074) * xamarin/monodroid@987ce4d1b: Remove external/debugger-libs (#1072) * xamarin/monodroid@7ded15051: Bump to mono/debugger-libs@5e5b5efb (#1071) * xamarin/monodroid@072746460: Bump to xamarin/android-sdk-installer@c694d0da (#1070)
jonpryor
pushed a commit
that referenced
this pull request
Feb 14, 2023
Remember CodeQL (acfc1ef)? CodeQL basically runs [GitHub LGTM][0] on source code, looking for possible security issues. Now that CodeQL is running, we can begin addressing reported issues. Add a `.lgtm.yml` file to exclude `cs/campaign/constantine`; this is a campaign asking for contact regarding certain constructs, and is just noise in the LGTM reporting page. Problems found include: * HttpClient created with CheckCertificateRevocationList disabled * Wrong type of arguments to formatting function * Weak cryptography * Possible information leakage from uninitialized padding bytes * ML Training and Serialization Files Referenced ~~ HttpClient created with CheckCertificateRevocationList disabled ~~ Apparently the `HttpClient` default constructor is "bad"; we should instead use the [`HttpClient(HttpMessageHandler)` constructor][1], provide our own `HttpClientHandler`, and ensure that [`HttpClientHandler.CheckCertificateRevocationList`][2] is True. ~~ Wrong type of arguments to formatting function ~~ Apparently LGTM doesn't realize that in C++ `long int` is synonymous with `long`, and thus warns that they're not the same. 🤦 Remove a cast to `long int`. ~~ Weak cryptography ~~ This is in `AuthDigestSession.cs`. Unfortunately, RFC2617 requires MD5, so we kinda need to use MD5. Add a `// lgtm [cs/weak-crypto]` comment to disable the warning. ~~ Possible information leakage from uninitialized padding bytes ~~ This is in `cpp-util.hh`, and it seems that LGTM doesn't appreciate our use of template metaprogramming to construct a `char_array<Len+1>` wherein `Len` is computed at compile time with no wasted padding. ~~ ML Training and Serialization Files Referenced ~~ LGTM apparently assumes that mentions of `.pb` are mentions of ML data training files. In our case, these were part of error messages from `aapt2` that we were attempting to translate. Add a `//lgtm [csharp/responsible-ai/ml-training-and-serialization-files-referenced]` comment to disable this warning. Co-authored-by: Alex Hsu <[email protected]> [0]: https://github.com/marketplace/lgtm [1]: https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.-ctor?view=netstandard-2.0#system-net-http-httpclient-ctor(system-net-http-httpmessagehandler) [2]: https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.checkcertificaterevocationlist?view=net-7.0
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Feb 14, 2023
* main: [lgtm] Fix LGTM-reported issues (dotnet#1074)
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Feb 14, 2023
* main: [lgtm] Fix LGTM-reported issues (dotnet#1074) [ci] Report issues in the API docs build log (dotnet#7784)
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Feb 17, 2023
* main: [tests] Bump NUnit versions to latest (dotnet#7802) [Microsoft.Android.Sdk.ILLink] target `net7.0` temporarily (dotnet#7803) [tests] `InstallAndroidDependenciesTest` can use `platform-tools` 34.0.0 (dotnet#7800) Bump to xamarin/Java.Interop/main@9e0a469 (dotnet#7797) [Xamarin.Android.Build.Tasks] FileWrites&libraryprojectimports.cache (dotnet#7780) Bump to dotnet/installer@d25a3bb 8.0.100-preview.2.23105.6 (dotnet#7769) [lgtm] Fix LGTM-reported issues (dotnet#1074) [ci] Report issues in the API docs build log (dotnet#7784)
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Feb 22, 2023
* main: Add Unit Test for testOnly apps (dotnet#7637) [build] Only build the latest API level (dotnet#7786) [Xamarin.Android.Build.Tasks] Improve aapt2+file not found handling (dotnet#7644) [MSBuildDeviceIntegration] Fix duplicated test parameter (dotnet#7809) [tests] Bump NUnit versions to latest (dotnet#7802) [Microsoft.Android.Sdk.ILLink] target `net7.0` temporarily (dotnet#7803) [tests] `InstallAndroidDependenciesTest` can use `platform-tools` 34.0.0 (dotnet#7800) Bump to xamarin/Java.Interop/main@9e0a469 (dotnet#7797) [Xamarin.Android.Build.Tasks] FileWrites&libraryprojectimports.cache (dotnet#7780) Bump to dotnet/installer@d25a3bb 8.0.100-preview.2.23105.6 (dotnet#7769) [lgtm] Fix LGTM-reported issues (dotnet#1074) [ci] Report issues in the API docs build log (dotnet#7784)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 https://bugzilla.xamarin.com/show_bug.cgi?id=60880
Turns out the design time build in Visual Studio does not
clean up after itself.. ever. So we really should not be
deleting the directory on a
Clean.This commit move that code into is own internal target
and updates the tests to reflect the changes.