This adds support for an apex-like file where the payload is a zip
file instead of a FS image. This makes it easier to examine and use
without root. These can also be built for the host.
This can be controlled using the 'type' modifier in the apex build
rule. 'type' may be "image" to build an apex file called {name}.apex
with an FS image payload, "zip" to build an apex with called
{name}.zipapex with a zip-file payload or "both" to build both. By
default we will use "image".
This also adds support for setting apex rules to
"host_supported: true".
Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex
artifact.
Test: go test android/soong/apex -v
Bug: 120436895
Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
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
