* It's not allowed to run `gcc` from within genrule in Soong. So It was an easier decision to create a cc_object and run it with a -E flag which is equivalent to what `gcc_preprocess` action does. Then perform a soong_zip on the result to generate the equivalent java file needed
Test: update_results && m cronet_aml_components_cronet_android_cronet
Change-Id: I1b2e50f1f95fbf700c1190902c716e624805a2b4
Add some checks to verify that the underlying network info will
only be cleared when the underlying network is lost, or will only
be sent when the category is not CATEGORY_EVENT_DEACTIVATED_BY_USER
and CATEGORY_EVENT_ALWAYS_ON_STATE_CHANGED.
Bug: 237050331
Test: atest FrameworksNetTests:VpnTest
Change-Id: Ifc66658cf59481c4a9804e6933be1048f758b698
For network lost case, the process should be triggered by calling
onLost() instead of triggering onClosedWithException() directly.
Bug: 237050331
Test: atest FrameworksNetTests:VpnTest
Change-Id: I32781d4ac96ee8212d1fd7ba23009293f72b442e
To prevent device testing via ADB over ethernet entering standby mode,
acquire a wake lock before sending KEYCODE_SLEEP to device.
We might lose connection when device entering standby mode, end up fail the test.
Test: atest com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testDozeModeNonMetered_whitelisted
Bug: 233154541
Change-Id: I09e0af35d32a8001913d3414c0c41ffbb10ace3d
Merged-In: Icb28d2db6f25bd12ba00f56e5d6e56fa108bdcbd
testTetherUdpV4AfterR verifies BPF map content that is going to
break on Android 13 devices with newer mainline module versions
which are going to support CLAT tethering offload.
The CLAT tethering offload requires BPF map format modification
which will break CTS for T.
This is for Android 13 only because testTetherUdpV4AfterR is
added since T and the BPF offload test has been moved from CTS
to MTS.
Changes:
Before:
- testTetherUdpV4UpToR: test tethering basic function on R.
- testTetherUdpV4AfterR: test tethering basic function and BPF
tethering offload on S+.
After:
- testTetherUdpV4: test tethering basic function on R+.
(renamed from testTetherUdpV4UpToR)
- testTetherUdpV4AfterR: (suppressed)
Bug: 258637850
Test: atest EthernetTetheringTest
Change-Id: Ia75347094fd7819c5dc68e05fcaac5c698c7729e
Add onServiceNameDiscovered method which is used to listen the
discovery callbacks. It would be called once the service is found
even the response is incomplete. This is different from
onServiceFound which needs to receive a complete response.
onServiceNameRemoved is used for service removal if received
response is incomplete.
Bug: 254166302
Test: atest FramworksNetTests
Change-Id: I03313b045d74bb65f7fe6ac93673f02ce3b2c664
In Cts test after disabling Wifi, the WifiManager#getConnectionInfo will
not return network id -1 immediately. Need to poll the wifi disabled and
the network connection info cleared before asserting the connection
info.
Bug: 252869312
Test: atest ConnectivityManagerTest#testRejectPartialConnectivity_TearDownNetwork
Change-Id: If88261b0d81c1dc1731c683513878d054d2cb0dc
Having SdkLevel.isAtLeastU() as a default value of
DeviceConfigUtils.isFeatureEnabled could result confusing behavior.
For example, when flag value is pushed to only the T device and the T
device with the flag is ugraded to U, this device could disable java bpf
map while the device keeps the flag value.
This CL prevents above confusing behavior.
Bug: 246218229
Test: atest BpfNetMaps
Change-Id: I615603c337bb94101dccac77ea0e6fa857041259
Current test triggers batterystats to update mobile stats by
switching default network and ConnectivityService will call
reportMobileRadioPowerState to have batterystats update the
mobile stats. But in current design, batterystats will
rate-limit the update if it is due to modem power state change.
So the modem stats might not be updated if it's rate-limited.
The other reasons (plug/unplug, battery level change,etc) will
be unaffected. Thus, dump battery stats in the test to trigger
a full sync of data.
Bug: 256087047
Test: CtsNetTestCases:BatteryStatsManagerTest
Change-Id: I936d51f0c205640eac94f80062ad66f55df9d0df
(cherry picked from commit 3c4231d613)
Merged-In: I936d51f0c205640eac94f80062ad66f55df9d0df
If we run an iterations test, TCP connections opened by previous tests
won't be closed immediately. They will stay in the TIME_WAIT state for
120 seconds before closed. Netfilter socket listens to both
NF_NETLINK_CONNTRACK_NEW and NF_NETLINK_CONNTRACK_DESTROY groups.
There is a tiny time gap between socket creation and sending dump
request to kernel. If an old TCP connection happened to be closed in
this time gap, listening socket would see a DESTROY message before
seeing the NEW messages triggered by dump request.
The current test only parsing the first contrack message in the read
buffer, so it will only find the DESTROY message and ignore all of the
following NEW messages. It does a netfilter socket dump, but does not
check whether the dump produces reasonable output. Now that we have
the ability to parse conntrack messages, do more in-depth checking.
Bug: 254608655
Test: atest ConntrackSocketTest --iteration 500
Change-Id: Icf95adb9d9390d598e9c6bdb4e245c5fce764e3e
Change the name to reflect the cronet class that is being tested
Test: atest CronetApiTest
Bug: 251012627
Change-Id: I8b9c6421393582b57043a140b400f6a1e8ace601
