From 0051abdc34422e72cfc4726f16c488f9803a121b Mon Sep 17 00:00:00 2001 From: Android Partner Docs Date: Tue, 4 Sep 2018 10:09:56 -0700 Subject: Docs: Changes to source.android.com - 211476450 September 2018 Android and Pixel bulletins by Danielle Roberts - 211470085 Edits to ASHA CoC Spec. by Christina Nguyen - 211462984 Updating vndk presentation; better formatting; updates to... by Heidi von Markham - 211462496 Devsite localized content from translation request 967292. by Android Partner Docs - 211460653 Update Sensor Fusion box zip file to 1.4 by Kenneth Lau - 211144393 Adjusted headings. by Christina Nguyen - 211143051 Add Passpoint R1 Auth Advisory to the Wi-Fi Passpoint pag... by Christina Nguyen - 211121648 Cloned from CL 209515989 by 'g4 patch'. by Christina Nguyen - 211110557 Updating the name of the Android 9 CDD directory, update ... by Gina Dimino - 211015057 Automated g4 rollback of changelist 211006706. by Android Partner Docs - 211006706 Automated g4 rollback of changelist 211003808. by Android Partner Docs - 211003808 Call out legacy HAL documentation as legacy. by Android Partner Docs - 210972364 Add tethering offload doc by Kenneth Lau - 210962927 Fix key 102 HOME to key 172 HOME by Christina Nguyen - 210933430 Fix key 102 HOME to key 172 HOME by Christina Nguyen - 210815755 Add WFoV ITS-in-a-box assembly page by Kenneth Lau - 210802757 Explicitly give both gdbserver and gdbserver64 examples. by Android Partner Docs - 210776064 Bump a non-title heading down to h2 by Christina Nguyen - 210559310 Devsite localized content from translation request 972157. by Android Partner Docs - 210559295 Devsite localized content from translation request 968674. by Android Partner Docs - 210451431 Changed version string from 9.0 to 9. by Gina Dimino - 210430962 Remove double space in Carrier Wifi config by Danielle Roberts PiperOrigin-RevId: 211476450 Change-Id: I8243ab4f3af151470fca849d7ca006a0f615f8e3 --- en/devices/architecture/vndk/index.html | 49 +- en/devices/architecture/vndk/renderscript.html | 635 +++++++++++++++---------- 2 files changed, 407 insertions(+), 277 deletions(-) (limited to 'en/devices/architecture/vndk') diff --git a/en/devices/architecture/vndk/index.html b/en/devices/architecture/vndk/index.html index 02722a66..f692f8d8 100644 --- a/en/devices/architecture/vndk/index.html +++ b/en/devices/architecture/vndk/index.html @@ -5,6 +5,7 @@ + {% include "_versions.html" %} -

RenderScript is a framework for running computationally intensive -tasks at high performance on Android. It is designed for use with data-parallel -computation, although serial workloads can benefit as well. The RenderScript -runtime parallelizes work across processors available on a device, such as -multi-core CPUs and GPUs, enabling developers to focus on expressing algorithms -rather than scheduling work. RenderScript is especially useful for applications -performing image processing, computational photography, or computer vision.

+

+ RenderScript is a framework for running computationally intensive + tasks at high performance on Android. It is designed for use with + data-parallel computation, although serial workloads can benefit as well. The + RenderScript runtime parallelizes work across processors available on a + device, such as multi-core CPUs and GPUs, enabling developers to focus on + expressing algorithms rather than scheduling work. RenderScript is especially + useful for applications performing image processing, computational + photography, or computer vision. +

-

Android O devices use the following RenderScript framework and vendor HALs: +

+ Devices running Android 8.0 and higher use the following RenderScript + framework and vendor HALs:

+ -
Figure 1. Vendor code linking to internal libs. +
+ Figure 1. Vendor code linking to internal libs
-

Differences from RenderScript in Android 7.x and earlier include:

+

+ Differences from RenderScript in Android 7.x and lower include: +

