From 1731f4ad91051c17b9c66913c56283c55751df41 Mon Sep 17 00:00:00 2001 From: Android Partner Docs Date: Mon, 13 Aug 2018 10:09:53 -0700 Subject: Docs: Changes to source.android.com - 208499135 Devsite localized content from translation request 952101. by Android Partner Docs - 208499120 Devsite localized content from translation request 956390. by Android Partner Docs - 208289251 Updated Develop CTS page on source.android.com to reflect... by Android Partner Docs - 208275837 Explain a complete stack unwind, showing all the differen... by Android Partner Docs - 208275639 Removing bug reporting from Jack article by Heidi von Markham - 208269325 Switch to gdbclient.py. by Android Partner Docs - 208122929 Devsite localized content from translation request 958914. by Android Partner Docs - 208122926 Devsite localized content from translation request 960485. by Android Partner Docs - 208122918 Devsite localized content from translation request 955354. by Android Partner Docs - 208122894 Devsite localized content from translation request 958911. by Android Partner Docs - 208122890 Devsite localized content from translation request 941625. by Android Partner Docs - 208122882 Devsite localized content from translation request 961382. by Android Partner Docs - 208106869 Update links for maintanability by Kenneth Lau - 208052953 Fix command path in terminal sample by Christina Nguyen - 207987258 Update java pseudocode by Android Partner Docs - 207947311 removing todos, general formatting updates, table tweaks by Heidi von Markham PiperOrigin-RevId: 208499135 Change-Id: I3d2bdb35299b34fa43360469b9496fdacad7a533 --- en/devices/architecture/vndk/build-system.html | 703 +++++++++++++------------ 1 file changed, 356 insertions(+), 347 deletions(-) (limited to 'en/devices/architecture/vndk') diff --git a/en/devices/architecture/vndk/build-system.html b/en/devices/architecture/vndk/build-system.html index 6c4acf64..72737be6 100644 --- a/en/devices/architecture/vndk/build-system.html +++ b/en/devices/architecture/vndk/build-system.html @@ -22,299 +22,288 @@ --> -

The build system comes with built-in VNDK support in Android 8.1. If the -VNDK support is enabled, the build system checks the dependencies between -modules, builds a vendor-specific variant for vendor modules, and automatically -installs those modules into designated directories.

- -

The following example illustrates the basic concepts:

- -

libexample with vendor_available:true and vndk.enabled:true

-
Figure 1. VNDK support enable.
- -

The Android.bp module definition defines a -library named libexample. The vendor_available -property means that both framework modules and vendor modules may depend on -libexample. In this example, both the framework executable -/system/bin/foo and the vendor executable -/vendor/bin/bar depend on libexample and have -libexample in their shared_libs properties.

- -

If libexample is used by both framework modules and vendor -modules, two variants of libexample are built. The core -variant (named after libexample) is used by framework modules -and the vendor variant (named after libexample.vendor) is -used by vendor modules.

- -

Two variants are installed into different directories. The core variant -is installed into /system/lib[64]/libexample.so. The vendor -variant is installed into /system/lib[64]/vndk/libexample.so -because vndk.enabled is true.

- -

For more details, see -Module definition.

- - +

+ In Android 8.1 and higher, the build system has built-in VNDK support. When + VNDK support is enabled, the build system checks the dependencies between + modules, builds a vendor-specific variant for vendor modules, and + automatically installs those modules into designated directories. +

+ +

VNDK build support example

+ +

+ In this example, the Android.bp module definition defines a + library named libexample. The vendor_available + property indicates framework modules and vendor modules may depend on + libexample: +

+ +

+ libexample vendor_available:true and vndk.enabled:true +

+
+ Figure 1. VNDK support enabled +
+ +

+ Both the framework executable /system/bin/foo and the vendor + executable /vendor/bin/bar depend on libexample and + have libexample in their shared_libs properties. +

+ +

