Make lingering delay 2000ms in testMultipleLingering
Phenotype is updating the flags while this test is running
and this DoS'es the device to such an extent that the test
process doesn't get the CPU for more that 300ms. That lets
the lingering timeout run its course and fails the test.
This won't necessarily fix all flakes (after all, if
Phenotype hogs the CPU for 2 seconds the same issue will
continue to happen), but it should help.
Bug: 277555492
Test: FrameworksNetTests
Change-Id: I78ab1573974427b10dd557c011fbbf64942fd09f
diff --git a/tests/unit/java/com/android/server/ConnectivityServiceTest.java b/tests/unit/java/com/android/server/ConnectivityServiceTest.java
index 1cc0c89..3188c9c 100755
--- a/tests/unit/java/com/android/server/ConnectivityServiceTest.java
+++ b/tests/unit/java/com/android/server/ConnectivityServiceTest.java
@@ -502,7 +502,7 @@
// complete before callbacks are verified.
private static final int TEST_REQUEST_TIMEOUT_MS = 150;
- private static final int UNREASONABLY_LONG_ALARM_WAIT_MS = 1000;
+ private static final int UNREASONABLY_LONG_ALARM_WAIT_MS = 2_000;
private static final long TIMESTAMP = 1234L;
@@ -3369,8 +3369,10 @@
// This test would be flaky with the default 120ms timer: that is short enough that
// lingered networks are torn down before assertions can be run. We don't want to mock the
// lingering timer to keep the WakeupMessage logic realistic: this has already proven useful
- // in detecting races.
- mService.mLingerDelayMs = 300;
+ // in detecting races. Furthermore, sometimes the test is running while Phenotype is running
+ // so hot that the test doesn't get the CPU for multiple hundreds of milliseconds, so this
+ // needs to be suitably long.
+ mService.mLingerDelayMs = 2_000;
NetworkRequest request = new NetworkRequest.Builder()
.clearCapabilities().addCapability(NET_CAPABILITY_NOT_METERED)