If either enableNat() or startInterfaceForwarding() fail, be sure
to cleanup any commands that might have succeeded.
Most of this change is a refactoring of cleanupUpstreamIface() into
two methods, one of which (cleanupUpstreamInterface()) is reused
in error handling scenarios.
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest -x .../tethering/TetherInterfaceStateMachineTest.java passes
Bug: 32031803
Bug: 32163131
Change-Id: Ia4d56e03beeab1908d8b8c2202e94992f1aa58a4
The test calls that need to pass but do not currently are commented out.
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest -x .../tethering/TetherInterfaceStateMachineTest.java passes
Bug: 32031803
Bug: 32163131
Change-Id: I68ed476920bef882f353d8e8a54c72120bc27002
All the tests are now asynchronous. The only remaining uses of
Thread.sleep() are in the tests that check for NetworkRequest
timeouts.
Test: ConnectivityServiceTest passes 100 times in a row
Bug: 32561414
Change-Id: If420bd66c692a90d5031ee06a888a8cc3b4398a8
The calls in testAvoidBadWifi are no longer necessary now that
waitForIdle is reliable, and the calls in testPacketKeepalives
are replaced with a wait for the NetworkAgent to disconnect.
Test: ConnectivityServiceTest passes 100 times in a row.
Bug: 32561414
Change-Id: Icbb161ca6e343bd14764a1c9ccfdd14b6cd6803f
Rename the class and ensure that all code related to bad wifi
avoidance has names that reflect its purpose. This will allow us
to reuse most of the the code for other purposes in future CLs.
Test: runtest frameworks-net passes
Bug: 34630278
Change-Id: Ida190e5a79e7a12f4eec07e1a3e4d9d138e83bcd
The current implementation of IdleableHandlerThread is based on
the assumption that MessageQueue#isIdle will return true iff the
message loop has finished processing its messages.
Unfortunately, this is incorrect: isIdle returns true iff are no
more messages waiting in the queue; thus, it will also return
true while it is processing the last message before going idle.
Instead of using idle handlers, take the simpler approach of
posting a runnable to the message loop and waiting for it to
be processed.
Test: see other CLs in this patch series
Bug: 31479480
Change-Id: Iae75781f067b762c8653a488a5e4d5ee0c789e01
This is for use while preferred upstreams are expressed as legacy types.
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest frameworks-net passes
- USB tethering to WiFi and DUN works
Bug: 32163131
Change-Id: I76e7b6c95eb1b54e926096b2791163617bb0a818
This activates all frameworks-test tests in runs of the continuous
platform tests.
Test: $ runtest frameworks-net passes (expect Tether
Bug: 32561414
(cherry picked from commit fa8a6f6220)
Change-Id: I7b0706a7e3368f971d508388e8ad4afc5de9d646
This is the same notification as the one shown during legacy lockdown
mode, sans the 'reset' button.
The notification is only shown during times when VPN has not yet
established or has failed, for example during boot or after a crash.
Bug: 29123115
(cherry picked from commit 1a405fe300)
Change-Id: I929a05c24df01e21415535a333bb14ac4b790a9d
This patch introduces an assertEventuallyThat helper function in
ConnectivityServiceTest which given a boolean function retries until the
function returns true or until a maximum retry time is reached.
This function is used to fix flakyness of testAvoidBadWifiSetting where
the Message posted by reevaluate() could reach the Handler's
MessageQueue after waitForIdle takes effect, resulting in the test to
fail.
Instead of fixing the flakyness by introdcing hard sleep times,
assertEventuallyThat is used to reduce the overall test time.
With this change the test has been observed to pass with 100% success
rate over 50000 invocations.
Test: $ runtest frameworks-net
Bug: 32561414
(cherry picked from commit 99c8294ef0)
Change-Id: If41a24989d5f65aeb439f68741f511b5eb53b18d
This patch fixes flakyness of testRequestBenchmark by adjusting time
limit for callback registration from 100ms to 180ms, and time limits for
onAvailable and onLost triggers from 30ms to 40ms.
With these timeouts the test succeeds 100% over 5000 iterations.
When using 150ms for registration timeout, running the test 5000 times
fails 2 times.
When using 30ms for onLost timeout, running the test 5000 times fails
1 times.
In addition, this patch also cleans testRequestBenchmark and uses the
more stable SystemClock.elapsedRealtime() for duration measurements.
Test: $ runtest frameworks-net
Bug: 32561414
(cherry picked from commit 38be57b438)
Change-Id: I196ab9ef7f5abe456a783eed65db09279d2ecb8c
Test: IpConnectivityMetricsTest passes. Also manually changed the new
setting and verified the buffer size is as expected after flushing the
buffer.
Bug: 32198637
(cherry picked from commit 05686dbb6b)
Change-Id: Iefbeac3a688b260fb3f92dfe0bfd9db28e26749d
This patch adds a version field to ipconnectivity.proto and populates it
to 2, which is the logical version number for NYC-MR2.
Test: IpConnectivity{EventBuilder,Metrics}Test pass
Bug: 32127906
(cherry picked from commit d680d4c856)
Change-Id: If8f167c0dc4c1abe0e235e2adfd131168a4ddc52
Guarantees that timeouts are only delivered if a network never
becomes available. Once a network is available the timeout is
canceled.
Bug: 31402633
Test: all timeout related unit tests pass (new one added)
(cherry picked from commit 681fcda589)
Change-Id: I7cd3086544c881915fc6dbf14b87a24ab0cd8748
This was broken by the implementation of IPv6 tethering, which
relies on various private classes which end up calling unmockable
final classes like NetworkInterface.
Making everything public like this is almost certainly not the
best way of fixing this test, but on the other hand there is
value to the test continuing to pass.
Test: runtest frameworks-net # Everything passes.
Test: IPv6 tethering continues to work.
(cherry picked from commit 7e0eeca8ba)
Change-Id: I8a3cf466871c026f4ae0f5cfa73071338cdf5b7e
