summaryrefslogtreecommitdiff
path: root/python/builder.go
diff options
context:
space:
mode:
author Jiyong Park <jiyong@google.com> 2018-11-18 18:02:45 +0900
committer Jiyong Park <jiyong@google.com> 2018-12-04 17:46:22 +0900
commit25fc6a9cc9b665882f6a422462cbc5d0670af87c (patch)
tree3912fdf1ef4fac03019dd909f12849130f41ea01 /python/builder.go
parent2098eb8c2ab0313855c3715369658fee9b6e4383 (diff)
Stubs variant is used when building for APEX
When a native module is built for an APEX and is depending on a native library having stubs (i.e. stubs.versions property is set), the stubs variant is used unless the dependent lib is directly included in the same APEX with the depending module. Example: apex { name: "myapex", native_shared_libs: ["libX", "libY"], } cc_library { name: "libX", shared_libs: ["libY", "libZ"], } cc_library { name: "libY", stubs: { versions: ["1", "2"], }, } cc_library { name: "libZ", stubs: { versions: ["1", "2"], }, } In this case, libX is linking to the impl variant of libY (that provides private APIs) while libY is linking to the version 2 stubs of libZ. This is because libY is directly included in the same apex via native_shared_libs property, but libZ isn't. Bug: 112672359 Test: apex_test added Change-Id: If9871b70dc74a06bd828dd4cd1aeebd2e68b837c
Diffstat (limited to 'python/builder.go')
0 files changed, 0 insertions, 0 deletions