The change fixes the problem that multiple APEXs having native component
(shared lib or executable) can't be built with an error similar to this:
error: bionic/linker/Android.bp:298:1: failed to find variation "com.android.art" for module "libclang_rt.builtins-aarch64-android" needed by "ld-android"
This is happening because the dependency to the built-in library is
arch-specific but apex.go ignores it. Specifically, let's assume that
32-bit variant of libFoo depends on libX while 64-bit variant of libFoo
depends on libY. Also assume that libFoo is included in two APEXs: apex1
(which is 64-bit) and apex2 (which is 32-bit). Then apexDepsMutator
records that libFoo shall be split into apex1 and apex2, while libX will
be only split into apex1 and libY will be split into apex2.
The problem is that, during apexMutator, both 32 and 64-bit varants of
libFoo are split into apex1 and apex2. As a result, a dependency to
apex2 variant of libX and a dependency to apex1 variant of libY are
requested, which don't exist.
Fixing this issue by using module's name AND target string as the key.
So, only the 32-bit variant of libFoo is split into apex1 and 64-bit
variant of libFoo is split into apex2.
Test: have following module somewhere. `m` is successful.
apex {
name: "com.android.art",
manifest: "manifest.json",
file_contexts: "file_contexts",
binaries: ["dex2oat"],
key: "apex.test.key",
target: {
android: {
// Prefer the 32-bit versions of these binaries.
compile_multilib: "prefer32",
},
},
}
Change-Id: I562b7be8e7c0325bd8d728dbee2ddcae608c181a
678529ef29