+ If libexample is used by both framework modules and vendor + modules, two variants of libexample are built. The core variant + (named after libexample) is used by framework modules and the + vendor variant (named after libexample.vendor) is used by vendor + modules. The two variants are installed into different directories: +

+
    +
  • The core variant is installed into + /system/lib[64]/libexample.so.
  • +
  • The vendor variant is installed into + /system/lib[64]/vndk/libexample.so because + vndk.enabled is true.
  • +
+

+ For more details, see Module definition. +

-

Configuration

+

Configuring build support

-

To enable full build system support for a product device, add -BOARD_VNDK_VERSION to BoardConfig.mk:

+

+ To enable full build system support for a product device, add + BOARD_VNDK_VERSION to BoardConfig.mk: +

BOARD_VNDK_VERSION := current
- - -

Migration notes

- -

Adding BOARD_VNDK_VERSION to BoardConfig.mk has a -global effect. When defined in BoardConfig.mk, all -modules are checked. There is no mechanism to blacklist or whitelist an -offending module. The practice is to add BOARD_VNDK_VERSION after -cleaning all unnecessary dependencies.

- -

During a migration process, you can test and compile a module by setting -BOARD_VNDK_VERSION in your environment variables:

+

+ This setting has a global effect: When defined in + BoardConfig.mk, all modules are checked. As there is no mechanism + to blacklist or whitelist an offending module, you should clean all + unnecessary dependencies before adding BOARD_VNDK_VERSION. You + can test and compile a module by setting BOARD_VNDK_VERSION in + your environment variables: +

$ BOARD_VNDK_VERSION=current m module_name.vendor
-

Yet another side effect is the removal of default global header search -paths. If BOARD_VNDK_VERSION is enabled, the following -default header search paths are not added by default:

+

When BOARD_VNDK_VERSION is enabled, several default global + header search paths are removed. These include: +

    -
  • frameworks/av/include
  • -
  • frameworks/native/include
  • -
  • frameworks/native/opengl/include
  • -
  • hardware/libhardware/include
  • -
  • hardware/libhardware_legacy/include
  • -
  • hardware/ril/include
  • -
  • libnativehelper/include
  • -
  • libnativehelper/include_deprecated
  • -
  • system/core/include
  • -
  • system/media/audio/include
  • +
  • frameworks/av/include
  • +
  • frameworks/native/include
  • +
  • frameworks/native/opengl/include
  • +
  • hardware/libhardware/include
  • +
  • hardware/libhardware_legacy/include
  • +
  • hardware/ril/include
  • +
  • libnativehelper/include
  • +
  • libnativehelper/include_deprecated
  • +
  • system/core/include
  • +
  • system/media/audio/include
-

If a module depends on the headers from these directories, its author must -explicitly specify the dependencies with header_libs, -static_libs, and/or shared_libs.

- - - - +

+ If a module depends on the headers from these directories, you must specify + (explicitly) the dependencies with header_libs, + static_libs, and/or shared_libs. +

Module definition

-

To build Android with BOARD_VNDK_VERSION, developers must -revise their module definition in either Android.mk or -Android.bp. This subsection describes different kinds of module -definitions, several VNDK-related module properties, and the dependency checks -implemented in the build system.

- - +

+ To build Android with BOARD_VNDK_VERSION, you must revise the + module definition in either Android.mk or + Android.bp. This section describes different kinds of module + definitions, several VNDK-related module properties, and dependency checks + implemented in the build system. +

Vendor modules

-

Vendor modules are vendor-specific executables or shared libraries that -must be installed into a vendor partition. In Android.bp files, -vendor modules must set vendor or proprietary property to true. In -Android.mk files, vendor modules must set -LOCAL_VENDOR_MODULE or LOCAL_PROPRIETARY_MODULE to -true.

+

+ Vendor modules are vendor-specific executables or shared libraries that + must be installed into a vendor partition. In Android.bp files, + vendor modules must set vendor or proprietary property to true. + In Android.mk files, vendor modules must set + LOCAL_VENDOR_MODULE or LOCAL_PROPRIETARY_MODULE to + true. +

