Bug: 122652441
Test: atest com.android.server.connectivity.VpnTest
Test: Establish a IPv4 VPN with minimal routes and check
(dumpsys connectivity) the VPN network does not have INTERNET
capability.
Change-Id: Ic7f19ebb7b7f78a6ffb2a8ec3fc3eca5e5421f57
NetworkStack is only used in services.net or clients of services.net. It
cannot stay in framework.jar because it needs to depend on AIDL
interfaces, which would conflict with app implementations if they were
in framework.jar.
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: Ib1d08a3669983640119d008db7e2990fa798724f
Merged-In: I501b125a388c1100c2182bde4670944c2f0d7a02
Previously, they were only updated when underlying network set was
non-null.
This change also ensures that all the calls b/w ConnectivityService and
Vpn that leads to updating capabilities are on ConnectivityService
handler thread.
Additionally, it also ensures that capabilities are propagated after VPN
enters connected state. This was previously done from establish which
could potentially lead to race between VPN getting connected and
capabilities getting updated.
This change also updates VPN capabilities inline from
ConnectivityService handler thread. Previously, there was an additional
loop where Vpn would update capabilities via NetworkAgent thru
AsyncChannel which posts back to CS handler thread, which could
potentially lead to delays in updating VPN capabilities.
Bug: 119129310
Bug: 118856062
Bug: 124268198
Test: atest FrameworksNetTests
Test: manual - verified VPNs capabilities are getting updated and
DownloadManager is working correctly.
Change-Id: Id0abc4d304bb096e92479a118168690ccce634ed
NetworkStack is only used in services.net or clients of services.net. It
cannot stay in framework.jar because it needs to depend on AIDL
interfaces, which would conflict with app implementations if they were
in framework.jar.
(cherry-pick of aosp/905233 with trivial conflicts in SystemServer.java)
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: I501b125a388c1100c2182bde4670944c2f0d7a02
The callback would be used to notify entitlement value. If the
cache value indicates entitlement succeeded, it just fire
callback with cache value instead of run entitlement check.
Bug: 120887283
Test: atest FrameworksNetTests
Change-Id: I8afe928423bd75c54c61533a50a5c0814922ceb1
For VPN apps targeting Q and above, they will by default be treated as
metered unless they override this setting before establishing VPN.
Bug: 120145746
Test: atest FrameworksNetTests
Test: On device tests verifying meteredness setup correctly for apps
targeting Q and apps targeting P.
Change-Id: Ia6d1f7ef244bc04ae2e28faa59625302b5994875
This is a cherry-pick of ag/607226 that has been rebased on
top of four years of changes and with comments addressed.
Gives each factory a serial number and propogates it to every
NetworkAgent so when a score comes back indicating a request is
being handled the factory can account for it properly.
Without this, a new request that's already handled by a network
offered by a factory will not cause an increment of the factorys
ref count. Concretely this results in issues like the RAT icon
not being displayed in spite of the network actually being up
and usable.
This will be ported to AOSP as soon as possible, but immediately
some master-only WiFi tests need to be adjusted with this change
which would not let me submit to AOSP.
Bug: 18637384
Bug: 29030667
Test: manual
Test: atest frameworks/opt/telephony/tests/telephonytests
Test: atest frameworks-net
Test: atest CtsNetTestCases CtsHostsideNetworkTests
Change-Id: I597ac588f76dd507512ff02868fd1310b7e63f7e
Captive portal app will be auto dismissed after user login the
captive portal network. In order to improve the user experience,
popup a notification to notify user that the captive portal
network is connected.
Bug: 113629026
Test: 1.atest FrameworksNetTests:NetworkNotificationManagerTest
2.Connect to a captive portal network and login, check if
there is a notification popup.
Change-Id: Id54d12268e107af2f213c2bb348c5f7908e880f4
Make Nat464Xlat talk to netd directly instead of through
NetworkManagementService. The methods in NetworkmanagementService
don't really provide any value: since the only thing they do is
call into netd, we might as well have the callers talk to netd
directly,
In order to do this, pass INetworkManagementService and INetd to
the NetworkAgentInfo constructor, and update callers appropriately.
Bug: 65674744
Test: builds, boots
Test: atest FrameworksNetTests
Change-Id: Iac4cfe709c6279e4d9682b6754963e533707bd12
The current code only uses InterfaceParams#name, and InterfaceParams is
defined in services/net which DhcpServer cannot depend on once moved to
a separate app.
Test: atest FrameworksNetTests
Bug: b/112869080
Change-Id: I94c7dce33200c111666a9dddde82ac2e66a6794f
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
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
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
Run most tests with TETHER_ENABLE_LEGACY_DHCP_SERVER set to 0 (will be
the default value). Add one test to verify that the new server is not
started when TETHER_ENABLE_LEGACY_DHCP_SERVER is 1.
Bug: b/109584964
Test: atest FrameworksNetTests
Change-Id: I288ba1f434918e62ff29f7ace00856108c9730f7
Rename TetherInterfaceStateMachine to IpServer. IControlsTethering
is folded into IpServer.Callback and some of the dependencies in
TetheringDependencies are moved into IpServer.Dependencies.
Several things still need fixing, including:
- convert message passing into method calls
- the calls that enable forwarding should be moved up out of
IpServer into the Tethering layer above it
Test: as follows
- built, flashed, booted
- runtest frameworks-net passes
Change-Id: I015f800ed23c8aa5c8c81a74d7b508abfcaab659
Not all preinstalled apps should have access to background
networks or restricted networks. But we give them all network
access permissions currently, it's not a good design. So we
shall limit preinstalled apps permissions, they should just
request the appropriate permission for their use case from
the network permissions.
Bug:19610688
Test: runtest frameworks-net
Change-Id: I184ae3197208c979847ca134c8f01b32528badf1
The newer implementation is disabled by default with this CL. Ultimately
the intention is to enable it by default.
Bug: b/109584964
Test: set tether_enable_legacy_dhcp_server to 0, ran DhcpServerTest.py,
observed new behavior. Added tests in CL also pass.
Change-Id: I0f830b9804b8956c127057e66ab75a21ca29dc57
