Status Update
Comments
de...@google.com <de...@google.com> #2
Hey, sorry for coming back to this so late. We've never seen this. Without any repro steps it's going to be hard to do anything about it.
We've some cases where the Gradle daemon gets started but Studio cannot connect to it and the Studio side Gradle code handling connection to the daemon will keep spawning new ones if the connection does not get established. In this instance though the fact that the build window shows all these daemon running means that this is a different problem.
de...@google.com <de...@google.com> #3
Hello, I had the issue reproduce on first project open after upgrading Android Studio from JetBrains Toolbox. Note that the project has a buildSrc.
I think you can reproduce it with the same steps if nothing changed since Arctic Fox alpha 08.
de...@google.com <de...@google.com> #4
When you upgraded from the toolbox, can you indicate which version you started from and what you upgraded to?
ha...@google.com <ha...@google.com> #5
Yes, actually it's in the title of the issue: Canary 7 to 8 of Arctic Fox.
br...@google.com <br...@google.com> #6
oops, thanks :)
br...@google.com <br...@google.com>
no...@google.com <no...@google.com> #7
I just had that again when upgrading from AS BB Canary 2 to AS BB Canary 6. I am attaching screenshots and a screencast so you can see how it is materializing.
Note that for some reason, Gradle sync is complaining about JDK location while it was working perfectly on Canary 2 (and I only touched the AGP version), I don't know why and I don't plan to investigate that now, I'll just try to fix it and move it.
kb...@google.com <kb...@google.com> #8
no...@google.com <no...@google.com> #9
ma...@google.com <ma...@google.com> #10
Wait, I cannot view my own restricted content? 😒
Description
Below is a list of tests in wifi_matfunc suite that have a passrate of less than 95%. These tests are not 'flaky' on all boards as most of them fail more often on a small subset of boards.
network_WiFi_PMKSACaching - flaky on all boards
network_WiFi_Reset - bob, epaulette, elm, hana*, kevin, krane, nyan_kitty, droid, scarlet*, veyron_*
network_WiFi_SimpleConnect.wifi_check1x_WEP - grunt*, kukui*, scarlet*
network_WiFi_SuspendStress.11g/24HT40/Hidden/VHT80/WEP40 - bob, epaulette, robo, drallion360, elm, careena, hana*, kevin, krane, droid, veyron_*
network_WlanRegulatory - bob, elm, kevin, veyron_*
Most network_WiFi_SuspendStress.* tests have fail rate in the 4-11% range.
Stainless link showing results for only pass and fail status:
I purpose moving network_WiFi_PMKSACaching to wifi_flaky
For network_WiFi_Reset and network_WiFi_SuspendStress, is there a real underlying issue related to suspend/resume on the listed boards? Should we disable the test on the affected boards? Move them to wifi_flaky?
For network_WlanRegulatory all the failure errors are "Expected iw to set regdomain 00 but got US". Do the listed devices not allow for the regulatory domain to be set properly?
network_WiFi_SimpleConnect.wifi_check1x_WEP fails only on devices with QCA 6174A wifi chip. Real issue?