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
Ensure every public method is annotated with why it's public.
This can be either an @Override or @VisibleForTesting annotation
or a comment explaining why it's public.
Bug: 29927488
Change-Id: I3582aef7997dc0d723718ca5e3dd115647d22979
This allows us to keep track of how many live requests a network
is satisfying without having to count them every time.
Bug: 23113288
Change-Id: Ic4756676491e09071dbf80b7c48da3be028d68eb
This will allow us to simplify code that deals with
NetworkRequests outside ConnectivityService.
Bug: 23113288
Change-Id: I9b3a859d0c68cad73d7f6baa4b584d13ffd2ae36
1. Support multiple callbacks in TestNetworkCallback. This is
necessary to test situations where multiple callbacks are
generated by the same event (e.g., CALLBACK_LOSING on cell
with CALLBACK_AVAILABLE on wifi when wifi connects), which is
necessary to test callback order. So far this has not been
covered because all callback testing was using per-network
callbacks.
2. Add a benchmark test for registering NetworkRequests and for
sending onAvailable and onLosing callbacks.
Bug: 23113288
Change-Id: Ib69373358ad766ab1bd989e864a5a51ef762c73c
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
This patch adds synchronization inside LegacyTypeTracker so that
getNetworkForType() can safely run concurrently with remove().
Without synchronization if remove() removes the last network for a
given type while getNetworkForType() runs for the same type, it is
possible that getNetworkForType tries to access the head of an empty
list, resulting in a runtime exception.
This issue was found by zoran.jovanovic@sonymobile.com who proposed a
fix in AOSP (Change-Id: Ia963662edb9d643790e8d9439e4dbdcac4c2187b).
This patch differs from the fix proposed by the bug reporter and tries
instead to do the minimum amount of locking to make getNetworkForType
safe.
Bug: 29030387
Change-Id: I915aac527fc8828b32bf35fee870add2dfb11d8d
It's with the rest of the logic now and allows checking whether the
lockdown state matches, too, which led to a lot of misunderstandings.
Fix: 29199431
Change-Id: I94a2c38c4837f9c33b5b9c2becb52eeb7e2a2534
All users should be made aware a captive portal is in place and be
given the opportunity to sign into the network. Without this fix
other users are not notified and given a chance to sign-in.
Change-Id: I1bf823d5f6a36f391dca4be5f6a584e8562a72a7
Fixes: 23079964
* changes:
Give WakeupMessage the ability to transport an object as well.
Don't treat the lingerExpired broadcast specially.
Add a test for mobile data always on.
Add a FakeSettingsProvider and use it in ConnectivityServiceTest.
NetworkMonitor no longer uses the broadcast for lingering, it
uses WakeupMessage instead.
Bug: 23113288
Change-Id: Idb0c55fc68cb8f45b3213c7134213904f227852e
This class makes it easier to test code that uses Settings:
1. Real device or emulator settings don't affect the code under
test; all settings always start off empty.
2. It's possible to change settings from the test without
affecting system settings.
3. No changes are needed to the code under test. The changes to
the tests are simple: just add a fake ContentResolver to
whatever mock Context is already used by the test, and make
that ContentResolver use the fake provider.
Bug: 23113288
Change-Id: I5e7e5a87571444ae49ccf551705620675a36cd17
Fix 2 problems of always-on vpn after always-on package is removed
1. Prevent network being locked down (blocking all network traffic)
Otherwise, user has no way to download the vpn app from Play Store,
and never be able to gain control of the network again.
2. Allow user to connect other vpn app.
Implementation
1. Switch off always-on mode if the package gets removed.
2. Restart always-on mode if the package gets replaced/upgraded.
Bug: 29050764
Change-Id: Id3e389ae0b11c6002a5167919292d9634c2014cb
am: 716fa18dcb
* commit '716fa18dcb00d78d98850c3eb0ce3f2963b3ce13':
Include network name in validation logs for dumpsys
Change-Id: Ic5345cb7f309e509c7b9d7cb7b7ec4b95b8f1102
am: 265f4113ee
* commit '265f4113ee42e89f324b087a81044a9f1dab457e':
Fix that fail to setup any vpn after Network Settings reset and always-on vpn is on
Change-Id: I86a8f5c9b2dbd8ea71bdc8fb6268f3d9dc7e329d
- 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
Previously this was included in the log messages from NetworkMonitor
but that has been removed (ag/944107), making it frequently impossible
to know what network the logs apply to as there may be no way to
correlate NetIDs to WiFi SSIDs or Cellular networks if the log has wrapped.
Bug: 26075613
Change-Id: I2e3cd41fffb616ab9f855cb16790360bd3414793
Cause: It revoked the user consent of the vpn app without reseting always-on vpn.
In addition, prepareVpn sets legacy vpn as the current package, the state in
Vpn.class is broken, as it thought the current always-on package is legacy vpn,
(mAlwaysOn is only for app vpn, not for legacy vpn). As a result, prepareVpn rejects
all VpnService.prepare.
Bug: 29031820
Change-Id: Id6bf1d6f38cf134a872811806301b8a602fb5725
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 enforceMeteredApnPolicy() is called when Data Saver mode is on and
the caller's UID is not whitelisted, it should add a
NET_CAPABILITY_NOT_METERED to the capabilities.
Change-Id: Ieed4f4a7634ee023ec58c91859263655e0ba62d4
Fixes: 28608499 (and https://code.google.com/p/android/issues/detail?id=208478)
This stops Settings from telling the user detailed information, and
doesn't really protect anything secret -- privileged apps can already
tell that there's an active VPN by looking at network info.
Change-Id: I9c2a3cab6dff1b62e94a9e0735dccde226fd26a3
Fix: 28624328
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
