Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1780
This PR is [not ready] for review.
Risk
This PR makes [no] API changes.
Testing Plan
Unit Tests
N/A
Core Tests
[List of tests performed against Core and behaviors verified]
Core version / branch / commit hash / module tested against: [INSERT]
HMI name / version / branch / commit hash / module tested against: [INSERT]
Summary
In
SdlDeviceListener
thebluetoothTransport
andbluetoothHandler
are only initialized if the device has not connected previously. In the event that the device has connected before thebluetoothTransport
is not initialized because we get the relevant data from the shared preferences. If this is the casebluetoothTransport
will not be initialized and will be null. If this is the case thevehicleInfo
will be retrieved from the shared preferences instead and the logic to retrieve the vehicleData from the startServiceACK is not needed.in
SdlDeviceListener
theonPacketRead
method will be called when the StartServiceACK is received. This will later callnotifyConnection
which will try to stop thebluetoothTransport
if the RFCOMM channel should not remain open. If this is the case after stoping thebluetoothTransport
it will then be set to null. When this happens we should also set thebluetoothHandler
to null as we no longer want itshandleMessages
method to be called. This will prevent the case wherenotifyConnection
is called while thebluetoothTransport
is nullIn
onPacketRead
we are already performing a null check before writing to thebluetoohTransport
. Since it is possible thatbluetoothTransport
is null whennotifyConnection
is called we should also check for null before callingbluetoothTransport.stop()
.CLA