The VNDK requires several changes to a codebase to separate concerns between vendor and system. Use the following guide to enable VNDK in a vendor/OEM codebase.
The build system contains several types of objects including libraries (shared, static, or header) and binaries:
vendor
, vendor_available
,
vndk
, or vndk-sp
libraries.
cc_library { name: "libThatIsCore", ... }
proprietary
). Used by the
vendor image, on the vendor image.
cc_library { name: "libThatIsVendorOnly", proprietary: true, # or: vendor: true, # (for things in AOSP) ... }
core
).
cc_library { name: "libThatIsVendorAvailable", vendor_available: true, ... }
vendor_available
).
cc_library { name: "libThatIsVndk", vendor_available: true, vndk: { enabled: true, } ... }
core
).
cc_library { name: "libThatIsVndkSp", vendor_available: true, vndk: { enabled: true, support_system_process: true, } ... }
llndk_library { name: "libThasIsLlndk", }
When a lib is marked as vendor_available:true
, it is built
twice:
/system/lib
)./vendor/lib
,
/system/lib/vndk
, or /system/lib/vndk-sp
).The vendor versions of libs are built with -D__ANDROID_VNDK__
.
Private system components that may change significantly in future versions of
Android are disabled with this flag. In addition, different libraries export a
different set of headers (such as liblog
). Options specific to a
vendor variant of a target can be specified in an Android.bp
file
in:
target: { vendor: { … } }
To enable the VNDK for a codebase:
vendor.img
and system.img
partitions.BOARD_VNDK_VERSION=current
. You can add to
BoardConfig.mk
or build components with it directly (i.e.
m -j BOARD_VNDK_VERSION=current MY-LIB
).After enabling BOARD_VNDK_VERSION=current
, the build system
enforces the following dependency and header requirements.
A vendor
object that depends on a core
component
that doesn't exist in the vndk
or as a vendor
object
must be resolved using one of the following options:
core
component is owned by vendor
, it can
be marked as vendor_available
or vendor
.vndk
may be
upstreamed to Google.In addition, if a core
component has dependencies on a
vendor
component, the vendor
component must be made
into a core
component or the dependency must be
removed in another way (for example, by removing the dependency or by moving the
dependency into a vendor
component).
Global header dependencies must be removed to enable the build system to know
whether to build the headers with or without -D__ANDROID_VNDK__
.
For example, libutils headers such as utils/StrongPointer.h
can
still be accessed using the header library
libutils_headers
.
Some headers (such as unistd.h
) can no longer be transitively
included but can be included locally.
Finally, the public part of private/android_filesystem_config.h
has been moved to cutils/android_filesystem_config.h
. To manage
these headers, do one of the following:
private/android_filesystem_config.h
by replacing all
AID_*
macros with
getgrnam
/getpwnam
calls if possible. For example:
(uid_t)AID_WIFI
becomes
getpwnam("wifi")->pw_uid
.(gid_t)AID_SDCARD_R
becomes
getgrnam("sdcard_r")->gr_gid
.private/android_filesystem_config.h
.
cutils/android_filesystem_config.h
.