+
    -
  • Two instances of RenderScript internal libs in a process. One set is for CPU -fallback path and is from directly at /system/lib; the other set is -for GPU path and is from /system/lib/vndk-sp.
    • -
  • RS internal libs in /system/lib are built as part of the -platform and are updated as system.img is upgraded. However, libs -in /system/lib/vndk-sp are built for the vendor and are not updated -when system.img is upgraded (while they can be updated for a -security fix, their ABI remains the same).
    • -
  • Vendor code (RS HAL, RS driver, and the bcc plugin) are linked against the -RenderScript internal libs located at /system/lib/vndk-sp. They -cannot link against libs in /system/lib because libs in that -directory are built for the platform and thus may not be compatible with the -vendor code (i.e., symbols may be removed). Doing so would make a framework-only -OTA impossible.
    • +
  • Two instances of RenderScript internal libs in a process. One set is for + CPU fallback path and is from directly at /system/lib; the other + set is for GPU path and is from /system/lib/vndk-sp.
    • +
  • RS internal libs in /system/lib are built as part of the + platform and are updated as system.img is upgraded. However, libs + in /system/lib/vndk-sp are built for the vendor and are not + updated when system.img is upgraded (while they can be updated + for a security fix, their ABI remains the same).
    • +
  • Vendor code (RS HAL, RS driver, and the bcc plugin) are + linked against the RenderScript internal libs located at + /system/lib/vndk-sp. They cannot link against libs in + /system/lib because libs in that directory are built for the + platform and thus may not be compatible with the vendor code (i.e., symbols + may be removed). Doing so would make a framework-only OTA impossible.
-

For more details, see -Renderscript -on developer.android.com.

+

+ For more details, see + Renderscript + on developer.android.com. +

Design

-

The following sections detail RenderScript design in Android O.

+ +

+ The following sections detail RenderScript design in Android 8.0 and higher. +

RenderScript libs available to vendors

-

This section lists the RenderScript libs (known as Vendor NDK for -Same-Process HALs or VNDK-SP) that are available to vendor code and which can be -linked against. It also details additional libraries that are unrelated to -RenderScript but which are also provided to vendor code.

-

While the following list of libraries might differ between Android release, -it is immutable for a specific Android release; for an up-to-date list of -available libraries, refer to /system/etc/ld.config.txt.

+

+ This section lists the RenderScript libs (known as Vendor NDK for Same-Process + HALs or VNDK-SP) that are available to vendor code and which can be linked + against. It also details additional libraries that are unrelated to + RenderScript but which are also provided to vendor code. +

+ +

+ While the following list of libraries might differ between Android releases, + it is immutable for a specific Android release; for an up-to-date list of + available libraries, refer to /system/etc/ld.config.txt. +

- + @@ -117,189 +139,249 @@ vendor's bcc plugin as the lib is not in the list.

Linker namespace configuration

-

The linking restriction that prevents libs not in VNDK-SP from being used by -vendor code is enforced at runtime using the linker namespace. (For details, -refer to the -VNDK Design in -Android O presentation.)

- -

On a device running Android O, all Same-Process HALs (SP-HALs) except -RenderScript are loaded inside the linker namespace sphal. -RenderScript is loaded into the RenderScript-specific namespace rs, -a location that enables a slightly looser enforcement for RenderScript libs. -Because the RS implementation needs to load the compiled bitcode, -/data/*/*.so is added to the path of the rs namespace -(other SP-HALs are not allowed to load libs from the data partition).

- -

In addition, the rs namespace allows more libs than provided for -by other namespaces. libmediandk.so and libft2.so are -exposed to the rs namespace because libRS_internal.so -has an internal dependency to these libraries.

+ +

+ The linking restriction that prevents libs not in VNDK-SP from being used by + vendor code is enforced at runtime using the linker namespace. (For details, + refer to the VNDK Design + presentation.) +

+ +

+ On a device running Android 8.0 and higher, all Same-Process HALs (SP-HALs) + except RenderScript are loaded inside the linker namespace + sphal. RenderScript is loaded into the RenderScript-specific + namespace rs, a location that enables a slightly looser + enforcement for RenderScript libs. Because the RS implementation needs to load + the compiled bitcode, /data/*/*.so is added to the path of the + rs namespace (other SP-HALs are not allowed to load libs from the + data partition). +

+ +

+ In addition, the rs namespace allows more libs than provided for + by other namespaces. libmediandk.so and libft2.so + are exposed to the rs namespace because + libRS_internal.so has an internal dependency to these libraries. +

-
Figure 2. Namespace configuration for linker. +
+ Figure 2. Namespace configuration for linker

Loading drivers

CPU fallback path

-

Depending on the existence of the RS_CONTEXT_LOW_LATENCY bit -when creating an RS context, either the CPU or GPU path is selected. When the -CPU path is selected, libRS_internal.so (the main implementation of -the RS framework) is directly dlopened from the default linker -namespace where the platform version of RS libs are provided.

- -

