* changes:
Add CTS tests for EthernetNetworkProvider changes
Move EthernetNetworkFactory to using the NetworkProvider API
Improve waiting for interface added or removed
This CL makes EthernetNetworkFactory inherit from NetworkProvider rather
than NetworkFactory. The name of the class is purposefully unchanged to
make the code review easier (it will be changed to
EthernetNetworkProvider in a follow up).
As part of the conversion, NetworkInterfaceState now registers a
NetworkOffer when the link comes up and unregisters it when the link
goes down. It updates the existing offer when capabilities change (by
calling registerNetworkOffer with an already registered
NetworkOfferCallback).
This change should fix existing refCount issues. When a NetworkOffer is
first registered, it receives callbacks for all existing requests. This
is the main problem with the NetworkFactory implementation where only
one NetworkOffer is registered when the factory is first created; so
when interfaces come up, they do not receive callbacks for existing
requests.
Test: atest EthernetNetworkTest
Bug: 197548738
Change-Id: I5e8e4673d2ed04bc1a0c8d232a8772edfff65b5d
Improve the setUnderlyingNetwork method by throwing IAE
when Network's LinkProperties is null. Also update the
API doc to give caller more guidance in using this API
Bug: 232309601
Test: UT: IpSecServiceParameterizedTest, IpSecServiceTest,
IpSecServiceRefcountedResourceTest, IpSecManagerTest, VpnTest
Test: CTS: IpSecManagerTest, IpSecManagerTunnelTest, Ikev2VpnTest
Test: make doc-comment-check-docs
Change-Id: Idab4706b0db42ed2222fb48b168589ed005d2f2f
In order to support rollbacks, the ethernet ipconfig file needs to be
written to the data apex's data directory. We still need to support
reading from the legacy location to be backwards compatible.
If the apex file path already exists, then read the IP configuration
from there directly, otherwise, check if the legacy file path exists,
if yes, read the legacy IP configuration and copy it to the new apex
file path.
Support for default IpConfiguration is also being removed in this CL.
The default IpConfiguration (configuration entry for interface "0")
was a way to transition from supporting a single interface to
supporting multiple interfaces and was introduced in P. Every device
that has used such a configuration and has connected to an ethernet
network since upgrading to P+ has already removed the "0" config and
has assigned it to the first interface (probably "eth0"). There has
never been an API to set this, but if someone wanted to install a
default IpConfiguration, they could just configure "eth0" instead.
Bug: 224919694
Test: atest EthernetConfigStoreTest --iterations
Test: manually test
- adb push <fake ipconfig.txt> /data/misc/ethernet/
- adb reboot
- read the IP config from legacy path and the same config
file is created in the apex file path
- adb reboot
- read the IP config from the apex file path directly
Change-Id: Ifb82a5d7fa13d17ea8fd3a42a19cd020cb95e26a
Updating the automotive allowed UIDs check to only work if the
capabilities have a single transport equal to ethernet.
Bug: 229419469
Test: atest FrameworksNetTests
Change-Id: I91e987d6b943a3c5986ab88553a6eef0d479b079
After turning off the ethernet settings via api, the ethernet service
can still be started when plugging-in the cable. Improve the api by
ignoring the upcoming interface unsolicited event listener callbacks
and register new interface observer once the ethernet setting is enabled
again.
Bug: 231933028
Test: atest testListenEthernetStateChange_unsolicitedEventListener
Change-Id: I1b1cb7d157f023fca82d75592168bd360a6fa6e1
Allow ethernet factories on automotive devices to set the allowed UIDs
on NetworkCapabilities.
Bug: 229419469
Test: atest FrameworksNetTests
Change-Id: I03e7cda75f1c530e0d0e4a756330bc9847a96668
Currently, even when VPN Lockdown mode is enabled, incoming packets are
not dropped if VPN is not connected.
This commit fixed this issue.
After this commit, If VPN Lockdown mode is enabled, incoming packets
are dropped regardless of the VPN connectivity.
Bug: 206482423
Test: atest TrafficControllerTest ConnectivityServiceTest PermissionMonitorTest
Change-Id: If52ece613c8aac1073355e43b6fb9cb3fcc87d1d
* changes:
Catch new exceptions from BpfMap
Revert "Open and close clat bpf map while clat is starting and stoping"
Revert "ClatCoordinator: replace BpfMap with IBpfMap"
This is needed to ensure corrupted data can be clean up if
the data migration process dones't go well.
Test: NetworkStatsCollectionTest
Bug: 197717846
Change-Id: Ic76ad6f3e96f03791b48988fb2622c9c647ffc7c
VPN configurations in T should automatically include the corresponding
SDK sandbox UID of an application.
The existing tests used a UID range outside the regular application
range, which means the new sandbox UIDs wouldn't be tested. Modified the
UIDs to run in the regular UID range of [10000, 19999]. Changed the
tests to include the SDK sandbox UID where necessary.
Also, changed the entire class to only run on T+, since that is the only
place where the SDK sandbox UIDs will be added. Since VPN code is not
mainline updatable, having coverage on earlier releases doesn't really
help anyway.
Finally, fixed up testNetworkBlockedStatusAlwaysOnVpn() in
ConnectivityServiceTest to include the sandbox UIDs as well.
Bug: 225317905
Test: atest VpnTest
Test: atest ConnectivityServiceTest
Change-Id: I83009344c270e520ac8ad1558c067cf7e46b1d2e
This is a follow-up commit from aosp/2076483. Mainly to update:
1. Update the hex string to human understandable code instead of
byte code.
2. Use IgnoreUpTo() to do the SDK check
3. Avoid relying on the code being tested
Bug: 192078259
Test: atest FrameworksNetTests
Change-Id: I8973d248a1d30fdcb597677dbf051e146041f905
Currently, there is no limtation for an app to request
data usage callback, which is dangerous if the app fire
hundreds of thousands requests and potientially this might
cause OOM if the apps don't free them.
Test: atest NetworkStatsObserversTest#testRegister_limit
Bug: 229103088
Change-Id: I8299f46fd47a82ec9b25ba2e0d3c95db5512c331
1) alowFallback flag was incorrectly not reset while setting profile
preference. Corrected it.
2) Threw exception if default preference and enterprise preference are
set together
3) renamed clearUser to withoutUser
Bug: 231670730
Test: ConnectivityServiceTest
Change-Id: Iaf49237bdc791c7e1dd884d069eff64e74757477
Normally if an app calls requestNetwork with capabilities that it
does not have permission to request, it gets a SecurityException,
except if it requests NET_CAPABILITY_CBS, in which case the request
will not throw but the app will get an onUnavailable callback.
Make this codepath throw as well. This simplifies the code and makes
the app-visible behaviour more consistent (and consistent with what
happens in S and below). The reason the code was written this way is because the carrier privilege app should receive a callback if it
loses permission. But onUnavailable is also not the best callback to
send, since it is used very rarely and also releases the app's
request. It seems better to leave the request registered and send
onLost.
Test: atest FrameworksNetTests
Bug: 194332512
Change-Id: I5eaeb415a6654851246e38599a996fbd9366fde0
Multiple enterprise slice can be setup within single user profile based
on different uids. So do not remove profile network preference with same
user profile but with different uids
Bug: 229644102
Test: manual system test and ConnectivityServciceTest
Change-Id: I897b643e01240958fff575de9e15182069efc698
1. Test that adding a new preference replaces the existing preference.
2. Test that if we pass in two simultaneous preferences for the same user.
(e.g., two different groups of apps), the second overrides the first.
Bug: 229644102
Test: ConnectivityServciceTest
Change-Id: I819247711f8457b12792585216ff47be31457ae8
BpfMap class supports AutoCloseable interface which closes
file descriptor only in try-exit. BpfMap class doesn't close
fds while the object is released.
Change the timing of opening and closing bpf map file descriptors
to clat is starting and stoping.
Moreover, the reason that manual close BPF map file descriptors is
as follows. Just don't rely on that GC releasing to close the file
descriptors even if class BpfMap supports close file descriptor in
finalize(). If the interfaces are added and removed quickly, too
many unclosed file descriptors may cause unexpected problems.
Bug: 230880517
Test: manual test
Steps:
1. Connect to IPv6 only wifi (GoogleGuest) and mobile data
2. Check that map fds are appeared:
/proc/$(system_server_pid)/fd/$(bpf_map_fd)
$ adb shell ps | grep system_server
system 1929 825 20311224 730060 do_epoll_wait 0 S system_server
$ adb shell ls -all proc/1929/fd | grep bpf-map
.. system system 64 2022-05-05 13:36:42 .. 331 -> anon_inode:bpf-map
.. system system 64 2022-05-05 13:36:42 .. 348 -> anon_inode:bpf-map
3. Check the clat maps are added.
$ adb shell dumpsys connectivity
NetworkAgentInfo{network{105} handle{454377263117} ni{WIFI ..
Nat464Xlat:
..
Forwarding rules:
BPF ingress map: iif nat64Prefix v6Addr -> v4Addr oif
47 /64:ff9b::/96 /2a00:79e1:abc:6f02:f182:6c29:ab56:9961 -> /192.0.0.4 62
BPF egress map: iif v4Addr -> v6Addr nat64Prefix oif
62 /192.0.0.4 -> /2a00:79e1:abc:6f02:f182:6c29:ab56:9961 /64:ff9b::/96 47 ether
NetworkAgentInfo{network{106} handle{458672230413} ni{MOBILE[LTE] ..
Nat464Xlat:
<not start>
4. Disconnect from wifi
5. Check that map fds are disappeared:
/proc/$(system_server_pid)/fd/$(bpf_map_fd)
$ adb shell ls -all proc/1929/fd | grep bpf-map
(fd 331 and 348 were not found)
Change-Id: I60c0301bf00beae5cf5ab3535c6a3da68a2a4a9b
Adding unit tests to QosSocketFilterTest
Bug: 203146631
Test: atest & verified on LTE test equipment
Change-Id: I0cd82dde0067d754dfab01ed0406370d7debb937
In order to have better logging to gather information
about the callers. This change includes:
1. Add pid and package name into RequestInfo for better logging.
2. Print current observers in dumpsys section.
3. Enable register/unregister usage request logging by default.
The log added in the dumpsys section looks like:
Stats Observers:
RequestInfo from pid/uid:2001/1000(android) for DataUsageRequest [...] accessLevel:3
...
Test: NetworkStatsObserversTest
Bug: 229103088
Change-Id: Ide68776dc279610e8dee0efd924b59a1fac2b7b6
isMangedProfile returns true for managed profiles.
But enterprise device can be fully managed like device owner.
Hence check specifically if request is coming on fully managed
device.
Bug: 226966328
Bug: 231071836
Test: ran DevicePolicyManager CTS and ConnectivityServiceTest
Change-Id: I7827466bd61e24ba9c36c3a2e25043257e2ed602
* changes:
Test VpnManager event for CATEGORY_EVENT_NETWORK_ERROR
Test VpnManager event for CATEGORY_EVENT_IKE_ERROR
Test VpnManager event for CATEGORY_EVENT_ALWAYS_ON_STATE_CHANGED
Test VpnManager event for CATEGORY_EVENT_DEACTIVATED_BY_USER
ConnectivityManager have a self reference static instance. This
causes a leak if context is refernce from a static variable. Using
the applicationContext, which will never be freed for the life of the
application, for the sInstance static instance.
Bug: 202978965
Test: atest ConnectivityManagerTest
Change-Id: I87206e1bfbb1f877b5a10f5fdbc25e2f9f11bef4
The sInstance static instance which self reference to
ConnectivityManager which holds a reference to a ConnectivityManager
instance causes the Context referenced by that instance to never be
GCed.
Bug: 202978965
Test: atest ConnectivityManagerTest
Change-Id: I0227f63dbc27688ea5f4ef9275fd0f9c247ad14c
