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
Some internal tests broke due to this. Revert for now to unblock, and investigate why this occurred.
This reverts commit f08ad98acbb83abf7d30b6583bdfc188145a4215.
Bug: 65319218
Change-Id: I1bfb2d4937708441eac2ee5909717abec10f4971
Properly map transport nan and lowpan to their corresponding link layer
enum. Also do so for interface names
Bug: 34901696
Bug: 65439160
Test: runtest frameworks-net
Merged-In: I44a1cb3b6d21881b64adda7744360e4dfc519b12
(cherry picked from commit f7f7ed013ca7641c784b81ef685bd84c4c45cfbb)
Change-Id: Ic92b6d5c07404ea79f9a8975e8fc6925eaa10ba4
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
It had been tested work well for both english characters
and chinese english misc characters.
Because utf-8 is supported in recovery mode, so
if we stored message by utf-8 encoding, we can
handle non-ascii character for ota packages's path.
Change-Id: I19555dc75640bbfd481f23009bff511c07ae0bdb
Signed-off-by: aquanox <aquanox@163.com>
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 26bcfa19d01758c86a8f43a5b39673cd5866d2f3)
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
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 1199a352fcb938a8dc7a34a2853c4fde7f5656f1)
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
(except for UidRange and APF tests that are missing libvndk)
- regular WiFi STA mode attach works for IPv4-only, dualstack,
and IPv6-only networks
- tethering works with dualstack upstream and downstream
Bug: 62476366
Change-Id: Id807b3091b0b2935b01aeb3644245034312b4183
Add a configurable black for protocols which packets are to be dropped
by APF. This enales an OEM to configure the APF to filter out un-needed
packets from reaching the host
Bug: 62415182
Test: runtest frameworks-net
Merged-In: I86335a0f854d5e83a2b2767978cd69b2cc25c2f8
Signed-off-by: Ahmed ElArabawy <arabawy@google.com>
(cherry picked from commit caffbe127726c6a9ab5dd023a9b09cfa43eac617)
Change-Id: I15a758d18464d73d24ba8364a867904bb3cd3b34
The OverlayManagerListener connected to the OverlayManagerServiceImpl
should be notified when and only when the overlay settings have been
modified. The pattern used to fulfill this contract as a result of a
change to a target package is as follows:
if (updateAllOverlaysForTarget(...)) {
mListener.onOverlaysChanged(...);
}
Fix two violations of this pattern:
- The listener was always notified
- The listener was never notified
Test: manual
Change-Id: Id24a439e2eaaf976e8c7d650af36d58632cfb4ba
Remove the unused methods
- IdmapManager.isDangerous(PackageInfo, int)
- IdmapManager.isDangerous(String)
The concept of a dangerous overlay is currently not used, so remove any
trace of it.
Test: builds
Change-Id: I79ea00c05c0ee113733c20e982ae8f517bbbbd11
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
When enabling the magnifier feature it is possible to trigger
a system crash.
Problem:
On ACTION_DOWN a MESSAGE_ON_ACTION_TAP_AND_HOLD is sent to the
handler with a delay based on long-press timeout. If the user
then removes their finger while outside of the magnification area,
(ACTION_UP) this message is not removed. Then when the message
is handled on long-press timeout, it puts the state into
STATE_VIEWPORT_DRAGGING. If the user then taps the screen again
it is handled by the StateViewportDraggingHandler resulting in:
IllegalArgumentException: Unexpected event type: ACTION_DOWN
and a system server crash.
Bug: 65101895
Test: Manual:
1. Enable "Magnify with button" from accessibility settings
2. Tap accessibility button on the right navbar
3. Touch & hold bottom part of application area
4. Quickly drag down to the navbar and release
5. Touch anywhere
With this patch it should not crash
Change-Id: I7df8d2185f6db9d148d24d2b155cb357b3637a71
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
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 d743601a002ac12c02da58e92ebd0544ab0b77ea)
This patch removes the call to runWithScissors() in
OffloadController#getTetherStats() that was causing a deadlock when
NetworkStatsService would be polled for stats in certain threading
contexts.
Instead of trying to query the tethering offload HAL synchronously all
the time, this patch:
- changes getTetherStats() to only call into the offload HAL when it
detects that it is called on the same thread as the Tethering handler
thread.
- changes the map of interface to accumulated tethering forwarded stats
to be concurrent.
This makes stats reading from getTetherStats() eventually consistent.
From the point of view of getTetherStats(), it preserves the guarantees
that tethering stats are monotonically increasing, and also guarantees
no tearing between rx bytes and tx bytes.
Bug: 29337859
Bug: 32163131
Bug: 64771555
Test: runtest frameworks-net
Merged-In: Ibcd351ad0225ef146b00a807833f76d2a886f6c1
Merged-In: I61786d61fe1422e429c0dd9eadaff6f02eb850e7
Merged-In: I999d1d1bf72e7ab02c5d17f37aad00bc711d3fc5
(cherry pick from commit eb5e465edd78bea26289f779b635c7e94d934854)
Change-Id: I28646b962cee8c8a6efd66059f84873c02ac5810
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
Switch from /data/misc/reboot/last_reboot_reason to persistent
Android property persist.sys.boot.reason for indicating why the
device is rebooted or shutdown.
persist.sys.boot.reason has a standard as outlined in b/63736262 and
the associated investigation. Made adjustments to the values so that
we did not create a problem even before we started. Compliance is
part of the tests in boot_reason_test.sh.
Test: system/core/bootstat/boot_reason_test.sh
Bug: 64687998
Change-Id: Iba69acf2105f4446411d86cdb8097a1755a20f15
This patch changes IpManager to take into account static provisioning
information specified in the InitialConfiguration for IPv6 static
configuration.
When a valid InitialConfiguration with IPv6 content is specified,
IpManager will do the following things:
- at start(), it will push the IPv6 addresses in the config to netd
- it will observe all addresses be notified via Netlink
- when all addresses are there, it will patch in the associated IPv6
routes in the config, so that they get passed to ConnectivityService
through the usual mechanism
The logic triggering onProvisioningSuccess is also changed to take into
account InitialConfiguration: when all addresses and all routes in the
config are seen the provisioning is successful.
Bug: 62988545
Test: runtest frameworks-net, with newly added tests
Change-Id: I77ed7c576c4b198de7a4726be70c78b74689e98b
