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 prepares some refactoring and the addition of a timeout to
resolveService.
Test: new tests pass
Bug: 37013369, 33298084
Change-Id: Ie8277bd5983278507bfa70495b4ce7d13895b24b
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 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
testApfFilterRa is failing with probabiliy 1/10 ~ 1/15 on the following
assert: assertDrop(program, packet, lifetime/6), for lifetime values
that are multiple of 6, where 6 is the hardcoded fraction of RA lifetime
to filter in ApfFilter.java.
When the lifetime is not a multiple of 6, the remainder of 1 to 5
seconds gives enough margin so that when the APF program is simulated
the faked lifetime of the program is less than lifetime/6 away and the
packet is dropped.
However for lifetimes which are exact multiples of 6, this margin is
always 0s and that result in nondeterminism in the result. This is
consistent with the obervation that the only failed assert was for a
lifetime of 300s, the only multiple of 6.
This can be observed by detecting the age limit at which the filter
stops dropping packet oscillating between lifetime/6 and lifetime/6 + 1
for lifetimes which are multiple of 6.
This patch fixes the flakyness by freezing the flow of time in tests so
that the expected filter age threshold is consistent and stable.
Test: no failure observed in 1000 runs.
Bug: 32561414
Change-Id: I5251d047039f34b82ce8a5d20ae46563e1e0cce8
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
Test: new unit test + $ runtest franeworks-net
Bug: 32833400
(cherry picked from commit f98182ef5e)
Change-Id: Ifaf6e778c811c7d865c790a293b1fce3f43cad1c
Test methods not tagged with @{Small,Medium,Large}Test will not appear
in the Android Platform Continuous Testing dashboard.
Test methods tagged with @LargeTest will not be run in the Android
Platform Continuous Testing dashboard.
Test: ApfTest passes ($runtest frameworks-net)
Bug: 31479480
(cherry picked from commit 4195c28347)
Change-Id: Ia215fc8e2ccc61f6223c24fdf390e1e759de302f
This will give us a good place to put all the networking tests.
Fix: 31479480
Test: adb shell am instrument -w -e notClass com.android.server.connectivity.tethering.TetherInterfaceStateMachineTest 'com.android.frameworks.tests.net/android.support.test.runner.AndroidJUnitRunner' # PASS
(cherry picked from commit ecc986d430)
Change-Id: I993eeaa5dec001c39389023f355f506129b356e7
