This splits headers into three locations:
include - for backwards compatibility, the global include
include_all - for things system/vendor both use
include_vendor - for things that only vendors use
The goal is to gradually have system things stop referencing
(at least most) of these headers.
Bug: 37280010
Test: build (CL on top adds back in symlinks)
Change-Id: Ibf194276b7faa857e1e7605d7719f4e7d873ecba
Due to adding a dependency of libmedia_helper on
libhardware_headers
Bug: 278976019
Test: m
Change-Id: I97df31b209630dc7fb6b46a0b0221c0d496e6375
Merged-In: I97df31b209630dc7fb6b46a0b0221c0d496e6375
This requires dropping a header file and avoiding a missing strlcpy API.
Required for host_supported fuzzers that include this lib.
Test: libsensorserviceaidl_fuzzer
Bug: 205764765
Change-Id: Ib1d2851e915ed87ef2936a044e7a72bab3077f40
A dependency to libdl is added by default by the build system based on
system_dynamic_libs property.
Test: m libhardware
Change-Id: I4bc1a7cb4af2c49d6f1343843cf86c436294bed7
codec2/vndk referenced, but did not use, libhardware. Now that
the reference is cleaned, we don't need to to export to apex's.
Bug: 221444002
Test: build, boot
Change-Id: I43bff5cab71d53d8c7422c13265f129b26ca0430
Move the implicit allowing by modules from a list in the build
tools to explicit lines in the relevant module's Android.bp
Bug: 215589022
Test: build
Change-Id: I17f93210f027cb8189e92b19a46b6d64faef7ed8
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 152655956
Test: m
Change-Id: Iab1437027fcbe4b7876207ec7605a765ba667b52
The default boot ctrl implementation depends
on libhardware.
Bug: 78793464
Test: Compiles, can load bootctrl in recovery
Change-Id: I9c8aa8b00b9b81f11736de13c85973e113056e69
As a VNDK/VNDK-SP module, Android.bp must have 'vndk' tag as well
as 'vendor_available: true'.
For a VNDK module, the 'vndk' tag has 'enabled: true'.
It will be installed system/lib(64)/vndk as a vendor variant.
For a VNDK-SP module, the 'vndk' tag has
'support_system_process: true' as well as 'enabled: true'.
It will be installed system/lib(64)/vndk-sp as a vendor variant.
Bug: 63866913
Test: build and boot with BOARD_VNDK_VERSION=current
Merged-In: I383af9ccc5457afe437c0cd910c11b636e4b6dd5
Change-Id: I383af9ccc5457afe437c0cd910c11b636e4b6dd5
(cherry picked from commit 8d9fa07fe1)
Some headers of libhardware are using headers from libcutils.
Bug: 33241851
Test: BOARD_VNDK_VERSION=current m -j successful with aosp_arm target
Change-Id: I649056285ced1cd5da4aba6a19b25e22c43c8621
'vndk' namespace should not have /vendor/lib/* in its search paths.
However, /vendor/lib/* has been included due to libhardware; it should
be able to load HAL libs in /vendor/lib and /vendor/lib/hw.
Since the HAL libs are not vndk but part of SP-HAL, they are loaded
explicitly from the 'sphal' namespace.
Bug: 37731053
Bug: 37323945
Test: sailfish builds and boots successfuly
Test: BOARD_VNDK_VERSION=current m libhardware.vendor successful
Merged-In: I1e1619de7deaa0e6610180e585bd7775887bc562
Change-Id: I1e1619de7deaa0e6610180e585bd7775887bc562
(cherry picked from commit 4d67d2e13a)
hardware/audio.h uses libaudio_system_headers
Test: works with BOARD_VNDK_VERSION := current
Bug: 33241851
(cherry picked from commit d24879050a)
Merged-In: I6042c9903b2bc580ec519b713f0f19d94e1daa2d
Change-Id: I6042c9903b2bc580ec519b713f0f19d94e1daa2d
libhardware uses system headers in its headers.
Test: links
Test: libraries using libhardware which don't have access to system
headers link when BOARD_VNDK_VERSION := current.
Bug: 33241851
(cherry picked from commit d39335254a)
Merged-In: I33cbd8a4d6188eed69cb8b55acb3b78b0628d82a
Change-Id: I33cbd8a4d6188eed69cb8b55acb3b78b0628d82a
hardware/audio.h uses libaudio_system_headers
Test: works with BOARD_VNDK_VERSION := current
Bug: 33241851
Change-Id: I6042c9903b2bc580ec519b713f0f19d94e1daa2d
libhardware uses system headers in its headers.
Test: links
Test: libraries using libhardware which don't have access to system
headers link when BOARD_VNDK_VERSION := current.
Bug: 33241851
Change-Id: I33cbd8a4d6188eed69cb8b55acb3b78b0628d82a
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: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Test: attempt to compile with BOARD_VNDK_VERSION := current
Merged-In: Ia4eb5378d941033b07673daf682e66051cd3c075
Change-Id: Ia4eb5378d941033b07673daf682e66051cd3c075
This doesn't need utils/Log.h, just log/log.h and some stdlib headers.
Bug: 33241851
Test: m -j libhardware
Merged-In: Id73059f5636af42b0d1680b89f6ca27f466d9ea8
Change-Id: Id73059f5636af42b0d1680b89f6ca27f466d9ea8
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: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Test: attempt to compile with BOARD_VNDK_VERSION := current
Change-Id: Ia4eb5378d941033b07673daf682e66051cd3c075
This doesn't need utils/Log.h, just log/log.h and some stdlib headers.
Bug: 33241851
Test: m -j libhardware
Change-Id: Id73059f5636af42b0d1680b89f6ca27f466d9ea8
