The receipt time in the MdnsResponse need to be updated every time new
packet is received. And then the record refreshing logic could calculate
remaining TTL correctly.
Bug: 285260665
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ib7a290ea0ea8e552c71c657696397e8114fcee52
When an mDNS request (discovery, advertising, resolving...) is
registered and gets assigned a socket on a wifi network, take the
multicast lock to ensure that it can reliably receive mDNS responses.
This is limited to when the application has importance
FOREGROUND_SERVICE or higher.
NsdManager is not documented to require usage of the multicast lock,
which has caused various reports about its reliability. Taking the lock
while the app is in the foreground should address the large majority of
cases, while limiting battery impact.
Going forward this should allow developers on U+ to not take the
lock themselves, allowing optimizations on devices supporting APF,
where instead of taking the lock APF would let through only select
mDNS packets.
Bug: 284389438
Test: atest
Change-Id: I1ce85220eac4a1529b6716d50727c1c462356846
Test: new test for this behavior in the preliminary change
Test: FrameworksNetTests NetworkStackTests
Fixes: 138810051
Fixes: 140610528
Change-Id: I95a979d232fb60ece2e33e972bf5d66d20357a1f
This patch mocks the SDK level and/or change IDs to help
developing functionality that depends on these without
having to flash a new device every time.
Test: TH
(cherry picked from https://android-review.googlesource.com/q/commit:df29a85ee70e56a888c82e4e885ab6f775416ff7)
Bug: 284253763
Merged-In: I1011193c99e123a0e5501ed313c9cecbceebdae6
Change-Id: I1011193c99e123a0e5501ed313c9cecbceebdae6
See system/netd/include/Fwmark.h which reserves the bottom 21 bits
of skb->mark for netid, etc... so out of necessity these have to be
in the top 11 bits.
In practice the only values that really make sense are either:
mark == mask == 0 (disabled)
or (mark == mask) being one of the top 11 available bits, for example:
mark == mask == 0x80000000 (enabled, using top-most bit)
(only a single bit makes sense, as this is really just a boolean signal,
and only the topmost is known to be used on any real devices)
Let's just force the use of 0x80000000 for ecosystem consistency.
Bug: 284334830
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:767cf7f1cfc6d612bc8554fef8c354fdd660695b)
Merged-In: I199e9b00de845b3747940426ea6644426ab72e87
Change-Id: I199e9b00de845b3747940426ea6644426ab72e87
See system/netd/include/Fwmark.h which reserves the bottom 21 bits
of skb->mark for netid, etc... so out of necessity these have to be
in the top 11 bits.
In practice the only values that really make sense are either:
mark == mask == 0 (disabled)
or (mark == mask) being one of the top 11 available bits, for example:
mark == mask == 0x80000000 (enabled, using top-most bit)
(only a single bit makes sense, as this is really just a boolean signal,
and only the topmost is known to be used on any real devices)
Let's just force the use of 0x80000000 for ecosystem consistency.
Bug: 284334830
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I199e9b00de845b3747940426ea6644426ab72e87
* changes:
FinalizePausedKeepalive in handleStopAllKeepalives.
Add tests for pause, resume and stop keepalives.
Ensure autoKi is not stored when keepalive stops or is not started.
Add tests for NATT keepalives stopped internally in KeepaliveTracker.
aosp/2490881 updated to use InetDiagMessage.destroyLiveTcpSocket for all
devices.
But it is possible that netd socketDestory is modified in T- devices.
So this CL revert changes to keep using netd socketDestroy in T-
devices.
Test: atest FrameworksNetTests
Bug: 284253763
(cherry picked from https://android-review.googlesource.com/q/commit:1d137267108a28881e399d62311b1a42a60616fc)
Merged-In: I9b61f10e975d2e38e9829a8c01d3af706e2518ef
Change-Id: I9b61f10e975d2e38e9829a8c01d3af706e2518ef
Address review comment on aosp/2490881
ConnectivityServiceDependencies was made public in aosp/2490881 to
verify destroyLiveTcpSockets call.
This CL reverts that change and updates tests to use mocked
DestroySocketsWrapper to verify destroy sockets call.
Bug: 270298713
Test: atest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:d54120344d02ab82df152c44fc855342783c12e1)
Merged-In: I101016399ea29bc5176b7559edf0447f0f7901ce
Change-Id: I101016399ea29bc5176b7559edf0447f0f7901ce
If there is no request for all networks, the tethered/local only
interface changes will be ignored. However, these available
interfaces are not used for mDNS when a user requests a socket
with a null network because the interfaces are lost due to the
previous ignore. Therefore, the interface changes should be
retained and will be used for socket creations afterwards.
Bug: 284939720
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
(cherry picked from https://android-review.googlesource.com/q/commit:bb69412f5b19c72ca5666ceec12f07b5e35df92d)
Merged-In: If830eb53af26f21f497314477b131ce28468a971
Change-Id: If830eb53af26f21f497314477b131ce28468a971
mDNS is used by wifi p2p in many places. However,
MdnsSocketProvider does not monitor changes to the wifi p2p
connection to get the names of the available wifi p2p interfaces.
This prevents mDNS from registering or discovering services on
the wifi p2p interfaces. Therefore, listen to the wifi p2p change
intent to know the available interfaces and status changes that
can be used by mDNS.
Bug: 284263838
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
(cherry picked from https://android-review.googlesource.com/q/commit:fbba5e83075fe3f1d96ca28ca00e8734b47e25a0)
Merged-In: If03514f1286c0507e5862372272234dd07eb084d
Change-Id: If03514f1286c0507e5862372272234dd07eb084d
aosp/2490881 updated to use InetDiagMessage.destroyLiveTcpSocket for all
devices.
But it is possible that netd socketDestory is modified in T- devices.
So this CL revert changes to keep using netd socketDestroy in T-
devices.
Test: atest FrameworksNetTests
Bug: 284253763
Change-Id: I9b61f10e975d2e38e9829a8c01d3af706e2518ef
As mentioned in RFC6762 7.1. The records only needed to be renewed if
at least half of the TTL passed. Usually A/AAAA records are included in
the response to the SRV record query, they are not refreshed individually.
Bug: 285260665
Bug: 285261577
Test: atest CtsNetTest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:f2cc01dc126ba1bd8c89add0853546ab4627c3aa)
Merged-In: Ifd7140de0d733191256184c5481412e1822d279b
Change-Id: Ifd7140de0d733191256184c5481412e1822d279b
Turn on removeExpiredService feature by: 1) Remove the unnecessary
allowSearchOptionsToRemoveExpiredService flag. 2) Turn on the
removeExpiredService flag in the MdnsSearchOptions.
Bug: 285260665
Test: atest CtsNetTest FrameworksNetTests
(cherry picked from https://android-review.googlesource.com/q/commit:ff96322c4f5e35c53443115e93df0f651a7218e7)
Merged-In: Ib115b40e70b0f81a7877deb73af7d61e2e0c385f
Change-Id: Ib115b40e70b0f81a7877deb73af7d61e2e0c385f
If there is no request for all networks, the tethered/local only
interface changes will be ignored. However, these available
interfaces are not used for mDNS when a user requests a socket
with a null network because the interfaces are lost due to the
previous ignore. Therefore, the interface changes should be
retained and will be used for socket creations afterwards.
Bug: 284939720
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: If830eb53af26f21f497314477b131ce28468a971
mDNS is used by wifi p2p in many places. However,
MdnsSocketProvider does not monitor changes to the wifi p2p
connection to get the names of the available wifi p2p interfaces.
This prevents mDNS from registering or discovering services on
the wifi p2p interfaces. Therefore, listen to the wifi p2p change
intent to know the available interfaces and status changes that
can be used by mDNS.
Bug: 284263838
Test: atest FrameworksNetTests android.net.cts.NsdManagerTest
Change-Id: If03514f1286c0507e5862372272234dd07eb084d
This change fixes the test crash that is caused by ART's JNI failure.
ART's JNI doesn't allow native code to raise another exception while
an exception is pending.
Bug: 282896580
Test: turned off private DNS; used iptables to drop DNS packets;
ran MultinetworkApiTest; verified no crash happened
Change-Id: Ide9e122f74d9939ce386d07d948a4e487870024f
As mentioned in RFC6762 7.1. The records only needed to be renewed if
at least half of the TTL passed. Usually A/AAAA records are included in
the response to the SRV record query, they are not refreshed individually.
Bug: 285261577
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ifd7140de0d733191256184c5481412e1822d279b
Turn on removeExpiredService feature by: 1) Remove the unnecessary
allowSearchOptionsToRemoveExpiredService flag. 2) Turn on the
removeExpiredService flag in the MdnsSearchOptions.
Bug: 285260665
Test: atest CtsNetTest FrameworksNetTests
Change-Id: Ib115b40e70b0f81a7877deb73af7d61e2e0c385f
Store the handler that should be running all the public methods and
use it by comparing its thread with the current thread.
Also refactor the tests to use and run on a test handler thread.
Bug: 273451360
Test: atest FrameworksNetTests
Change-Id: I053f1043a3b518728c4b30b94eec1d33fbfe39c0
In the case that a keepalive is paused and handleStopAllKeepalives is
called, there is no KeepaliveInfo for the paused keepalive and so no
onError callback will be called. The autoKi will also be cleaned up so
no callback will ever called that notifies the keepalive is stopped.
Bug: 281646074
Test: atest FrameworksNetTests
Change-Id: I8fcaa1f07746235326c7ae05d97e20fd27927fea
The tests added verify the following:
1. Stopping the keepalive will cleanup the autoKi.
2. Pausing the keepalive does not cleanup the autoKi and stopping
a paused keepalive will still call the onStopped callback.
3. A starting error by resuming the keepalive will cleanup the
autoKi.
4. handleStopAllKeepalives also does the appropriate callback for paused
keepalives.
5. Stopping a resumed keepalive stops the correct slot when a second
keepalive is started while the first is paused.
Bug: 281646074
Test: atest FrameworksNetTests
Change-Id: I8925fbe40323dc4584a111d0cf31de016525ef41
In the cases below, the keepalive is already cleaned up internally in
KeepaliveTracker, but are not be cleaned up in
AutomaticOnOffKeepaliveTracker. This means the mAutomaticOnOffKeepalives
list is storing stopped keepalives and the metrics will still conisder
the keepalive as active.
1. In KeepaliveInfo.start, return whether the keepalive is successfully
starting(i.e. mStartedState == STARTING). Check for this in
handleStartKeepalive and return early on failure, without storing the
autoKi. Also check in handleResumeKeepalive.
2. In handleEventSocketKeepalive, return whether the handleStopKeepalive
is called, indicating the keepalive is forced to stop and was not
already STOPPING. This should happen when the state is STARTING but
the network agent returned an unsuccessful event.
3. In handleCheckKeepalivesStillValid, move the checking logic to
AutomaticOnOffKeepaliveTracker so the handleStopKeepalive is called.
Bug: 281646074
Test: atest FrameworksNetTests
Change-Id: I7839464534baed43abbd40b321287132da25b978
