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
This commit also updates to use V11 dnsresolver APIs which was V9.
Bug: 262683651
Test: unit tests
Change-Id: Ifbd71157012dc66ec0f377beef9fa59d1c8620b8
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
MdnsAdvertiser takes requests to advertise services on given Networks,
and relays them to internal maps of MdnsInterfaceAdvertisers.
SocketProvider is used to create the sockets for the requested networks.
It also ensures that added services do not have name conflicts, as
registration of one service should use the same name on all interfaces,
so any conflict means that every MdnsInterfaceAdvertiser needs to use a
different name. Names are automatically updated with a number suffix
(like "service (2)", "service (3)"), similarly to the legacy
mdnsresponder implementation.
The implementatio of MdnsInterfaceAdvertiser will be added in a
different change.
Bug: 241738458
Test: atest
Change-Id: I21aa93c681dd179b9d6ec425bc0f247a10ba5b0b
This allows us to skip any older CONNECTIVITY_ACTION broadcasts
waiting to be delivered when a new broadcast is dispatched.
Bug: 255545931
Test: TH
Change-Id: Iac5da2f727e295d1775bfe91358900f316258be4
In the original design that using qtaguid module to get the
stats, mDevRecorder was for interface-level summary which
may include non IP layer traffic and mXtRecorder was for
interface-level summary which is only IP layer traffic.
It's migrated to use xt_bpf to read ifaces stats currently
since the qtaguid proc file is no longer exist. Both
readNetworkStatsSummaryXt() and readNetworkStatsSummaryDev()
return stats from bpf iface stats map. mDevRecorder has the
same content as mXtRecorder, and there's no usage actually
reference to mDevRecorder. Thus mDevRecorder can be removed.
Bug: 241880278
Test: FrameworksNetTests
CtsNetTestCases
Change-Id: Ib0fe823517c81989ee01dc8835ab69a9da818162
NetworkTemplate was moved into mainline module and
provide Builder for external users to build template.
MATCH_MOBILE_WILDCARD and MATCH_WIFI_WILDCARD are not
exposed so currently the usage of these two constants
only in module. This change is to remove the constants.
After removing the constants, two methods matchesWifi
and matchesMobile are changed to adapt the original
matches[Wifi|Mobile]Wildcard behavior.
Bug: 238843364
Test: FrameworksNetTests
Change-Id: I9e156b504ce4eb903b39279e443fad27bc921186
