To do this we register a UidFrozenStateChangedCallback with
ActivityManager. The callback then queues up work on the Handler thread
to consume the original callback args and kill appropriate sockets.
Test: atest ConnectivityServiceTests
Bug: 277100090
Change-Id: I93f174811aef726145a18ea90443ddfc1456478e
Currently, native networks for non-VPN networks are created only
when the NetworkAgent goes into the CONNECTED state. This is not
ideal, because until the network is connected:
- Nothing routes to the network, so no IP packets can be sent on
it (except via packet sockets).
- Many network configuration changes (e.g., routes and DNS
servers) fail to apply because the network does not exist yet.
These cause ENONET errors in the logs.
Fix this starting in U by creating the native network as soon as
the agent registers. This should not impact apps because
NetworkCallbacks are not sent until networks are connected.
Bug: 143158421
Test: new coverage in NetworkAgentTest
Change-Id: I26bfa8630c085422175558645c47a6c64be96ae6
Lorenzo Colitticommited 2023-05-10 20:01:07 +09:00
This is not a substantially new test, as VTS has already required
either reno or cubic, and reno is ancient and obsolete (and was
only ever included because it's builtin to the kernel), so in
practice everything should have already always been using cubic.
Bug: 281477097
Test: TreeHugger, atest ProcNetTest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I04622ae37265361f648bbcf46c0a10e22be3b24f
Maciej Żenczykowskicommited 2023-05-09 18:16:52 +00:00
If the network is null in MdnsServiceTypeClient, it should use
MdnsSocketClient for single socket only. So it's expected to
process any response from only the socket (network).
Move the stopDiscovery outside the listener check loop.
Because the stop should only be called once.
Add a test to verify the response processing with a non-null
network MdnsServiceTypeClient
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: I76965302037f050e0ac3b2cfdbaa5a855e2283c7
CtsNetUtils#connectToCell can fail if the device does not have a cell
network available in which case the allow bad wifi setting was not reset.
Test: TH
Change-Id: I2dc20c8982a427379f94a4b92774e149a78628d5
As per RFC 1034/1035, the max size of the label is 63 bytes. It should
also be guaranteed when the serviceName is renamed due to the conflict.
Bug: 265865456
Test: atest FrameworksNetTests
Change-Id: I077d8abdb91071db62b9618d9918e3a12682aaf4
For a template with MATCH_TEST, since the wifi network key is
just a placeholder to identify a specific test network, it is
not related to track user location. Hence the check is not
really needed.
Test: 1. atest NetworkStatsIntegrationTest with use location turned off
2. atest FrameworksNetTests:android.net.connectivity.com.android.server.net.NetworkStatsServiceTest
Fix: 280686048
Change-Id: Ic128cfbbb2d03c427c9030c99bf205eb65a33e58
This includes:
1. Specify a read timeout: At present, the test only specifies
a connect timeout and terminates if the timeout is exceeded.
However, if the connection takes a long time to establish,
there may be very little time left for the test to perform
a read operation.
2. Read only the initial bytes: Since the exact amount of data
is not important for the test, it is preferable to read only
a small amount of data at the beginning rather than reading
the entire content.
Test: atest CtsNetTestCases:android.net.cts.NetworkStatsManagerTest \
--rerun-until-failure 100
Fix: 274835045
Change-Id: If53a8db7ab6c5df462757d80b563de89531c3c3f
Some tests flake because the previous test networks are
still registered. It's not very clear how this can happen
considering `tearDown` is waiting for each agent to be
torn down, but logs suggest that the array of agents may
not contain all agents at `tearDown` time, and `tearDown`
does not run on the same thread as the test. It's hard
to imagine that there isn't a memory barrier between the
end of the test and the start of `tearDown`, but that's
the only hypothesis at this point.
Also add logs that will help diagnose further in case
the (admittedly hard to believe) hypothesis is wrong.
Fixes: 280035560
Test: ran a few hundred times without failures, though
I can't repro even without this change anyway
Change-Id: I620df32c43c855ca882e2e21201fe5b23b71a65a
The tests do not need to run on devices where the module is not updated
or updatable.
Tests that are not in presubmit were missed when annotating keepalive
tests in a previous change.
Change-Id: I11ef44987b5a9cbcdf5b892807f65c4f9d04812f
Test: atest
Fixes: 280131407
From service-connectivity, NAMESPACE_TETHERING must be used, as
NAMESPACE_CONNECTIVITY is used for the NetworkStack module. Also the
isFeatureEnabled with module name must be used, otherwise the "android"
package version is queried instead of the tethering module version.
BpfNetMaps is using flag value 1 to workaround this issue.
flags in NsdService, AutomaticOnOffKeepaliveTracker, and ConnectivityFlags
were not pushed currently.
So, this change has no effect to devices.
Bug: 279108992
Test: TH
Change-Id: I2b4b6a13c048c20beef52b1f43b9e21aca0c637a
The ConnectivityResources class is only usable with QUERY_ALL_PACKAGES
permission, so it is not generally usable in framework-connectivity. It
is also backed by the ServiceConnectivityResources APK, which is
intended as resources for service-connectivity.
Move the class to service-connectivity and update callers. CTS needs a
way to determine the supported keepalive count as it used the
resources from KeepaliveUtils as @hide API, so provide a
ConnectivityManager @hide API for testing.
Bug: 279108992
Test: atest
Change-Id: I3c9a77c580b5ab87c922c32778bce15dc33b4d1d
Remi NGUYEN VANauthored and Motomu Utsumicommited 2023-04-28 19:18:39 +09:00
Cellular networks are now supported for marking wakeup packets. As a
result onWakeupEvent now also reports data relevant to the cell
transport.
These unit tests should add coverage for these new behaviors.
Test: atest FrameworksNetTests
Bug: 276498460
Change-Id: I0b8a03fff6255e067b736f3dbfb53de56420f90b
Currently, the mDns discovery services will clear if no listener
registers to that MdnsServiceTypeClient. If an app does discover,
stop discover, resolve, at this point the listener was
unregistered, so the MdnsServiceTypeClient was deleted, and the
service is gone from cache. So this will actually restart
discovery without returning previous results from cache. Thus,
add MdnsServiceCache to store all services and reduce the
duplicated queries.
Bug: 265787401
Test: atest FrameworksNetTests
Change-Id: If3d4eb4e3dc5455f6f97cb782aa1b99b2a00f6e0
To prevent WiFi-to-WiFi interruption while entering APM:
- If WiFi is retained while entering APM, hotspot will also remain enabled.
- If WiFi is off before APM or disabled while entering APM, hotspot will be disabled.
To make sure hotspot always be disabled while entering APM, disable wifi before enable hotspot.
Bug: 278150162
Test: 1. turn on wifi while airplan mode on, then turn off airplan mode
2. atest ConnectivityManagerTest#testFactoryReset
Change-Id: Ic48ba63deab02683280543516228104be928a6a2
Markauthored and Mark Chiencommited 2023-04-26 07:24:11 +00:00
Currently, the MTU tests work on networks that have not yet been
connected. This is not very realistic because most MTU changes
(like most LinkProperties changes in general) happen after the
network has connected. Change these tests to use connected
networks instead.
To avoid losing coverage for setting the MTU before the network
is connected, add a test just for that.
Bug: 143158421
Test: test-only change
Change-Id: I7f808249722924a0b1253e402c5580bb104afd8e
Lorenzo Colitticommited 2023-04-25 17:15:26 +09:00
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
Test may be flaky because the target network did not apply the
private DNS setting change because test assumes setting applied
successfuly by receiveing any success from link properties
change. The test failed because the target network did not apply
the change. Test should wait for setting to be applied to all
networks since the private DNS setting change will be applied
one by one for each Network
Fix: 279051721
Test: atest com.android.cts.net.HostsideVpnTests
Change-Id: I649c2d573a245f15b7749c3b0ac824d2f846873c
This is a no-op change to move the getTestableNetworks() to
CtsNetUtils for the follow up change which will also need the
same method to reduce code duplication.
This change also updates the nullability of the private dns
server so that it can also verify non-strict mode.
Test: atest CtsNetTestCases
Change-Id: I67c94cd5aefeb9cf1ecd4126178c2410f3f08b1b
Wifi remembers the wifi enabled state under airplane mode in the
Settings.Secure.WIFI_APM_STATE setting for the airplane mode
enhancement. Wifi will not be disconnected if user enables
the wifi under airplane mode. This behavior breaks the
assumption in testSetAirplaneMode. The test expects to always
receive the WiFi network disconnect after turning airplane
mode on.
The wifi enhancement was done with hidden method which should not
be referred in the cts. The intention of testSetAirplaneMode was
to verify the permission required for setting ariplane mode.
This change should be no harm for original intention.
Bug: 278150162
Test: atest CtsNetTestCases
Change-Id: I3458679378f0c12c26051f3dac7fcf155c1f469c
Lorenzo Colitti
authored and
Gerrit Code Review
commited 
Paul Hu
authored and
Mark Fasheh
authored and
Junyu Lai
authored and
Maciej Żenczykowski
authored and
Treehugger Robot
authored and
Yichun Li
authored and
Patrick Rohr
commited 
Yuyang Huang
commited 
Chalard Jean
commited 
Remi NGUYEN VAN
commited 
Motomu Utsumi
commited 
Suprabh Shukla
commited 
Mark
authored and
Chiachang Wang
authored and
Treehugger Robot
authored and