This patch addresses a few post-submit comment for
commits f562ac34a51dc and 60c9f63b66921.
Bug: 34901696
Bug: 62179647
Test: runtest frameworks-net
Change-Id: I4abec57e0c6bc869dc57b5eb54582dd977b64c30
This patch defines a new WakeupStats event in ipconnectivity.proto and
populates these events from the NFLOG wakeup events stored in
NetdEventListenerService.
There is one WakeupStats object per known interface on which ingress
packets arrive and may wake the system up.
Example from $ adb shell dumpsys connmetrics list:
UPDATEME
...
WakeupStats(wlan0, total: 58, root: 0, system: 3, apps: 38, non-apps: 0, unrouted: 17, 6111s)
WakeupEvent(13:36:31.686, iface wlan0, uid -1)
WakeupEvent(13:38:50.846, iface wlan0, uid -1)
WakeupEvent(13:39:16.676, iface wlan0, uid 10065)
WakeupEvent(13:40:32.144, iface wlan0, uid 1000)
WakeupEvent(13:40:35.827, iface wlan0, uid 1000)
WakeupEvent(13:40:47.913, iface wlan0, uid 10004)
WakeupEvent(13:40:52.622, iface wlan0, uid 10014)
WakeupEvent(13:41:06.036, iface wlan0, uid 10004)
...
Bug: 34901696
Bug: 62179647
Test: runtest frameworks-net
Change-Id: Ie2676b20bfb411a1902f4942643df0c20e268d99
Bad synchronization between the mock handler and the test assertions
were causing testDiscoverService() to sometime fails (1/50 ~ 1/100 repro
rate).
Bug: 32561414
Bug: 62918393
Test: runtest frameworks-net, NsdManager#testDiscoverService now passes
1000 times without errors.
Change-Id: I0308cdf48fc6bdc2fc9b4e8f7d5241a1cf2ea443
This will finally allow to write captive portal detection unit tests.
Bug: 32561414
Bug: 62918393
Test: runtest frameworks-net
Change-Id: I38db1bb79ae80a82b4199dc9cb1b56257e0cf222
Otherwise we risk a race condition when we are fixing the LinkProperties
routes, other parts of ConnectivityService is reading the field at the
same time.
Test: runtest frameworks-net -c com.android.server.ConnectivityServiceTest
Test: runtest frameworks-core -c android.net.LinkPropertiesTest
Bug: 65529483
Bug: 35995111
Change-Id: I539578703570a901e0a5dff0155422ca78c52401
This patch stores NFLOG packet wakeup events sent by Netd to the system
server into a ring buffer inside NetdEventListenerService. The content
of this buffer is accessible by $ dumpsys connmetrics or $ dumpsys
connmetrics list, and is added to bug reports.
The wakeup event buffer stores currently uid and timestamps.
Bug: 34901696
Bug: 62179647
Test: runtest frameworks-net, new unit tests
Change-Id: Ie8db6f8572b1a929a20398d8dc03e189bc488382
Move all corner case logic from call sites to CompareResult's implementation,
add a constructor to directly do the comparison.
Test: runtest frameworks-core -c android.net.LinkPropertiesTest
Change-Id: I95bba82ec38d295b18c49c025dffab5f17271cbd
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 4bfaefeb95)
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 729f0b476d)
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 adds the following wakelock related counters to connectivity
service dumps included in bug reports:
- total number of wakelok acquisitions and releases
- total cumulative wakelock duration
- longest time the lock was held
Bug: 65085354
Test: runtest frameworks-net, also manually dumped connectivity service
and check new logging
Merged-In: I8f67750c2eea73abf3d44f7f6df484427a8ea3f9
Merged-In: I93c0eb7c8add966378647400e11e33765d952345
Merged-In: Iabe99993001e069b8a8077533bca1fa7fb2f59ba
(cherry picked from commit 3ac913c614)
Change-Id: I4d6bb43110916b440819813b478523546ac5570e
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
This patch adds a layer of asynchonicity to the NetworkBaseObserver
callbacks implemented by Nat464Xlat in order to allow these callbacks
to run on the main ConnectivityService handler.
This allows to run interfaceLinkStateChanged and interfaceRemoved
callbacks in the same thread context as other Nat464Xlat methods and
solves the following issues:
- NPE risk due to race between fixupLinkProperties called on the
ConnectivityService thread and interfaceRemoved called as a
callback by NetworkManagementService.
- stale LinkProperties reads in both callbacks not called on
ConnectivityService handler.
- removes the race between stop() and interfaceRemoved().
This patch also:
- removes/simplifies comments related to the threading
model which are no obsolete.
- extract clatd management logic from ConnectivityService into
NetworkAgentInfo
Bug: 62997041
Bug: 64571917
Test: runtest frameworks-net
manually connected to ipv6 network and went to test-ipv6.com
Change-Id: I889d98e47423ff3d4746d6ed8015b265286e7c52
This patch does some cleanup of Nat464Xlat internal state guards
against the Nat464Xlat state Idle | Started | Running, which reduces
code nesting.
It also replaces introspection of internal state for distinguishing
between different stages in 464xlat lifecycle with an enum explicitly
introducing these three Idle | Started | Running states.
Bug: 62997041
Bug: 64571917
Test: runtest frameworks-net
manually connected to ipv6 network and went to test-ipv6.com
Change-Id: I6efc9fed2420ca488731a2b9b9c3c025b16eca10
This patch does some minor refactoring of clat starting/stopping code:
- remove unused LinkProperties arguments in updateClat
- remove unused Context argument in Nat464Xlat ctor
- introduce ensureClatIsStarted and ensureClatIsStopped methods and
simplify updateClat
- add clatd to NetworkAgentInfo toString() method
- clarify some comments
This changes prepare for moving BaseNetworkObserver callbacks to
ConnectivityService.
Bug: 62997041
Bug: 64571917
Test: runtest frameworks-net
manually connected to IPv6 only network and went to test-ipv6.com
Change-Id: Idb204784614cfe700f73255a7a7b78c5e9ee6eca
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
