| What does this document tell? |
| |
| This document details how to use the vehicle service if you are implementhing |
| HAL. It lists the various places to look for code and how to build and test the |
| code on your own dev device. |
| |
| This code also provides a simple command line utility for the target to test the |
| vehicle HAL. |
| |
| What is the code? |
| |
| The code is split into folowing logical components: |
| a) hardware/libhardware/include/hardware/vehicle.h - this is the main HAL |
| interface that will be required to be implemented by the OEMs. It includes all |
| documentation necessary to understand what vehicle subsystems are exposed, |
| various units, capabilities and any other relevant details about the HAL design |
| itself. |
| |
| b) hardware/libhardware/modules/vehicle/vehicle.c |
| This is a reference implementation for the OEMs to have a peek into getting |
| started with a barebones structure. There are implementation for each of the |
| critical HAL functions such as, get(), set() and subscribe(). |
| |
| c) hardware/libhardware/tests/vehicle/vehicle_test.cpp & vehicle_test_fixtures.h |
| These are native tests that can be run on the target to validate basic |
| features of HAL implementation. Things such as loading of HAL and |
| basic functions are implemented (by check if the returned functions are not NULL |
| pointers) can be asserted. It also checks if the subscribe function is doing its |
| job by spitting out data at continuous intervals and printed on the stdout. |
| |
| d) hardware/libhardware/tests/vehicle/vehicle-hal-tool.c |
| This tool will provide you with a simple utility which can set commands to the |
| HAL such as: |
| i) Getting a property (and printing its value). |
| ii) Setting a property (and the HAL will take some setting action). |
| iii) Subscribe to a property (and the HAL should send you values at some certain |
| intevals). |
| |
| See the usage() function in vehicle-hal-tool.c for details on how to use the |
| binary. |
| |
| How to build and run? |
| |
| You can build everything by issuing the following from the top of directory. It |
| is assumed that you have done a first run of make from the top level so that |
| intermediates are generated. |
| |
| $ croot |
| $ mmm hardware/libhardware |
| |
| This will generate the following binaries that we care about: |
| i) out/target/product/XXX/vendor/lib/hw/vehicle.default.so |
| ii) out/target/product/XXX/data/nativetest/vehicle_tests |
| iii) out/target/product/XXX/system/bin/vehicle-hal-tool |
| |
| The location for the first shared library would be: |
| $ adb push out/target/product/XXX/vendor/lib/hw/vehicle.default.so |
| /vendor/lib/hw |
| You can also use 'adb sync' if you like, although this is the easiest least |
| hassle way of putting it in place. |
| |
| The second binary is a native test - which is nothing but an executable for the |
| target device. You can load it anywhere in your /data directory and run it as: |
| $ adb push out/target/product/XXX/data/nativetest/vehicle_tests |
| /data/tmp/vehicle_tests |
| $ adb shell |
| $ ./data/tmp/vehicle_tests |
| <...output should be spitted with passing tests for atleast the reference |
| implementation ...> |
| |
| The last binary is the command line tool, to push the binary on your target do: |
| $ adb push out/target/product/XXX/system/bin/vehicle-hal-tool |
| /data/tmp/vehicle-hal-tool |