The SparseArray.indexOfValue() uses == to compare values,
MulticastRoutingCoordinator uses SparseArray with String type values,
and the indexOfValue function would sometimes return -1 when looking for
a value in the SparseArray.
Added a helper function getIndexForValue in CollectionUtils to get index
by comparing values with equals, and used this function in MulticastRoutingCoordinator.
Updated
MulticastRoutingCoordinatorServiceTest#testMulticastRouting_applyConfigNone_removesMfc
test case to use copies of interface names when updating the multicast
configs, so the test would fail without this fix.
Test: atest NetworkStaticLibTests:com.android.net.moduletests.util.CollectionUtilsTest#testGetIndexForValue
atest android.net.connectivity.com.android.server.connectivity.MulticastRoutingCoordinatorServiceTest#testMulticastRouting_applyConfigNone_removesMfc
Change-Id: I862242d6be01b8552cdd6af6c9691948a9f0bfe0
NsdServiceInfo may contain an interface index if it was obtained from a
previous discovery callback which found a service on an interface that
does not belong to any Network.
In that case, subsequent resolve or registerServiceInfoCallback queries
using that NsdServiceInfo should only be done on the matching interface.
Apps may otherwise receive replies from other networks, with different
interface addresses.
As a simple fix, still request sockets from all interfaces in that case,
but only create the MdnsServiceTypeClients on matching sockets.
The sockets are created / cleaned up based on the lifecycle of the
requests, which does not change.
Fixes: 332262554
Test: atest
Change-Id: I2bbb498d4a0d37725f019a4cf5e367fef76fa0e8
The BACKGROUND firewall chain has been recently added. We want to
be able to turn it off in case of contingencies with a device-config
flag flip.
The flag is assumed to be boot-stable and its value is read at boot.
When the flag is off, we ignore any operation on this firewall chain.
Additionally, this chain is always considered disabled on versions
upto UPSIDE_DOWN_CAKE.
Note: All firewall chains are in disabled state at boot by default.
Test: atest FrameworksNetTests
Test: Manually, using adb shell device_config commands.
Bug: 331484830
Change-Id: I9ccc483e02e27a584da6714931466a9f2ec95ca9
With satellite transport supported at device and satellite
network to appear under type mobile, considers cellular or
satellite, or combination of both interfaces under mobile interfaces.
Note: getUidStatsForTransport(TRANSPORT_SATELLITE) is not supported,
considering the same interface name could be used by cellular as well,
supporting this might lead to double counting problem.
Bug: 329003473
Test: atest FrameworksNetTests
Change-Id: I85465cedcc5550fa0555dc36b3be364ac90aade1
- Handle onRoleHoldersChanged is not triggered even if the user has a
default app setup and gets deleted scenario.
- Adding ACTION_USER_REMOVED intent filter, to monitor for User
removal. This to used to update satellite fallback uid list
and to keep allowed uid range updated at multi layer request
of track default and satellite transport with Internet
restricted capability
Bug: 326373613
Test: atest FrameworksNetTests
Change-Id: I1f30cd129309486bccbc61802ed600c142077411
If the query with known answer feature is enabled and the
MdnsPacket is too large for a single DatagramPacket, it
will be split into multiple DatagramPackets.
Bug: 312657709
Test: atest FrameworksNetTests NsdManagerTest
Change-Id: I831fb6035cc0ad03078fbd3b9c550b56ddca07fb
CSTest SetUp sets flag values based on annotations before
constructing ConnectivityService.
For flags that are loaded at ConnectivityService constructor, tests can
use this annotation to set flag values.
Test: TH
Change-Id: I5a995a3de4e433ac39e6ccc116b9d89da468b04b
This method can generate query packets from an oversized
MdnsPacket.
Bug: 312657709
Test: atest FrameworksNetTests
Change-Id: I21c1e082e01e0a6421920692115b0afdca0c9f9c
Similar to aosp/2988171, this CL restarts the announcement of services
when the services' host gets new addresses.
Bug: 327304356
Bug: 323712889
Change-Id: I1d9706d4721c216dacda203bf0445f557b008ebf
NetworkPolicyManager#isUidNetworkingBlocked does not know about some
firewall chains status(e.g. FIREWALL_CHAIN_OEM_DENY_1)
So BpfNetMaps#isUidNetworkingBlocked is more correct but there could be
some behavior difference.
To avoid breaking devices and have longer verification time, this CL
updates to use BpfNetMaps#isUidNetworkingBlocked only on V+ devices.
Bug: 328732146
Test: TH
Change-Id: I60f84a5fff90386103692841dead465652249446
When some of a custom host's addresses are removed, the services which
are using the custom host should be updated accordingly:
- For the services being probed, the probing should be restarted with
the updated address records.
- For the services which already finished probing, they should be
re-announced with the updated address records.
For example, here is a scenario where the fix is necessary:
1. Register a host (host1) with addresses (addresses1)
2. Register a service (service1) using the host1.
3. Unregister the host1.
4. Re-register the host1 with different addresses (addresses2).
Then the probing messages of the second registration of host1 may
conflict with the announcements of service1 (which containing addresses
records of the addresses1). This is an undesired conflict. Restarting
the announcement of service1 when updating the addresses of host1
can get rid of this conflict.
Bug: 327304356
Change-Id: Ie97b72f1482c69fb5f24eab3ce9ed8f7cea957ec
When request_restricted_wifi is enabled CarrierPrivilegeAuthenticator
calls CarrierPrivilegesLost callback passed from ConnectivityService.
But CarrierPrivilegeAuthenticator was using its own handler thread to
receive broadcast and callbacks so CarrierPrivilegesLost callback needed
to post a message to the CS handler.
This CL updates CarrierPrivilegeAuthenticator to use CS handler if
request_restricted_wifi is enabled, and remove the message post in
ConnectivityService.
Test: TH
Change-Id: Ib41304a30e3dd366b0f6f1d7df81145f0e05ece1
The last dependency in the vpn-jarjar-rules can be removed
after refactoring the test as the test does not really
rely on the content of VpnProfileStore.
Test: atest FrameworksNetTests
Change-Id: Ib665dd7c05cca1eae77bf4100c43911686aac0ea
To support known-answer suppression, the querier should include
its known answers within each query packet. This allows the
service to determine whether a response is necessary based on
the querier's existing knowledge.
Bug: 312657709
Test: atest FrameworksNetTests NsdManagerTest
Change-Id: I2fb421aff1ae150b310e1a44f50f098a3edb9992
This no-op change uses MdnsUtils#createRawDnsPacket to construct
query packets instead of MdnsPacketWriter. This refactoring sets
the stage for future support of constructing multiple query
packets.
Bug: 312657709
Test: atest FrameworksNetTests NsdManagerTest
Change-Id: I404ec52e97635eed9d965d7c7ceaf6e726386d64
Use getAndClearLastScheduledRunnable() to run the query task
instead of getAndClearSubmittedRunnable(). Additionally,
remove running the query task twice incorrectly.
Test: atest MdnsServiceTypeClientTests
Change-Id: If8ee1b4d08fe716eaae97d66e6c10ec2af89c024
When there are addresses that are used by a single VPN interface,
ConnectivityService sets ingress discard rules to drop packets to this
address from the non-Vpn interfaces
Test: FrameworksNetTests
Bug: 295800201
Change-Id: I089d01a38eff3f37a851627fa9e4acefb8d9ad5e
KeepaliveStatsTracker calls addOnSubscriptionsChangedListener from the
constructor.
And KeepaliveStatsTracker is instantiated from ConnectivityService
constructor.
So using actual SubscriptionManager leaked listener and tests started
failing.
Bug: 329365833
Test: atest ConnectivityCoverageTests
Change-Id: I65ac34e4bc6b5fd86a290706be844914d09918a5
This enforceNetworkStackPermission() should be adopted to check
the required permission but this may be break OEM captive portal
apps. Simply ignore the request if the caller does not have
permission.
This commit also fixes the format issues that is auto-fixed by
ktlint.
Fix: 329385091
Test: ates FrameworksNetTests
Change-Id: Ia973a1078eda3134fc8ff261d3954cd050767880
Instead of creating one NetworkInterfaceProvider for each MdnsSocket,
create one in MdnsSocketClient and use it for each MdnsSocket.
MdnsSocket only calls getMulticastNetworkInterfaces and
getAvailableNetwork on MulticastNetworkInterfaceProvider, which are
thread-safe (the first one is synchronized). There is no need to have
multiple MulticastNetworkInterfaceProvider tracking the same state.
This allows reducing the number of callbacks filed to
ConnectivityManager, which is a resource usage improvement and can be
beneficial for huge apps that have many components which may
collectively reach the MAX_NETWORK_REQUESTS_PER_UID limit in
ConnectivityService (100).
MdnsSocketClient is unused in AOSP so this is a no-op in the platform.
It is only used by users of the unbundled mdns library.
Bug: 322049918
Test: atest
Change-Id: I515459beaee6aacc99c7c0c2a05c3c9c41473b62
This change also implement a getOrCompute method, if the entry
is not found in the cache or has expired, computes it using the
provided supplier and stores the result in the cache.
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.server.net.TrafficStatsRateLimitCacheTest
Bug: N/A
Change-Id: I60f07e84b7d2c754548b7cd431bd079b0d808c0a
There is a race condition in MdnsAdvertiser when removing the last
service:
1. When the last service is removed, it will call the destroyNow()
to tear down the interface advertiser and schedule a onDestroyed()
callback for MdnsAdvetiser to do further cleanup
2. If another serivce is registered after removing the last service but
before onDestroyed() is invoked, then onAdvertiserDestroyed() will
return false and the InterfaceAdvertiserRequest is kept in the map in
MdnsAdvertiser. This is because the newly registered service is in
the mPendingRestionstrations.
3. The problem is that InterfaceAdvertiserRequest now have no
InterfaceAdvertiser (because the only advertiser has already
destroyed) and cause the newly registered service can't be
advertised.
It needs to schedule onDestroyed() on the handler thread because we
can't do modify-during-iteration, but this introduces the race condition
here.
The fix in this commit changes to not destroy the InterfaceAdvertiser
immediately when the last service is removed but destroy when there are
no pending registrations in the InterfaceAdvertiserRequest.
Test: atest --iterations 100 CtsNetTestCases:android.net.cts.NsdManagerTest#testRegisterService_registerImmediatelyAfterUnregister_serviceFound
Change-Id: I6b6f01e6ddf103d16a8b0296af000dc8262ea65b