Currently, NET_CAPABILITY_TEMPORARILY_NOT_METERED traffic is
counted as unmetered data usage, and "mobile data usage"
settings screen shows metered data usage which means it doesn't
include TEMPORARILY_NOT_METERED traffic. However, some carriers
show TEMPORARILY_NOT_METERED data usage in customer's bill which
would be confusing if the data usage in the device shows different
results. Thus, revert the change to avoid confusing.
Bug: 183776809
Test: FrameworksNetTests
Change-Id: I4ef25095462adf30b1ecf82134996739f167930d
In current design, mMatchSubscriberIds can be null which has the
same meaning with empty set, and is not easy to maintain since it
need more checks for this variable when mSubscriberId is null.
Thus make mMatchSubscriberIds NonNull for the maintenance.
Bug: 238843364
Test: build, FrameworksNetTests
Change-Id: I6cfc529b5f4a39ded8598283ff968f2f4d1bc89f
NetworkTemplate.Builder was introduced in Android T and the callers
outside of Connectivity module should use this Builder to build a
template instead. Thus remove the buildTemplate* methods from
NetworkTemplate class. Also, deprecate the methods which are
annotated with @UnsupportedAppUsage and also use Builder to build
the template.
Bug: 238843364
Test: build, FrameworksNetTests
Change-Id: I3190325f6663e4771edf5c7a19bf5ecc7780bf12
Send MdnsServiceInfo on onServiceRemoved callback which include
service name, service type and other info instead of service name
only. These extra info is necessary for service lost callback on
NsdService on the following changes.
Bug: 254166302
Test: atest FrameworksNetTests
Change-Id: Ibacbef4b893209bbc2a37376bf26d713ce41429c
* changes:
Add synchronized to UidRange getter and dump methods
Deal with permission update on handler thread
Running PermissionMonitor#startMonitoring on handler thread
Paul Huauthored and Gerrit Code Reviewcommited 2022-11-23 02:59:17 +00:00
To ensure that permission cannot change while CS is doing works,
scoring networks, sending callbacks, etc. So making all
permission update are running on handler thread.
Bug: 232048835
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I5380ec8ff1282a1056d9063848e0fff8b3a570ec
In current code, the test will call pressHome before show
network notification but it does not verify the home screen
is shown. The test might be failed due to the notification
shade is still opened. Thus adding an assertion to verify
the launcher is shown.
Bug: 255643296
Test: FrameworksNetTest:NetworkNotificationManagerTest
Change-Id: Iee3476a26030b9ba72994dee624e0e6974c9369f
Move VpnTransportInfoTest to common test to add the cts
coverage.
Annotate @ConnectivityModuleTest so that the test will
not fail with module that is not up-to-date, and use
assertParcelingIsLossless to prevent similar order module
in device case.
Bug: 256775913
Test: atest CtsNetTestCases:android.net.VpnTransportInfoTest
Change-Id: I1c40a4fc42468748d71c3df5c18b2ceb5b3769e1
When two devices connected to the same access point run the test
simultaneously, they may find each other when discovering for the same
service type, instead of finding themselves as expected by the test.
Similarly to the service name, use a random service type to avoid that.
Bug: 257459913
Bug: 248121960
Test: atest
Change-Id: I462841fb4331c6e441b74302f6463986472f1340
NSEC records are included as mDNS negative responses, as per
RFC6762 6.1.
Bug: 241738458
Test: atest
Change-Id: I1546a2c10447ad46321f595b714c7ee7f6dc34c7
Refactor this test to make it easier to test the no-op
refactoring coming as a follow-up
Test: this
Change-Id: I47c81bdec2b8f9575835ba664b61721d5f2c69ff
NsdManager may take some time to register a service when the device
hostname is already used on the network, as after probing it needs to
choose another hostname and try again. As the default hostname is
"Android" and the alternatives are "Android-2", "Android-3", ..., this
may take several seconds: RFC6762 8.1 says probing should be 3 packets
with a 250ms interval.
Relax the timeout to 10s, which should allow ~10 conflicts before the
test starts failing; at that point, MDNS isn't reliably testable on the
network.
Bug: 248121960
Bug: 257459913
Bug: 257393724
Test: atest
Change-Id: I31e47787ed9661524edd6b676342fb9a442408a8
In previous CL, the behavior was modified in the module,
but the test was not skipped for T device with unmodified module,
which usually happens in some specific test suites, e.g. wifi MTS.
Move the assertion to another test and annotate with
@ConnectivityModuleTest to indicate that the test needs
to be executed with updated module to prevent from breaking
the test.
Test: atest CtsNetTestCasesLatestSdk:android.net.cts.ConnectivityManagerTest# \
testRegisterNetworkCallback
on tm-qpr-dev devices
Fix: 258471863
Change-Id: Ifb3d1ac45ebde727ad719b45497ab458ad0a4b7a
In most cases, this change will make this test run faster,
as the device isn't processing a lot of broadcasts so the
broadcast queue becomes idle much earlier than 5 seconds
(tests on a Pixel 4A running AOSP indicate ~1 second).
On low-end devices, this will give the device a better
chance to actually pass the test in spite of high load.
The drawback is that this will wait for the broadcast
*queue* to be idle, so for all broadcasts to have been
delivered to all apps, not just the one this test is
interested in. To wit, there will be cases where this
will increase the length of the test. But this should
be a minority of cases.
Test: atest ConnectivityDiagnosticsManagerTest
Bug: 257412943
Change-Id: I84a8929635ee3a587ef2712a59323abe68fda31b
During the test, content of LinkProperties might be changed
according to network conditions, e.g. IPv6 RA, DNS64, etc.
Thus, verify equality of two LinkProperties got in different
time is not reliable and would cause flaky. Change it to
verify with the LinkProperties received from callbacks.
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest
Fix: 254188130
Change-Id: I845940ff6c6defb1887bfda4bcb47f01382b40bc
While the test case was running, if the network condition changes,
e.g. IPv6 RA received, the test case would fail since unexpected
LinkPropertiesChanged event was received, while blockedStatusChanged
event was expected.
Make the test wait for the expected event and ignore others to make
the test more robust.
Test: atest android.net.cts.ConnectivityManagerTest#testBlockedStatusCallback \
--rerun-until-failure 100
Fix: 242833720
Change-Id: Ic3cd47773955d27445511dbd94733f91e3037596
This is a chery-picked commit from internal branch which is to
add nullability to reslove the nullness suppression.
Bug: 242631897
Bug: 254155029
Test: atest FrameworksNetTests
Change-Id: I289b0408c0c4ccdefc498d3b6d3f381c2b04132e
Treehugger Robot
authored and
Gerrit Code Review
commited 
Aaron Huang
commited 
Paul Hu
authored and
Remi NGUYEN VAN
authored and
Chalard Jean
commited 
Chiachang Wang
authored and
Junyu Lai
authored and
Michael Groover
authored and
Maciej Żenczykowski
authored and