No description. Add one?
- Java 78%
- Kotlin 11.8%
- AIDL 4.4%
- C++ 3.7%
- C 1.5%
- Other 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
3e09f80e8a
Currently, TestConnectivityManager immediately sends all callbacks and broadcasts to the Tethering code as soon as the test code makes any change. This makes it impossible to affect the order in which those events are delivered to the Tethering code, so it is not possible to test for races. Fix some of this as follows: 1. Make TestConnectivityManager post all its callbacks to the handlers that Tethering registered them with. 2. In TetheringTest, use the existing TestLooper object to advance time manually. Also use setUseRegisteredHandlers to ensure that the broadcasts are sent in order. This requires calling dispatchAll() after sending the broadcast to preserve the existing synchronous behaviour. Take advantage of that to remove lots of existing dispatchAll calls. 3. Add a TestLooper to UpstreamNetworkMonitorTest and use it. Keep the test passing by adding lots of mLooper.dispatchAll(), which is a bit ugly but probably acceptable given the additional coverage it provides. This exposes an existing bug in the code where if upstream selection is in automatic mode, and all CONNECTIVITY_ACTION broadcasts are received before all NetworkCallbacks, the code does not switch upstream. In order to make the tests pass, re-order the CONNECTIVITY_ACTION broadcasts with the NetworkCallbacks in TestConnectivityManager so as not to trigger the bug. A future CL will make the order configurable. While I'm at it, switch TestConnectivityManager from HashMap to ArrayMap, which is generally preferred for maps that do not contain too many elements. Bug: 173068192 Test: test-only change Change-Id: I964f365c691fbc396ab0a87f292bd32b123011fe |
||
| tests/cts | ||
| Tethering | ||
| .gitignore | ||
| OWNERS | ||
| PREUPLOAD.cfg | ||
| TEST_MAPPING | ||