This patches changes how captive portal tests and network lifecycle
events are logged as connectivity events:
- it splits NetworkMonitorEvent into two event classes:
- ValidationProbeEvent for logging individual probe events.
- NetworkEvent for logging network connection, validation,
lingering, and disconnection.
- it removes the redundant CaptivePortalCheckResultEvent class.
The information logged in CaptivePortalCheckResultEvent was already
logged by NetworkMonitorEvent, but missing the evaluation durations.
It is now logged by ValidationProbeEvent.
- it removes the CaptivePortalStateChangeEvent class, which is now
redundant with NetworkEvent, but missing evaluation durations.
In addition, it adds event logging when ConnectivityService puts a
network into lingering or removes a network from lingering.
Bug: 28204408
Change-Id: I8f9752e4d36175ecfcbd1545a01a41bad6e06ea4
am: 6f61176bb3
* commit '6f61176bb3b7dd60edb03042d9e5cc93332a24f6':
Cap number of NetworkRequests a UID can make to 100
Change-Id: I72fe474d3618c2900e972cefdc85e80767610405
am: 4088540675
* commit '40885406754e50c5e6f0b9ca2175f1b46062d692':
Cap number of NetworkRequests a UID can make to 100
Change-Id: Ic664fa080316eff75dd22fc8e84431cb0eb903be
When users add or remove an app to the Data Saver Mode whitelist, the
app is notified through a
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED. But besides this
broadcast, it's also necessary to notify internal apps such Settings,
hence a new method is being added to INetworkPolicyListener.
BUG: 27481520
Change-Id: I1537a77becf6b7da1535ed5faabdc894fd9f7084
am: 0928b62
* commit '0928b620d2f0b78d49b13059eba475da4801ad70':
When the applicantion is removed, reset network permission of this uid.
Change-Id: I3750e3f805bfc71558025fe078f1ad25e5af7cff
am: 886d17c
* commit '886d17c035805cef3bce3d2d96e53ba48bf5b62b':
Also log IPv4 and IPv6 connectivity of any previous default network
Change-Id: I8c82f1058531d1f5a0cdb73314b8fd742dae7860
am: f8ef3c3
* commit 'f8ef3c36a97b68b5e27127681973244f481cca09':
Log an event whenever we lose the default network.
Record the transport types for connectivity events.
Change-Id: If019f2c448ed3411a0b23dfdd6038e1b9fe2099d
am: 2c1f03a
* commit '2c1f03ade023a61428b7d9101bc10e4c88ae941a':
If Internet probe is redirected, pass redirect destination to NetworkAgent.
Change-Id: I4c5f5cb8591d8729de9036a6c2aabacd4aba0f39
Transport may use the redirect to make additional determination about network
state.
Bug: 25203607
Change-Id: I07d8918f13fdcbe0b6fd757536bfc1850a2a244f
am: 6754d23
* commit '6754d237bb8c6e1fba779f90417b4a2fe07d2b3e':
Excluded certain APNs (e.g. IMS) from mobile data usage.
Change-Id: I0f37f4d296de88763019f469a0356e753b9f3636
Added not_metered capability to a mobile network if none
of its associated APN types are metered. Also used not_metered
capability to determine if a network should be accounted for
data usage or not instead of using network type, which is
always MOBILE after refactoring. Will add VT usage support
in next phase.
bug: 20888836
Change-Id: Id692cb856be9a47d0e918371112630128965b1bb
am: a948f88
* commit 'a948f8872aa045ab22f42285f195fdb413c5ff66':
Internal API for system apps to determine default network for other apps
Change-Id: Ib719f0cebb41afe4aa52241f3797598a7e468d2d
Callers with CONNECTIVITY_INTERNAL permission can read off the netId
that an application is assigned to by default.
Necessary for making connections as the default network for a client
app eg. when downloading stuff on its behalf.
Bug: 27074270
Change-Id: I8d35e8e99126875f55f3c545090326f3e9be43fb
Since Lollipop, routes are isolated within Networks. Flushing a
Network's DNS cache whenever that same Network's routes are updated
doesn't provide any benefit. Any system components depending on this
behaviour need to uncovered and fixed.
Additionally, clean up no-longer-used flushNetworkDnsCache(). This
should be replaced, when needed, by a proper binder interface to netd.
Change-Id: I34bf79e4839da014d466058a876d754209d0c007
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
