1 What does this document tell? 2 3 This document details how to use the vehicle service if you are implementhing 4 HAL. It lists the various places to look for code and how to build and test the 5 code on your own dev device. 6 7 This code also provides a simple command line utility for the target to test the 8 vehicle HAL. 9 10 What is the code? 11 12 The code is split into folowing logical components: 13 a) hardware/libhardware/include/hardware/vehicle.h - this is the main HAL 14 interface that will be required to be implemented by the OEMs. It includes all 15 documentation necessary to understand what vehicle subsystems are exposed, 16 various units, capabilities and any other relevant details about the HAL design 17 itself. 18 19 b) hardware/libhardware/modules/vehicle/vehicle.c 20 This is a reference implementation for the OEMs to have a peek into getting 21 started with a barebones structure. There are implementation for each of the 22 critical HAL functions such as, get(), set() and subscribe(). 23 24 c) hardware/libhardware/tests/vehicle/vehicle_test.cpp & vehicle_test_fixtures.h 25 These are native tests that can be run on the target to validate basic 26 features of HAL implementation. Things such as loading of HAL and 27 basic functions are implemented (by check if the returned functions are not NULL 28 pointers) can be asserted. It also checks if the subscribe function is doing its 29 job by spitting out data at continuous intervals and printed on the stdout. 30 31 d) hardware/libhardware/tests/vehicle/vehicle-hal-tool.c 32 This tool will provide you with a simple utility which can set commands to the 33 HAL such as: 34 i) Getting a property (and printing its value). 35 ii) Setting a property (and the HAL will take some setting action). 36 iii) Subscribe to a property (and the HAL should send you values at some certain 37 intevals). 38 39 See the usage() function in vehicle-hal-tool.c for details on how to use the 40 binary. 41 42 How to build and run? 43 44 You can build everything by issuing the following from the top of directory. It 45 is assumed that you have done a first run of make from the top level so that 46 intermediates are generated. 47 48 $ croot 49 $ mmm hardware/libhardware 50 51 This will generate the following binaries that we care about: 52 i) out/target/product/XXX/system/lib/hw/vehicle.default.so 53 ii) out/target/product/XXX/data/nativetest/vehicle_tests 54 iii) out/target/product/XXX/system/bin/vehicle-hal-tool 55 56 The location for the first shared library would be: 57 $ adb push out/target/product/XXX/system/lib/hw/vehicle.default.so 58 /system/lib/hw 59 You can also use 'adb sync' if you like, although this is the easiest least 60 hassle way of putting it in place. 61 62 The second binary is a native test - which is nothing but an executable for the 63 target device. You can load it anywhere in your /data directory and run it as: 64 $ adb push out/target/product/XXX/data/nativetest/vehicle_tests 65 /data/tmp/vehicle_tests 66 $ adb shell 67 $ ./data/tmp/vehicle_tests 68 <...output should be spitted with passing tests for atleast the reference 69 implementation ...> 70 71 The last binary is the command line tool, to push the binary on your target do: 72 $ adb push out/target/product/XXX/system/bin/vehicle-hal-tool 73 /data/tmp/vehicle-hal-tool 74
