send ULP the position mode if it is valid when ULP handle
is first received. This helps handling a race condition
where ULP handshake happens when a GPS session is about
to happen or already happening.
Change-Id: I029e5c3bbb9d8e89b220ca44e9704b5a1d1451ff
CRs-Fixed: 554340
In order to preserve the ordering of
position reports and status reports from
the GPS engine, status reports are sent
through the ULP too
CRS-Fixed: 538143
Change-Id: I41be2121493c6a0b35a5726fd546eb0fa5e9b20c
ULP will no longer be loaded and init'ed from loc eng
HAL. GPS HAL will look for ULP once it completes init
and waits for a msg back once it hears from ULP. This
is done with introduction of UlpProxy. Default proxy
is a no op proxy.
Change-Id: If0be0b5744f9de20f12c2f0b9704dea66aa454c0
(cherry picked from commit 2eb4ddcae94283df6c6be450c4c070ffd8ff9cd7)
Changes can be highlighted with below summary:
* Split the original LocApiAdapter to LocAdapter and LocApi.
Now different adapter implementations can flexibly connect
to different LocApi;
* LocApi continues to abstract the API binding to RPC or QMI;
* MsgTask which creates and owns a msg Q and a thread, and it
define a LocMsg base msg class. The handler pulls a msg out
of the Q and calls its proc() method. This makes it possible
for msg sender to keep the data in the msg encapsulated, as
it no longer requires a central msg handler who must under-
stand all data format. This used to be where all the compile
time dependencies are tangled together;
* Added Context to bundle MsgTask and LocApi;
* Added LocDualContext specifically for the FLP Location Hal
architecture requirement;
* Placed all the base classes of the above in loc_core folder
/ loc_core namespace / libloc_core.so, so other libraries
can easily use derive from here without having to pull in
the loc_eng implementation, which is a large library to
include or link to;
Change-Id: I40abfba96dea76757c98530c1f5e076b34ba4ac7
