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
2018-11-18 10:02:45 +01:00
|
|
|
// Copyright 2018 Google Inc. All rights reserved.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
package apex
|
|
|
|
|
|
|
|
import (
|
|
|
|
"io/ioutil"
|
|
|
|
"os"
|
|
|
|
"strings"
|
|
|
|
"testing"
|
2018-12-19 09:12:36 +01:00
|
|
|
|
|
|
|
"github.com/google/blueprint/proptools"
|
|
|
|
|
|
|
|
"android/soong/android"
|
|
|
|
"android/soong/cc"
|
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
2018-11-18 10:02:45 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
func testApex(t *testing.T, bp string) *android.TestContext {
|
|
|
|
config, buildDir := setup(t)
|
|
|
|
defer teardown(buildDir)
|
|
|
|
|
|
|
|
ctx := android.NewTestArchContext()
|
2018-12-06 23:00:02 +01:00
|
|
|
ctx.RegisterModuleType("apex", android.ModuleFactoryAdaptor(ApexBundleFactory))
|
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
2018-11-18 10:02:45 +01:00
|
|
|
ctx.RegisterModuleType("apex_key", android.ModuleFactoryAdaptor(apexKeyFactory))
|
|
|
|
|
|
|
|
ctx.PostDepsMutators(func(ctx android.RegisterMutatorsContext) {
|
|
|
|
ctx.TopDown("apex_deps", apexDepsMutator)
|
|
|
|
ctx.BottomUp("apex", apexMutator)
|
|
|
|
})
|
|
|
|
|
|
|
|
ctx.RegisterModuleType("cc_library", android.ModuleFactoryAdaptor(cc.LibraryFactory))
|
|
|
|
ctx.RegisterModuleType("cc_library_shared", android.ModuleFactoryAdaptor(cc.LibrarySharedFactory))
|
2018-12-20 10:18:08 +01:00
|
|
|
ctx.RegisterModuleType("cc_binary", android.ModuleFactoryAdaptor(cc.BinaryFactory))
|
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
2018-11-18 10:02:45 +01:00
|
|
|
ctx.RegisterModuleType("cc_object", android.ModuleFactoryAdaptor(cc.ObjectFactory))
|
2018-12-19 09:12:36 +01:00
|
|
|
ctx.RegisterModuleType("llndk_library", android.ModuleFactoryAdaptor(cc.LlndkLibraryFactory))
|
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
2018-11-18 10:02:45 +01:00
|
|
|
ctx.RegisterModuleType("toolchain_library", android.ModuleFactoryAdaptor(cc.ToolchainLibraryFactory))
|
2018-12-06 16:42:25 +01:00
|
|
|
ctx.RegisterModuleType("prebuilt_etc", android.ModuleFactoryAdaptor(android.PrebuiltEtcFactory))
|
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
2018-11-18 10:02:45 +01:00
|
|
|
ctx.PreDepsMutators(func(ctx android.RegisterMutatorsContext) {
|
2018-12-19 09:12:36 +01:00
|
|
|
ctx.BottomUp("image", cc.ImageMutator).Parallel()
|
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
2018-11-18 10:02:45 +01:00
|
|
|
ctx.BottomUp("link", cc.LinkageMutator).Parallel()
|
2018-12-19 09:12:36 +01:00
|
|
|
ctx.BottomUp("vndk", cc.VndkMutator).Parallel()
|
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
2018-11-18 10:02:45 +01:00
|
|
|
ctx.BottomUp("version", cc.VersionMutator).Parallel()
|
|
|
|
ctx.BottomUp("begin", cc.BeginMutator).Parallel()
|
|
|
|
})
|
|
|
|
|
|
|
|
ctx.Register()
|
|
|
|
|
|
|
|
bp = bp + `
|
|
|
|
toolchain_library {
|
|
|
|
name: "libcompiler_rt-extras",
|
|
|
|
src: "",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
toolchain_library {
|
|
|
|
name: "libatomic",
|
|
|
|
src: "",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
toolchain_library {
|
|
|
|
name: "libgcc",
|
|
|
|
src: "",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
toolchain_library {
|
|
|
|
name: "libclang_rt.builtins-aarch64-android",
|
|
|
|
src: "",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
toolchain_library {
|
|
|
|
name: "libclang_rt.builtins-arm-android",
|
|
|
|
src: "",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
cc_object {
|
|
|
|
name: "crtbegin_so",
|
|
|
|
stl: "none",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
cc_object {
|
|
|
|
name: "crtend_so",
|
|
|
|
stl: "none",
|
2018-12-19 09:12:36 +01:00
|
|
|
vendor_available: true,
|
|
|
|
recovery_available: true,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
2018-12-19 09:12:36 +01:00
|
|
|
llndk_library {
|
|
|
|
name: "libc",
|
|
|
|
symbol_file: "",
|
|
|
|
}
|
|
|
|
|
|
|
|
llndk_library {
|
|
|
|
name: "libm",
|
|
|
|
symbol_file: "",
|
|
|
|
}
|
|
|
|
|
|
|
|
llndk_library {
|
|
|
|
name: "libdl",
|
|
|
|
symbol_file: "",
|
|
|
|
}
|
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
2018-11-18 10:02:45 +01:00
|
|
|
`
|
|
|
|
|
|
|
|
ctx.MockFileSystem(map[string][]byte{
|
2019-01-19 11:24:06 +01:00
|
|
|
"Android.bp": []byte(bp),
|
|
|
|
"build/target/product/security": nil,
|
|
|
|
"apex_manifest.json": nil,
|
|
|
|
"system/sepolicy/apex/myapex-file_contexts": nil,
|
|
|
|
"system/sepolicy/apex/otherapex-file_contexts": nil,
|
|
|
|
"mylib.cpp": nil,
|
|
|
|
"myprebuilt": nil,
|
|
|
|
"vendor/foo/devkeys/test.x509.pem": nil,
|
|
|
|
"vendor/foo/devkeys/test.pk8": nil,
|
|
|
|
"vendor/foo/devkeys/testkey.avbpubkey": nil,
|
|
|
|
"vendor/foo/devkeys/testkey.pem": nil,
|
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
2018-11-18 10:02:45 +01:00
|
|
|
})
|
|
|
|
_, errs := ctx.ParseFileList(".", []string{"Android.bp"})
|
|
|
|
android.FailIfErrored(t, errs)
|
|
|
|
_, errs = ctx.PrepareBuildActions(config)
|
|
|
|
android.FailIfErrored(t, errs)
|
|
|
|
|
|
|
|
return ctx
|
|
|
|
}
|
|
|
|
|
|
|
|
func setup(t *testing.T) (config android.Config, buildDir string) {
|
|
|
|
buildDir, err := ioutil.TempDir("", "soong_apex_test")
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
config = android.TestArchConfig(buildDir, nil)
|
2018-12-19 09:12:36 +01:00
|
|
|
config.TestProductVariables.DeviceVndkVersion = proptools.StringPtr("current")
|
2018-12-24 03:31:58 +01:00
|
|
|
config.TestProductVariables.DefaultAppCertificate = proptools.StringPtr("vendor/foo/devkeys/test")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
func teardown(buildDir string) {
|
|
|
|
os.RemoveAll(buildDir)
|
|
|
|
}
|
|
|
|
|
|
|
|
// ensure that 'result' contains 'expected'
|
|
|
|
func ensureContains(t *testing.T, result string, expected string) {
|
|
|
|
if !strings.Contains(result, expected) {
|
|
|
|
t.Errorf("%q is not found in %q", expected, result)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// ensures that 'result' does not contain 'notExpected'
|
|
|
|
func ensureNotContains(t *testing.T, result string, notExpected string) {
|
|
|
|
if strings.Contains(result, notExpected) {
|
|
|
|
t.Errorf("%q is found in %q", notExpected, result)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func ensureListContains(t *testing.T, result []string, expected string) {
|
|
|
|
if !android.InList(expected, result) {
|
|
|
|
t.Errorf("%q is not found in %v", expected, result)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func ensureListNotContains(t *testing.T, result []string, notExpected string) {
|
|
|
|
if android.InList(notExpected, result) {
|
|
|
|
t.Errorf("%q is found in %v", notExpected, result)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Minimal test
|
|
|
|
func TestBasicApex(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["mylib2"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib2",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
`)
|
|
|
|
|
|
|
|
apexRule := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("apexRule")
|
|
|
|
copyCmds := apexRule.Args["copy_commands"]
|
|
|
|
|
|
|
|
// Ensure that main rule creates an output
|
|
|
|
ensureContains(t, apexRule.Output.String(), "myapex.apex.unsigned")
|
|
|
|
|
|
|
|
// Ensure that apex variant is created for the direct dep
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureListContains(t, ctx.ModuleVariantsForTests("mylib"), "android_arm64_armv8-a_core_shared_myapex")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that apex variant is created for the indirect dep
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureListContains(t, ctx.ModuleVariantsForTests("mylib2"), "android_arm64_armv8-a_core_shared_myapex")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that both direct and indirect deps are copied into apex
|
2018-11-30 02:12:15 +01:00
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/mylib.so")
|
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/mylib2.so")
|
2018-12-26 08:32:21 +01:00
|
|
|
|
|
|
|
// Ensure that the platform variant ends with _core_shared
|
|
|
|
ensureListContains(t, ctx.ModuleVariantsForTests("mylib"), "android_arm64_armv8-a_core_shared")
|
|
|
|
ensureListContains(t, ctx.ModuleVariantsForTests("mylib2"), "android_arm64_armv8-a_core_shared")
|
2018-11-30 02:12:15 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestBasicZipApex(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
payload_type: "zip",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["mylib2"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib2",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
`)
|
|
|
|
|
|
|
|
zipApexRule := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("zipApexRule")
|
|
|
|
copyCmds := zipApexRule.Args["copy_commands"]
|
|
|
|
|
|
|
|
// Ensure that main rule creates an output
|
|
|
|
ensureContains(t, zipApexRule.Output.String(), "myapex.zipapex.unsigned")
|
|
|
|
|
|
|
|
// Ensure that APEX variant is created for the direct dep
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureListContains(t, ctx.ModuleVariantsForTests("mylib"), "android_arm64_armv8-a_core_shared_myapex")
|
2018-11-30 02:12:15 +01:00
|
|
|
|
|
|
|
// Ensure that APEX variant is created for the indirect dep
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureListContains(t, ctx.ModuleVariantsForTests("mylib2"), "android_arm64_armv8-a_core_shared_myapex")
|
2018-11-30 02:12:15 +01:00
|
|
|
|
|
|
|
// Ensure that both direct and indirect deps are copied into apex
|
|
|
|
ensureContains(t, copyCmds, "image.zipapex/lib64/mylib.so")
|
|
|
|
ensureContains(t, copyCmds, "image.zipapex/lib64/mylib2.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestApexWithStubs(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib", "mylib3"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["mylib2", "mylib3"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib2",
|
|
|
|
srcs: ["mylib.cpp"],
|
2018-12-13 10:37:29 +01:00
|
|
|
cflags: ["-include mylib.h"],
|
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
2018-11-18 10:02:45 +01:00
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["1", "2", "3"],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib3",
|
2018-12-07 14:42:47 +01:00
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["mylib4"],
|
|
|
|
system_shared_libs: [],
|
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
2018-11-18 10:02:45 +01:00
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["10", "11", "12"],
|
|
|
|
},
|
|
|
|
}
|
2018-12-07 14:42:47 +01:00
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib4",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
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
2018-11-18 10:02:45 +01:00
|
|
|
`)
|
|
|
|
|
|
|
|
apexRule := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("apexRule")
|
|
|
|
copyCmds := apexRule.Args["copy_commands"]
|
|
|
|
|
|
|
|
// Ensure that direct non-stubs dep is always included
|
2018-11-30 02:12:15 +01:00
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/mylib.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that indirect stubs dep is not included
|
2018-11-30 02:12:15 +01:00
|
|
|
ensureNotContains(t, copyCmds, "image.apex/lib64/mylib2.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that direct stubs dep is included
|
2018-11-30 02:12:15 +01:00
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/mylib3.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
2018-12-19 09:12:36 +01:00
|
|
|
mylibLdFlags := ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_shared_myapex").Rule("ld").Args["libFlags"]
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that mylib is linking with the latest version of stubs for mylib2
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, mylibLdFlags, "mylib2/android_arm64_armv8-a_core_shared_3_myapex/mylib2.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... and not linking to the non-stub (impl) variant of mylib2
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "mylib2/android_arm64_armv8-a_core_shared_myapex/mylib2.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that mylib is linking with the non-stub (impl) of mylib3 (because mylib3 is in the same apex)
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, mylibLdFlags, "mylib3/android_arm64_armv8-a_core_shared_myapex/mylib3.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// .. and not linking to the stubs variant of mylib3
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "mylib3/android_arm64_armv8-a_core_shared_12_myapex/mylib3.so")
|
2018-12-13 10:37:29 +01:00
|
|
|
|
|
|
|
// Ensure that stubs libs are built without -include flags
|
2018-12-19 09:12:36 +01:00
|
|
|
mylib2Cflags := ctx.ModuleForTests("mylib2", "android_arm64_armv8-a_core_static_myapex").Rule("cc").Args["cFlags"]
|
2018-12-13 10:37:29 +01:00
|
|
|
ensureNotContains(t, mylib2Cflags, "-include ")
|
2018-12-07 08:25:39 +01:00
|
|
|
|
|
|
|
// Ensure that genstub is invoked with --apex
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, "--apex", ctx.ModuleForTests("mylib2", "android_arm64_armv8-a_core_static_3_myapex").Rule("genStubSrc").Args["flags"])
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
|
|
|
|
Don't create unnecessary APEX variations
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
|
|
|
func TestApexWithExplicitStubsDependency(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["libfoo#10"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libfoo",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["libbar"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["10", "20", "30"],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libbar",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
`)
|
|
|
|
|
|
|
|
apexRule := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("apexRule")
|
|
|
|
copyCmds := apexRule.Args["copy_commands"]
|
|
|
|
|
|
|
|
// Ensure that direct non-stubs dep is always included
|
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/mylib.so")
|
|
|
|
|
|
|
|
// Ensure that indirect stubs dep is not included
|
|
|
|
ensureNotContains(t, copyCmds, "image.apex/lib64/libfoo.so")
|
|
|
|
|
|
|
|
// Ensure that dependency of stubs is not included
|
|
|
|
ensureNotContains(t, copyCmds, "image.apex/lib64/libbar.so")
|
|
|
|
|
2018-12-19 09:12:36 +01:00
|
|
|
mylibLdFlags := ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_shared_myapex").Rule("ld").Args["libFlags"]
|
Don't create unnecessary APEX variations
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
|
|
|
|
|
|
|
// Ensure that mylib is linking with version 10 of libfoo
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, mylibLdFlags, "libfoo/android_arm64_armv8-a_core_shared_10_myapex/libfoo.so")
|
Don't create unnecessary APEX variations
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
|
|
|
// ... and not linking to the non-stub (impl) variant of libfoo
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "libfoo/android_arm64_armv8-a_core_shared_myapex/libfoo.so")
|
Don't create unnecessary APEX variations
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
|
|
|
|
2018-12-19 09:12:36 +01:00
|
|
|
libFooStubsLdFlags := ctx.ModuleForTests("libfoo", "android_arm64_armv8-a_core_shared_10_myapex").Rule("ld").Args["libFlags"]
|
Don't create unnecessary APEX variations
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
|
|
|
|
|
|
|
// Ensure that libfoo stubs is not linking to libbar (since it is a stubs)
|
|
|
|
ensureNotContains(t, libFooStubsLdFlags, "libbar.so")
|
|
|
|
}
|
|
|
|
|
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
2018-11-18 10:02:45 +01:00
|
|
|
func TestApexWithSystemLibsStubs(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib", "mylib_shared", "libdl", "libm"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["libdl#27"],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library_shared {
|
|
|
|
name: "mylib_shared",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["libdl#27"],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libc",
|
|
|
|
no_libgcc: true,
|
|
|
|
nocrt: true,
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["27", "28", "29"],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libm",
|
|
|
|
no_libgcc: true,
|
|
|
|
nocrt: true,
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["27", "28", "29"],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libdl",
|
|
|
|
no_libgcc: true,
|
|
|
|
nocrt: true,
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["27", "28", "29"],
|
|
|
|
},
|
|
|
|
}
|
2018-12-20 14:10:17 +01:00
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libBootstrap",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
stl: "none",
|
|
|
|
bootstrap: true,
|
|
|
|
}
|
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
2018-11-18 10:02:45 +01:00
|
|
|
`)
|
|
|
|
|
|
|
|
apexRule := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("apexRule")
|
|
|
|
copyCmds := apexRule.Args["copy_commands"]
|
|
|
|
|
|
|
|
// Ensure that mylib, libm, libdl are included.
|
2018-11-30 02:12:15 +01:00
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/mylib.so")
|
2018-12-20 14:10:17 +01:00
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/bionic/libm.so")
|
|
|
|
ensureContains(t, copyCmds, "image.apex/lib64/bionic/libdl.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// Ensure that libc is not included (since it has stubs and not listed in native_shared_libs)
|
2018-12-20 14:10:17 +01:00
|
|
|
ensureNotContains(t, copyCmds, "image.apex/lib64/bionic/libc.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
2018-12-19 09:12:36 +01:00
|
|
|
mylibLdFlags := ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_shared_myapex").Rule("ld").Args["libFlags"]
|
|
|
|
mylibCFlags := ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_static_myapex").Rule("cc").Args["cFlags"]
|
|
|
|
mylibSharedCFlags := ctx.ModuleForTests("mylib_shared", "android_arm64_armv8-a_core_shared_myapex").Rule("cc").Args["cFlags"]
|
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
2018-11-18 10:02:45 +01:00
|
|
|
|
|
|
|
// For dependency to libc
|
|
|
|
// Ensure that mylib is linking with the latest version of stubs
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, mylibLdFlags, "libc/android_arm64_armv8-a_core_shared_29_myapex/libc.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... and not linking to the non-stub (impl) variant
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "libc/android_arm64_armv8-a_core_shared_myapex/libc.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... Cflags from stub is correctly exported to mylib
|
|
|
|
ensureContains(t, mylibCFlags, "__LIBC_API__=29")
|
|
|
|
ensureContains(t, mylibSharedCFlags, "__LIBC_API__=29")
|
|
|
|
|
|
|
|
// For dependency to libm
|
|
|
|
// Ensure that mylib is linking with the non-stub (impl) variant
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, mylibLdFlags, "libm/android_arm64_armv8-a_core_shared_myapex/libm.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... and not linking to the stub variant
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "libm/android_arm64_armv8-a_core_shared_29_myapex/libm.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... and is not compiling with the stub
|
|
|
|
ensureNotContains(t, mylibCFlags, "__LIBM_API__=29")
|
|
|
|
ensureNotContains(t, mylibSharedCFlags, "__LIBM_API__=29")
|
|
|
|
|
|
|
|
// For dependency to libdl
|
|
|
|
// Ensure that mylib is linking with the specified version of stubs
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureContains(t, mylibLdFlags, "libdl/android_arm64_armv8-a_core_shared_27_myapex/libdl.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... and not linking to the other versions of stubs
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "libdl/android_arm64_armv8-a_core_shared_28_myapex/libdl.so")
|
|
|
|
ensureNotContains(t, mylibLdFlags, "libdl/android_arm64_armv8-a_core_shared_29_myapex/libdl.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... and not linking to the non-stub (impl) variant
|
2018-12-19 09:12:36 +01:00
|
|
|
ensureNotContains(t, mylibLdFlags, "libdl/android_arm64_armv8-a_core_shared_myapex/libdl.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
// ... Cflags from stub is correctly exported to mylib
|
|
|
|
ensureContains(t, mylibCFlags, "__LIBDL_API__=27")
|
|
|
|
ensureContains(t, mylibSharedCFlags, "__LIBDL_API__=27")
|
2018-12-20 14:10:17 +01:00
|
|
|
|
|
|
|
// Ensure that libBootstrap is depending on the platform variant of bionic libs
|
|
|
|
libFlags := ctx.ModuleForTests("libBootstrap", "android_arm64_armv8-a_core_shared").Rule("ld").Args["libFlags"]
|
|
|
|
ensureContains(t, libFlags, "libc/android_arm64_armv8-a_core_shared/libc.so")
|
|
|
|
ensureContains(t, libFlags, "libm/android_arm64_armv8-a_core_shared/libm.so")
|
|
|
|
ensureContains(t, libFlags, "libdl/android_arm64_armv8-a_core_shared/libdl.so")
|
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
2018-11-18 10:02:45 +01:00
|
|
|
}
|
2018-12-06 16:42:25 +01:00
|
|
|
|
|
|
|
func TestFilesInSubDir(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
prebuilts: ["myetc"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
prebuilt_etc {
|
|
|
|
name: "myetc",
|
|
|
|
src: "myprebuilt",
|
|
|
|
sub_dir: "foo/bar",
|
|
|
|
}
|
|
|
|
`)
|
|
|
|
|
|
|
|
generateFsRule := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("generateFsConfig")
|
|
|
|
dirs := strings.Split(generateFsRule.Args["exec_paths"], " ")
|
|
|
|
|
|
|
|
// Ensure that etc, etc/foo, and etc/foo/bar are all listed
|
|
|
|
ensureListContains(t, dirs, "etc")
|
|
|
|
ensureListContains(t, dirs, "etc/foo")
|
|
|
|
ensureListContains(t, dirs, "etc/foo/bar")
|
|
|
|
}
|
2018-12-19 09:12:36 +01:00
|
|
|
|
|
|
|
func TestUseVendor(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
use_vendor: true,
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
shared_libs: ["mylib2"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
vendor_available: true,
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib2",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
vendor_available: true,
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
`)
|
|
|
|
|
|
|
|
inputsList := []string{}
|
|
|
|
for _, i := range ctx.ModuleForTests("myapex", "android_common_myapex").Module().BuildParamsForTests() {
|
|
|
|
for _, implicit := range i.Implicits {
|
|
|
|
inputsList = append(inputsList, implicit.String())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
inputsString := strings.Join(inputsList, " ")
|
|
|
|
|
|
|
|
// ensure that the apex includes vendor variants of the direct and indirect deps
|
|
|
|
ensureContains(t, inputsString, "android_arm64_armv8-a_vendor_shared_myapex/mylib.so")
|
|
|
|
ensureContains(t, inputsString, "android_arm64_armv8-a_vendor_shared_myapex/mylib2.so")
|
|
|
|
|
|
|
|
// ensure that the apex does not include core variants
|
|
|
|
ensureNotContains(t, inputsString, "android_arm64_armv8-a_core_shared_myapex/mylib.so")
|
|
|
|
ensureNotContains(t, inputsString, "android_arm64_armv8-a_core_shared_myapex/mylib2.so")
|
|
|
|
}
|
2018-12-20 10:18:08 +01:00
|
|
|
|
|
|
|
func TestStaticLinking(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
stubs: {
|
|
|
|
versions: ["1", "2", "3"],
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_binary {
|
|
|
|
name: "not_in_apex",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
static_libs: ["mylib"],
|
|
|
|
static_executable: true,
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_object {
|
|
|
|
name: "crtbegin_static",
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_object {
|
|
|
|
name: "crtend_android",
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
`)
|
|
|
|
|
|
|
|
ldFlags := ctx.ModuleForTests("not_in_apex", "android_arm64_armv8-a_core").Rule("ld").Args["libFlags"]
|
|
|
|
|
|
|
|
// Ensure that not_in_apex is linking with the static variant of mylib
|
2018-12-26 08:32:21 +01:00
|
|
|
ensureContains(t, ldFlags, "mylib/android_arm64_armv8-a_core_static/mylib.a")
|
2018-12-20 10:18:08 +01:00
|
|
|
}
|
2018-12-24 03:31:58 +01:00
|
|
|
|
|
|
|
func TestKeys(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
`)
|
|
|
|
|
|
|
|
// check the APEX keys
|
|
|
|
keys := ctx.ModuleForTests("myapex.key", "").Module().(*apexKey)
|
|
|
|
|
|
|
|
if keys.public_key_file.String() != "vendor/foo/devkeys/testkey.avbpubkey" {
|
|
|
|
t.Errorf("public key %q is not %q", keys.public_key_file.String(),
|
|
|
|
"vendor/foo/devkeys/testkey.avbpubkey")
|
|
|
|
}
|
|
|
|
if keys.private_key_file.String() != "vendor/foo/devkeys/testkey.pem" {
|
|
|
|
t.Errorf("private key %q is not %q", keys.private_key_file.String(),
|
|
|
|
"vendor/foo/devkeys/testkey.pem")
|
|
|
|
}
|
|
|
|
|
|
|
|
// check the APK certs
|
|
|
|
certs := ctx.ModuleForTests("myapex", "android_common_myapex").Rule("signapk").Args["certificates"]
|
|
|
|
if certs != "vendor/foo/devkeys/test.x509.pem vendor/foo/devkeys/test.pk8" {
|
|
|
|
t.Errorf("cert and private key %q are not %q", certs,
|
|
|
|
"vendor/foo/devkeys/test.x509.pem vendor/foo/devkeys/test.pk8")
|
|
|
|
}
|
|
|
|
}
|
2019-01-19 11:24:06 +01:00
|
|
|
|
|
|
|
func TestMacro(t *testing.T) {
|
|
|
|
ctx := testApex(t, `
|
|
|
|
apex {
|
|
|
|
name: "myapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex {
|
|
|
|
name: "otherapex",
|
|
|
|
key: "myapex.key",
|
|
|
|
native_shared_libs: ["mylib"],
|
|
|
|
}
|
|
|
|
|
|
|
|
apex_key {
|
|
|
|
name: "myapex.key",
|
|
|
|
public_key: "testkey.avbpubkey",
|
|
|
|
private_key: "testkey.pem",
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "mylib",
|
|
|
|
srcs: ["mylib.cpp"],
|
|
|
|
system_shared_libs: [],
|
|
|
|
stl: "none",
|
|
|
|
}
|
|
|
|
`)
|
|
|
|
|
|
|
|
// non-APEX variant does not have __ANDROID__APEX__ defined
|
|
|
|
mylibCFlags := ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_static").Rule("cc").Args["cFlags"]
|
|
|
|
ensureNotContains(t, mylibCFlags, "-D__ANDROID_APEX__=myapex")
|
|
|
|
ensureNotContains(t, mylibCFlags, "-D__ANDROID_APEX__=otherapex")
|
|
|
|
|
|
|
|
// APEX variant has __ANDROID_APEX__=<apexname> defined
|
|
|
|
mylibCFlags = ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_static_myapex").Rule("cc").Args["cFlags"]
|
|
|
|
ensureContains(t, mylibCFlags, "-D__ANDROID_APEX__=myapex")
|
|
|
|
ensureNotContains(t, mylibCFlags, "-D__ANDROID_APEX__=otherapex")
|
|
|
|
|
|
|
|
// APEX variant has __ANDROID_APEX__=<apexname> defined
|
|
|
|
mylibCFlags = ctx.ModuleForTests("mylib", "android_arm64_armv8-a_core_static_otherapex").Rule("cc").Args["cFlags"]
|
|
|
|
ensureNotContains(t, mylibCFlags, "-D__ANDROID_APEX__=myapex")
|
|
|
|
ensureContains(t, mylibCFlags, "-D__ANDROID_APEX__=otherapex")
|
|
|
|
}
|