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
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
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
Like kale, one can never have enough stats. =)
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
Bug: 29337859
Bug: 32163131
Merged-In: I5d40eae488cab685be6a44849181c0286fe28fdb
Merged-In: I759e97f9a72d15a84036c3a56451b872143539c6
Change-Id: Ieb47c3beed50f21c2c858fe57438afd48cfdc662
(cherry picked from commit 1199a352fc)
Like kale, one can never have enough stats. =)
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
Bug: 29337859
Bug: 32163131
Change-Id: Ieb47c3beed50f21c2c858fe57438afd48cfdc662
Try sticking with integer-based math as much as possible for speed,
but switch to double-based math if we detect that we'd end up
causing an overflow.
New tests to verify.
Test: bit FrameworksNetTests:com.android.server.net.NetworkStatsCollectionTest
Bug: 65257769
Change-Id: I1ae35599be134f81850c0a3d86928b057fba1eff
When a carrier provides an "anchor" of data usage at a specific
moment in time, augment the network statistics used by warning/limit
thresholds and Settings UI. For example, if the OS measured 500MB
of usage, but the carrier says only 400MB has been used, we "squish"
down the OS measured usage to match that anchor.
Callers using the hidden API will have their data augmented by
default, and the public API offers a way to opt-into augmentation.
Thorough testing to verify behavior.
Test: bit FrameworksNetTests:android.net.,com.android.server.net.
Test: cts-tradefed run commandAndExit cts-dev -m CtsUsageStatsTestCases -t android.app.usage.cts.NetworkUsageStatsTest
Bug: 64534190
Change-Id: Id3d4d7625bbf04f57643e51dbf376e3fa0ea8eca
Fixes:
frameworks/base/tests/net/java/com/android/server/connectivity/tethering/OffloadControllerTest.java:149: error: [JUnit4TestNotRun] Test method will not be run; please add @Test annotation
public void testNoSettingsValueDefaultDisabledDoesNotStart() throws Exception {
^
(see http://errorprone.info/bugpattern/JUnit4TestNotRun)
Did you mean '@Test'?
frameworks/base/tests/net/java/com/android/server/connectivity/tethering/OffloadControllerTest.java:170: error: [JUnit4TestNotRun] Test method will not be run; please add @Test annotation
public void testNoSettingsValueDefaultEnabledDoesStart() throws Exception {
^
(see http://errorprone.info/bugpattern/JUnit4TestNotRun)
Did you mean '@Test'?
Bug: 64489631
Test: m -j RUN_ERROR_PRONE=true javac-check
Merged-In: Ib32489d07778465134bca52c589baddbd78ab129
Change-Id: I41dfdf87529e532df385617fa05c7006a7a14c86
Currently, if setting a data limit fails, we completely stop
offload in order to avoid data overages. However, the next thing
we do is try to fetch the stats and crash, because once offload
is stopped all our local state is cleared.
Fix this by fetching stats before we stop offload.
Bug: 29337859
Bug: 32163131
Bug: 64867836
Test: OffloadControllerTest passes
Test: no crash when disabling wifi tethering with BT tethering active
Merged-In: I7fc47e60b2da5f39c26fb22c1325618f9948dd38
Merged-In: I464dd2a6d1996b1cfb8bbf82b6ee453fd0747569
Change-Id: I260f5450f8b67f055983af68fb23a5f3cfc0bc69
(cherry picked from commit d743601a00)
