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
Add MdnsMultinetworkSocketClient which is using for managing
multinetwork for discovery and resolution. If the requests are
specified the network to do the discovery or resolution, it
should send the queries and receive the responses on the active
networks only. This can save the resource by reducing unnecessary
queries and align the behavior with mdnsresponder.
Bug: 254166302
Test: atest FramworksNetTests
Change-Id: I9f49ac11e70cb945f9a90efc5eb684be87801286
PacketRepeater can just try to send to both v4 and v6 multicast
addresses, and rely on MdnsReplySender to check whether the sockets have
(automatically) joined the v4 or v6 groups, so there is no need to use
this unusual lambda setup anymore.
Bug: 264947218
Test: atest MdnsProberTest MdnsAnnouncerTest
Change-Id: I09e0fa4bf14e1f31f2d2508f17e23adf1415feb7
This commit exposes APIs to migrate a tunnel mode transform to
new source/destination addresses, as required by MOBIKE.
By calling the exposed API, the caller only caches the new
address in the transform. To complete the migration, caller
MUST apply the tranform to the appropriate tunnel.
This API design is mainly based on the kernel interface and use
cases. The Linux kernel requires Android to provide both the
IpSecTransform and the IpSecTunnelInterface to perform the
migration. And in most cases those two instances are managed
by different entities: IpSecTranform is managed by the key
exchange protocol (e.g. IKE) and IpSecTunnelInterface is managed by
the security tunnel provider (e.g. VPN, VCN, and IWLAN). Thus the
migration process has been designed to have two steps where the
key exchange protocol negotiates and caches the new address,
passes out the updated transform, and the security tunnel
provider applies the transform to a tunnel.
Another benefit of this API is it can also apply to the case
where the network peer does not support MOBIKE and thus cannot
update the existing transforms. In this case, the key exchange
protocol can create a new transform and give it to the security
tunnel provider, and the tunnel provider can still call "apply"
to perform migration without needing to know the details of the
transform update process.
Bug: 169171001
Test: atest FrameworksNetTests, IpSecManagerTunnelTest
Change-Id: I0658cdb09fb31f7e0fb9d0b07f37c2b72b6e705f
Remi NGUYEN VAN
authored and
Gerrit Code Review
commited 
Paul Hu
authored and
chiachangwang
authored and
Chalard Jean
commited 
Treehugger Robot
authored and
Oli Lan
authored and
Aaron Huang
authored and
Yan Yan
authored and
Junyu Lai
authored and