The RS HAL implementation from the vendor is not used at all when the CPU -fallback path is taken, and an RsContext object is created with -null mVendorDriverName. libRSDriver.so is (by default) -dlopened and the driver lib is loaded from the default -namespace because the caller (libRS_internal.so) is also loaded in -the default namespace.

+ +

+ Depending on the existence of the RS_CONTEXT_LOW_LATENCY bit + when creating an RS context, either the CPU or GPU path is selected. When the + CPU path is selected, libRS_internal.so (the main implementation + of the RS framework) is directly dlopened from the default linker + namespace where the platform version of RS libs are provided. +

+ +

+ The RS HAL implementation from the vendor is not used at all when the CPU + fallback path is taken, and an RsContext object is created with + null mVendorDriverName. libRSDriver.so is (by + default) dlopened and the driver lib is loaded from the + default namespace because the caller + (libRS_internal.so) is also loaded in the default + namespace. +

-
Figure 4. CPU fallback path.
+
+ Figure 4. CPU fallback path +

GPU path

-

For the GPU path, the libRS_internal.so is loaded differently. -First, libRS.so uses -android.hardware.renderscript@1.0.so (and its underlying -libhidltransport.so) to load -android.hardware.renderscript@1.0-impl.so (a vendor implementation -of RS HAL) into a different linker namespace called sphal. The RS -HAL then dlopens libRS_internal.so in a another linker -namespace called rs.

- -

Vendors can provide their own RS driver by setting the build-time flag -OVERRIDE_RS_DRIVER, which is embedded into the RS HAL -implementation -(hardware/interfaces/renderscript/1.0/default/Context.cpp). This -driver name is then dlopened for the RS context for the GPU path. -

- -

The creation of the RsContext object is delegated to the RS HAL -implementation. The HAL calls back to the RS framework using -rsContextCreateVendor() function with the name of the driver to use -as an argument. The RS framework then loads the specified driver when the -RsContext is initialized. In this case, the driver library is -loaded into the rs namespace because the RsContext -object is created inside the rs namespace and -/vendor/lib is in the search path of the namespace.

+ +

+ For the GPU path, the libRS_internal.so is loaded differently. + First, libRS.so uses + android.hardware.renderscript@1.0.so (and its underlying + libhidltransport.so) to load + android.hardware.renderscript@1.0-impl.so (a vendor + implementation of RS HAL) into a different linker namespace called + sphal. The RS + HAL then dlopens libRS_internal.so in a another + linker namespace called rs. +

+ +

+ Vendors can provide their own RS driver by setting the build time flag + OVERRIDE_RS_DRIVER, which is embedded into the RS HAL + implementation + (hardware/interfaces/renderscript/1.0/default/Context.cpp). This + driver name is then dlopened for the RS context for the GPU path. +

+ +

+ The creation of the RsContext object is delegated to the RS HAL + implementation. The HAL calls back to the RS framework using + rsContextCreateVendor() function with the name of the driver to + use as an argument. The RS framework then loads the specified driver when the + RsContext is initialized. In this case, the driver library is + loaded into the rs namespace because the RsContext + object is created inside the rs namespace and + /vendor/lib is in the search path of the namespace. +

-
Figure 5. GPU fallback path.
+
+ Figure 5. GPU fallback path +
-

When transitioning from the default namespace to the -sphal namespace, libhidltransport.so uses the -android_load_sphal_library() function to explicitly order the -dynamic linker to load the -impl.so library from the -sphal namespace.

+

+ When transitioning from the default namespace to the + sphal namespace, libhidltransport.so uses the + android_load_sphal_library() function to explicitly order the + dynamic linker to load the -impl.so library from the + sphal namespace. +

-

When transitioning from the sphal namespace to the rs -namespace, loading is done indirectly by the following line in -/system/etc/ld.config.txt:

+

+ When transitioning from the sphal namespace to the + rs namespace, loading is done indirectly by the following line in + /system/etc/ld.config.txt: +

 namespace.sphal.link.rs.shared_libs = libRS_internal.so
-

This line specifies the dynamic linker should load -libRS_internal.so from the rs namespace when the lib -can't be found/loaded from the sphal namespace (which is always the -case because sphal namespace does not search -/system/lib/vndk-sp where libRS_internal.so resides). -With this configuration, a simple dlopen() call to -libRS_internal.so is enough to make the namespace transition.

+

