When the avoidBadWifi configuration is false and not overridden,
a WiFi network that was validated in the past but becomes
unvalidated needs to outscore a cell network that is validated.
This is happening correctly when the stack compares two networks.
However, when the stack compares an existing network to an offer
for a cellular network, the offer was automatically considered
not to yield. This would mean the stack would be requesting cell
out of the telephony factory, only for that network to lose to
WiFi and be discarded immediately, then recreated again etc.
When there is some other reason cell should be up (such as the
"mobile always on" setting being active), this would not be
visible because the cell network would have another reason not
to be torn down.
Have offers correctly account for the current value of the
configuration and setting. This has the ranking of the offer
lose against WiFi like the actual network loses, meaning the
offer is not needed.
This also requires updating the offers whenever the value of
the setting changes.
Test: new test for this, also ConnectivityServiceTest
Bug: 195441367
Change-Id: I4fe5de98bc15bcf9bbbe25c6c7c8a7ba382f8db7
Currently, when a VPN app calls registerDefaultNetworkCallback,
it will always get its own VPN, even if the VPN app called
VpnService.Builder#addDisallowedApplication to take itself out
of the VPN's UID ranges.
Add a test for the current incorrect behaviour.
Also fix an indentation error elsewhere.
Bug: 195265065
Test: test-only change
Change-Id: Id9648ea71fc7ae10855aa311beeb7975569d17f2
testAvoidBadWifi could pass without issue. The refactor should
also be done. The test does not need to be ignored now. Remove
the annotation to bring the test coverage back.
Bug: 178071397
Test: atest ConnectivityServiceTest
Change-Id: I5652fa817f16b8c241f1e2066a0b04ad2156a3b7
The resolverOptions member of the ResolverParamsParcel has never
been set by AOSP code but was only used by OEMs modifying
DnsManager. Now that DnsManager is mainline code, this is no
longer possible. So the DNS resolver introduces a new
setResolverOptions IPC to allow OEMs to set the options and makes
the resolverOptions nullable.
Make DnsManager set resolverOptions to null, to ensure that when
DnsManager calls setResolverConfiguration, it does not overwrite
any options set by the OEM.
Bug: 194048056
Test: Device boots and has connectivity
Change-Id: I310a79521f5a365e50e2c65e9dd87d9b68f105d7
Add an option to display the no internet dialog directly instead of
showing a notification when the notification would have been high
priority (typically when the network was explicitly selected). This is
disabled by default, but allows device manufacturers to use a slightly
more disruptive UX to ensure that the user is aware that the network has
no connectivity, and can take action.
Also add an option to show the same notification as "no internet"
instead of the "partial connectivity" notification. This is also
disabled by default, but allows device manufacturers to use the "no
internet" text if they feel that "partial connectivity" text is hard
to understand for the user.
Bug: 193847396
Test: atest NetworkNotificationManagerTest
Change-Id: Ib5bd74d8cf973bf70d373dd63648c178fae0ebae
DisplayMetrics are used in some downstream branches and need to be
mocked. This avoids merge conflicts in NetworkNotificationManagerTest.
Partial cherry-pick of change IDs:
I35d28c8df341dbbac2774026c6ca749e296c0482
I1aeed1c79e4a829d8829eb08224f9b21fafc50fe
Test: atest NetworkNotificationManagerTest
Bug: 176239013
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: I118ec1af615aef36293bf0b480389f766122ccab
The crash occurs when some app has more than half its limit
in requests that will need to be moved to some other default
network upon changing the preferences.
This will send the requests for this app over the limit
temporarily when creating new requests for the reevaluated
ones.
While ConnectivityService has a provision for making a
transaction-like addition/removal of requests that is meant
to avoid exactly this kind of crash with the transact()
method on PerUidCounter, the code only transacts on
mSystemNetworkRequestCounter. But these requests are counted
in the mNetworkRequestCounters, which is not part of the
transaction, causing the crash anyway.
To avoid the problem, this patch allows the request counters
to go over the max if and only if the system server is
updating the request counts for a UID other than its own.
This should allow only the case where ConnectivityService is
moving the requests over to the new per-uid default, while
keeping the exception when registering from an app (then the
calling UID is not the system server), or when the system
server registers its own requests (then the UID inside the
request is that of the system server).
A much better solution than this patch would be to completely
eliminate the transact() method by somehow unregistering the
old ones before creating the new ones.
However this would be a much bigger and difficult patch than
this, and much more dangerous, because callers depend on the
list of requests to find out the old requests to remove, so
they have to be created first.
Another possible clean solution would be to count the
requests not in the NRI constructor, but later. This would be
more error-prone though because it would be very easy to
create an NRI without counting it.
Bug: 192470012
Test: ConnectivityServiceTest. Improve tests so they catch
this case.
Change-Id: Ia482e6fbf2bf300ce6cbaca72810d394ed201b98
- This is a no-op refactor for reducing duplicated code.
- Add a global NetdMonitor which can use for every test.
- Statically import INetd permissions.
Bug: 189705071
Test: atests FrameworksNetTests
Change-Id: I78f4b46cce16ea7e25b67cf2e9470cb09f1c3e75
The scenario is as follows : an app registers a network callback,
then unregisters it and dies immediately after. In this scenario,
the system server will receive a notification of the binder death
and enqueue a call to handleRemoveNetworkRequest. If the callback
unregister message has been process first, this call would result
in unlinkToDeath being called twice on the same Binder, crashing.
This patch fixes the problem by using handleReleaseNetworkRequest
instead of Remove, which looks up the NRI in a map on the handler
thread before calling Remove, returning without doing anything if
the NRI has already been removed.
Test: ConnectivityServiceTest
Test: New test for this
Bug: 194394697
Change-Id: I82a28c37450146838410bf5a059aac295a985fca
Instead of jarjaring the whole com.android.internal.util package, apply
the jarjar rules per-class. Jarjaring the whole package causes problems
in tests, as for example ConnectivityServiceTest depends on Vpn that
uses other internal utils as hidden API, and these should not be
jarjared.
Also avoid jarjaring INetdUnsolicitedEventListener which is used by
NetdEventListenerServiceTest, and ensure KeepalivePacketDataUtilTest
expects the right package name in toString.
Generally the problems appear because ConnectivityCoverageTests also
includes tests for classes that are not part of the connectivity module,
and use hidden APIs that refer to classes that should not be jarjared.
Some of the tests could be excluded from the coverage suite instead, but
keeping them is helpful for future modularization efforts.
Test: Build service-connectivity, dexdump classes and verify jarjared
atest ConnectivityCoverageTests
Change-Id: Id6b7e6833d49fa03d9442d7c1c3e4dc16fb48dfc
The hypothesis here is that some other thread is using
the mock between the call to when() and the call to
.thenReturn() a few lines above the failure. It's not
clear this is really the reason, but using this syntax
is safer anyway, so whether it fixes the issue or not
this is a good change.
Test: m FrameworksNetTests
Change-Id: I501d2ec8e794c67a53d7c84e290e4cc63481472d
Internal utils are generally jarjared by connectivity jarjar rules, but
ArrayUtils is not actually statically linked into the tests, so this
makes the ConnectivityCoverageTests fail. FrameworksNetTests has been
fine because it does not use jarjar, but does not exercise updated code
because of that.
Remove usage of the hidden utility, as there are reasonable alternatives
with non-hidden APIs that avoid other breakages long-term.
Bug: 187935317
Test: atest ConnectivityCoverageTests:ConnectivityServiceTest
Change-Id: I8ed85b941c3d1028771a5ac33196b1509a95789d
This CL updates ConnectivityService to do null checks on received
parameters when registering and unregistering ConnectivityDiagnostics
callbacks (and also when simulating Data Stalls).
Bug: 181583568
Test: atest ConnectivityServiceTest ConnectivityDiagnosticsManagerTest
Change-Id: I7f297f10bf8d379a5d33ca5e11ca1e12132ba3a5
- Add a new transport type for USB and a new network capability
to support automotive head unit.
- In order to pass DnsManagerTest#testTransportTypesEqual, Android.bp
needs to link to dnsresolver_aidl_interface-V8-java. That test checks
whether the TRANSPORT types defined in NetworkCapabilities are the
same as IDnsResolver.aidl.
(clean cherry-pick of change in downstream branch history, original
change ID before project move:
Iec2df09a776d779108f95098e01b7ffdf6f8867a)
Bug: 181742019
Test: atest FrameworksNetTests
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ie438ec68577ebdaaf990795fa27f1169b0105411
- Each network preference has been assigned a priority value so
that netd can know which uid range rule has higher priority. So
remove the restriction that all network preferences are
exclusive.
- Add priority check when getting request for uid.
Bug: 171872461
Test: atest FrameworksNetTests
(cherry-pick from ag/14731887)
Merged-In: I6912db753c8b4a194aa7af92b01ca6dcfec10d8b
Change-Id: I6912db753c8b4a194aa7af92b01ca6dcfec10d8b
Replace network[Add|Remove]UidRanges to
network[Add|Remove]UidRangesParcel. The new methods are passing
NativeUidRangeConfig which contains priority value for each uid
range rules.
Bug: 171872461
Test: atest FrameworksNetTests
Test: atest HostsideVpnTests
(cherry-pick from ag/14911836)
Merged-In: I08bbdbcb8450b08e6208fa730137348550f9e3d2
Change-Id: I08bbdbcb8450b08e6208fa730137348550f9e3d2
The internal structure backing getAllNetworks is updated after
invoking lost callbacks, so the test needs to wait for the handler
to be idle before calling getAllNetworks.
Also avoid assertions in finally clauses, as it causes confusing
error messages.
Bug: 185081944
Change-Id: I8ad5ab45a3e65b0031672e6f594b1a6d6ad5abcb
Test: atest ConnectivityServiceTest
The test relied on waitForIdle to ensure diagnostics callbacks were called,
but as this may require several iterations in the handler queue, this makes
the test unreliable.
Use mockito timeouts on the verify() calls instead.
Bug: 192651465
Change-Id: Iae1704af7ae3649eae301c6aee223ac753629d55
Test: atest ConnectivityServiceTest
Replace all FIRST_SDK_INT usage in Connectivity because it has
been renamed to DEVICE_INITIAL_SDK_INT.
Bug: 184735771
Test: m CtsNetTestCases
Merged-In: I2f155592b08cdbf259a00b035cacb37ca9847e72
(clean cherry-pick)
Change-Id: I2f155592b08cdbf259a00b035cacb37ca9847e72
- Some applications are installed on external storage and they
are unavailable until exernal storage installed them
completely. And their permission need update after becoming
available. Thus, listen EXTERNAL_APPLICATIONS_AVAILABLE intent
and update those package whose is listed in chaged package
list.
- Remove user argument on buildPackageInfo() because the uid on
ApplicationInfo is based uid.
Bug: 145234989
Test: atest FrameworksNetTests
Merged-In: Ia11ca4a7ba6fc1b87c27c0c40e36c91d9cdb322a
Change-Id: Ia11ca4a7ba6fc1b87c27c0c40e36c91d9cdb322a
Certain network types, like the VCN, have underlying
networks for the purpose of data usage, but do not want to
propagate the underlying network capabilities.
Allow these networks to set underlying networks, but continue
not to propagate the capabilities.
Bug: 190620024
Test: new unit test
Change-Id: I53d6080f48707ff3c37fbfbef534284ba77a7432
This change adds relevant tests for the migrateTun functionality in
NetworkStats.
Bug: 190620024
Test: atest NetworkStatsTest
Change-Id: I33f14f2d0f71013a594fd4c8c3914a590d30ea06
The utilities are part of com.android.internal.util, but were
historically tested as part of the services.net tests. They were then
mistakenly moved to packages/modules/Connectivity with the rest of the
networking code, but actually belong in coretests.
Bug: 187935317
Test: atest FrameworksCoreTests
Change-Id: I74702f6a4d9bed5985d2a830dacd78129a7854a8
This CL updates ConnectivityDiagnostics to report
NETWORK_VALIDATION_RESULT_SKIPPED when the platform does not validate
the reported Network. This CL also updates the behavior for
ConnectivityManager#reportNetworkConnectivity, such that it will always
generate a ConnectivityReport on the reported network. If the reported
connectivity does not match the known connectivity of this network, the
network is revalidated and a report is generated. Otherwise,
revalidation is not performed and the cached ConnectivityReport is sent
instead.
This CL also updates ConnDiags behavior for calls to
ConnectivityManager#reportNetworkConnectivity. Specifically, ConnDiags
callbacks are only notified for these calls if:
a) the call causes the Network to be re-validated, or
b) the callback registrant was the caller of
#reportNetworkConnectivity().
For b), the caller is always guaranteed to receive a ConnectivityReport
(a fresh report if the Network is re-validated, else the cached report).
Bug: 162407730
Test: atest FrameworksNetTests ConnectivityDiagnosticsManagerTest
Change-Id: I78b78919d5b0f09348dfdd5fdb37418b8c7f861f
