This is no longer used and is advantageously replaced
by a call to poll(), which has the same semantics.
Test: TH
Bug: 157405399
Change-Id: I3182fd3e3ac749e11a8f962ef1acfdca5d031b05
This is not useful because it has the exact same semantics
as poll() : it returns the first event that matches the
predicate within the timeout, or null if none.
Unfortunately the method can't be removed until all
uses in internal master are removed, so the actual
removal will have to wait for the next patch.
Test: TH
Bug: 157405399
Change-Id: I471c44568e359f8686dcb21ae04c76ca8095f02f
It's a reason, so it's a lot clearer this way
Bug: 157405399
Test: ConnectivityServiceTest NetworkStaticLibTests
Change-Id: Id71d710a33b4df3c211e40141adb2aa0a535f458
This is not clearer than using the base method.
Test: ConnectivityServiceTest NetworkStaticLibTests
Bug: 157405399
Change-Id: Iac9aeffb563d0a1cb6c1287b46b9bbfffc0c75ca
The annotation is used to verify behavior for apps with max target SDK
33.
Bug: 267102290
Test: atest CtsNetTestCasesMaxTargetSdk33
Change-Id: I71ba4433389ba07553ea3d6d34a2bf64fdc132ad
This is a helper function that lets a caller make sure the
side effects of a piece of code are visible both on a handler
thread and in the caller thread before continuing.
Also move HandlerUtilsTests to the tests directory of
frameworks/libs/net from the NetworkStack where it used to be
Test: NetworkStaticLibTests
Change-Id: Icf1bd8bbe1216777c52b73cfbd0a46b647b72260
It's useful for the java code to have the overload methods for
eventuallyExpect and expectAvailableCallbacks.
Bug: 231749077
Test: atest CtsHostsideNetworkTests:HostsideVpnTests
Change-Id: I6bb1385ee84d1ff1e9f0472e6de3f452ab142958
Test failed when socket.close() ran, and in the other thread
we are trying to initialize an InetSocketAddress. If the socket
was closed, the port got from the socket object becomes -1 hence
the InetSocketAddress cannot be constructed and the
IllegalArgumentException would be thrown.
Interrupt thread before closing socket to prevent from the race.
Test: atest TestDnsServerTest --rerun-until-failure 1000
Fix: 259160848
Change-Id: I219ee1e32144ba9983a28765e7a84621c27c1c09
This is re-upload of aosp/1390056, CL that fixes test is separated
in a follow-up CL that submit at the same time.
Bug: 139774492
Test: atest DnsAnswerProviderTest TestDnsServerTest
Change-Id: Ia72975f3044f009ebb0f4564a527830268a4a157
If the preparer throws AssertionError, tests will still
be retried without re-running the preparer. It needs
to throw TargetSetupError to indicate that setup failed.
Change-Id: Id01845536a216e1a3ca1c671c97f7bcd992c354e
Fixes: 254542801
Test: atest
Before :
java.lang.AssertionError: Did not receive callback after 5000
After :
java.lang.AssertionError: Did not receive Available after 5000ms
Test: manual
Change-Id: If46d52cb0db8ea3d418169ea330d915d835e4373
Revert "[ST03.1] Add DnsAnswerProviderTest"
Revert submission 1390056-st03
Reason for revert: test failed in presubmit, still under checking.
Reverted Changes:
Ia5039a47f:[ST03] Add test dns server for integration tests
I9157e030c:[ST03.1] Add DnsAnswerProviderTest
Change-Id: I1ff291ca62e2209343ed5c5e4aa3bf3e93229f47
It's sometimes not clear that tests call ensureWifiConnected
but no wifi enabled. It's hard to clarify design with wifi
stack, so add the gotten wifi info in the log to help on
debugging.
Bug: 252869312
Test: atest CtsNetTestCases
Change-Id: I3bc74dd38dd5a36a93510fc5d70c0fa00b66e842
These methods have been migrated to the shorter and better
provisioned expect<> family of methods.
Test: Builds
Change-Id: I60c77bfeabe373557d61f0f8d0295b385fe5271e
Sometimes the tests are run under high load, e.g. immediately
after boot while all apps that listen for the boot completed
broadcast run their listeners. Under these circumstances,
40ms of leeway is tight ; on recent Android devices HZ is
commonly 100 too, meaning a general time unit of 60 will give
a little bit of air.
The drawback in this is that the test is less stringent on
TrackRecord, which as a multi-thread primitive should have
really tight tests to make sure that a non-threading primitive
(e.g. a polling implementation) doesn't pass. This patch makes
the testing on that front a little bit less reliable.
Note that this patch won't actually fix all flakes in that it
isn't really possible to guarantee the device will have any
CPU time to run the test at all anyway, but this should make
most failures go away.
Also, the argument for the time unit is never used, and can
be removed ; at least, the possibility of the timeArg() func
not using the same value as the sleep directive is scary, so
that possibility should be removed. If the time unit argument
is ever needed it can be added back, but considering the arg
has been available for years and never used, it's unlikely.
Test: NetworkStaticLibTests
Fixes: 254188131
Change-Id: Ia7a4fe775942484dcd7dc223c7710e82a8329beb
This already has all necessary methods, it only needs to
declare it implements the interface.
Test: ConnectivityServiceTest
Change-Id: I8de643f2b8de9765c25c3efe934c94549f341a51
"callback" is redundant – it's a TestCallback object and
it takes a type of callback anyway.
"assertNextIs" is shorter than expectCallback, and more
directly explicit than "expect", but it's also 3 words
and very different from previous usage.
Using expect() is a little bit less in-your-face obvious,
but it's simple, familiar, and short.
Test: CtsNetTestCases
FrameworksNetIntegrationTests
FrameworksNetTests
NetworkStackTests
Bug: 157405399
Change-Id: I6c8c85a8be3895dd8f0ef681faa4a8b2b4f2f493
In Java, "poll" methods return null when the collection is
empty. Respect this convention.
Bug: 157405399
Test: FrameworksNetTests
Change-Id: I3b17908f9ce1f60b18908605a645da3199c010b9
This commit is part of a large scale change to fix errorprone
errors that have been downgraded to warnings in the android
source tree, so that they can be promoted to errors again.
The full list of changes include the following, but not all
will be present in any one individual commit:
BadAnnotationImplementation
BadShiftAmount
BanJNDI
BoxedPrimitiveEquality
ComparableType
ComplexBooleanConstant
CollectionToArraySafeParameter
ConditionalExpressionNumericPromotion
DangerousLiteralNull
DoubleBraceInitialization
DurationFrom
DurationTemporalUnit
EmptyTopLevelDeclaration
EqualsNull
EqualsReference
FormatString
FromTemporalAccessor
GetClassOnAnnotation
GetClassOnClass
HashtableContains
IdentityBinaryExpression
IdentityHashMapBoxing
InstantTemporalUnit
InvalidTimeZoneID
InvalidZoneId
IsInstanceIncompatibleType
JUnitParameterMethodNotFound
LockOnBoxedPrimitive
MathRoundIntLong
MislabeledAndroidString
MisusedDayOfYear
MissingSuperCall
MisusedWeekYear
ModifyingCollectionWithItself
NoCanIgnoreReturnValueOnClasses
NonRuntimeAnnotation
NullableOnContainingClass
NullTernary
OverridesJavaxInjectableMethod
ParcelableCreator
PeriodFrom
PreconditionsInvalidPlaceholder
ProtoBuilderReturnValueIgnored
ProtoFieldNullComparison
RandomModInteger
RectIntersectReturnValueIgnored
ReturnValueIgnored
SelfAssignment
SelfComparison
SelfEquals
SizeGreaterThanOrEqualsZero
StringBuilderInitWithChar
TreeToString
TryFailThrowable
UnnecessaryCheckNotNull
UnusedCollectionModifiedInPlace
XorPower
See https://errorprone.info/bugpatterns for more
information on the checks.
Bug: 253827323
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I772563b5e54b468a755520d2ed9b78bcb5fc3ad6
The timeout is used in the test should be WIFI_CONNECT_TIMEOUT_MS
but log shows WIFI_CONNECT_INTERVAL_MS instead. The debug log is
confusing. Correct it to right variable.
Test: atest CtsNetTestCases
Change-Id: I4cedaa6e03aea6cc02a07bdbea2f0b1e7f5076e1
TestableNetworkCallback is using on both unit and cts tests with
same timeout 200ms. For unit tests, most of objects are mock, so
the callback should respond quickly and this interval is fine.
But for cts tests, they are running on the real system and the
callback time will depend on the system which may be over 200 ms
sometimes if the system is busy or has performance problems. So
enlarge the Network Callback default timeout to 500ms that can
reduce the test flake on cts tests. To ensure there is no impact
on no callback check, add the no callback timeout 200ms which is
the same timeout as before.
Bug: 245000567
Test: Run the FrameworksNetTests CtsNetTestCases and check
no running time increase.
Change-Id: I31f8bc08f65a622f6ab9b6c7f0577f0b107440c1
The concurrent interpreter supports a `time` directive that
lets testers ensure some instruction has taken at least some
amount of time. This is useful when testing that some
callback didn't arrive before it was sent, for example.
Unfortunately, there is some unavoidable uncertainty in how
time is measured. Because the thread that measures time
needs a very small amount of time before it starts measuring
the time taken by its instruction, it is possible that the
time that is intended to be measured actually took X, but
because the measuring thread took Ɛ before it started
measuring time, the measured time is X - Ɛ, which may fail
the test because it didn't take enough time.
Because there is no way at all to know how much time passed
between the measuring thread being woken up and it measuring
start time, it's not possible to fix this as long as the
measure for the minimum time is taken after the wait. So
instead, take the measure before the wait.
It's always technically possible that there is a bug where
the code doesn't take enough time, but the test doesn't
catch it because the device happened to run slowly as it
ran the test (e.g. other stuff running at the same time),
and this patch makes it a little worse – there will be more
true negatives, but this is the only way to ensure no false
positives and it should still catch the "too fast" cases
most of the time.
Now, each thread has its own "blocked" time. It would be
possible to store that time in a local and pass it down to
all instructions, but that would require all instructions
to take the blocked time as an argument, while only the
`time` instruction can have any meaningful use of it.
Therefore, store it in a thread local instead of adding an
argument to all instructions for all interpreters.
Test: atest --iterations 100 'TestableNetworkCallbackTest#testPollForNextCallback'
...although I can't get it to fail locally, so the
proof will be in a dying out of the flakes.
Also checked that increasing the minimum time on an
existing test does fail as expected
Bug: 185735163
Change-Id: I0afb651337a8b10a864cc5bc793d65d2ce56ab20
