apex { name: "foo", native_shared_libs: ["mylib"] }
cc_library { name: "mylib", shared_libs: ["other_lib"],
stubs: { versions: ["1"]}, }
This is causing build error due to missing variant for other_lib.
This is happening because the stubs variant of mylib is added to apex
foo instead of the non-stubs variant. Because stubs variant does not
have any further dependencies, other_lib is not included to the APEX and
is not built for it.
Fixing this issue by specifying the version variant when adding a lib to
the dependency of an APEX, so that non-stub variant of the lib is
depended on.
Test: m (apex_test updated)
Change-Id: I972b6dcbce11942f83a76212715ba915534ec3df
This change fixes the bug that when a module is defined with sub_dir,
then build breaks when the module is included in an APEX.
This was happening because, for example when we have a prebuilt_etc
module having sub_dir set to "foo/bar", then only etc/foo/bar is added
to the canned_fs_config file and other intermediate directories (etc,
etc/foo) are not added. e2fsdroid however expects that every directories
to be listed.
Fixing the problem by adding parent directories when adding a directory
to canned_fs_config.
Bug: 120600179
Test: m (a new test case added to apex_test)
Change-Id: If712ff65761a7e1e3216371bb2eb7acf9cb5dc9e
Art needs to be able to create an ApexBundle with a LoadHook to
support art testing using the HOST_PREFER_32_BIT=true hack.
Bug: 120617876
Test: HOST_PREFER_32_BIT=true m nothing
Change-Id: Ia11e61a92094dfbc013c6c53a6edff33371ed8e1
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
