LocIpc client apps such as garden app is unable
to delete LocIpc object since its socket listening
thread cannot be closed while it is waiting for
data and cannot be closed. Fixed to close it by
sending an abort message.
CRs-Fixed: 2213212
Change-Id: I95f26862e9faf7bd75a2f447421ba4ab7220576e
LocIpc client apps such as garden app is unable
to delete LocIpc object since its socket listening
thread cannot be closed while it is waiting for
data and cannot be closed. Fixed to close it by
sending an abort message.
CRs-Fixed: 2213212
Change-Id: I95f26862e9faf7bd75a2f447421ba4ab7220576e
GNSS Time estimate shown in Gnss debug report
is incorrect. It always shows default value
instead of value delivered by PQWM1 message.
Change-Id: Iff471613ac6fa25d213c14b543871b6c3ae7af0a
CRs-Fixed: 2235219
GNSS Time estimate shown in Gnss debug report
is incorrect. It always shows default value
instead of value delivered by PQWM1 message.
Change-Id: Iff471613ac6fa25d213c14b543871b6c3ae7af0a
CRs-Fixed: 2235219
GNSS Time estimate shown in Gnss debug report
is incorrect. It always shows default value
instead of value delivered by PQWM1 message.
Change-Id: Iff471613ac6fa25d213c14b543871b6c3ae7af0a
CRs-Fixed: 2235219
There are a couple of issues. NetworkInfoDataItemBase
objects might be from OsAgent or GnssLocationProvider.
The two sources actually have mTypes defined differently.
In addtion, when there are different types of connections
such as wifi / mobile, getting connected / disconnected
independently, clients need to be all notified correctly.
Right now, if mConnected hasn't changed, no updates are
send. For exmple, if mobile is connected, later wifi
gets connected too, clients won't know.
SystemStatus is also updated to get updated / colated
informtion. In the above example, SystemStatus's top
record would record as both mobile and wifi are connected.
Change-Id: I1825902247fe1d4e6363f5e24a75be7e984d0dc4
CRs-Fixed: 2221114
to allow clients to subscribe before subscription obj
arrives, and also simplified ClientIndex and DataItemIndex
implementation significantly.
Change-Id: I092f344e688fa698aa98795b8a8f0c1ba8fcd9e4
CRs-Fixed: 2218519
mAGnssCbIface is a static C++ obj, which ctor may not get
called at load time, but its memory block will only be 0'ed
out.
Change-Id: Ie275f916a01c5eb3bf0a7cfa71b19fe4e0d3e879
CRs-Fixed: 2190347
Include intermediate location fix info in gnss
debug report that is cached in SystemStatus in
addition to final fixes, so that the gnss debug
report should always hold the latest information.
Change-Id: I60aef92cf6d143a1b4f4b510ca2113887d051dcc
CRs-Fixed: 2230415
Include intermediate location fix info in gnss
debug report that is cached in SystemStatus in
addition to final fixes, so that the gnss debug
report should always hold the latest information.
Change-Id: I60aef92cf6d143a1b4f4b510ca2113887d051dcc
CRs-Fixed: 2230415
Include intermediate location fix info in gnss
debug report that is cached in SystemStatus in
addition to final fixes, so that the gnss debug
report should always hold the latest information.
Change-Id: I60aef92cf6d143a1b4f4b510ca2113887d051dcc
CRs-Fixed: 2230415
1. LocApiBase to create its own MsgTask thread to allow QMI calls
to be made asynchronously. It shall no longer share the adapter's thread.
2. Implementation of new LocApiResponse classes for generic response type
from LocApi layer to Adapter layers
3. GnssAdapter modified to handle the asynchronous nature of LocApi calls.
CRs-Fixed: 2218658
Change-Id: I6e401a89f16791ec144763ac5f070b7ee1dad931
The event mask can be retrieved in the context of
client thread as zero and then queued up to go to
msg task thread. By the time the msg is actually
handled in msg task thread, the actual event
mask at LOC API layer may have already changed, but
this mask would then be overridden by zero. This
can cause no modem events to ever come, including
position reports.
The fix is to not retrieve the event mask in the
client thread, but instead wait for msg to be
handled in msg task thread before retrieving it.
Change-Id: I48562d028bbfa187732686c060b5cdd62c6d5a89
CRs-fixed: 2219519
Change default values for accuracies and
uncertainties in GNSS Debug Data to non-
zero constant values.
Bug: 72753638
Change-Id: I075b364ed81c8a466b062ab4d5381c3d4ece1ea6
CRs-Fixed: 2185247
1: GNSS adapter change to block out position and SV report from
ULP when engine hub aggregator is used
2: Support unpropagated position report
Change-Id: Id0cacd87d3f3f8eec893d751b9f7a55a736a4023
CRs-fixed: 2210253
to allow clients to subscribe before subscription obj arrives,
and also simplified ClientIndex and DataItemIndex implementation
significantly.
Change-Id: I092f344e688fa698aa98795b8a8f0c1ba8fcd9e4
CRs-Fixed: 2218519
1. LocApiBase to create its own MsgTask thread to allow QMI calls
to be made asynchronously. It shall no longer share the adapter's thread.
2. Implementation of new LocApiResponse classes for generic response type
from LocApi layer to Adapter layers.
3. GnssAdapter modified to handle the asynchronous nature of LocApi calls.
CRs-Fixed: 2218658
Change-Id: I6e401a89f16791ec144763ac5f070b7ee1dad931
1: GNSS adapter change to block out position and SV report from
ULP when engine hub aggregator is used
2: Support unpropagated position report
Change-Id: Id0cacd87d3f3f8eec893d751b9f7a55a736a4023
CRs-fixed: 2210253
The event mask can be retrieved in the context of
client thread as zero and then queued up to go to
msg task thread. By the time the msg is actually
handled in msg task thread, the actual event
mask at LOC API layer may have already changed, but
this mask would then be overridden by zero. This
can cause no modem events to ever come, including
position reports.
The fix is to not retrieve the event mask in the
client thread, but instead wait for msg to be
handled in msg task thread before retrieving it.
Change-Id: I48562d028bbfa187732686c060b5cdd62c6d5a89
CRs-fixed: 2219519
Map velocity and system time fields from GpsLocationExtended to
GnssLocationInfoNotification
Change-Id: If53575213de575ad71b68018beb8c3f5fd587bcf
CRs-fixed: 2184592