+ This line specifies the dynamic linker should load + libRS_internal.so from the rs namespace when the lib + can't be found/loaded from the sphal namespace (which is always + the case because sphal namespace does not search + /system/lib/vndk-sp where libRS_internal.so + resides). With this configuration, a simple dlopen() call to + libRS_internal.so is enough to make the namespace transition. +

Loading bcc plugin

-

bcc plugin is a vendor-provided library loaded into the -bcc compiler. Because bcc is a system process in the -/system/bin directory, the bcc plugin library can be -considered an SP-HAL (i.e., a vendor HAL that can be directly loaded into the -system process without being binderized). As an SP-HAL, the -bcc-plugin library:

+ +

+ bcc plugin is a vendor-provided library loaded into the + bcc compiler. Because bcc is a system process in the + /system/bin directory, the bcc plugin library can be + considered an SP-HAL (i.e., a vendor HAL that can be directly loaded into the + system process without being binderized). As an SP-HAL, the + bcc-plugin library: +

+
    -
  • Cannot link against framework-only libraries such as -libLLVM.so.
    • -
  • Can link against only the VNDK-SP libraries available to the -vendor.
    • +
  • Cannot link against framework-only libraries such as + libLLVM.so.
    • +
  • Can link against only the VNDK-SP libraries available to the vendor.
-

This restriction is enforced by loading the bcc plugin into the -sphal namespace using the android_sphal_load_library() -function. In previous versions of Android, the plugin name was specified using -the -load option and the lib was loaded using the simple -dlopen() by libLLVM.so. In Android O, this is -specified in -plugin option and the lib is directly loaded by the -bcc itself. This option enables a non-Android-specific path to -the open source LLVM project.

+

+ This restriction is enforced by loading the bcc plugin into the + sphal namespace using the + android_sphal_load_library() function. In previous versions of + Android, the plugin name was specified using the -load option and + the lib was loaded using the simple dlopen() by + libLLVM.so. In Android 8.0 and higher, this is specified in the + -plugin option and the lib is directly loaded by the + bcc itself. This option enables a non-Android-specific path to + the open source LLVM project. +

-
Figure 6. Loading bcc plugin, Android 7.x and -earlier.
+
+ Figure 6. Loading bcc plugin, Android 7.x and lower +


-
Figure 7. Loading bcc plugin, Android O. +
Figure 7. Loading bcc plugin, Android 8.0 and + higher

Search paths for ld.mc

-

When executing ld.mc, some RS runtime libs are given as inputs -to the linker. The RS bitcode from the app is linked against the runtime libs -and when the converted bitcode is loaded into an app process, the runtime libs -are again dynamically linked from the converted bitcode.

+ +

+ When executing ld.mc, some RS runtime libs are given as inputs + to the linker. The RS bitcode from the app is linked against the runtime libs + and when the converted bitcode is loaded into an app process, the runtime libs + are again dynamically linked from the converted bitcode. +

Runtime libs include:

+
    -
  • libcompiler_rt.so
    • -
  • libm.so
    • -
  • libc.so
    • -
  • RS driver (either libRSDriver.so or -OVERRIDE_RS_DRIVER)
    • +
  • libcompiler_rt.so
    • +
  • libm.so
    • +
  • libc.so
    • +
  • RS driver (either libRSDriver.so or + OVERRIDE_RS_DRIVER)
-

When loading the compiled bitcode into the app process, we must provide the -exact same library that was used by ld.mc. Otherwise, the compiled -bitcode may not find a symbol which was available when it was linked.

+

+ When loading the compiled bitcode into the app process, provide the exact same + library that was used by ld.mc. Otherwise, the compiled bitcode + may not find a symbol which was available when it was linked. +

-

To do so, RS framework uses different search paths for the runtime libs when -executing ld.mc, depending on whether the RS framework itself is -loaded from /system/lib or from /system/lib/vndk-sp. -This can be determined by reading the address of an arbitrary symbol of a RS -framework lib and using dladdr() to get the file path mapped to the -address.

+

+ To do so, RS framework uses different search paths for the runtime libs when + executing ld.mc, depending on whether the RS framework itself is + loaded from /system/lib or from /system/lib/vndk-sp. + This can be determined by reading the address of an arbitrary symbol of a RS + framework lib and using dladdr() to get the file path mapped to + the address. +

SELinux policy

-

As a result of the SELinux policy changes in Android O, you must follow -specific rules (enforced through neverallows) when labelling -additional files in vendor partition:

+ +

+ As a result of the SELinux policy changes in Android 8.0 and higher, you must + follow specific rules (enforced through neverallows) when + labelling additional files in vendor partition: +

