API changes in IpSecManager and IpSecTransform are
reflected in these test updates: no functional change
to the test; just style updates along with improvement
in the clarity of using a single transform for both
directions.
Bug: 71717213
Test: CTS - IpSecManagerTest
Change-Id: Ia6933d010620516672687080898f8c4fd83223bc
This ensures the function IpSecManager.applyTransportModeTransform()
works as expected when used with Java sockets.
Bug: 70160694
Test: Ran CTS test (./run_cts.sh)
Change-Id: Ia4b636c0f48a0eeffb8813d271e59aeb86bd44bc
Investigation shows that 4.4 kernels take longer for loopback TCP
packets to be ack'd, and results in extra ack packets to be generated in
cases where both the server and client sockets send data packets at the
same time. This was verified via TCPdump, where an extra ack packet was
generated per run of the bidirectional transmissions in checkTcp().
This change verifies that the data + ack packets have been sent and
counted before initiating the reverse transmission. Further, changes
have been made to improve the reliability of this code via counting
expected packets (rather than sleeps).
Bug: 62994731
Test: CTS tests run (and passing) on walleye, marlin and angler
Change-Id: I7c707ec3b11235a5a9cba10275aee40e2eb37169
Notification listeners are not allowed on low ram devices.
Skip testDozeModeMetered_enabledButWhitelistedOnNotificationAction
and testDozeModeNonMetered_enabledButWhitelistedOnNotificationAction
on low ram devices since these tests depend on being able to
register notification listeners.
Bug: 70242457
Bug: 70545780
Test: testDozeModeMetered_enabledButWhitelistedOnNotificationAction
and testDozeModeNonMetered_enabledButWhitelistedOnNotificationAction
Change-Id: I8ce6f330760042ca790cd6fb10e62ebe86498a06
This change ensures that all forms of transport-mode packets are
correctly accounted for, and not double-counted. This includes both
per-UID counters, as well as interface counters.
Bug: 62994731
Test: CTS tests updated, passing
Change-Id: I83be0724ac21d9db7d91ce72733d13fb6736e66e
IPsec API is renaming reserveSecurityParameterIndex to
allocateSecurityParameterIndex. Update tests to reflect this.
Bug: 69128142
Test: TreeHugger should be enough
Change-Id: I0bfaa3584920096ffde7f9eeee9fccd0ec842821
I saw a bunch fly by. Here are a few fixes.
ssize_t is %zd. Types from stdint.h use PRI* macros from inttypes.h.
Finally, use C99 initializers rather than the old GNU extension.
Test: make checkbuild
Change-Id: I343dfb99984ab826c7641e311e041e859eb61d93
Update the key lengths for SHA1 and MD5 authentication
to pass the new tighter range checks.
Bug: 70324823
Test: this
Change-Id: I8f533f043d16b0571bac628d21878e31027fe853
Added CTS test to check the transform (for IPv4 & IPv6) with
various authentication & encryptions types
Bug: 34812052
Test: Ran CTS on angler using aosp/run_cts.sh
Change-Id: I51b4d13847ed0f8ad8d5f19132fdb35b1bd2950c
Let the OS pick a random unused port so that the test never gets
EADDRINUSE.
Bug: 68657805
Test: Run tests in android.net.cts.IpSecManagerTest
Change-Id: I7f6c68f3c92f5cbed856eda52adcdffb8adc4734
Before calling the testAddPasspointConfigWithCertCredential
we need to check number of network already present in device
Bug: 67630919
Test: android.server.cts.CtsNetTestCases, WifiManagerTest
Change-Id: If643ab7bde760a65e9a5b1e9d47af53378a178fd
Tests basic functionality of UDP encap sockets:
> Creates SPIs
> Creates & applies transforms
> Creates UDP encap socket
> Ensures UDP encap socket port is non-zero
> Validates that ESP, IKE packets can be sent correctly
Test: Ran on aosp_angler-eng
Bug: 67662580
Change-Id: Ia7eca384cd779e663d53cbede97ec70da33d28ec
This creates a new timeout constant for scan duration, so
this test doesn't share timeout constant with other events.
This also increases the scan timeout time to 9 seconds per
our estimation.
Bug: 67462981
Test: cts-tradefed run cts -m CtsNetTestCases -t
android.net.wifi.cts.WifiManagerTest#testWifiScanTimestamp
Change-Id: I7e1dea64bc8df3e4b31adbf8b5f05c8564a739b1
Currently, it's possible for isNetworkSupported() to return false
for TYPE_ETHERNET even if the device could otherwise support
Ethernet (e.g., via a USB host adapter). This can lead to APIs
APIs such as getActiveNetworkInfo and CONNECTIVITY_ACTION
behaving as if Ethernet was not present, even if it's connected.
Reduce the chance of this sort of misconfiguration by ensuring
that if the Ethernet service is running, isNetworkSupported
will return true for TYPE_ETHERNET. OEMs that would like the
function to return false should avoid starting the Ethernet
service.
(cherry picked from commit c4f38c2e5b)
Bug: 37359230
Test: ConnectivityManagerTest passes on aosp_bullhead
Change-Id: Iad8884bf7d12bbf661e5502b31f052a6e8457a6f
Merged-In: Iad8884bf7d12bbf661e5502b31f052a6e8457a6f
Currently, it's possible for isNetworkSupported() to return false
for TYPE_ETHERNET even if the device could otherwise support
Ethernet (e.g., via a USB host adapter). This can lead to APIs
APIs such as getActiveNetworkInfo and CONNECTIVITY_ACTION
behaving as if Ethernet was not present, even if it's connected.
Reduce the chance of this sort of misconfiguration by ensuring
that if the Ethernet service is running, isNetworkSupported
will return true for TYPE_ETHERNET. OEMs that would like the
function to return false should avoid starting the Ethernet
service.
Bug: 37359230
Test: ConnectivityManagerTest passes on aosp_bullhead
Change-Id: I395c689e47074910fb56bbd8fc5b2d698d3893ab
