| 58276308709e5568ba2976e93b37211a52589166 |
|
09-Jun-2017 |
Brian Duddie <bduddie@google.com> |
Add debug dump support
Integrate CHRE with the new ASH debug dump implementation to enable
dumping debug info to a place where it will be included in a bugreport.
This is accomplished by implementing the debugDump function in the HIDL
interface in the context hub HAL, and sending a message to CHRE to
retrieve debugging information as a series of strings. CHRE currently
does not put any useful information in this log, only a test string.
Bug: 37640330
Test: load on device with updated SLPI firmware, run
lshal debug android.hardware.contexthub@1.0::IContexthub/default
also, collect a bugreport and confirm that the info shows up in
lshal-debug.txt
Change-Id: Ia841d623b1e581d4435f907700082567edb53769
/system/chre/host/common/host_protocol_host.cc
|
| 4434ba0232d49dfe88b77fd15cb5c7c01ef45427 |
|
23-May-2017 |
Arthur Ishiguro <arthuri@google.com> |
Modify TimeSync flatbuffer schema to send offset
- Initially planned to send AP time, but discovered we can directly
access QTimer register at AP side
- Modifies TimeSync message to send the AP-SLPI time offset
Test: run_sim.sh, runs on device
Change-Id: I5c5d9bc91014fd8498cff821d6a4135d0120e994
/system/chre/host/common/host_protocol_host.cc
|
| b4723e2821f47797fa772249caa93d9e13e06c5f |
|
17-May-2017 |
Arthur Ishiguro <arthuri@google.com> |
Initial framework for time sync flatbuffer msg
- Adds flatbuffer schema for sending AP timestamp
- Adds message handler (does nothing now) in host_link.cc
Test: ./run_sim.sh, runs on device
Change-Id: Ia32d1fc3232246f86856b57107df8d1dc2e4ca19
/system/chre/host/common/host_protocol_host.cc
|
| 2f6b50aa8e01717948efd3024f6ab4f4825c0a18 |
|
15-Apr-2017 |
Andrew Rossignol <aarossig@google.com> |
Support for printing logs via logcat on the host
Test: Run on device, see logs in logcat
Change-Id: I067defab05173b119923a850cdb0bce5b038dd8e
/system/chre/host/common/host_protocol_host.cc
|
| 99f01ac9bd6e351538cb8922ef15d9e838e7339a |
|
06-Apr-2017 |
Brian Duddie <bduddie@google.com> |
Add support for unloading nanoapps
Add the capability for clients on the host to dynamically request the
unloading of a nanoapp. This initial implementation takes measures to
avoid potentially referencing the memory in the nanoapp after it is
unloaded, by flushing events and messages, but does not clean up after
the nanoapp if it leaves a sensor request open, or a timer running, or
doesn't free all of its dynamic memory, etc. As part of ensuring this
safety, CHRE will now prevent a nanoapp that is being unloaded from
sending events or messages just prior to invoking the nanoappEnd
callback.
Add an unload tester nanoapp that unloads the spammer test nanoapp after
a short delay, to help verify that event and message cleanup is handled
appropriately.
Test: run unload tester nanoapp in simulator and on SLPI, use
chre_test_client on SLPI to unload AR
Change-Id: Ib6dbe26b6414e417401412375390ceef5663d4d9
/system/chre/host/common/host_protocol_host.cc
|
| 47a99dc3cacacb0418548609c0e2d3b2b70d821e |
|
27-Mar-2017 |
Brian Duddie <bduddie@google.com> |
Implement dynamic loading of nanoapps
Add support for loading a dynamic shared object containing a nanoapp
that has been received over the communications link with the host.
Test: use chre_test_client to load activity recognition on SLPI
Change-Id: I76da777ec19283ee67120b4b024133c556edf6e2
/system/chre/host/common/host_protocol_host.cc
|
| f685db3a6b34f8dd6942964ae99836bda87c8134 |
|
21-Mar-2017 |
Brian Duddie <bduddie@google.com> |
Support unicast messages from CHRE to host
Tag messages sent to CHRE with the client ID of the sender. Populate
this same value in the response to discriminate the addressee so that
responses are only delivered to the client who sent the request.
Test: run multiple instances of chre_test_client
Change-Id: I60d52944cf4e6cb2bb1fb21e9806eadd7f74b6c2
/system/chre/host/common/host_protocol_host.cc
|
| 07da7d6425058577d477074f99bafd4b8e81bb83 |
|
20-Mar-2017 |
Brian Duddie <bduddie@google.com> |
Use FlatBuffers object API on host
Generate and use the FlatBuffers object API to interact with messages
from CHRE on host-side code. Although it involves some more overhead,
this API is a bit cleaner to use.
Test: run chre_test_client
Change-Id: If48d18999fc2743425bd1ba425a05b8fc5df8efe
/system/chre/host/common/host_protocol_host.cc
|
| a2f5add27054c406f36528cf8a5cbc6d4c79d246 |
|
20-Mar-2017 |
Brian Duddie <bduddie@google.com> |
Add support for querying the list of apps
Add a new FlatBuffers message to encapsulate the list of loaded apps,
and add code to CHRE to populate it. Update the reference HAL
implementation to pass the request and response through the HAL.
Test: run chre_test_client
Change-Id: I7b470daa2f051280fdb5415cdab7297de6ab4d59
/system/chre/host/common/host_protocol_host.cc
|
| 7621b3267fd2ff1068d7aa7d75441d68646226ab |
|
19-Mar-2017 |
Brian Duddie <bduddie@google.com> |
Reorganize HostProtocol, add hub info query
Split HostProtocol into three classes: one for the host, one for CHRE,
and one that's shared. Since the protocol is not fully symmetric (e.g.
messages to/from nanoapps are the same in both directions, but only one
side will ever request hub info, and only CHRE will ever construct the
response), this avoids pulling in unneeded code.
Also, add support for querying hub information from CHRE to be used in
the HAL, and rework the HostLink pending outbound message queue to be
more generic.
Test: run chre_test_client
Change-Id: Id88485b8c5a085eb886d4059840ac640c0383c88
/system/chre/host/common/host_protocol_host.cc
|