+
    -
  • vendor_file must be the default label in for all files in -vendor partition. The platform policy requires this to access -passthrough HAL implementations.
    • -
  • All new exec_types added in vendor partition -through vendor SEPolicy must have vendor_file_type attribute. This -is enforced through neverallows.
    • -
  • To avoid conflicts with future platform/framework updates, avoid labelling -files other than exec_types in vendor partition. -
  • All library dependencies for AOSP-identified same process HALs must be -labelled as same_process_hal_file.
    • +
  • vendor_file must be the default label in for all files in + vendor partition. The platform policy requires this to access + passthrough HAL implementations.
    • +
  • All new exec_types added in vendor partition + through vendor SEPolicy must have vendor_file_type attribute. + This is enforced through neverallows.
    • +
  • To avoid conflicts with future platform/framework updates, avoid labelling + files other than exec_types in vendor partition. +
    • +
  • All library dependencies for AOSP-identified same process HALs must be + labelled as same_process_hal_file.
- +

+ For details on SELinux policy, see + Security-Enhanced Linux in Android. +

ABI compatibility for bitcode

-

If no new APIs are added, which means no HAL version bump, the RS frameworks -will keep using the existing GPU (HAL 1.0) driver.

-

For minor HAL changes (HAL 1.1) not affecting bitcode, the frameworks should -fallback to CPU for these newly added APIs and keep using GPU (HAL 1.0) driver -elsewhere.

+

+ If no new APIs are added, which means no HAL version bump, the RS frameworks + will keep using the existing GPU (HAL 1.0) driver. +

-

For major HAL changes (HAL 2.0) affecting bitcode compilation/linking, RS -frameworks should choose not to load vendor-provided GPU drivers and instead use -the CPU or Vulkan path for acceleration.

+

+ For minor HAL changes (HAL 1.1) not affecting bitcode, the frameworks should + fallback to CPU for these newly added APIs and keep using GPU (HAL 1.0) driver + elsewhere. +

+ +

+ For major HAL changes (HAL 2.0) affecting bitcode compilation/linking, RS + frameworks should choose not to load vendor-provided GPU drivers and instead + use the CPU or Vulkan path for acceleration. +

Consuming RenderScript bitcode occurs in three stages:

@@ -310,114 +392,145 @@ the CPU or Vulkan path for acceleration.

Compile -
    -
  • The input bitcode (.bc) for bcc must be in -LLVM 3.2 bitcode format and bcc must be backward -compatible with existing (legacy) apps.
    • -
  • However, the meta-data in .bc could change (there could new runtime -functions, e.g, Allocation setters ∓ getters, math functions, etc.). Part -of the runtime functions lives in libclcore.bc, part of them -lives in LibRSDriver or vendor equivalent.
    • -
  • New runtime functions or breaking meta-data changes require incrementing -the bitcode API level. Because vendor drivers won't be able to consume it, the -HAL version must also be incremented.
    • -
  • Vendors may have their own compilers, but the conclusions/requirements for -bcc also apply to those compilers.
    • -
+ +
    +
  • The input bitcode (.bc) for bcc must be in + LLVM 3.2 bitcode format and bcc must be backward + compatible with existing (legacy) apps.
    • +
  • However, the meta-data in .bc could change (there could new runtime + functions, e.g, Allocation setters ∓ getters, math functions, etc.). Part + of the runtime functions lives in libclcore.bc, part of them + lives in LibRSDriver or vendor equivalent.
    • +
  • New runtime functions or breaking meta-data changes require incrementing + the bitcode API level. Because vendor drivers won't be able to consume it, + the HAL version must also be incremented.
    • +
  • Vendors may have their own compilers, but the conclusions/requirements + for bcc also apply to those compilers.
    • +
+ Link -
    -
  • The compiled .o will be linked with vendor driver, e.g, -libRSDriver_foo.so, and libcompiler_rt.so. The CPU -path will link with libRSDriver.so.
    • -
  • If the .o requires a new runtime API from libRSDriver_foo, the -vendor driver has to be updated to support it.
    • -
  • Certain vendors may have their own linkers, but the argument for -ld.mc also apply to them.
    • -
+ +
    +
  • The compiled .o will be linked with vendor driver, e.g, + libRSDriver_foo.so, and libcompiler_rt.so. The CPU + path will link with libRSDriver.so.
    • +
  • If the .o requires a new runtime API from libRSDriver_foo, + the vendor driver has to be updated to support it.
    • +
  • Certain vendors may have their own linkers, but the argument for + ld.mc also apply to them.
    • +