-

If BOARD_VNDK_VERSION is defined, the build system -disallows the dependencies between vendor modules and framework modules. The -build system emits errors if:

+

+ If BOARD_VNDK_VERSION is defined, the build system disallows + dependencies between vendor modules and framework modules and emits errors if: +

  • a module without vendor:true depends on a module with vendor:true, or
  • -
  • a module with vendor:true depends on a non-llndk_library module that has neither vendor:true nor vendor_available:true.
-

The aforementioned dependency check applies to header_libs, -static_libs, and shared_libs in -Android.bp. It also applies to -LOCAL_HEADER_LIBRARIES, LOCAL_STATIC_LIBRARIES and -LOCAL_SHARED_LIBRARIES in Android.mk.

- - +

+ The dependency check applies to header_libs, + static_libs, and shared_libs in + Android.bp, and to LOCAL_HEADER_LIBRARIES, + LOCAL_STATIC_LIBRARIES and LOCAL_SHARED_LIBRARIES in + Android.mk. +

LL-NDK

-

LL-NDK shared libraries are shared libraries with stable ABIs. Both -framework and vendor modules share the same and the latest implementation. For -each LL-NDK shared library, there is an llndk_library module definition in -an Android.bp file:

+

+ LL-NDK shared libraries are shared libraries with stable ABIs. Both framework + and vendor modules share the same and the latest implementation. For each + LL-NDK shared library, Android.bp contains a + llndk_library module definition: +

-
llndk_library {
+
+llndk_library {
     name: "libvndksupport",
     symbol_file: "libvndksupport.map.txt",
-}
+} +
-

This module definition specifies a module name and a symbol file, which -describes the symbols that should be visible to vendor modules. For -example:

+

+ This module definition specifies a module name and a symbol file that + describes the symbols visible to vendor modules. For example: +

-
LIBVNDKSUPPORT {
+
+LIBVNDKSUPPORT {
   global:
     android_load_sphal_library; # vndk
     android_unload_sphal_library; # vndk
   local:
     *;
-};
- -

Based on the symbol file, the build system generates a stub shared -library for vendor modules. Vendor modules link with these stub -shared libraries if BOARD_VNDK_VERSION is enabled.

+}; +
-

A symbol is included in the stub shared library only if:

+

+ Based on the symbol file, the build system generates a stub shared library for + vendor modules, which link with these libraries when + BOARD_VNDK_VERSION is enabled. A symbol is included in the stub + shared library only if it: +

    -
  • it is not defined in the section end with _PRIVATE or +
  • Is not defined in the section end with _PRIVATE or _PLATFORM,
  • - -
  • it does not have #platform-only tag, and
  • - -
  • it does not have #introduce* tags or the tag matches with the +
  • Does not have #platform-only tag, and
  • +
  • Does not have #introduce* tags or the tag matches with the target.
- - - +

VNDK

-

In Android.bp files, cc_library, -cc_library_static, cc_library_shared, and -cc_library_headers module definitions support three VNDK-related -properties: vendor_available, vndk.enabled, and -vndk.support_system_process.

- -

If vendor_available or vndk.enabled is -true, two variants (core and vendor) may be -built. The core variant should be treated as a framework module and the vendor -variant should be treated as a vendor module. If some framework modules depend -on this module, the core variant is built. If some vendor modules -depend on this module, the vendor variant is built.

- -

The build system enforces these dependency checks:

+

+ In Android.bp files, cc_library, + cc_library_static, cc_library_shared, and + cc_library_headers module definitions support three VNDK-related + properties: vendor_available, vndk.enabled, and + vndk.support_system_process. +

+ +

