This change moves the logic to read /proc/config.gz from the static
initializer to a function that runs the first time setUp is called. This
improves error reporting as exceptions thrown inside
ensureKernelConfigLoaded get reported as test failures.
Test: atest RateLimitTest
Change-Id: I3b7913c567507dec8ecad26602cfccdad3d6f4bd
An NullPointerException in tearDown is a symptom of an initialization
error and should not be reported in the test failure result.
Test: atest RateLimitTest
Change-Id: I9c1d6294678cdc9cdf4beae597f8373b92b52077
Assumptions that are placed in BeforeClass annotated methods are not
reported correctly. See b/203722419 for more information.
Test: atest RateLimitTest
Bug: 220801455
Change-Id: Ia7f0eaddc75d0ee091e107615f1677c75865dbcb
As it turns out, /proc/config.gz can be accessed via shell command from
within a CTS test. This adds a proper kernel support check for the
RateLimitTest.
Bug: 220801455
Test: atest RateLimitTest
Change-Id: I4d3a6848c1c05c313cb74b235294cee982eecf57
This test is highly flaky in presubmit with error messages that
look like:
java.lang.AssertionError: Did not receive callback after 200ms
The test itself looks correct, so it's possible that 200ms just
isn't enough time for the callbacks to be delivered. Set the
timeout to DEFAULT_TIMEOUT_MS like most of the other
TestableNetworkCallbacks in this class.
Fix: 218389790
Test: test-only change
Change-Id: Ie68356a48e9618e5fea3865aa06bfbfc457b89c4
This is being added as the lowest priority score factor, just
above the tie-breakers. It ensures that a network that has been
destroyed will lose to another identical network that has not
been destroyed, but will otherwise be scored identically.
The flag is a CS-managed flag that is stored in NetworkAgentInfo.
Currently it is always false, but it will be populated in
future CLs.
Bug: 216567577
Test: atest FrameworksNetTests
Change-Id: Ib1cd342ab7dfc4df45715da19b743d711fe8d605
These don't break compilation because NetworkAgentInfo doesn't
expose any APIs and thus doesn't generate javadoc, but they
are flagged by the IDE.
Test: treehugger
Change-Id: I2b63c24b2afbc98950f53c38f80d27474aab0622
The test assume the first tethering upstream would be test network. But
if there are mutiple networks available, this is a wrong assumption
because of race condtion. If tethering choose upstream while wifi or
celluar is available but test network may not available for tethering yet
(it depend on the NetworkCallback from ConnenectivityService), the first
upstream may not be the test network.
Bug: 215224286
Test: atest EthernetTetheringTest
Change-Id: Idfa972008643f1fb5119179383b06e2c8f65c667
These also cause ConnectivityCoverageTests to fail when built
from master and run on S. They are used in Vpn.java, not
LockdownVpnTracker.
They were not addressed in the previous CL because running this
test locally is difficult.
Test: forrest
Change-Id: I7d687338fd6bc7468b1abcae58898322554e647b
LockdownVpnTracker directly uses resources from
com.android.internal.R. This is acceptable because it's platform
code. But ConnectivityServiceTest uses the LockdownVpnTracker
built from the module source tree, and when that code fetches
resources on a previous Android release, it crashes because the
resource IDs don't exist; non-public resource IDs aren't stable.
Fix this by mocking the resources used by LockdownVpnTracker.
Test: atest ConnectivityCoverageTests
Change-Id: I239a18a38d4f1082f76f5ff1b831c15ee753bdfd
This test creates a TUN interface and registers it with
ConnectivityService. For 15 seconds, it continuously writes data to that
interface and measures at what rate it is received.
Data accounting is currently not covered by this test.
Test: atest RateLimitTest
Bug: 172053704
Change-Id: I74f891f3b7113855375c48a10cefbfe47221931b
This makes the code easier to maintain because we do not need to
manually add string representations, and because it will throw at
static initialization time if the clas contains duplicate
POLICY_xxx values. The memory overhead is likely negligible.
Bug: 216567577
Test: new coverage in FullScoreTest
Change-Id: Iab23d414c8e28ff7f26060ad44fa996f277d361f
Currently, there are two EVENT_NETWORK_TESTED message types in
ConnectivityService. One is used by the ConnectivityService
handler to process validation results, and one is used by
ConnectivityDiagnosticsHandler to send connectivity reports.
The two messages have different contents so it is confusing that
they have the same integer and the same name. Rename the second
one to CMD_SEND_CONNECTIVITY_REPORT.
Test: atest ConnectivityServiceTest
Test: atest CtsNetTestCases:android.net.cts.ConnectivityDiagnosticsManagerTest
Change-Id: I77d63dad477315e1fcc7225a5ef03aff2bed8c35
TestNetworkAgentWrapper does not set the interface name in its
LinkProperties causing logwtf to fail tests on -eng build.
Test: atest FrameworksNetTests:ConnectivityServiceTest on -eng build
Change-Id: Ieba0453ce897aa1052cb98f1de4c7bb099383c8d
NetworkStatsService was mainlined in T, so the test does not need to be
run on previous Android versions.
Test: atest CtsNetTestCases:NetworkStatsServiceTest
Change-Id: I8e69746a03ef029b1121cc8fa71e299ac12c2905
Add some happy path logging that informs about active rate limits.
Test: TreeHugger
Bug: 218840346
Change-Id: Iddd50583ca2e90afe83a5c68611418fa794afb3f
All NetworkMonitor messages contain the netId of the source
NetworkMonitor. But the netId is in various places in the
message. It's most frequently in arg2, but sometimes it's boxed
into an Integer in obj, and sometimes it's in another object.
Always pass the netId into arg2. This allows us to write
common code at the beginning of the function that extracts the
netId and nai, and performs common actions on all messages.
Bug: 216567577
Test: atest FrameworksNetTests FrameworksNetIntegrationTests
Test: atest CtsNetTestCases:ConnectivityManageTest
Test: atest CtsNetTestCases:NetworkAgentTest
Change-Id: Idbbe3cddfc5475a2d56df387f840439dc4c9514c
The version of ConnectivityManagerTest#waitForAvailable that
takes a callback and a Network implicitly requires that the
network be validated, because it calls expectAvailableCallbacks
with validated=true.
This is incorrect because a network can become available without
being validated. In particular, testMobileDataPreferredUids is
flaky due to this problem, because it calls connectToCell, which
does not wait for validation, and then calls waitForAvailable,
which expects that the network is already validated.
Fix it by not requiring any particular validation state. This
method is only used by a few tests and they should not be
affected by this change:
- The first two calls in testSetOemNetworkPreferenceForTestPref
happen after waiting for validation, so the network is
validated already. The third call waits for a test network,
and test networks are always validated.
- The first call in testSetOemNetworkPreferenceForTestOnlyPref
waits for a test network, which is always validated. The
second is incorrect because ensureWifiConnected does not
wait for validation, and is fixed by this CL.
- The calls in testMobileDataPreferredUids similarly incorrectly
assume that wifi is validated and are fixed by this CL.
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest#testMobileDataPreferredUids
Change-Id: I614d0ba87c3931fcbe4011fed379e1736f5c4a44
