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
Legacy metrics are unused and deprecated, so they are being removed.
Therefore, delete the usage of the hidden MetricsLogger API.
Bug: 157966864
Test: atest CtsNetTestCases
atest CaptivePortalTest
atest ConnectivityServiceTest
Change-Id: I51241f5d50ec580015882c84dd917b015c700c7c
Because the constuctor PersistableBundle(Bundle) is a hidden
API which is not visible to connectivity mainline module.
Currently, EVENT_NETWORK_TESTED and EVENT_DATA_STALL_SUSPECTED
are two events sent by ConnectivityService so they can build a
PersistableBundle directly and send PersistableBundle instead of
setting Bundle in the data field of the Message.
For EVENT_NETWORK_TESTED, add a new PersistableBundle member in
ConnectivityReportEvent so that the PersistableBundle can be
passed with ConnectivityReportEvent.
For EVENT_DATA_STALL_SUSPECTED, create a Pair<Long, PersistableBundle>
and put this in .obj of the Message, then the PersistableBundle can be
sent with timestampMillis together.
Bug: 177865050
Test: FrameworksNetTests
Change-Id: Ia2220f33f000e7c9439d97617cc08014dc4478a3
The modification of HdmiCecStandbyModeHandler is for processing
DeviceDiscoveryAction on quiescent boot, where the power status
is POWER_STATUS_STANDBY.
Without the modification,<Device vendor ID> and <Report power status>
are not passed to DeviceDiscoveryAction, and CEC framework cannot
establish device information correctly.
Bug: 174982925
Change-Id: Ie0a7ec3892d5f0a97d192b184454c9bde9f92a09
Check if HotplugDetectAction and PowerStatusMonitorAction exists
before starting them
Bug: 174982925
Change-Id: I5199dc85a15fa3fd5ac5b962eb29d73d2bda6440
The test is currently flaky as broadcasts can take a long time
to be delivered, often more than 500ms.
Extend the timeout for broadcasts to 30s.
Historically the test would wait for broadcasts for at most 500ms,
but not verify that they were received before proceeding. This was
fixed recently by adding an assertion, but the assertion needs to
give enough time for the broadcast to be received.
Bug: 173331190
Change-Id: I0760f3418c635aa4d68de5aefdb7120a9d3e930b
Test: atest FrameworksNetTests
* changes:
Call setUnderlyingNetwork to complete VCN MOBIKE
Rename isRunning to isQuitting, and flip all booleans
Notify Vcn of VcnGatewayConnection quits
Allow NETWORK_LOST disconnections to retry
This fixes a small bug in debug code where the wrong
request would be displayed for RequestReassignment#toString.
Test: manual
Change-Id: Ie8d983593e67082eb818ef65bd8708e97596bce2