+ If vendor_available or vndk.enabled is + true, two variants (core and vendor) may be + built. The core variant should be treated as a framework module and the vendor + variant should be treated as a vendor module. If some framework modules depend + on this module, the core variant is built. If some vendor modules + depend on this module, the vendor variant is built. The build system enforces + the following dependency checks: +

  • The core variant is always framework-only and inaccessible to vendor modules.
  • -
  • The vendor variant is always inaccessible to framework modules.
  • -
  • All dependencies of the vendor variant, which are specified in header_libs, static_libs, and/or shared_libs, must be either an llndk_library or a module with vendor_available or vndk.enabled.
  • -
  • If vendor_available is true, the vendor variant is accessible to all vendor modules.
  • -
  • If vendor_available is false, the vendor variant is accessible only to other VNDK or VNDK-SP modules (i.e., modules with vendor:true cannot link vendor_available:false modules).
-

The default installation path for cc_library or -cc_library_shared is determined by the following rules:

+

+ The default installation path for cc_library or + cc_library_shared is determined by the following rules: +

    -
  • - The core variant is installed to /system/lib[64]. -
  • - -
  • - The vendor variant installation path may vary: - +
  • The core variant is installed to /system/lib[64].
  • +
  • The vendor variant installation path may vary:
      -
    • - If vndk.enabled is false, the vendor - variant is installed into /vendor/lib[64]. -
    • - -
    • - If vndk.enabled is true, +
    • If vndk.enabled is false, the vendor variant + is installed into /vendor/lib[64].
    • +
    • If vndk.enabled is true, vndk.support_system_process can be either true or - false. - -
        -
      • - If vndk.support_system_process is false, - the vendor variant is installed into - /system/lib[64]/vndk-${VER}. -
      • - -
      • - Conversely, the vendor variant is installed to - /system/lib[64]/vndk-sp-${VER}. -
      • + false. If: +
          +
        • false, the vendor variant is installed into + /system/lib[64]/vndk-${VER}.
        • +
        • true, the vendor variant is installed to + /system/lib[64]/vndk-sp-${VER}.
    -

    The table below summarizes how the build system handles the vendor -variants:

    - - +

    + The table below summarizes how the build system handles the vendor variants: +

    - - - + + + + - - + + + + - - - - + + - - + + + - - - - - - - - + + @@ -325,51 +314,48 @@ variants:

    - - + + - - - + + + - - + +

    vendor_available

    vndk

    Vendor variant descriptions

    vendor_availablevndk
    enabled
    vndk
    support_same_process
    Vendor variant descriptions

    enabled

    support_same_process

    truefalsefalseThe vendor variants are VND-ONLY. Shared libraries are + installed into /vendor/lib[64].

    true

    false

    false

    -

    The vendor variants are VND-ONLY

    -

    Shared libraries are installed into /vendor/lib[64].

    -
    trueInvalid (Build error)

    true

    Invalid (Build error)

    truefalseThe vendor variants are VNDK. Shared libraries are installed + to /system/lib[64]/vndk-${VER}.

    true

    false

    -

    The vendor variants are VNDK.

    -

    Shared libraries are installed to - /system/lib[64]/vndk-${VER}.

    -

    true

    -

    The vendor variants are VNDK-SP.

    -

    Shared libraries are installed to - /system/lib[64]/vndk-sp-${VER}.

    -
    trueThe vendor variants are VNDK-SP. Shared libraries are + installed to /system/lib[64]/vndk-sp-${VER}.

    true

    Invalid (Build error)

    trueInvalid (Build error)

    true

    false

    -

    The vendor variants are VNDK-Private.

    -

    Shared libraries are installed to - /system/lib[64]/vndk-${VER}.

    -

    These must not be directly used by vendor modules.

    -
    truefalseThe vendor variants are VNDK-Private. Shared libraries are + installed to /system/lib[64]/vndk-${VER}.These must not be + directly used by vendor modules.

    true

    -

    The vendor variants are VNDK-SP-Private.

    -

    Shared libraries are installed to - /system/lib[64]/vndk-sp-${VER}.

    -

    These must not be directly used by vendor modules.

    -
    trueThe vendor variants are VNDK-SP-Private. Shared libraries are + installed to /system/lib[64]/vndk-sp-${VER}. These must not be + directly used by vendor modules.
    - - - +

    VNDK extensions

    -

    VNDK extensions are VNDK shared libraries with additional APIs. VNDK -extensions are installed to /vendor/lib[64]/vndk[-sp] (without -version suffix) and override the original VNDK shared libraries at runtime.

    - +

    + VNDK extensions are VNDK shared libraries with additional APIs. Extensions are + installed to /vendor/lib[64]/vndk[-sp] (without version suffix) + and override the original VNDK shared libraries at runtime. +

    Defining VNDK extensions

    -

    In Android P, Android.bp natively supports VNDK extensions. To -build a VNDK extension, define another module with a vendor:true -and an extends property:

    +

    + In Android 9 and higher, Android.bp natively supports VNDK + extensions. To build a VNDK extension, define another module with a + vendor:true and an extends property: +

     cc_library {
    @@ -390,28 +376,28 @@ cc_library {
     }
     
    -

    A module with vendor:true, vndk.enabled:true, and -extends properties defines VNDK extension:

    +

    + A module with vendor:true, vndk.enabled:true, and + extends properties defines the VNDK extension:

    • The extends property must specify a base VNDK shared library - name (or VNDK-SP shared library name).
    • - -
    • VNDK extensions (or VNDK-SP extensions) are named after the base module - names from which they extend. For example, the output binary of libvndk_ext - is libvndk.so instead of libvndk_ext.so.
    • - -
    • VNDK extensions are installed into /vendor/lib[64]/vndk.
    • - -
    • VNDK-SP extensions are installed into - /vendor/lib[64]/vndk-sp.
    • - -
    • The base shared libraries must have both vndk.enabled:true and - vendor_available:true.
    • + name (or VNDK-SP shared library name). +
    • VNDK extensions (or VNDK-SP extensions) are named after the base module + names from which they extend. For example, the output binary of + libvndk_ext is libvndk.so instead of + libvndk_ext.so.
    • +
    • VNDK extensions are installed into /vendor/lib[64]/vndk.
    • +
    • VNDK-SP extensions are installed into + /vendor/lib[64]/vndk-sp.
    • +
    • The base shared libraries must have both vndk.enabled:true + and vendor_available:true.
    -

    A VNDK-SP extension must extend from a VNDK-SP shared library. In other -words, vndk.support_system_process must be equal:

    +

    + A VNDK-SP extension must extend from a VNDK-SP shared library + (vndk.support_system_process must be equal): +

     cc_library {
    @@ -434,8 +420,10 @@ cc_library {
     }
     
    -

    VNDK extensions (or VNDK-SP extensions) may depend on other vendor shared -libraries:

    +

    + VNDK extensions (or VNDK-SP extensions) may depend on other vendor shared + libraries: +

     cc_library {
    @@ -464,16 +452,19 @@ cc_library {
     }
     
    - - +

    Using VNDK extensions

    -

    If a vendor module depends on some additional APIs defined by VNDK -extensions, it must specify the name of the VNDK extension in its -shared_libs property:

    +

    + If a vendor module depends on additional APIs defined by VNDK extensions, the + module must specify the name of the VNDK extension in its + shared_libs property: +

     // A vendor shared library example
    @@ -495,33 +486,40 @@ cc_binary {
     }
     
    -

    If a vendor module depends on some VNDK extensions, those VNDK extensions -will be installed to /vendor/lib[64]/vndk[-sp] automatically.

    - -

    If a module no longer depends on a VNDK extension, add a clean step to -CleanSpec.mk to remove the shared library. For example:

    +

    + If a vendor module depends on VNDK extensions, those VNDK extensions are + installed to /vendor/lib[64]/vndk[-sp] automatically. If a module + no longer depends on a VNDK extension, add a clean step to + CleanSpec.mk to remove the shared library. For example: +

     $(call add-clean-step, rm -rf $(TARGET_OUT_VENDOR)/lib/libvndk.so)
     
    - -

    Conditional compilation

    -

    This subsection describes how to deal with the subtle differences -(e.g. adding or removing a feature from one of the variants) between three VNDK -shared libraries: (1) the core variant (e.g. -/system/lib[64]/libexample.so), (2) the vendor variant (e.g. -/system/lib[64]/vndk[-sp]-${VER}/libexample.so), and (3) the VNDK -extension (e.g. /vendor/lib[64]/vndk[-sp]/libexample.so). +

    + This section describes how to deal with the subtle differences (e.g. + adding or removing a feature from one of the variants) between the following + three VNDK shared libraries: +

    +
      +
    • core variant (e.g. /system/lib[64]/libexample.so)
    • +
    • vendor variant (e.g. + /system/lib[64]/vndk[-sp]-${VER}/libexample.so)
    • +
    • VNDK extension (e.g. /vendor/lib[64]/vndk[-sp]/libexample.so) +
    • +

    Conditional compiler flags

    -

    The Android build system defines __ANDROID_VNDK__ for -vendor variants (including VNDK extensions) by default. You may guard the code -with the C preprocessor guards:

    +

    + The Android build system defines __ANDROID_VNDK__ for vendor + variants (including VNDK extensions) by default. You may guard the code + with the C preprocessor guards: +

     void all() { }
    @@ -535,12 +533,14 @@ void vndk_only() { }
     #endif
     
    -

    In addition to __ANDROID_VNDK__, different cflags -or cppflags may be specified in Android.bp. The -cflags or cppflags specified in -target.vendor is specific to the vendor variant. For example, the -code below is the Android.bp module definition for -libexample and libexample_ext:

    +

    + In addition to __ANDROID_VNDK__, different cflags or + cppflags may be specified in Android.bp. The + cflags or cppflags specified in + target.vendor is specific to the vendor variant. For example, the + following code example is the Android.bp module definition for + libexample and libexample_ext: +

     cc_library {
    @@ -572,7 +572,9 @@ cc_library {
     }
     
    -

    The code listing of example.c:

    +

    + Code listing of example.c: +

     void all() { }
    @@ -590,7 +592,9 @@ void vndk_ext() { }
     #endif
     
    -

    And the exported symbols for each variant will be:

    +

    + Exported symbols for each variant: +

    @@ -614,30 +618,29 @@ void vndk_ext() { }
    - - -

    The VNDK ABI compliance checker compares the ABI of VNDK and VNDK -extensions to the ABI dumps under prebuilts/abi-dumps/vndk:

    +

    + The VNDK ABI compliance checker compares the ABI of VNDK and VNDK + extensions to the ABI dumps under prebuilts/abi-dumps/vndk: +

      -
    • Symbols exported by original VNDK shared libraries must be identical to - (not the supersets of) the symbols defined in ABI dumps.
    • - -
    • Symbols exported by VNDK extensions must be supersets of the symbols - defined in ABI dumps.
    • +
    • Symbols exported by original VNDK shared libraries must be identical to + (not the supersets of) the symbols defined in ABI dumps.
    • +
    • Symbols exported by VNDK extensions must be supersets of the symbols + defined in ABI dumps.
    +

    Excluding source files or shared libs

    -

    Exclude source files or shared -libs

    - -

    To exclude source files from the vendor variant, add them to the -exclude_srcs property. Similarly, to ensure specific shared -libraries are not linked with the vendor variant, add them to the -exclude_shared_libs property. For example:

    +

    + To exclude source files from the vendor variant, add them to the + exclude_srcs property. Similarly, to ensure shared libraries are + not linked with the vendor variant, add those libraries to the + exclude_shared_libs property. For example: +

    -
    cc_library {
    +
    +cc_library {
         name: "libcond_exclude_example",
         srcs: ["fwk.c", "both.c"],
         shared_libs: ["libfwk_only", "libboth"],
    @@ -647,64 +650,70 @@ libraries are not linked with the vendor variant, add them to the
                 exclude_shared_libs: ["libfwk_only"],
             },
         },
    -}
    - -

    In this example, the core variant of libcond_exclude_example -includes the code from fwk.c and both.c and depends -on the shared libraries libfwk_only and libboth.

    - -

    On the other hand, the vendor variant of -libcond_exclude_example includes only the code from -both.c because fwk.c is excluded by the -exclude_srcs property. Similarly, -libcond_exclude_example depends only on the shared library -libboth because libfwk_only is excluded by -the
    exclude_shared_libs property. - - - - - - +} +

    +

    + In this example, the core variant of libcond_exclude_example + includes the code from fwk.c and both.c and depends + on the shared libraries libfwk_only and libboth. The + vendor variant of libcond_exclude_example includes only the code + from both.c because fwk.c is excluded by the + exclude_srcs property. Similarly, + libcond_exclude_example depends only on the shared library + libboth because libfwk_only is excluded by the + exclude_shared_libs property. +

    Product packages

    -

    In the Android build system, the variable PRODUCT_PACKAGES -specifies the executables, shared libraries, or packages that should be -installed into the device. The transitive dependencies of the specified modules -are implicitly installed into the device as well.

    - -

    If BOARD_VNDK_VERSION is enabled, modules with -vendor_available or vndk.enabled get special -treatments. If a framework module depends on a module with -vendor_available or vndk.enabled, the core -variant is included in the transitive installation set. Similarly, if a -vendor module depends on a module with vendor_available or -vndk.enabled, the vendor variant is included in the -transitive installation set.

    - -

    When the dependencies are invisible to the build system (e.g. shared -libraries that may be opened with dlopen() in runtime), you -should specify the module names in PRODUCT_PACKAGES to install -those modules explicitly.

    - -

    If a module has vendor_available or vndk.enabled, -the module name stands for its core variant. To explicitly specify the -vendor variant in PRODUCT_PACKAGES, append a .vendor -suffix to the module name. For example:

    - -
    cc_library {
    +

    + In the Android build system, the variable PRODUCT_PACKAGES + specifies the executables, shared libraries, or packages that should be + installed into the device. The transitive dependencies of the specified + modules are implicitly installed into the device as well. +

    + +

    + If BOARD_VNDK_VERSION is enabled, modules with + vendor_available or vndk.enabled get special + treatment. If a framework module depends on a module with + vendor_available or vndk.enabled, the core variant + is included in the transitive installation set. Similarly, if a vendor module + depends on a module with vendor_available or + vndk.enabled, the vendor variant is included in the transitive + installation set. +

    + +

    + When the dependencies are invisible to the build system (e.g. shared libraries + that may be opened with dlopen() in runtime), you should specify + the module names in PRODUCT_PACKAGES to install those modules + explicitly. +

    + +

    + If a module has vendor_available or vndk.enabled, + the module name stands for its core variant. To explicitly specify the + vendor variant in PRODUCT_PACKAGES, append a .vendor + suffix to the module name. For example: +

    + +
    +cc_library {
         name: "libexample",
         srcs: ["example.c"],
         vendor_available: true,
    -}
    +} +
    -

    In this example, libexample stands for -/system/lib[64]/libexample.so and libexample.vendor -stands for /vendor/lib[64]/libexample.so. To install -/vendor/lib[64]/libexample.so, add libexample.vendor -to PRODUCT_PACKAGES:

    +

    + In this example, libexample stands for + /system/lib[64]/libexample.so and libexample.vendor + stands for /vendor/lib[64]/libexample.so. To install + /vendor/lib[64]/libexample.so, add libexample.vendor + to PRODUCT_PACKAGES: +

    PRODUCT_PACKAGES += libexample.vendor
    -- cgit v1.2.3