If anything unrestricted is bundled in the whole thing has to be
unrestricted (we can't restrict based on destination or intent)
but the NOT_METERED flag wasn't taken into account.
This wasn't a problem before because telephony set that statically
and late, but a change caused it to be marked NOT_METERED earlier
which exposed this bug.
bug: 37208956
Merged-In: I7b7a1c38621ce0ecde8cf041e82b1ebb7a9c6f15
Test: new NetworkCapabilitiesTest. Fails without fix, works with.
Change-Id: I86c1b2854413a94662aa53e697d32380695ab9ac
This patch changes how callback unregistration works in order to be
consistent with undocumented use cases currently de-facto supported
by the API (although in a buggy way):
- callback recycling: releasing then reregistering a callback again.
- multiple request registrations with the same callback.
The second use case is not desirable but needs to be taken into account
for now for the purpose of correctly releasing NetworkRequests
registered in ConnectivityService.
In order to support request release in both use cases with minimal
amount of complexity for the time being the following changes are done:
- request to callback unmapping is done synchronously at callback
release time.
- all requests associated to a callback are unmapped at callback
release time.
This fixes the following issues:
- a callback stops being triggered as soon as it is released.
Otherwise when recycling the callback immediately, it is possible
the previous request associated with it triggers it, confusing the
app.
- when a callback is registered multiple times, the requests are not
leaked.
- when a callback is registered multiple times and then released, the
N-1 first registrations do not trigger the callback anymore.
In the future it would be desirable to enforce the intended 1:1 mapping
between callbacks and requests at registration time.
Bug: 35921499, 35955593, 20701525
Test: - added new tests in ConnectivityManagerTest to test releasing,
recycling, and a disabled test for no multiple regristration.
- new tests catch regression causing b/35921499, b/35955593.
Change-Id: Ia0917ac322fc049f76adb4743bc745989fed6d26
This groups them together with the rest of the networking unit
tests. It also speeds up compile/test cycles ("runtest -x" of one
file goes from 1m15s to 30s).
Test: runtest frameworks-net passes on internal tree
Change-Id: I53cb0c51355fe4b4b30e451fa09fbbf58da39efd
This patch fixes mismatch between current proto compiler and what is
expected in several IP connectivity metrics unit tests.
Test: built, flashed, $ runtest frameworks-net
Bug: 37126521
Change-Id: I1476c923d61f748ecac1146423127f54ba117502
This allows an application that knows how to provide seamless
network connectivity (e.g., using QUIC multipath) to find out if
doing so is desired.
(cherry picked from commit 48a2a32bdd)
Test: builds, boots, runtest frameworks-net passes.
Bug: 34630278
Change-Id: Ic7fd0b9e1cd879fdfaf84009d7125391895e9087
Tests various combinations of empty / non-empty NetworkSpecifiers
and changing specifiers on the fly.
Test: ConnectivityServiceTest passes
Bug: 27533960
Change-Id: Ibd6b4efc861dc51689e46f3882ba859223411bf0
Test: ConnectivityServiceTest passes on ryu on internal master
Test: ConnectivityServiceTest passes on bullhead
Change-Id: If94102c7df0257ea9e69e72b07a685ae3c2c4022
This cleanup helps declutter ConnectivityService, and encapsulates the
always-on setting inside of Vpn instead of spreading it across two
classes.
In particular having the save code in one file and the load code in
another file was weird and I apologise for that.
Added a SystemServices wrapper for Settings.Secure and PendingIntent
calls to decouple some of the global state nastiness and make it
testable without forcing ConnectivityService to drive the load/save.
Test: runtest -x tests/net/java/com/android/server/ConnectivityServiceTest.java
Test: runtest -x tests/net/java/com/android/server/connectivity/VpnTest.java
Bug: 33159037
Change-Id: Ie2adb1c377adfcef0a5900dc866e6118f451b265
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest frameworks-net passes
- manual USB tethering toggling between WiFi and mobile
Bug: 32163131
Change-Id: I57edf5114b6361f320577c7870e40f8b3cdf74ce
The state that needs to be transferred includes:
- NetworkCapabilities
- LinkProperties
- whether the network is currently suspended
Additionally:
- Rename notifyNetworkCallback() to notifyNetworkAvailable()
in order to clarify its real function.
- fix previous copy/paste error in unittest
Test: as follows
- built (bullhead)
- flashed
- booted
- runtest frameworks-net passes
- USB tethering with mobile and Wi-Fi upstream toggling
Bug: 32163131
Change-Id: Ib4460bcd5d08863a9feac9e8ab41a238897bb3ea
This static method returns a NetworkCapabilities instance with
transports and capabilities set according to the given legacy type.
Also:
- add NetworkRequest.Builder.setCapabilities(), to be able to use
the NetworkCapabilities instances returned from the above
- update UpstreamNetworkMonitor to make immediate use of this
Test: as follows
- build (bullhead)
- flashed
- booted
- runtest frameworks-net passes
- WiFi to DUN upstream tethering works
Bug: 32163131
Change-Id: Idfe1ddd2815c355cbf27cf29eb0e3de177de84e9
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 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 3664598601)
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 9ca892f698)
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 b54c8cffa8)
Change-Id: If41a24989d5f65aeb439f68741f511b5eb53b18d
