There's a few advantages to having ApfFilter in IpManager:
1. If things go wrong, crashing a particular transport is less bad then
crashing ConnectivityService. We also don't want to use
ConnectivityService as a dumping ground for transport-specific logic.
2. This makes implementing WifiManager.MulticastLock a lot simpler and
safer because enabling/disabling it doesn't have to go through the
NetworkAgent, which could risk various races (e.g. installing a filter
into the wrong WiFi network).
3. IpManager is the ultimate source for LinkProperties for a particular
transport and since ApfFilter uses the LinkProperties it's better to
have it closely paired with the IpManager. Likewise, ApfFilter needs
to know the APF capabilities of the transport, so having it in
the transport avoids having to parcel this information through the
NetworkAgent.
Bug: 26238573
Change-Id: I99b85f2b64972f0e7572170ec5d1926081aa3429
Adds initial support for IP connectivity metrics collection (DHCP
client, IP reachability monitor, network monitor, connectivity
service).
Change-Id: If9a0455f2a34aa9abea90f9c1b38e4d895dc1a72
This should only happen if we get a packet in the small time
window between binding the packet socket and programming the
BPF filter on it.
Bug: 26696823
Change-Id: I481f1bc74bbaeb9646d96e1841d2a69acdb47d62
This centralizes code that is shared by both bluetooth and ethernet
transport layers.
Bug: 26991160
Change-Id: I8e2dd8580c29c86394119768e3a5529850b4b859
This class uses reflection to find accessible static integer
members in a specified list of classes and returns a SparseArray
mapping the integers to their names. This will allow us to
replace various 400-line switch statements with a simple
array access.
Change-Id: I3607e6389a423cde0bd83270c00b3c863ae1bb29
Additionally, remove IpManager.Callback#usingIpReachabilityMonitor()
now that this is now longer used.
Bug: 26991160
Change-Id: I9a17497c82238a9fb37a20d01aeca7bc4913ae2c
This class captures provisioning request parameters to be passed to
IpManager#startProvisioning().
Bug: 26991160
Change-Id: I56652bbc4b9ae6cfca3f225a8d99cdfc01bb54d9
- netlink from core to services/net/netlink
- IpReachabilityMonitor from core to services/net/ip
Cherry-picked from 02cc5a030a6f132e776b754dd5684ae632009f76
Change-Id: I45ac3f591bade45dd5ec441111b02b621234c0e4
1. Entering DhcpBoundState cancels the renew alarm, but at that
point the renew alarm is guaranteed not to have been scheduled.
This is harmless, but results in an "unknown listener" message
in the AlarmManager logs.
2. We don't cancel the renew alarm when exiting DhcpBoundState.
This is also harmless, because that alarm does nothing except
in DhcpBoundState, and we cancel it whenever we enter
DhcpBoundState. But canceling it on exit is more correct.
Change-Id: I60dfcf00f243253b81b8906540e0a6218a7a489c
This is useful when using the new AlarmManager direct callback
interface to wake up the system and request that an object whose
API consists of messages (such as a StateMachine) perform some
action.
In this situation, using AlarmManager.onAlarmListener by itself
will wake up the system to send the message, but does not
guarantee that the system will be awake until the target object
has processed it. This is because as soon as the onAlarmListener
sends the message and returns, the system is free to go to sleep
again.
Bug: 20157436
Bug: 25823676
Change-Id: Idff20029d287f26347441a2523b7fb20eda6a8b0
