Start tracking default upstream from boot.This is useful for
entitlement refine in following change. EntitlementManager can
decide if it needs to process entitlement provisioning before
tethering started.
Test: -atest FrameworksNetTests
-build, flash, booted
-manually turnoff/on tethering with different upstream
bug: 111490073
Change-Id: I8fdbd64c52f26b5363693bb5bd8050930e8ea961
Currently, PermissionMonitor listen to user add/remove and
package add/remove intent respectively, and so does VPN.
Thus, races might occurr between them.
This commit refactor VPN part by using ConnectivityService to
listen to intents and dispatch events to VPN.
Bug: 118811303
Test: 1. atest FrameworksNetTests
2. manually add/remove package
3. cts-tradefed run cts -m CtsHostsideNetworkTests
Change-Id: Id76fd77c5fcfb2b0e21f211f63f007b1ea1aa53f
Netd use this parameter to determine which network it should use for
DNS query when VPN is enabled. But it is no more reliable when we have
seamless vpn handover, since the parameter does not make update to
netd if we have DNS configuration change. Netd should call resolver
API to get latest DNS information rather than this one.
Bug: 116539103
Test: runtest frameworks-net passes
Change-Id: I6491114ab6de0ff66322f1da69056e6f3c999b5a
updateTcpBufferSizes() only need tcp buffer size as its
parameter. Also unify the logic to check default network
outside the function.
Bug: 120119769
Test: 1. Build pass.
2. runtest frameworks-net
Change-Id: Iee9fec3efe7d5be5b590dd1c1f67ec5de636e613
In previous design, it will always assign newLp to nai in
handleUpdateLinkProperties(). And Private dns configuration
will be missing when the same LinkProperties are updated
because the updated LinkProperties is not assigned back to
NetworkAgentInfo.
Bug: 118518971
Test: 1.Build pass.
2.runtest frameworks-net
Change-Id: I405c8f29497fec438082a2cf30eb5c7b9497e1c4
The system server is controlling the tcp buffer now by writing to
/sys/kernel/ipv4/tcp_{rmem,wmem}_{min,def,max}. Those files are
basically the same as /proc/sys/net/ipv4/tcp_{rmem,wmem} except those
latter ones contain all three values in one file. Netd can directly write
to those files so we no longer need to depend on these android specific
files.
Test: netd_integration_test
Bug: 118572798
Change-Id: I588b48be29ecf61fd5bbf94f97f63738be4eae25
If dns resolver on a network get consecutively timeout then it
is a strong signal that the network is no longer usable.
Reevaluate the network once it's data stall suspected
Test: 1. runtest frameworks-net
2. SettingsBackupTest passes
2. Run on wifi w/o internet capability
Bug: 112653893, 113916551
Change-Id: I74287b174d933f97a91fa1529b1809856ac3b38d
Currently, PermissionMonitor listen to user add/remove and
package add/remove intent respectively, and so does VPN.
Thus, races might occurr between them.
This commit refactor PermissionMonitor part by using
ConnectivityService to listen to intents and dispatch events
to PermissionMonitor.
Bug: 118811303
Test: 1. atest FrameworksNetTests
2. manually add/remove package
Change-Id: I6e45b5870d5b1300cad252d25bdb4da78f9bf70e
The previous patch was applied to the wrong member and did not actually
fix the issue.
Bug: b/117516272
Test: remote run passed
Change-Id: I3f9c27ebd6c339e98a71cb179b0be65950f9b864
If time since boot is lower than the rate limit, notifications would not
be shown.
This is causing tests to fail on continuous testing.
Test: atest FrameworksNetTests
Bug: b/117516272
Change-Id: I03da28f2ca61119fa0ef9534bb4ce3f6406c1ff2
Some native daemons legacy design work with SYSTEM_UID. If none of
SYSTEM_UID apps declare the restricted network permission, it will
result in permission denial in daemons. Allow SYSTEM_UID in the
devices shipped before Q to support backward compatibility.
Bug:114245686
Test: 1. runtest frameworks-net
2. atest FrameworksNetTests
3. Native daemons with SYSTEM_UID can work normally
Change-Id: I6f3f0d83bcae74ef5389535b528af3baf649fa48
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
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
Require NETWORK_SETTINGS (or NETWORK_SETUP_WIZARD) instead of the
legacy CONNECTIVITY_INTERNAL permission. The users are as follows:
- The system callers (Phone, Settings, SystemUI, VrSettings) all
have NETWORK_SETTINGS.
- SetupWizard has NETWORK_SETUP_WIZARD
- sl4a has NETWORK_STACK
Bug: 115302596
Test: builds, boots, airplane mode via SystemUI works
Change-Id: I8ca40182bd8b5e3fd9a82296c0cc28de30ed4baf
To add skip464exlat in NetworkMisc.
NetworkAgent can skip to start 464xlat if need.
(e.g. IMS PDN for Cellular can be disabled)
Device will treat the network as IPv6-only if it is set
Bug: 69949375
Test: Nat464XlatTest, ConnectivityServiceTest
Change-Id: I676a02cb92530d64f29f34e89482a934f3ec4553
Currently, apps rely on querying NetworkInfo object to know
whether their network is blocked or not. There is no proactive
way to tell app when it is being blocked/unblocked. The only
event that app would receive is SocketException with
ECONNABORTED when their ongoing socket connection has been
blocked, which is not an elegant way to notify app.
Thus, this commit is trying to address this problem. Therefore,
with the uses of other callbacks, the need of
getState/getDetailedState in NetworkInfo could be completely
eliminated.
Test: runtest frameworks-net
runtest -x NetworkPolicyManagerServiceTest.java
cts-tradefed run cts -m CtsHostsideNetworkTests
cts-tradefed run cts -m CtsNetTestCases -t \
android.net.cts.ConnectivityManagerTest
Bug: 74575553
Change-Id: Iec96a3103d0aa9a505020eb89d69b89c0b694486
This contains a significant logic change : it will load the
deprecated proxy settings synchronously instead of on the next
run loop. I think this is okay because it would happen almost
immediately anyway, and there is nothing in ConnectivityService
that might be changing this setting in the mean time. As for
the possibility that this was executed in the handler because
of possible disk access, I want to point out that the
loadGlobalProxy method that now calls this was already doing
those same similar accesses.
Test: runtest
Change-Id: Idc6f260e2a337689dc274eb758eb00f6a31089bb
This will improve the user experience on Android TV devices,
see bug for details.
In addition when connecting adb to the device by ethernet
for cts, wifi will not connect, causing lots of tests to fail.
For example:
[CTS7.1]android.net.wifi.cts.WifiInfoTest#testWifiInfoProperties
[CTS7.1]android.net.cts.ConnectivityManagerTest#testConnectivityChanged_
manifestRequestOnlyPreN_shouldReceiveIntent
Use command:settings to put global wifi_data_always_on 1 to enable it.
Bug: 26102779
Test: Manual, CTS.
Change-Id: I711d93061a6bc7164d98a858912f781e1b967406
By construction, this WTF should never happen, since it's in an
if (nri.request.isRequest()) and by definition requests can only
be satisfied by one network at a time.
I don't think we've ever seen this particular WTF in an APR
report, which suggests that it's not happening in practice.
Test: atest FrameworksNetTests CtsNetTestCasesLegacyApi22 CtsNetTestCasesLegacyPermission22 android.net.cts.ConnectivityManagerTest
Change-Id: Icf4c7d2bb1da3c7db695cf0bcebc5806190a1677
This is the first step for ConnectivityService
call into INetd directly.
Import INetd and get it by using NetdService.
Test: runtest frameworks-net passes
Test: manual testing of wakeupAdd/DelInterface works
Change-Id: I643dba5206c66958134152d062f3f3a19a34cf2c
