|author||Steven Moreland <email@example.com>||Thu Sep 05 14:17:09 2019 -0700|
|committer||Steven Moreland <firstname.lastname@example.org>||Thu Sep 05 14:17:09 2019 -0700|
Remove libhwbinder/libhidltransport deps Since these were combined into libhidlbase. Bug: 135686713 Test: build only (libhwbinder/libhidltransport are empty) Change-Id: I44006c8c3e3e39bc94ed226a299d6355185a2902
Build targets are arranged in the form of a variant triple consisting of:
The vendor is the provider of the CHRE implementation (ex: google, qcom). The arch is the CPU architecture (ie: hexagonv60, x86, cm4). The variant is the target platform (ie: slpi, nanohub, linux, googletest).
A debug build can be obtained by appending
_debug to the variant triple. As an example:
CHRE is compatible with Linux as a simulator.
The simulator has system dependencies:
These are the commands to install these dependencies for Ubuntu:
sudo apt-get install libtclap-dev sudo apt-get install libsndfile1-dev
The build target for x86 linux is
google_x86_linux. You can build/run the simulator with the following command:
You can run all unit tests with the following command. Pass arguments to this script and they are passed to the gtest framework. (example:
CHRE is also compatible with Android as a simulator.
This is not intended to be a production implementation but is suitable for testing CHRE nanoapps on the applications processor where Android runs. It uses Android NDK APIs to interact with the system.
First, setup paths to the Hexagon Tools (v8.x.x), SDK (v3.0), and SLPI source tree, for example:
export HEXAGON_TOOLS_PREFIX=~/Qualcomm/HEXAGON_Tools/8.0 export HEXAGON_SDK_PREFIX=~/Qualcomm/Hexagon_SDK/3.0 export SLPI_PREFIX=~/Qualcomm/msm8998/slpi_proc
Then use the provided Makefiles to build:
make google_hexagonv62_slpi -j
The CHRE project is organized as follows:
Within each of these directories, you may find a
tests subdirectory containing tests written against the googletest framework.
The platform directory contains an interface that common code under
core leverages to implement the runtime. All platforms are required to implement the interface provided in
The following gives a more detailed explanation of the directory structure.
platform- The top-level directory for platform-specific code.
include- The interface that platforms are required to implement.
shared- Code that may be shared by more than one platform but not necessarily required for all.
slpi- The implementation of the common interface for the SLPI and any SLPI-specific code.
linux- The implementation of the common interface for the simulator running on Linux and any simulator-specific code.
Common CHRE code that is expected to run across all platforms is located in
core. This code must have a stable way to access the platform-specific implementation of the common platform API. This is handled by providing a stable include path and changing the search path for the platform implementation. Here is an example directory layout:
The build system will add
platform/<platform_name>/include to the include search path allowing common code to find the implementation of the platform interface. Here is an example of core code including a platform-specific header in this way:
When building for the linux platform, the file is included from:
This project includes a number of nanoapps that serve as both examples of how to use CHRE, debugging tools and can perform some useful function.
All nanoapps in the
apps directory are placed in a namespace when built statically with this CHRE implementation. When compiled as standalone nanoapps, there is no outer namespace on their entry points. This allows testing various CHRE subsystems without requiring dynamic loading and allows these nanoapps to coexist within a CHRE binary. Refer to
apps/hello_world/hello_world.cc for a minimal example.
Any of the nanoapps that end with the term World are intended to test some feature of the system. The HelloWorld nanoapp simply exercises logging functionality, TimerWorld exercises timers and WifiWorld uses wifi, for example. These nanoapps log all results via chreLog which makes them effective tools when bringing up a new CHRE implementation.
This nanoapp implements IMU calibration.
This codebase is intended to be ported to a variety of operating systems. If you wish to port CHRE to a new OS, refer to the
platform directory. An example of the Linux port is provided under
There are notes regarding initialization under
platform/include/chre/platform/init.h that will also be helpful.
Platforms are required to implement support for invoking the constructors and destructors of global, non-POD types at load and unload time, respectively. This is required for both the runtime and nanoapps.
There are many well-established coding standards within Google. The official C++ style guide is used with the exception of Android naming conventions for methods and variables. This means 2 space indents, camelCase method names, an mPrefix on class members and so on. Style rules that are not specified in the Android style guide are inherited from Google.
A CHRE variant allows injecting additional source files into the build on a per-device basis. This can be used to inject:
undefinedif not specified
CHRE_VARIANT_MK_INCLUDES containing the mk files that you wish to be included the CHRE variant build. Refer to
run_sim.sh and the
variant/simulator subdirectory for an example as used by the simulator.
This project uses C++11, but with two main caveats: