NetworkState is becoming an internal implementation class, with
NetworkStateSnapshot replacing it as a proper API. Considering this it
belongs inside Connectivity.
Bug: 174123988
Test: m
Change-Id: I201f1a07c50d9da31e33f5c207875da8863ef57c
Unit test automation validating how multiple default networks are
tracked within ConnectivityService when set by network preferences
used with setOemNetworkPreference() API functionality.
Bug: 178632672
Bug: 172347841
Bug: 170068946
Test: atest FrameworksNetTests
Change-Id: Iae1935944214efaa8a21636c55e6d8be816275f7
Merged-In: Iae1935944214efaa8a21636c55e6d8be816275f7
These methods will be reused for 5G slicing and should
have a more generic name/signature.
This is a no-op refactoring.
Test: FrameworksNetTests
Change-Id: I13cf9fc405fef7dc650d5ea7df44d025f6713b46
IS_USER is a hidden symbol, whereas IS_DEBUGGABLE is part
of the module API.
The check is generally equivalent, as non-user builds are eng or
userdebug, which are debuggable.
Bug: 170598012
Change-Id: I7d09939652844eb2e3a6f0200b1ba50691a147da
Test: atest FrameworksNetTests
When a new OemPreference object is set, the requests
tracking that default will be re-created to track the
new default. This is true regardless of whether that
particular default has changed.
Because the new copied request doesn't know about the
old satisfier, the rematch code will mistakenly think
this callback didn't have a network and will send a
spurious onAvailable to it.
This patch fixes this by simply copying the satisfier
together with the rest of the NRI. The matching code
will then understand the correct previous status.
As a drive-by fix, this also fixes the annotations on
the reassignment contents that can be null. They have
more complex interactions (not everything can be null
at the same time), but the old annotations were just
putting @NonNull on nullable stuff.
In the same line, while there used to be a case with
a satisfier but no request when the satisfier is the
no-service network, there may now be a case where the
old satisfier is known but the old request isn't.
Test: FrameworksNetTests
Test: TODO : need a unit test for this
Change-Id: Ide2567b226722ea9d35ebd8205943363e27647a2
This ends up crashing the system when the request
is unregistered, because the ref counter finds the
count associated with the relevant UID is zero.
Test: FrameworksNetTests
Test: TODO : this needs a new unit test
Change-Id: I0ee0ce925a826d35d8fd58cefb8a870e98ce9add
When a new preferences object is sent that no longer contains
a particular app, a new set of requests will be generated. All
requests corresponding to that app will be unregistered, and
no new ones will be filed since the preferences no longer
contain that app.
The place where the UID ranges are removed however is in
makeDefaultForApps(), which takes a request. As there no
longer is a default request for this app, makeDefaultForApps()
will never be called with a request for it, and the UID ranges
will never be removed.
This change applies an emergency fix with some side effects
when setting a new preference. This is acceptable, but should
ideally be fixed ; see TODO in the code for details.
Test: FrameworksNetTests
Test: TODO : Need a unit test for this
Change-Id: Iac3f55af5d00d174460e1d4cdd31f581835dbaa6
Currently, battery stats service uses noteConnectivityChanged in
connectivity service(CS) to pass connection state and the type of
connection for BatteryStats. However, CS is going to be a mainline
module which can only access formal API. noteConnectivityChanged
is a hidden API and it pass LegacyNetworkType which has been
deprecated years ago, so it should avoid to expose this API with
a deprecated argument. Thus, register a NetworkCallback in
BattyeryStatsService to listen the network capabilities changed to
remove the noteConnectivityChanged from connectivity service.
Besides, let noteConnectivityChanged take display transport instead
of legacy network type.
Bug: 171686421
Test: atest FrameworksNetTests
atest FrameworksCoreTests:BatteryStatsTests
(cherry-picked from ag/13749983)
Change-Id: I3dac94ec06f673aa719e124f1ef3d8169f68f9fb
Merged-In: I3dac94ec06f673aa719e124f1ef3d8169f68f9fb
