For implementing parcelable interface for NattKeepalivePacketData.
Move this class out of framework.jar and move to services.jar
This class is used in telephony-common.jar and it also loads
service.jar.
Bug: 33530442
Test: - build pass
- atest NetworkStackTests
- atest ConnectivityServiceTest
Change-Id: Id2fdec5c4015d2cefd8a93e0cfdcc3c304fc9b64
ApfFilter maintains separate counters for each reason why a packet was
passed or dropped by the filter logic.
There's also a total which should match the individual counters,
*unless* the APF interpreter aborted execution early due to an illegal
instruction or an out-of-bounds access.
Test: both on APFv2 and APFv4-capable device:
runtest -x tests/net/java/android/net/ip/IpClientTest.java
runtest -x tests/net/java/android/net/apf/ApfTest.java
manual tests connected to an AP
Bug: 73804303
Change-Id: I54b17fcbb95dfaea5db975d282314ce73d79d6ec
This allows an application that knows how to provide seamless
network connectivity (e.g., using QUIC multipath) to find out if
doing so is desired.
(cherry picked from commit 48a2a32bdd)
Test: builds, boots, runtest frameworks-net passes.
Bug: 34630278
Change-Id: Ic7fd0b9e1cd879fdfaf84009d7125391895e9087
Rename the class and ensure that all code related to bad wifi
avoidance has names that reflect its purpose. This will allow us
to reuse most of the the code for other purposes in future CLs.
Test: runtest frameworks-net passes
Bug: 34630278
Change-Id: Ida190e5a79e7a12f4eec07e1a3e4d9d138e83bcd
During IpManager startup, anything sending messages to the state machine
must not begin doing so until after the state machine has been started.
Reorder the constructor accordingly.
During shutdown, AvoidBadWifiTracker needs to unregister the registered
BroadcastReceiver and might as well also unregister the ContentObserver.
Test: backport from internal
Bug: 33388922
Change-Id: I58e07f7ccddaab160c153bcfb69fd45f50bb8710
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
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
