This patch adds in IpReachabilityMonitor a timestamp variable set
everytime that probeAll() send NUD probe requests to RTNETLINK.
This allows to distinguish between:
1) NUD_FAILED events resulting from such a forced NUD probe
2) "organic" NUD_FAILED notifications from the kernel
This distinction is added to IpReachabilityEvent as a one-bit flag.
This patch also changes the formatting of ApfProgramEvent flags to use
'|' as a joining character, similarly to other flags formatting.
Bug: 21859053
Change-Id: I24c64a3f17fa283eace5bd0a05c21a90a2305359
This patch partially undoes ag/869831 (Change-Id:
Ia42ed7aefaebd8caf3eada8e42b6cb7a940d7647) so that ConnectivityManager
does not remove callbacks from its internal request-to-callback map at
unregistration, but instead let the singleton CallbackHandler do it when
receiving a CALLBACK_RELEASED from ConnectivityService.
ag/869831 was thought to fix b/26749700 that reported a callback leak
from sNetworkCallback, but a finer analysis of the code shows that
callbacks were correctly removed by the CallbackHandler before
ag/869831. There was therefore no callback leak.
Bug: 26749700
Bug: 28537383
Change-Id: I421d889d0e225c0e3d1eebea664f44a1cc0f3191
The older Time class is deprecated and doesn't handle edge cases
very well. So migrate the cycle calculation logic to use the
long-standing and well-supported Calendar API.
Bug: 28689087
Change-Id: Ic1802b3f8556402f99bfea4cd625c35dfed81ac0
This patch adds lifetime durations of DhcpClient states to
DhcpClientEvents.
To record the duration of a state, the event is now recorded when the
DhcpClient state machine exits that state.
In addition this patch removes event logging of StoppedState,
DhcpState and DhcpHaveLeaseState.
Change-Id: Ibd37b5e3070f35113b6b45942b1e1ff19c27a90b
This patch
- adds a Builder class for RaEvent.
- uses this Builder class for correctly recording the minimum
lifetime seen for every ICMP6 options tracked, instead of
recording the last lifetime seen.
- adds unit test coverage for RaEvent logging.
Change-Id: I6443932f5cf7a613a5c695c65a60eab01e60602a
http://ag/1194313 broke unregisterNetworkCallback because the
system does not parcel the type of the request back to the app.
So when the app calls unregisterNetworkCallback, the
NetworkRequest that's passed in does not have a type and thus
doesn't match the request in mNetworkRequests.
Fix this by parceling over the type as well.
This was not caught by the unit test because the unit test all
runs in the same process with no parceling.
Bug: 23113288
Change-Id: I58b2ed651b9bf5cbdcca5b25c3ca24db53cffdf1
This will allow us to simplify code that deals with
NetworkRequests outside ConnectivityService.
Bug: 23113288
Change-Id: I9b3a859d0c68cad73d7f6baa4b584d13ffd2ae36
This patch defines a new android.net.metrics.RaEvent class carrying
lifetime values contained in RA packets. RaEvent are recorded when
ApfFilter processes a new RA for which there is no match.
Example:
ConnectivityMetricsEvent(15:39:39.808, 0, 0): RaEvent(lifetimes: router=3600s, prefix_valid=2592000s, prefix_preferred=604800s, route_info=-1s, dnssl=-1s, rdnss=3600s)
Change-Id: Ia28652e03ed442d5f2a686ef5b3fafbcb77c503a
This patch adds a new ApfStats event class that counts RA packet
reception statistics on the RA listener thread of ApfFilter and reports
the maximum program size advertised by hardware.
Statistics are gathered for the lifetime of a network with APF
capabilities and uploaded at network teardown when the listener thread
exits.
Example event:
ConnectivityMetricsEvent(15:44:23.741, 0, 0): ApfStats(284945ms 2048B RA: 2 received, 0 matching, 0 ignored, 0 expired, 0 parse errors, 2 program updates)
Bug: 28204408
Change-Id: Id2eaafdca97f61152a4b66d06061c971bc0aba4c
This patch removes static methods for logging IP connectivity events
defined in android.net.metrics and replaces them with a single log()
instance method defined on IpConnectivityLog. Event constructors are
now public also. Every classes logging such events now create an
instance of IpConnectivityLog for logging event objects directly
instantiated with new.
Removing static dependencies allow straightforward testing of logging.
This patch also removes the base IpConnectivityEvent class which is not
needed any more.
Bug: 29035129
Change-Id: I3de700f93f46deaa48a759f938f7d00e1d8bff98
IpConnectivityEvent was using ConnectivityMetricsLogger directly for
logging events. However ConnectivityMetricsLogger keeps track in a
thread-unsafe way of skipped events rejected by MetricsLoggerService.
This patch introduces a subclass of ConnectivityMetricsLogger that
does not track skipped events, for using in IpConnectivityEvent.
It also qualifies the mServiceBlockedTimestampMillis variable as
volatile so that throttling is effective accross concurrent callers
of logEvent.
Bug: 28204408
Bug: 29023888
Change-Id: I33707ba1d07487b42f3ce9a1ad9a66d785e99fa7
- add a new field: provisioningNotificationEnabled from NetworkMisc. set
to false if we want to hide "sign in" notification and placed
carrier-specific notification instead. it is set on connect, once set,
it is carrier-app's responsibility to post new UI to users
- rework on the interaction between carrier app and framework
- code cleanup
- unit test support
Bug: 28567303
Change-Id: Ic84db7ffbb920d15344717f104496d3cb82e1a85
When disconnecting from a default network X and falling back on another
connected network Y as the new default, ConnectivityService was
attempting to record this event as a X -> Y "atomic" transition.
In practice the default network connectivity is actually lost and
recovering default network takes some non-zero time.
This patch changes the event recording to always record disconnection as
X -> 0 events. At the same time, if there is a fallback network that is
elected as the new default ConnectivityService will also record a 0 -> Y
event.
This patch also improves pretty-printing of DefaultNetworkEvent.
Extract from $ adb shell dumpsys connectivity_metrics_logger --events
17:51:00.086: DefaultNetworkEvent(0 -> 100:CELLULAR)
17:51:25.232: DefaultNetworkEvent(100:IPv4 -> 101:WIFI) # wifi goes on
17:51:44.064: DefaultNetworkEvent(101:DUAL -> 0) # wifi goes off
17:51:44.187: DefaultNetworkEvent(0 -> 100:CELLULAR)
Bug: 28204408
Change-Id: I63252633235bf6ba833b9ac431a80dda75a93e67
When an UID is added / removed to the Data Saver blacklist, it's
necessary to notify internal components such as the Settings UI (which
was erroneously listening to UID rules changes instead).
BUG: 28743623
BUG: 28791717
Change-Id: I11c85e141dfe074ad390fd324309d2412bfbbd45
By changing some member refs into arguments and having one of the
functions create the UID range instead of adding to mVpnUsers.
This will be useful for other layers of UID filtering like having
UIDs explicitly blocked from the VPN.
Deleted one broken line of code that cleared the status intent when
a restricted profile is removed. Other than that, this commit shouldn't
change any behaviour. If it does, that's a bug.
Bug: 26694104
Change-Id: Ieb656835d3282a8ba63cc3f12a80bfae166bcf44
NetworkPolicyManagerService (NPMS) manages 4 type of network restriction
when apps are running on background:
- Data Saver Mode (data usage restriction on metered-networks)
- Battery Saver Mode (power restriction on all networks)
- Doze Mode (power restriction on all networks)
- App Idle (power restriction on all networks)
These restrictions affects 2 parts of the system:
- Internal framework state on NPMS which is propagated to other internal
classes.
- External firewall rules (managed by netd).
Although each of the power-related restrictions have their own external firewall
rules, internally apps are whitelisted to them through the same
whitelist, and the current code is only updating the internal state (and
notifying the internal listeners) when Battery Saver Mode is on.
As a consequence of this problem, there are scenarios where an app
correctly does not have internet access (because the firewall rules are
properly set), but the NetworkInfo state returns the wrong state (like
CONNECTED / CONNECTED).
This CL fixes this problem by splitting the power-related logic from
updateRulesForRestrictBackgroundLocked() into its own
method (updateRulesForPowerRestrictionsLocked()), and making sure such
method is called whenever the firewall rules are updated.
Externally to this change, the CTS tests were also improved to verify
the apps get the proper connection state; it can be verified by running:
cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests \
-t com.android.cts.net.HostsideRestrictBackgroundNetworkTests
BUG: 28521946
Change-Id: Id5187eb7a59c549ef30e2b17627ae2d734afa789
Callbacks
- DataUsageCallback renamed to UsageCallback
- DataUsagePolicy removed; passing in params directly to register method
- making it an abstract class
- passing in (networkType, subscriberId) that reached its threshold
- renaming onLimitReached to onThresholdReached to match existing naming
- only monitor single network,subscriberId
- no monitoring of specific uids; using device or user wide instead
Tags
- only owner uid can read its tags
- exposing only TAG_NONE to match service side
BUG: 27530098
Change-Id: I2b2664da71806868a1e937d2bf4d1f234637509b
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
Another scenario that is not properly handled is when a UID whitelisted
for Data Saver is brought back to foreground: although the proper
firewall rules are set, CS is not notified, and the apps state would be
DISCONNECTED / BLOCKED.
This CL introduces many changes that fix this issue:
- Fixed updateRuleForRestrictBackgroundLocked() to invoke
onUidRulesChanged() when the Battery Saver status changed.
- Fixed updateRuleForRestrictBackgroundLocked() to invoke
onUidRulesChanged() when an app whitelisted for Data Saver is brought
back to the foreground.
- Added a new API (onRestrictPowerChanged() and getRestrictPower())
to notify external services about Battery Saver mode changes.
- Fixed CS logic to properly handle the Battery Saver changes.
Externally to this change, the CTS tests were also improved to verify
the apps get the proper connection state; they can be verified running:
cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests \
-t com.android.cts.net.HostsideRestrictBackgroundNetworkTests
BUG: 28521946
Change-Id: I8eaccd39968eb4b8c6b34f462fbc541e5daf55f1
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
This change refactores the mUidRules to use bitmasks, in preparation for
another change that will fix the issue.
It also fixes a minor bug that was preventing removed packages to be
removed from the whitelist.
BUG: 28521946
Change-Id: I9f0e1509a6192cad403f740c1cd76a6b7dab7d26
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ibfbd43ad09a25f2e38053fcd6306df3711f8bde2
When a job will eventually run in the foreground, the internal
scheduling needs to ignore any background network restrictions when
satisfying constraints. This also means the job should ignore the
current device doze state, since the requesting app could get the
same behavior by starting their own foreground service.
Always dispatch network policy changes to ConnectivityService first
to ensure that it has up-to-date information. Fix bugs around data
saver that were causing networks to not be marked as BLOCKED for
background apps; before this fix apps would have been spinning in
internal connectivity loops, thinking that the network was actually
connected when the kernel was actually blocking their traffic.
Offer new ConnectivityService method overloads to ignore the blocked
state for a specific UID.
Print unsatisfied job constraints to aid debugging.
Bug: 26571724
Change-Id: Iaaa17933e6dc1bf6d3dff26d0bfc12222e51e241
The URL path could contain credentials that apps don't want exposed
to a potentially malicious PAC script.
Bug: 27593919
Change-Id: I4bb0362fc91f70ad47c4c7453d77d6f9a1e8eeed
