Commit Graph

4 Commits

Author SHA1 Message Date
Erik Kline
95ecfee674 Refactor "avoid bad wifi" logic into a utility class
Additionally, add this utility class to IpManager for compatibility
verification.  A follow-on CL will make use of IpManager's local
AvoidBadWifiTracker.

Bug: 31827713
Change-Id: If8c56c3f8076d6a5157ea180e361bbdadc2bc1dd
2016-10-04 15:07:42 +09:00
Paul Jensen
a9ae8bb696 ApfFilter unit test
Bug: 26238573

Change-Id: I5171038228782bd54e91f5bcc663cc529d2c1150
2016-05-10 11:54:42 -04:00
Lorenzo Colitti
bd0c0af47f Add a toString method to ApfCapabilities.
Change-Id: I505b90b7cd818cb3477990ec6b41b16db46d1c08
2016-03-28 17:33:30 +09:00
Paul Jensen
6b7f7a0852 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
2016-03-25 07:46:07 -04:00