Core platform API stubs are now correctly included in module_current and
system_server_current, so workarounds used to use such APIs can be
removed.
OsCompat and InetAddressCompat were only necessary because manually
adding the stubs did not resolve the problem for classes that had
public API stubs, which shadowed the module API stubs.
The manual stubs dependency was already removed in another change. Also
remove the service jar dependency on android_system_server_stubs_current
as it is already included in sdk_version system_server_current.
Bug: 183097033
Test: atest CtsNetTestCases
Change-Id: Id448be03b679f832edb24f1b77f471227faf5268
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
Allow overlays to change the connectivity notification icons, and
whether the notifications are auto-cancelled.
This does not change default behavior, but is necessary to allow vendors
to adapt the notifications to their standards.
Bug: 173171709
Bug: 172048052
Test: atest NetworkNotificationManagerTest
Added test overlay, verified icon replaced
Change-Id: Ibbb765a5e828b8b870cbfb81e89df2dbd2828be7
Previously, the return condition in stop() will check if the state
is STOPPING and the reason is ERROR_INVALID_NETWORK. The condition
is too restricted so that if another event is happened after binder
died, the exception will be thrown and crash the system.
Since calling stop() twice doesn't make sense, so relax the condition
of return when the state is STOPPING.
Bug: 182586681
Test: atest FrameworksNetTests
Change-Id: I2454c1c080d8954dd3785d4ac6e96fc4131fdb47
- If Mobile data always on is OFF, mobile data preferred uids
feature does not work.
- We need to request mobile data when MDO list is not empty.
Bug: 171872461
Test: atest FrameworksNetTests
Test: atest CtsNetTestCases
Signed-off-by: Ansik <ansik.shin@samsung.com>
Change-Id: Ie9d6b3e39ef16813c4be3979900d226c8f3d656d
Currently, ConnectivityService uses EVENT_REGISTER_NETWORK_LISTENER
to dispatch registering network callback with pending intent, this
is wrong since the code flow will not check if the pending intent
is duplicated. Thus, the registration will be duplicated if the
caller uses the same pending intent and register multiple times.
This change fixes the logic by using
EVENT_REGISTER_NETWORK_LISTENER_WITH_INTENT instead of
EVENT_REGISTER_NETWORK_LISTENER when dispatching register network
callback with pending intent.
Test: atest android.net.cts.ConnectivityManagerTest#testRegisterNetworkRequest_identicalPendingIntents
Test: atest android.net.cts.ConnectivityManagerTest#testRegisterNetworkCallback_identicalPendingIntents
Test: atest ConnectivityServiceTest#testNetworkCallbackMaximum
Test: 1. Use test app to file callback with same PendingIntent
2. Check dumpsys output
Bug: 189868426
Change-Id: I38bdea3a026a78a6dc34b5200d43a75b3cd1ac0c
Add an overlay boolean that allows setting the SIGN_IN notification as
an ongoing notification.
This can be useful to make sure users can always easily find the
notification to sign in to a captive portal, as studies have found that
some users have a tendency to dismiss notifications before reading them.
At the same time the notification shade is generally too crowded, which
is what causes such behaviors in the first place, so this option is not
enabled by default and should generally not be enabled without proper
user studies or metrics.
Bug: 173171709
Test: atest NetworkNotificationManagerTest
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ic187d2a2b7e49ad152ea2aa35bb784864b97473c
In S ConnectivityService was changed to use getActiveRequest() to fill
EXTRA_NETWORK_REQUEST, but there is no active request in the case of
listens.
When getActiveRequest() is missing, use the first mRequest instead. This
should match previous behavior.
Bug: 191713869
Test: atest android.net.cts.ConnectivityManagerTest
Change-Id: Id7343a4cc020aba16b7979b16334721c56b2839c
Yielding cell wins to exiting wifi (whether good or bad).
It loses to bad wifi that's not exiting.
In R, yielding to bad wifi only affects wifis that are
unvalidated, but a wifi that is exiting should still be
dropped in favor of a cell that yields to bad wifi.
I had misunderstood the policy and implemented it wrong.
Now it's implemented right, and has careful tests.
Test: new tests for this
Bug: 186458024
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: Ib8637100d491e72a2edb837584ce55b7dda58524
Change-Id: Ib8637100d491e72a2edb837584ce55b7dda58524
(cherry-picked from ag/14486203)
ConnectivityManager.setAvoidUnvalidated only works if the
config_networkAvoidBadWifi configuration is set to 0 and the
NETWORK_AVOID_BAD_WIFI setting is unset. There is no easy way
for a testing app to temporary set a test value to verify the
behavior of the API. Thus, add a mechanism to allow test app
to set a period of time to temporary unstrict the resource
configuration, i.e. Temporary simulate config_networkAvoidBadWifi
configured to 0.
Bug: 186061922
Test: atest CtsNetTestCases FrameworksNetTests
Change-Id: If772078c61a9b12926f104d5dfc9c9071e844732
Multiple user's ares of mApps are not initialized in startMonitoring(),
so mApps.get(uid) of multi-user's app returns null in onPackageAdded().
As the result, permission of system uid is updated to "Network" and
any system application cannot use dedicated apn like IMS.
Using appId avoids this problem.
Bug: 168932048
Test: atest FrameworksNetTests
Signed-off-by: Sangcheol Lee <goodsc.lee@samsung.com>
Change-Id: Ib8ea2185d8056bddb2ca5a8006f83afb3cffc9f4
To allow unit tests to run without platform certificates, remove
signature permission usage in ConnectivityServiceTest.
This mocks permission checks done in ConnectivityService for which the
test assumed that the permission was held, and mocks calls to
BatteryStatsManager. Calls to ActivityManagerService (through
PendingIntent) are done with shell permissions as the test uses real
PendingIntent mechanics.
Bug: 187935317
Test: atest FrameworksNetTests
Change-Id: If309d653ac2e9bbcf1b94bcee6336367289df359
- Add default network priority to NetworkRequestInfo.
- The default network priority value is used when issue uid
ranges rules to netd. Netd will use the priority value and uid
ranges to generate corresponding ip rules specific to the given
network preference.
Bug: 171872461
Test: atest FrameworksNetTests
Merged-In: I0ea71b348492aeb4784d487bed4cfd5d387426ba
Change-Id: I0ea71b348492aeb4784d487bed4cfd5d387426ba
- Add more tests for mobile data preferred uids.
- Also address leftover comments on implementation commit.
Bug: 171872461
Test: atest FrameworksNetTests
Merged-In: I63f65bffc1b8883ddfd774222e26e629d7ea1f94
Change-Id: I63f65bffc1b8883ddfd774222e26e629d7ea1f94
Currently, when a network that uses 464xlat is torn down,
NetworkCallbacks will receive onLinkPropertiesChanged after
onLost. This is confusing and incorrect.
The incorrect callback is sent because handleLinkProperties
checks that the netId of the agent still exists, not that the
NetworkAgent is still registered. This is normally correct,
because the NetworkAgent is removed from mNetworkAgentInfos and
the netId are removed from mNetworkForNetId by the same method,
disconnectAndDestroyNetwork.
In this specific case it's not correct, because the call to
handleUpdateLinkProperties is from disconnectAndDestroyNetwork
itself via nai.clatd.update and calls Nat464Xlat#stop.
No other callers of handleUpdateLinkProperties are affected
because:
- EVENT_NETWORK_PROPERTIES_CHANGED is called only by
maybeHandleNetworkAgentMessage, which first checks that the
NetworkAgent is registered.
- handlePrivateDnsSettingsChanged only looks at registered
NetworkAgents (it loops over mNetworkAgentInfos).
- handlePrivateDnsValidationUpdate, handleNat64PrefixEvent and
handleCapportApiDataUpdate call getNetworkAgentInfoForNetId,
which will correctly determine that the agent is no longer
registered, since they run on the handler thread and thus
cannot run at the same time as disconnectAndDestroyNetwork.
The existing code contains a check for the netId being current.
This is intended to ensure that an update from a NetworkAgent
cannot affect another agent with the same Network. This extra
check is not necessary, because code running on the handler
thread can never observe a NetworkAgent in mNetworkAgentInfos
unless mNetworkForNetId maps that NetworkAgent's Network to that
NetworkAgent. This is because mNetworkForNetId is updated by the
same methods as mNetworkAgentInfos, and those updates occur on
the handler thread. So all code on the handler thread will see
those two as consistent.
Bug: 176496580
Test: atest FrameworksNetTests CtsNetTestCases HostsideVpnTests
Original-Change: https://android-review.googlesource.com/1727829
Merged-In: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
Change-Id: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
