getVpnLockdownUidRanges acquire lock and access internal state of a
Handler-based class (PermissionMonitor), which is bad practice in
general.
getVpnLockdownUidRanges returns keySet of mVpnLockdownUidRanges.
PermissionMonitor call updateUidLockdownRule and update the bpf map
based on mVpnLockdownUidRanges.
PermissionMonitorTest verifies the args of updateUidLockdownRule call.
So, It's not necessary to verify the mVpnLockdownUidRanges which
is internal states of PermissionMonitor.
Test: atest PermissionMonitorTest
Bug: 262199762
Change-Id: I85b39ab2aff44dcbe809b39560d6bb87fbb0c084
getVpnInterfaceUidRanges acquire lock and access internal state of a
Handler-based class (PermissionMonitor), which is bad practice in
general.
getVpnInterfaceUidRanges returns mVpnInterfaceUidRanges.
PermissionMonitor call add/removeUidInterfaceRules and update the bpf
map based on mVpnInterfaceUidRanges.
PermissionMonitorTest/ConnectivityServiceTest verifies the args of
add/removeUidInterfaceRules call.
So, It's not necessary to verify the mVpnInterfaceUidRanges which
is internal states of PermissionMonitor.
Test: atest ConnectivityServiceTest PermissionMonitorTest
Bug: 262199762
Change-Id: I31cbb9b1dd43eaf0354799a81c9df292fb5f6445
When registering and advertising a service on the same device, it is
possible for NsdService to find the service on the dummy0 interface. It
is however unusable and not resolveable.
Skip callbacks on the dummy0 interface as they would confuse apps and
tests.
Bug: 266176036
Test: atest NsdServiceTest
Change-Id: I98cca0135e0f6936187d45707cbdad7a7f263ff1
Even if there are no preferences, the allow list needs
to be updated upon adding a new user, because it's set
unconditionally when the network connects.
Adding all existing UIDs would address this issue too
and we probably want to do it, but immediately this
seems simpler.
Bug: 266136779
Test: new test for this
Change-Id: I77091a6c3d3ccf2b80ab0aaa01d09ef0df922501
Add a flag to control dynamic keepalive mode so that this
feature could be dynamically enabled via flag push. Default
is enabled in KeepaliveTracker.
Bug: 259000745
Test: atest FrameworksNetTests
Change-Id: I438de9aefd22229669a9ae4da5fd109fdfa73b10
chiachangwangauthored and Chalard Jeancommited 2023-01-20 17:47:11 +09:00
On each received packet, query MdnsRecordRepository to detect any
conflicting service, and report it though onServiceConflict.
Implement restartProbingForConflict and renameServiceForConflict which
may be called when that callback is dispatched.
Bug: 266151066
Test: atest MndsInterfaceAdvertiserTest MdnsRecordRepositoryTest
Change-Id: I5434b00879e0c8f7fc1e4769455b688c3bd7a9b5
Currently, the resolution is a one shot query, it only notifies
the first finding service information. There is no way to listen
the service update. Thus, add a new API that can register a
callback to listen to the service updates continuously.
Bug: 245369943
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I0e9d92b9028375feb3e344ab6c4acb515c5b2be9
Paul Huauthored and Remi NGUYEN VANcommited 2023-01-19 20:16:03 +09:00
Add a new AutomaticOnOffKeepaliveTracker class between
ConnectivityService and KeepaliveTracker to handle the automatic
on/off keepalive. This commit only creates this new class and
move the TCP polling code to the new class as a preparation for
the following commit.
The original test file was created for testing the TCP polling
mechanism, so rename it to match the new class.
Bug: 259000745
Test: m ; atest FrameworksNetTests
Change-Id: I1b229f906283c0f5ef7a3efdb0572fcbfc5df72b
chiachangwangauthored and Chalard Jeancommited 2023-01-19 13:17:54 +09:00
Based on a flag, use MdnsAdvertiser for advertising instead of the
legacy mdnsresponder implementation.
Bug: 241738458
Test: atest NsdServiceTest
Change-Id: I2d5069097c11f2959e3792cac326d179a3116479
Resolve service may take long time due to network issue or
using wrong service information, but users are not able to stop
it. They can only wait for the callback of resolveService to end,
which sometimes takes a long time. Thus, add the new API that
users can stop the service resolution.
Bug: 245369943
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I6b6183c8c73f8db981b9afa51fbc73bf886d9ed3
Service resolved should be notified when receive the
onServiceFound callbacks from MdnsServiceBrowserListener
Bug: 254166302
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I681720065084bf3449c5b1ab44cd4ed6a659dcdb
Implement the onServiceConflict callback in MdnsAdvertiser, refactoring
the conflict detection to reuse it both in onServiceConflict (when a
conflict is detected on the network after add) and at service add time.
Bug: 241738458
Test: atest MdnsAdvertiserTest
Change-Id: I69128db936296bd2c5e90e9f00df19fd881e1748
MdnsInterfaceAdvertiser registers to receive incoming packets, and
sends replies to queries as built by MdnsRecordRepository.
Bug: 241738458
Test: atest
Change-Id: I13db22f8efc870b6e0747d105f6bc8f759910f81
Factor out generic packet decoding into MdnsPacket, out from
MdnsResponseDecoder.
This allows reusing the same decoding code for replies, and other kinds
of MdnsPackets.
Bug: 241738458
Test: atest MdnsResponseDecoderTests MdnsPacketTest
Change-Id: I4380f80240ed5a367accfc1b0c595967ee475578
Service lost should be notified when receive the
onServiceNameRemoved callbacks from
MdnsServiceBrowserListener.
Bug: 254166302
Test: atest FrameworksNetTests
Change-Id: I298816ac186efeda85cea4cd11f3beab6b341bc5
Service found should be notified when receives the
onServiceNameDiscovered callbacks from
MdnsServiceBrowserListener.
Bug: 254166302
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I3f41b4fe85cd85ad356fa764663187a88914412c
Add TCP polling mechanism in KeepaliveTracker to understand if
there are any TCP sockets in the target network. This is a
preparation commit for dynamically control keepalive based on
the existence of TCP sockets. This is non-functional now since
there is no caller to retrieve the information now.
Bug: 259000745
Test: atest FrameworksNetTests
Test: Manually test by creating TCP sockets on the target network
in device and check if deisgn works.
Change-Id: I355ac340cad2fac618bb9d65fb1b1539ea644959
In the context of ConnectivityServiceTest this is plenty
clear, so terser is better.
Test: ConnectivityServiceTest
Change-Id: Id20afc8a81a6c00c932ffae3b8dbc2919773d35b
Create the MdnsDiscoveryManager for mdns discovery and resolution
if the feature is enable.
Bug: 254166302
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I4d7591b50cb06f0efcc0dde9834b775c513cceff
Build ExitAnnouncementInfo in MdnsRecordRepository.exitService. Use a
separate class for AnnouncementInfo and ExitAnnouncementInfo, so
announcement callbacks can differentiate each case.
Bug: 241738458
Test: atest
Change-Id: I3b1ad1bef3dc1514479d7c789ef06b6a7de02e59
Once probing succeeds, the advertiser sends announcements for its
records as per RFC6762 8.3.
Implement MdnsRecordRepository.onProbingSucceeded to return the
AnnouncementInfo which will be sent.
Bug: 241738458
Test: atest
Change-Id: Id4c2e610911fdf471a6d6ae08c2127fbf1530dc7
Instead of using a separate service-mdns library, move the code to
service-connectivity-t.
service-connectivity-t is chosen because it has access to hidden API of
classes that were made updatable in T, such as NsdServiceInfo and
NsdManager. mdns code can be there as it is only loaded on T+.
Bug: 241738458
Test: atest
Change-Id: I7eb6c9ab8bf0e0a614ea2994c6ed80a1a780241f
Add tests for MdnsRecordRepository and MdnsInterfaceAdvertiser
implementations of probing.
Bug: 241738458
Test: atest
Change-Id: If41a387f14e805e81b6d0d8217d081ca053e340f
Motomu Utsumi
commited 
Sudheer Shanka
commited 
Remi NGUYEN VAN
authored and
Gerrit Code Review
commited 
Chalard Jean
commited 
Treehugger Robot
authored and
chiachangwang
authored and
Paul Hu
authored and
Oli Lan
authored and
Aaron Huang
authored and