platform_hardware_interfaces/sensors/1.0/default/Android.bp

64 lines
1.4 KiB
Text
Raw Normal View History

cc_library_shared {
name: "android.hardware.sensors@1.0-impl",
defaults: ["hidl_defaults"],
proprietary: true,
relative_install_path: "hw",
srcs: ["Sensors.cpp"],
shared_libs: [
"liblog",
"libcutils",
"libhardware",
"libbase",
"libutils",
"libhidlbase",
"libhidltransport",
"android.hardware.sensors@1.0",
],
static_libs: [
"android.hardware.sensors@1.0-convert",
"multihal",
],
local_include_dirs: ["include/sensors"],
}
cc_library_static {
name: "android.hardware.sensors@1.0-convert",
Mark as vendor_available By setting vendor_available, the following may become true: * a prebuilt library from this release may be used at runtime by in a later releasse (by vendor code compiled against this release). so this library shouldn't depend on runtime state that may change in the future. * this library may be loaded twice into a single process (potentially an old version and a newer version). The symbols will be isolated using linker namespaces, but this may break assumptions about 1 library in 1 process (your singletons will run twice). Background: This means that these modules may be built and installed twice -- once for the system partition and once for the vendor partition. The system version will build just like today, and will be used by the framework components on /system. The vendor version will build against a reduced set of exports and libraries -- similar to, but separate from, the NDK. This means that all your dependencies must also mark vendor_available. At runtime, /system binaries will load libraries from /system/lib*, while /vendor binaries will load libraries from /vendor/lib*. There are some exceptions in both directions -- bionic(libc,etc) and liblog are always loaded from /system. And SP-HALs (OpenGL, etc) may load /vendor code into /system processes, but the dependencies of those libraries will load from /vendor until it reaches a library that's always on /system. In the SP-HAL case, if both framework and vendor libraries depend on a library of the same name, both versions will be loaded, but they will be isolated from each other. It's possible to compile differently -- reducing your source files, exporting different include directories, etc. For details see: https://android-review.googlesource.com/368372 None of this is enabled unless the device opts into the system/vendor split with BOARD_VNDK_VERSION := current. Bug: 36426473 Bug: 36079834 Test: m -j android.hardware.sensors@1.0-convert Test: attempt to compile with BOARD_VNDK_VERSION := current Change-Id: I0a4e8a658b5b33bd7a6668242f98a4f6cda2a94f
2017-04-12 02:33:54 +02:00
vendor_available: true,
defaults: ["hidl_defaults"],
srcs: ["convert.cpp"],
export_include_dirs: ["include"],
shared_libs: [
"liblog",
"libcutils",
"libhardware",
"libbase",
"libutils",
"libhidlbase",
"libhidltransport",
"android.hardware.sensors@1.0",
],
local_include_dirs: ["include/sensors"],
export_shared_lib_headers: [
"libhardware",
],
}
cc_binary {
name: "android.hardware.sensors@1.0-service",
relative_install_path: "hw",
vendor: true,
init_rc: ["android.hardware.sensors@1.0-service.rc"],
srcs: ["service.cpp"],
shared_libs: [
"liblog",
"libcutils",
"libdl",
"libbase",
"libutils",
"libhidlbase",
"libhidltransport",
"android.hardware.sensors@1.0",
],
}