Still not sure whether the log message is 100% correct. Technically, it
means no callback was received between now and the last successful poll
operation that incremented the track record position.
Test: TH
Flag: EXEMPT trivial
Change-Id: I57e9600321cb4a79d035d64d488af09b17a50706
This makes it much more powerful as well as consistent with
other use cases of this paradigm.
Test: TH
Flag: EXEMPT test-only
Change-Id: I4f5b86bfdd16d8bfe21b79235444817a13bc3c49
Chalard Jeanauthored and Jean Chalardcommited 2025-06-20 01:08:25 -07:00
This will make these agents testing a lot easier.
Also fix a small bug where waiting for callbacks that
are not expected would take a lot longer than it should.
Also trivial improvements to logging that I needed to stabilize
this.
Test: TH
Flag: EXEMPT test-only
Change-Id: I654d63eb226990ad1c5087cade7cf0a82d8526a1
Have TestableNetworkCallback adopt it, as a first client. It's also by
far the most complex.
Test: TH
Flag: EXEMPT test-only
Change-Id: Ie58d051b4478c901b7f0f54e89a67d22f1ee2ce2
This reverts commit a77d5ac126.
Reason for revert: Droidmonitor created revert due to b/422782308. Will be verifying through ABTD before submission.
Fix: 422782308
Change-Id: I00825e0f17a9a9e0d152ac8ebe767da3f267fbb1
Have TestableNetworkCallback adopt it, as a first client. It's also by
far the most complex.
Test: TH
Flag: EXEMPT test-only
Change-Id: Ifd636a09d0695f04b17330c4987f2b7b742508fa
This is a shared public utility. Its main utility is for methods
that can fail, have an error message of their own, and also want
to take an error message from a caller and want to combine them.
Example use :
fun <T> assertEquals(expected: T, actual: T, msg: String? = null) {
if (expected != null) {
failWithErrorReason(msg, "Expected $expected, got $actual")
}
}
...which allows someone to say
assertEquals(a, b, "Checking a vs b")
Test: TH
Flag: EXEMPT test-only change
Change-Id: Id3eaa8384b4177f38f13576d9b4d742c52027ae4
It was thought originally that it would not make a lot of sense to
offer such a call, but with usage it became clear that there is a
simple, obvious and useful behavior.
In particular this is very useful to mix eventuallyExpect and
expect calls. Interestingly, before this patch, calling
callback.eventuallyExpect<...>()
callback.expect<...>()
does not actually behave like you would intuitively think, because
eventuallyExpect does not advance the read head. When this
utility was made we thought this was the better behavior, but
usage has shown that advancing is both obvious and more useful.
Astonishingly, there seem to be no caller who needs to
eventuallyExpect() and later expect(), meaning that this
behavior change is apparently fine.
Test: ConnectivityCoverageTest and treehugger
Flag: EXEMPT test-only change
Change-Id: I2078330bd913cf0f75240bf3d4852e487e3e0163
Figuring out what packets were received is useful for debugging.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: I3184845b76e33da186f39a2344548c2d16715173
Instead of reporting tryTest errors when the tryTest block throws,
report them in the cleanup block if no catch block has caught it.
This fixes a bug where tests that use tryTest/catch would collect
diagnostics in expected cases.
Test: atest
Change-Id: Ic53ae54f1945a2784becd50e5890fad8e7461474
On some networks, telephony may teardown its network
(unregisterAfterReplacement) when wifi is toggled to change the MMS
capability.
Update testRejectUnvalidated_TearDownNetwork to take that into account:
right after toggling wifi to make it unvalidated, wifi may still be
default if mobile data is being reconnected. Wait for mobile data to
reconnect and validate in that case.
Bug: 296403855
Test: atest
Change-Id: Ief46bed41ecb23d75c9a1f58e7a272e7f3de7caf
When CtsNetTestCases tests fail, or when a tryTest statement fails,
collect connectivity diagnostics and output them as a test artifact.
tryTest must be followed by cleanup blocks, which often change the
configuration, so having diagnostics when the tryTest fails in addition
to after the test failure is useful.
The collected diagnostics will be available as individual test
artifacts. They should make it easier to investigate test failures, and
could be collected across test runs in an automated way.
Output files are currently limited at 20 per run, to avoid collecting
too much data in case everything is failing in the run.
Test: atest
Change-Id: Iaa48e519028dc61c03d387beeade7d41fca2ef48
Similarly to NetworkMonitorTest, terminate NetworkMonitor threads and
ExecutorServices after each test case in integration tests.
This should fix flakes where the HTTP probe from testValidation could
finish after mock probe responses are cleared in tearDown.
The utils used in NetworkMonitorTest are factored out to ConcurrentUtils
to achieve that.
Fixes: 292481238
Test: atest --rerun-until-failure 50
Change-Id: I5cdeee8d4f06ea40e338dd2cb1fdcc2fe0907a7d
Instead of (wrongly) looking at the DNS message flags for the Query
Unicast bit, look at the flag in the question record.
The previous bug means that all queries would be replied multicast
instead of sometimes unicast. The fix is flagged off as this is a
behavior change that may affect performance and latency.
Bug: 289482497
Test: atest
Change-Id: I08e30c4ffa747c9073d631e8addca1278ea40648
This change adds a backtrace() method which returns a list of events
that were received since the last time a user called poll() on a
ReadHead. This is particularly useful for logging observed events while
a poll was in progress that did not end up matching an event.
Test: atest EthernetManagerTest
Change-Id: If019cf9eb5e3e9268c5e6b74edbd8f49959cc71c
This will typically be used in mainline-presubmit TEST_MAPPING
configuration to exclude some tests.
This is necessary as some tests are flaky in mainline configurations
(when running on older devices), and they need to be disabled to meet
SLO requirements, but they are not flaky on presubmit using the latest
platform builds.
Test: m
Change-Id: Ia532d6d3f9833ddec613d79c0eb517d20a1c529a
This annotation can be used to mark a test case that requires
the latest resolv module. Tests that don't run with the latest
resolv module (for example CtsNetTestCasesLatestSdk) can exclude
the testcases being flaky due to some known issues in old resolv
module.
Bug: 279846955
Test: TreeHugger
Change-Id: Ie19eed1c4aa17645c4eec45493e7999027a01205
This annotation can be used to exclude the testcases which requires the
latest NetworkStack module in the CTS/MTS suite.
Bug: 283200648
Test: atest CtsTetheringTestLatestSdk
Change-Id: Idaffed93af077c2998081142af7b3bfa311dcd90
...and rename ExceptionUtils to FunctionalUtils as the old name
would no longer be appropriate.
Test: FrameworksNetTests
Change-Id: I2affd69fb84d7f250b4a45497eec6c052bf6ec50
Throwable could be used as a type argument to catch(), but it would
possibly never be caught, because the method only catches Exception.
Notably, junit assertions fail with AssertionError, which is not a
subclass of Exception. Due to that, tests or utilities like
DeviceConfigRule that have failing assertions in catch() would not
run the subsequent cleanup steps.
Bug: 210377950
Test: atest CleanupTest
Change-Id: I54e2922cb466f077ba4d219f8c3c6f885316296c
This is useful for some tests that need to make sure a few
things all happen, but some of them may throw an exception.
In vanilla Java you'd say
try {
...
} finally {
try {
...
} finally {
try {
...
} finally {
...
}
}
}
With this patch, you can pass a list of blocks to clean.
Kotlin :
tryTest {
...
} cleanupStep {
...
} cleanupStep {
...
} cleanup {
...
}
Java :
tryAndCleanup(() -> {
...
}, () -> {
...
}, () -> {
...
})
This keeps the semantics of tryTest{} of throwing any
exception that was thrown in tryTest{} and adding the
exception in the cleanup steps as suppressed.
Test: new tests for this
Change-Id: Ie26b802cb4893e13a70646aa0b7887701dee1ec6
This is the same thing try{} does, and allows to lift
return out of tryTest.
This allows syntaxes like :
fun foo() = try {
"Foo";
} cleanup {
doSomeCleanup()
}
}
val network = try {
registerNetworkCallback
callback.getNetwork()
} cleanup {
unregisterNetworkCallback
}
}
Note: bypassing ktlint because of b/185077240
Test: FrameworksNetTests
Change-Id: Ib8f6fde7ccfd62fdcb3c1e3b7b03909ed94d4b23
Non-local returns will prevent the execution of the cleanup{}
block, which is too much of a footgun to allow. See the bug
for details of how it happens.
There doesn't seem to be a way to keep the nice syntax, allow
non-local returns and still guarantee execution of the cleanup
block in all cases. Thus, forbid non-local returns. Users can
still use return@tryTest to accomplish almost the same thing,
and the next patch will also let tryTest{} return its last
evaluated value, fixing remaining cases.
E.g.
tryTest {
foo()
if (condition) return result
bar()
} cleanup {
doCleanup()
}
can always be written
return tryTest {
foo()
if (condition) return@tryTest result
bar()
} cleanup {
doCleanup()
}
...and it's a rare case, so the additional syntax is acceptable.
Test: NetworkStaticLibTests
Bug: 207358921
Change-Id: I40443acf7e4d86813641adc877e27fb2334d0daf
In fact the test already passes, because addSuppressed contains
an explicit test that if this === argument, then it doesn't add
it. But otherwise that's a bug in tryCleanup
Test: NetworkStaticLibTests
Change-Id: I202790bbe8d82445c5affdd9076561c2c6ea9b59
A common pattern in tests is to use try-finally to make sure
cleanup is executed. This is necessary in CTS in particular to
make sure the test does not leave the device in a bad state.
The problem with using try-finally in this manner is that any
exception thrown in the finally{} block will override any thrown
in the try{} block. If the exception in finally{} is caused by
the one from try{}, then the stack trace reported by the tools
is the consequence and not the cause, making it difficult to
interpret the stack trace of automated tests.
So today, code has to make sure that either the code in
finally{} can't throw, or can't be affected by any code in
try{}, and both of these are really difficult to ensure in
presence in finally{} of code the tester does not control.
What we'd want ideally is a structure like try-finally, that
guaratees the code in finally{} is executed in all cases,
but that bubbles up the exception from try{} if any, and
will still bubble up any exception from finally{} if the
try{} block hasn't thrown.
That's what this new tool does.
Usage from Kotlin is like try-finally :
tryTest {
testing code
} cleanup {
cleanup code
}
Usage from Java can't be made as nice, but it's relatively okay :
testAndCleanup(() -> {
testing code
}, () -> {
cleanup code
});
Bugs listed below are some tests that have been affected by
this issue and have unhelpful traces.
Test: new test for this code
Bug: 198586720
Bug: 198998862
Change-Id: I54b30a7d53772feeade99274b6120a79707ad1c9
The annotation will be used to mark tests cases that are part of MTS
modules used by multiple modules, to indicate that the test case should
only be run if the MTS suite should cover an updated Connectivity
(tethering) module.
This allows tests to verify new behavior in the Connectivity module,
without failing if that module is not updated.
Bug: 196755836
Test: mts-tradefed run mts-network with exclude-annotation in the config
Change-Id: I05d2200c7ab68042e4e48029e045f164c26b8037
Having the test targets in a different directory allows setting
visibility rules for tests only, which is necessary for access to
targets that should not be used for device builds.
Bug: 182859030
Test: m
Change-Id: Iaf426cf339a97833acf80c941db692329c6e2dcb
Patrick Rohr
commited 
Chalard Jean
authored and
Priyanka Advani (xWF)
authored and
Android (Google) Code Review
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Remi NGUYEN VAN
commited 
Mike Yu
commited 
Xiao Ma
commited 
junyulai
commited