Currently, if VPN lockdown is disabled, the blocking judgement
inside VPN will return false immediately. It will make
ConnectivityService hard to check blocked status by a given
VPN lockdown status.
Thus, move this check into ConnectivityService and check it
externally.
Bug: 117814902
Test: 1. manual test with 3rd-party vpn app
2. runtest frameworks-net
Change-Id: Ia8319b1a1a12f1058c24badf2431f2ec69bc78e7
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 15cfeb58a4)
Make log of ConnectivityService configurable by system property.
Two levels:
VERBOSE: whole VDBG log.
DEBUG: selected necessary log for debug purpose.
Relevant log can be enbled in either way:
1. use adb command at run time.
2. config init.xx.rc file at compile time by adding.
on boot && property:ro.build.type=userdebug
setprop log.tag.ConnectivityService DEBUG
Bug: 117632924
Change-Id: I43cc84878c64c5b448853c7393393a02262afd15
onBlockedStatusChanged is intruduced for network blocked status.
The changes in this patch are:
- Test onBlockedStatusChanged which tells apps whether the
network is blocked.
- Fixed the tests which is affected by the order changed in
onAvailable.
Test: as follows
- runtest frameworks-net
- runtest -x NetworkPolicyManagerServiceTest.java
Bug: 74575553
Change-Id: I383c037ed895ef69c478dc3cff69fb1e27c42845
sendProxyBroadcast is always called with the same argument, and
it would make no sense with another argument anyway. Remove it.
This concludes the ProxyTracker refactoring with 227 lines removed
from ConnectivityService, a lot clarified, and some bugs removed.
Things can still be improved, but presumably at a much higher cost.
Next steps are : write tests, now that ProxyTracker is both testable
and mockable. And try to pour some gasoline on the PROXY_CHANGE_ACTION
broadcast, see if it burns well.
Test: runtest
Change-Id: I66e40b4bf5cfd0b2dc4fa37ea97b3429fe1b7e6c
This bug has existed for a long time. If mDefaultProxyEnabled is
false, then the mDefaultProxy member should obviously not be used
in the broadcast.
Test: runtest
Change-Id: I599a2ff9f96d4667e824cf000c2125f86010bb02
If mGlobalProxy is non-null, then getDefaultProxy returns mGlobalProxy
so the first change is a no-op.
If mGlobalProxy is null and mDefaultProxyEnabled is true, then
getDefaultProxy returns mDefaultProxy, which has just been set to
proxyInfo, so the second change is a no-op.
If mGlobalProxy is null and mDefaultProxyEnabled is true, then
getDefaultProxy returns mDefaultProxy ; if mGlobalProxy is null and
mDefaultProxyEnabled is false, then getDefaultProxy returns null,
therefore the third change is a no-op.
Test: runtest
Change-Id: I7c21062302bf54f4fc917c82e0175975051a55ec