+ Load -
    -
  • libRSCpuRef loads the the shared object. If there are changes -to this interface, a HAL version bump is needed.
    • -
  • Vendors would either rely on libRSCpuRef to load the shared -object, or implement their own.
    • -
+ +
    +
  • libRSCpuRef loads the shared object. If there are + changes to this interface, a HAL version bump is needed.
    • +
  • Vendors would either rely on libRSCpuRef to load the shared + object, or implement their own.
    • +
+ -

In addition to the HAL, runtime APIs and the exported symbols are also -interfaces. Neither interface has changed since Android 7.0 (API 24) and there -are no immediate plans to change it in Android O and beyond. However, if the -interface does change, the HAL version will also increment.

+

+ In addition to the HAL, runtime APIs and the exported symbols are also + interfaces. Neither interface has changed since Android 7.0 (API 24) and there + are no immediate plans to change it in Android 8.0 and beyond. However, if the + interface does change, the HAL version will also increment. +

Vendor implementations

-

Android O requires some GPU driver changes for the GPU driver to work -correctly.

+ +

+ Android 8.0 and higher requires some GPU driver changes for the GPU driver to + work correctly. +

Driver modules

+
    -
  • Driver modules must not depend on any system libraries that are not in -the list.
    • -
  • Driver must provide its own -android.hardware.renderscript@1.0-impl_{NAME}, or declare the -default implementation android.hardware.renderscript@1.0-impl as -its dependency.
    • -
  • CPU implementation libRSDriver.so is a good example of how to -remove non-VNDK-SP dependencies.
    • +
  • Driver modules must not depend on any system libraries that are not in + the list.
    • +
  • Driver must provide its own + android.hardware.renderscript@1.0-impl_{NAME}, or declare the + default implementation android.hardware.renderscript@1.0-impl as + its dependency.
    • +
  • CPU implementation libRSDriver.so is a good example of how to + remove non-VNDK-SP dependencies.

Bitcode compiler

-

You can compile RenderScript bitcode for the vendor driver in two ways:

+ +

+ You can compile RenderScript bitcode for the vendor driver in two ways: +

+
    -
  1. Invoke vendor-specific RenderScript compiler in /vendor/bin/ -(preferred method of GPU compilation). Similar to other driver modules, the -vendor compiler binary cannot depend on any system library that is not in the -list of RenderScript libs -available to vendors.
    2. -
  2. Invoke system bcc: /system/bin/bcc with a vendor-provided bcc -plugin. The bcc plugin cannot depend on any system library that is -not in the list of -RenderScript libs available to -vendors.
    3. +
  3. Invoke vendor-specific RenderScript compiler in /vendor/bin/ + (preferred method of GPU compilation). Similar to other driver modules, the + vendor compiler binary cannot depend on any system library that is not in the + list of RenderScript libs + available to vendors.
    4. +
  4. Invoke system bcc: /system/bin/bcc with a vendor-provided + bcc plugin; this plugin cannot depend on any system library that + is not in the list of + RenderScript libs available + to vendors.
-

If the vendor bcc plugin needs to interfere with the CPU -compilation and its dependency on libLLVM.so cannot be easily -removed, the vendor should copy bcc (and all the non-LL-NDK -dependencies, including libLLVM.so, libbcc.so) into -/vendor partition.

+

+ If the vendor bcc plugin needs to interfere with the CPU + compilation and its dependency on libLLVM.so cannot be easily + removed, the vendor should copy bcc (and all the non-LL-NDK + dependencies, including libLLVM.so, libbcc.so) into + /vendor partition. +

+ +

+ In addition, vendors need to make the following changes: +

-

In addition, vendors need to make the following changes:

-
Figure 8. Changes to vendor driver.
+
+ Figure 8. Changes to vendor driver +
+
    -
  1. Copy libclcore.bc to /vendor partition. This -ensures libclcore.bc, libLLVM.so, and -libbcc.so are in sync.
    2. -
  2. Change the path to the bcc executable by setting -RsdCpuScriptImpl::BCC_EXE_PATH from the RS HAL implementation.
    3. +
  3. Copy libclcore.bc to /vendor partition. This + ensures libclcore.bc, libLLVM.so, and + libbcc.so are in sync.
    4. +
  4. Change the path to the bcc executable by setting + RsdCpuScriptImpl::BCC_EXE_PATH from the RS HAL implementation. +
-