Rename the opt-out flag in AndroidManifest to
SERVICE_META_DATA_SUPPORTS_ALWAYS_ON
as directed by the API Council.
Bug: 64331776
Bug: 36650087
Test: runtest --path java/com/android/server/connectivity/VpnTest.java
Change-Id: I24326fad7a89083a2409134640bda81ee0359d08
Merged-In: I24326fad7a89083a2409134640bda81ee0359d08
(cherry picked from commit d681363fd1)
Always-on VPN is a feature introduced in N. Since then, all VPN apps
targeting N+ are assumed to support the feature, and the user or the DPC
can turn on / off always-on for any such VPN app. However, a few VPN
apps are not designed to support the always-on feature. Enabling
always-on for these apps will result in undefined behavior and confusing
"Always-on VPN disconnected" notification.
This feature provides a new manifest meta-data field through which a VPN
app can opt out of the always-on feature explicitly. This will stop the
always-on feature from being enabled for the app, both by the user and
by the DPC, and will clear its existing always-on state.
A @hide API is provided to check whether an app supports always-on VPN.
Documentation is updated to reflect the behavior change.
Bug: 36650087
Test: runtest --path java/com/android/server/connectivity/VpnTest.java
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedDeviceOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackage'
Test: cts-tradefed run cts --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testAlwaysOnVpnUnsupportedPackageReplaced'
Change-Id: I477897a29175e3994d4ecf8ec546e26043c90f13
Merged-In: I477897a29175e3994d4ecf8ec546e26043c90f13
(cherry picked from commit 9369e61e2d)
For some networks such as mobile data connections, its LinkProperties
does not contain routes for the local subnet so no such route is added
to the interface's routing table. This can be problematic especially
if the device is in VPN lockdown mode where there exists high-priority
PROHIBIT routing rule which in turn blocks the network's default gateway
route from being added (next hop address hitting the prohibit rule).
We fix this by patching LinkProperties to always include direct connected routes
when they are received by ConnectivityService. This has the added advantage that
when apps get LinkProperties, they see the directly connected routes as well.
Bug: 63662962
Test: runtest frameworks-core -c android.net.LinkPropertiesTest
Test: runtest frameworks-services -c com.android.server.ConnectivityServiceTest
Test: Start with device with mobile data, set up ics-OpenVPN in always-on
lockdown mode. Turn off mobile data then turn it back on, observe
mobile data connectivity is restored and VPN successfully reconnects.
Change-Id: I35b614eebccfd22c4a5270f40256f9be1e25abfb
This patch relays the NetworkBaseObserver notifications about nat
464xlat stacked interfaces onto the ConnectivityService handler.
This allows to process interface up and down notifications in the
same thread context and eliminates several races:
- NPE risk due to race between fixupLinkProperties called on
ConnectivityService thread and interfaceRemoved called on
NetworkManagementService thread.
- stale LinkProperties pointer reads in both NetworkBaseObserver
callbacks not called on ConnectivityService handler.
- removes the race between stop() and interfaceRemoved().
- removes superfluous LinkProperties notifications when stop() is
called before the stacked interface goes up.
The teardown procedure logic common to stop() and interfaceRemoved() is
put into enterStoppedState() and enterIdleState().
This allows to distinguish and correctly handle the following teardown
scenarios:
- an IPv4 appears -> ConnectivityService calls Nat464Xlat#stop()
-> Nat464Xlat calls stopClatd
-> clatd stops
-> if the stacked interface was up, it is removed
-> Nat464Xlat#interfaceRemoved() is triggered and
a LinkProperties update is sent.
- network disconnects -> ConnectivityService calls Nat464Xlat#stop()
-> Nat464Xlat calls stopClatd
-> clatd stops
-> if the stacked interface was up, it is removed
-> Nat464Xlat#interfaceRemoved() is triggered and
a LinkProperties update is sent.
- clatd crashes or exit -> Nat464Xlat#interfaceRemoved() is triggered
-> Nat464Xlat unregisters itself as a network
observer
-> ConnectivityService is updated about the
stacked interface missing, and restarts
Nat464Xlat if needed.
Note that the first two scenarios have two cases: stop() can be called
before the notification for the stacked interface going up (STARTED), or
after (RUNNING). In the first case, Nat464Xlat must unregister
immediately as a network observer to avoid leaks.
This patch also:
- removes/simplifies comments related to the threading model which
are no obsolete.
- extract clatd management logic from ConnectivityService into
NetworkAgentInfo
- add new unit tests where there was none before.
Bug: 62918393
Bug: 62997041
Bug: 64571917
Bug: 65225023
Test: runtest frameworks-net
Change-Id: I27221a8a60fd9760b567ed322cc79228df877e56
1. Mock the service manager so that NMS can fetch mock versions
of INetd and IBatteryStats.
2. Call LocalServices.removeServiceForTest to avoid a duplicate
service registration error. // check this
3. Change the timeout from 100ms to 200ms, as otherwise the tests
that check for IfaceClass fail.
4. Convert NetworkManagementServiceTest to JUnit 4.
5. Move NetworkManagementServiceTest to tests/net
Bug: 29337859
Bug: 32163131
Bug: 32561414
Bug: 62918393
Test: runtest frameworks-net
Change-Id: Ic7371b427b35809ccd446addf35c9d8ae99ccfd3
Currently, we only count add tethering traffic to per-UID
stats, but not to total data usage (i.e., dev and XT stats). This
is correct for software tethering, because all software forwarded
packets are already included in interface counters, but it is
incorrect for hardware offload, because such packets do not
increment interface counters.
To fix this:
1. Add an argument to ITetheringStatsProvider#getTetherStats to
indicate whether per-UID stats are requested. For clarity,
define integer constants STATS_PER_IFACE and STATS_PER_UID
to represent these operations.
2. Make NetdTetheringStatsProvider return stats only if per-UID
stats are requested. (Otherwise tethering traffic would be
double-counted).
3. Make OffloadController's stats provider return the same
stats regardless of whether per-UID stats were requested or
not.
4. Make NetworkStatsService add non-per-UID tethering stats to
the dev and XT snapshots. The per-UID snapshots were already
correctly adding in per-UID stats.
(cherry picked from commit 49ab263c0b)
Bug: 29337859
Bug: 32163131
Test: runtest frameworks-net
Test: runtest frameworks-telephony
Change-Id: I325b13d50e88841dfb0db4c35e7e27f163ee72fe
Merged-In: I4e8e923d68dce1a4a68608dbd6c75a91165aa4ee
Also moving relevant test files into tests/net as part of runtest
framworks-net.
Also removes testHashCode in LinkAddress() because this test relies on
the assumption that hashCode() is stable across releases or jdk
versions, which is absolutely not true.
This creates maintenance work for little benefit since hashCode is
already tested as part of the equality test.
For instance this test is now broken because hashing for InetAddress
changed.
Bug: 62988545
Bug: 62918393
Test: runtest frameworks-net, added coverage in tests
Change-Id: I695bc3f0e801bf13bc4fc0706565758f12b775b4
This patch fixes the mask used in describeImmutableDifferences which did
not correctly turn NET_CAPABILITY_NOT_METERED into bit flag.
Bug: 63326103
Test: added unit tests, runtest frameworks-net
Change-Id: Ib6b390b1daef5912859302692af7dcd6cfd3e39a
This patch corrects a regression added by commit fd35080555 that did
not take into account the case of multiple notifications shown for a
single network id. Given how network notifications are triggered, it can
happen that NO_INTERNET and SIGN_IN notifications are both triggered for
the same network when captive portal detection is slow.
Contrary to the situation before commit fd35080555, a notification
priority order is introduced so that SIGN_IN always overrides
NO_INTERNET, and NO_INTERNET is ignored if SIGN_IN is already present.
Bug: 63676954
Bug: 62503737
Test: runtest frameworks-net, added new unit tests
Change-Id: Ib8658601e8d4dc6c41b335ab7dd8caa0cccd9531
This patch fixes a couple of flakyness issues with
testNetworkInfoOfTypeNone. It also fixes some typos and naming issues.
Bug: 62918393, 62918393
Test: runtest frameworks-net
Change-Id: I1c56557ab113d3ef57dbc06a6e882634d03c5b09
This patch allows to use TYPE_NONE for the legacy network type variable
of NetworkInfo. This usage is "safe" with respect to legacy APIs using
network types as most of them already returns null or do nothing for
TYPE_NONE.
Of the existing APIs in ConnectivityManager that accept a network type
argument, those which were already returning null or doing nothing for
TYPE_NONE are:
getNetworkInfo(int)
getNetworkForType(int)
stopUsingNetworkFeature(int, String)
networkCapabilitiesForType(int)
requestRouteToHostAddress(int, InetAddress)
reportInetCondition(int, int)
isNetworkSupported(int)
getLinkProperties(int)
Only setProvisioningNotificationVisible needs an additional guard
against TYPE_NONE.
Bug: 30088447
Bug: 62844794
Test: runtest frameworks-net
Change-Id: I112596fcd03d3c2cd42a2a84d265adb38e3944bb
ConnectivityServiceTest was still using sleep() in a few places although
these were unnecessary:
- in testSatisfiedThenLostNetworkRequestDoesNotTriggerOnAvailable(),
expectNoCallback() and expectAvailableCallback() already include
waitForIdleHandler calls that drain the message queues and make
sleep no-ops.
- in testTimedoutAfterUnregisterdNetworkRequest, the sleeps were
introduced before unregisterNetworkCallback was changed to have a
synchronous effect for callback unregistration, therefore the sleep
becomes simply non-sensical. To reflect this the name of the method
is also changed.
Bug: 62918393
Test: runtest frameworks-net
Change-Id: I7b701ecf5846a5e1890e86107b8d2544b419ce44
ConnectivityServiceTest was still using sleep() in a few places although
these were unnecessary:
- in testSatisfiedThenLostNetworkRequestDoesNotTriggerOnAvailable(),
expectNoCallback() and expectAvailableCallback() already include
waitForIdleHandler calls that drain the message queues and make
sleep no-ops.
- in testTimedoutAfterUnregisterdNetworkRequest, the sleeps were
introduced before unregisterNetworkCallback was changed to have a
synchronous effect for callback unregistration, therefore the sleep
becomes simply non-sensical. To reflect this the name of the method
is also changed.
Bug: 62918393
Test: runtest frameworks-net
Change-Id: I78426665670f702304212753f417b3d5a8a2c107
This patch allows to use TYPE_NONE for the legacy network type variable
of NetworkInfo. This usage is "safe" with respect to legacy APIs using
network types as most of them already returns null or do nothing for
TYPE_NONE.
Of the existing APIs in ConnectivityManager that accept a network type
argument, those which were already returning null or doing nothing for
TYPE_NONE are:
getNetworkInfo(int)
getNetworkForType(int)
stopUsingNetworkFeature(int, String)
networkCapabilitiesForType(int)
requestRouteToHostAddress(int, InetAddress)
reportInetCondition(int, int)
isNetworkSupported(int)
getLinkProperties(int)
Only setProvisioningNotificationVisible needs an additional guard
against TYPE_NONE.
Bug: 30088447
Bug: 62844794
Test: runtest frameworks-net
Change-Id: I4455f2726d06406047086368628c1f253d854d8d
- less strict regex for SharedLogTest: the subsecond part of the
timestamp can have 0, 1, 2 or 3 digits.
- refactor NetworkStatsServiceTest and NetworkStatsObserversTest to use
waitForIdleHandler facility of ConnectivityServiceTest.
NetworkStatsServiceTest was using a flaky custom version of
waitForIdleHandler.
Bug: 62918393
Bug: 32561414
Test: runtest frameworks-net
Change-Id: I634acfb5f4fe1bd5267e3f14b9f645edc32d5d12
NsdManagerTest relies on the lastMessage variable to assert the
connection of a client to the service. The asserts in test are done on a
different thread, although the variable was not qualified volatile,
which creates the chance to read a stale value. This patch fixes this
race by marking the variable volatile.
Bug: 32561414
Bug: 62044295
Test: NsdManagerTest works
Change-Id: I0bc2cd8059c6ff8b78a2dda0ba8d6bc7e13ef951
Recent continuous testing runs indicates that commit 79614aee did not
completely fixed the issue with testRequestBenchmark.
This patch changes the name of the test to not include "test" and
removes @SmallTest annotation, which should do the job of @Ignore while
ConnectivityServiceTest still extends AndroidTestCase.
In addition timeouts are adjusted to take into account recent failures
observed.
This is the last pending action before turning on FrameworksNetTests on
presubmits.
Bug: 32561414
Test: no functional change
Change-Id: I56ef334e19e99e5a3483418330e5f0ccd6eb31bb
