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
(cherry picked from commit 389633f8d2)
Change-Id: I915aac527fc8828b32bf35fee870add2dfb11d8d
- Use com.android.okhttp.Dns in place of com.android.okhttp.internal.Network
- Specify TimeUnit.MILLISECONDS for timeouts which 2.7.5 allows and
brings us closer to 3+
Change-Id: I95b5d72a94ebe1389f7c2e8d95903aa1aadd944b
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
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: I157481d338e65d7e89e4f97382f84ab2a3110e20
am: 265f4113ee
* commit '265f4113ee42e89f324b087a81044a9f1dab457e':
Fix that fail to setup any vpn after Network Settings reset and always-on vpn is on
Change-Id: Iba3df72496f067c5e0291449be3bfbd9ce2031ff
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
am: 3e0e975a38
* commit '3e0e975a38688b4d5dbc96830788df00499fc01b':
API council feedback: hide and document.
Change-Id: I180f504fe21f6f90179d359e8808ffff006e4538
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
am: efd3a1749f
* commit 'efd3a1749f2737199643cc29bea6132a9786223b':
Fixed enforceMeteredApnPolicy when Data Saver is on.
Change-Id: I87b596346c058c7ac8efbebb67b43664f1be0fed
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)
am: f9773c5fdd
* commit 'f9773c5fdd952e0628bc4b0e80c55258b49335ad':
Lock down networking when waiting for always-on
Change-Id: I7be0a85597936421750d1da0fde3d55d7d4fabc5
am: 89bf3e3aa2
* commit '89bf3e3aa2b3e95486445a50f4666a20b3d8e830':
Make some of the UID-based VPN code reusable
Change-Id: I3f1b1a08059aa58cb76db6cdd070b103024b9bf3
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
am: bc26d925c6
* commit 'bc26d925c62968c0728a524a45c6e60f2b8fb781':
Fixed connectivity state in some power saving scenarios.
Change-Id: I7ebe3864657d2147034ffae400312e94deb5ef35
