History log of /frameworks/base/services/net/java/android/net/apf/ApfCapabilities.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
9132f34976f16a626c2ec1d3d90624d71e054346 13-Apr-2016 Paul Jensen <pauljensen@google.com> ApfFilter unit test

Bug: 26238573

Change-Id: I5171038228782bd54e91f5bcc663cc529d2c1150
/frameworks/base/services/net/java/android/net/apf/ApfCapabilities.java
37127f8620188f5e04c3e0e2aeaa2c15fa8c8e2d 28-Mar-2016 Lorenzo Colitti <lorenzo@google.com> Add a toString method to ApfCapabilities.

Change-Id: I505b90b7cd818cb3477990ec6b41b16db46d1c08
/frameworks/base/services/net/java/android/net/apf/ApfCapabilities.java
f21b4dc1d6e9cc3fc164828e9eba33445c0801d0 18-Mar-2016 Paul Jensen <pauljensen@google.com> Move ApfFilter from ConnectivityService to IpManager

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
/frameworks/base/services/net/java/android/net/apf/ApfCapabilities.java