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
ICaptivePortal is used in the framework and cannot be used as a
dependency in NetworkMonitor, as the framework class takes precedence
when linking.
Also fix NetworkMonitorTest that was not verifying the right
startCaptivePortalApp call.
Test: atest FrameworksNetTests NetworkStackTests
Bug: 124033493
Change-Id: I8e7bb79e50650ae182a2e4277fb49abf5fb6d910
Merged-In: Ib6a89e54312628662b130fbeec18d11e139f09fa
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
The test did not wait for the WifiNetworkAgent to disconnect, and there
are reports of flakes where it is still connected in
connectKeepaliveNetwork.
Test: atest FrameworksNetTests
Bug: 124319553
Change-Id: I85968806885c8853ec4f4dbea356366c1af0ea1c
In aosp/861571, it tried to refine the design to prevent the
lingering notification is cleared unexpectedly. However, all
notifications should be cleared when network is disconnected.
Refine the design by clearing all lingering notifications when
network is disconnected.
Bug: 123488640
Bug: 123537643
Test: 1.Build pass
2.atest FrameworksNetTests
3.Connect to a hotspot which doesn't have internet,
after getting "NO_INTERNET" notification, disconnect
the wifi and check if "NO_INTERNET" notification will
be cleared or not.
Change-Id: Iac45ec186cf81915c318dba37f43136609d579f6
This change adds new network types for testing purposes, signifying a
network with an extremely limited feature set.
Bug: 72950854
Test: Compiles, CTS tests relying on this work correctly.
Change-Id: I06cade6044afd12e0b69ed3c2f160f27f85d43d0
Have the network stack pass its package name in
showProvisioningNotification instead.
Bug: 124033493
Test: flashed, WiFi and captive portal works
Test: atest FrameworksNetTests NetworkStackTests
Change-Id: I1f3312768ba1fb34e99a827e1fcdaf7510e318a8
The new set of API allows applications to request keepalives
offload for established TCP sockets over wifi.
However, the application must not write to or read from the
socket after calling this method, until specific callbacks are
called.
Bug: 114151147
Test: atest FrameworksNetTests FrameworksWifiTests NetworkStackTests
Change-Id: I3880505dbc35fefa34ef6c79555458ecf5d296a4
Treat NetworkStack.PERMISSION_MAINLINE_NETWORK_STACK as equivalent to
NETWORK_STACK, CONNECTIVITY_INTERNAL and NETWORK_SETTINGS combined.
NetworkStack.PERMISSION_MAINLINE_NETWORK_STACK is defined as signature
permission in NetworkStackPermissionStub, which is signed with the
platform certificate, so requirements are the same for both permissions.
The permission is defined by NetworkStackPermissionStub and only used by
NetworkStack, which must be signed with the same key as the stub.
Test: flashed, booted, WiFi works, also with changes on top removing
CONNECTIVITY_INTERNAL and NETWORK_SETTINGS
Bug: 112869080
Change-Id: I9d0ea8fc99eadf7e902421efdba9b8bf535658b8
Endpoints protected with INTERACT_ACROSS_USERS_FULL, such as
startActivityAsUser, should only be used by modules signed with the
platform cert. The NetworkStack needs to have the system server start
the application so this restriction can be applied.
Bug: 123846255
Test: flashed, captive portal works from primary and secondary user
Change-Id: Ib3e427b3fd03ced80c02985e795f79b096a2ec9a
There are other, more idiomatic ways to do this. Deprecating this
with usage limited to P will curb usage and reduce the maintenance
load.
This also deprecates the extra EXTRA_NETWORK_TYPE, which has
survived from an old world but has only been used in deprecated
broadcasts for some time.
Bug: 109783091
Test: eyeball current.txt
Change-Id: I87b74833bb4ec362ee3fd07511a66d318c29067d
When offload is starting, socket will be switched to repair
mode. Read and write on the socket will not be allowed until
repair mode is turned off. If remote packet arrives, repair
mode will be turned off automatically and a callback will
be raised to indicate that socket is ready to read from.
Bug: 114151147
Test: -atest FrameworksNetTests
-manual
Change-Id: I0c335865912e183e7ad32a8ea12188f02ccde5fd
In previous change, the new SocketKeepalive API was exported.
But internally, old PacketKeepalive names and structures are
still used.
This change rename them properly for code consistency and also
refactor KeepalivePacketData to support different types of
KeepalivePacketData.
Bug: 114151147
Test: 1. atest FrameworksNetTests
2. atest FrameworksWifiTests
3. atest FrameworksTelephonyTests
Change-Id: Ia9917d12987e91e87e34ffb3f126e7bc7c9c187e
Merged-In: Ia9917d12987e91e87e34ffb3f126e7bc7c9c187e
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
Currently it is not possible to change private DNS bypass by
doing:
setProcessDefaultNetwork(network.getPrivateDnsBypassingCopy());
setProcessDefaultNetwork(network);
because the code will ignore the change. Fix this by ensuring
that we always call bindProcessToNetwork (which does not have
side effects) and then only performing the expensive operations
(flushing DNS cache, upating socket pools) if the netId changed.
Bug: 112869080
Test: None
Change-Id: I5e8999cb11d8b8c1e9eb583fa8b3932f212accff
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
