This change reverts following three changes to remove the no_apex
property. no_apex: true is equivalent to apex_available:
["//apex_available:platform"].
Revert "fix: "no_apex" can be put in defaults"
This reverts commit cc372c5b1d.
Revert "Add no_apex check for static library"
This reverts commit 2db7f46d0c.
Revert "Add no_apex property"
This reverts commit 4f7dd9b4db.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Ia4b094e371e9f8adff94ae6dc3ebb8e081381d4e
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
VNDK APEX should be named after the version of VNDK libs.
For example, if vndk_version is 29, then the apex name should be
com.android.vndk.v29. If vndk_version is not set or is 'current', then
the platform vndk version is implied.
This is done with setting "apex_name" with proper name.
Bug: 139774701
Test: m (soong test added)
Change-Id: I918252f12ccd351886030fe9139a020d6cf1ff32
For now, apex_name is used only for flattened apex.
Even if apex_name is set, the activation point of unflattened is
determined by 'name' in apex_manifest.json.
This change make apex_name as priority.
If apex_name is set, then use this for apex name
- update name in apex_manifest.json to apex_name
- do not check if key filename matches (use apex_name as key name)
This can be useful if soong wants to rename apex module. Simply setting
apex_name has the same effect of renaming "activation point" of apex.
But: 139774701
Test: m (soong test)
Change-Id: I8ea3645e4aa8f317997bc1443ec308ed0595b1c2
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
Translated second architectures now go in NativeBridgeArch instead
of DeviceSecondaryArch.
This reapplies I568046330abc002d4eed582cb999b62a5eaba790 with
ctx.Config().HasMulitlibConflict() added to fix the NDK build,
which has arm64, arm, x86_64, and x86 architectures enabled.
Test: m checkbuild
Test: OUT_DIR=out_ndk build/soong/scripts/build-ndk-prebuilts.sh
Test: no change to build.ninja or Android-aosp_cf_x86_phone.mk
Change-Id: Iadcafbd64bfb9579ae7c86914927c43a062b0c8e
Vendor variant is now divided into several vendor.{version} variants,
depending on their intended usages:
vendor.{BOARD_VNDK_VERSION}: vendor and vendor_available modules
vendor.{PLATFORM_VNDK_VERSION}: VNDK modules in the source tree
vendor.{snapshot_ver}: VNDK snapshot modules
This also affects exported module names from Soong to Make. But to
maintain backward compatibility, ".{BOARD_VNDK_VERSION}" suffix will not
be emitted for modules having version BOARD_VNDK_VERSION, so that vendor
modules still can be referred as-is.
Bug: 65377115
Bug: 68123344
Test: clean build and boot blueline
Change-Id: Ib9016a0f1fe06b97e9423fd95142653a89a343fa
"apex_vndk" is a variant of "apex" module.
apex_vndk {
name: "com.android.vndk",
..
}
This rule is used to produce a VNDK APEX per vndk version.
It supports automatic inclusion of vndk libs.
If "vndk_version" property is set, the prebuilt vndk libs of
the version will be included in the apex bundle.
apex_vndk {
name: "com.android.vndk.v29"
vndk_version: "29",
...
}
Otherwise, platform's vndk version is used.
This will replace /system/{lib}/vndk-{ver} and vndk-sp-{ver}.
Bug: 134357236
Bug: 139772411
Test: m com.android.vndk
Change-Id: Ib5c86e625839389670d13c683a7427198ef6852f
New property "apps" is added to APEX soong module. This property
configure a list of APKs to package inside APEX payload. For each
android_app module package it's APK into /app/$(android_app module Name)
directory.
Bug: 139906763
Test: m -j
Change-Id: Ic6655f211951af08097c76e157a07ebc52425718
If no_apex module is static library, this module is not included to
filesInfo. So add a check tat the static library is no_apex among
indirect dependencies.
Bug: 139016109
Test: m -j
Change-Id: I46ddf099715aea0e088027a1141e282969cef0e1
This will check if direct deps of android.Module type is "Enabled()".
Previously, this is checked only if a module calls VisitDeps*()
functions in GenerateAndroidBuildActions().
Most modules call VisitDeps*() in GenerateAndroidBuildActions(),
but some modules don't. For example, "apex" module calls
WalkDepsBlueprint() or VisitDirectDepsBlueprint() since it
exceptionally depends on non-android.Module modules.
Therefore, when an apex module depends on disabled(enabled:false) module,
build fails with panic, which is fixed by this change.
Test: m # runs soong tests
Change-Id: I81c5c148bbd51a253d2904690eb76ae7b6df1a0f
This change adds 'no_apex' property which, when set to true, prevents
the module from being installed to any APEX. If the module is included
either directly or transitively in an APEX, but build fails.
Bug: 139016109
Test: m
Change-Id: If1478aa9660a3442f7dd1ffe45e4ca5611a6acbe
"use_vendor: true" APEX modules may bundle vendor variants of cc
modules, which can depend on llndk stubs.
In that case, those llndk libraries should be also counted as required
libraries. (stored in 'requireNativeLibs' key in apex_manifest.json)
Bug: 138695532
Test: m nothing (runs soong tests)
Change-Id: If7ad4dec0e723c8d0c73ca60453b555063e14694
java_import can be included in apex via 'java_libs' property.
Bug: 139175488
Test: m (apex_test.go updated)
Change-Id: I3680a47cdac93b0cb2d41da8df3f8defa2bbe670
To generate ld.config.txt dynamically(b/123722631), each APEX should
provide some dependency information:
a) list of libraries which other APEXes(or system) can use from this apex
b) list of libraries which this apex uses from other APEXes(or system)
This change puts dependency information in apex_manifest.json at
build-time with two additional keys:
a) provideNativeLibs
b) requireNativeLibs
Bug: 138695532
Test: m (runs soong tests)
Test: find $OUT/apex -name apex_manifest.json -exec cat {} \;
(shows contents of apex_manifest.json files)
Change-Id: Iaad12c8c35454222ad177ce923cce76ef12a8a5a
In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the
"all tests" ("") module as `module` for all `apexFile` objects created
from a test module using `test_per_src: true`. An immediate issue of
this situation was that the "" module is hidden from Make, which made
all the generated `apexFile` objects hidden from Make too. This would
break the construction of flattened APEXes, as they rely on Make logic
to install their files.
Instead of collecting `test_per_src` test variations' output files in
`cc.Module.GenerateAndroidBuildActions` and using them in
`apex.apexBundle.GenerateAndroidBuildActions` as part of handling the
"" variation as a direct dependency of an `apexBundle`, process them
as indirect dependencies (and do nothing for the "" variation direct
dependency).
Adjust the indirect dependency logic in
`apex.apexBundle.GenerateAndroidBuildActions` to allow not only
shared/runtime native libraries as indirect dependencies of an
`apexBundle`, but also `test_per_src` tests.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
Just like native libs, a java library that is included in an APEX is
mutated for the APEX. This allows us to infer the context (e.g.
sdk_version, etc.) for building a java library in an APEX.
Bug: 138182343
Test: apex_test added
Change-Id: I9292ea097b98e74a8a794f164bd2bed3921d6337
If a test module with a `test_per_src` property set to `true` is
included in an APEX module, add all the variants for mutator
`test_per_src` as dependencies of the APEX module (not just the
first one).
This is done by adding variation "" of mutator `test_per_src` when
adding a test dependency to an APEX module, which creates an indirect
dependency of the APEX module on all the `test_per_src` variants of
the test module. When generating outputs for the APEX bundle, fetch
and include the set of test outputs from the "" variant.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
For APEXes to share C++ native libraries, we need a new kind of depedency
between APEXes: "providing" APEXes and "using" APEXes. To reflect this
dependency two new properties are added.
provide_cpp_shared_libs: bool
this indicates that the current APEX module provides the native C++ shared
libs to other APEXes.
uses: []string
this indicates that the current APEX module uses the native C++ shared
libraries from APEXes listed.
With these two, "using" APEXes can omit shared libraries in its APEX
bundle and use them from the "providing" APEXes.
Note that without corresponding changes in ld.config.txt, this won't
work.(The linker namespaces should be configured so that user APEX can
access provided libs.)
Bug: 136975105
Test: m nothing (this will trigger soong's test)
Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
Instead of outputting an aggregated NOTICE file as an intermediate build
resource to allow Make to include it in the final system-wide NOTICE,
process and embed it as an asset in the final APEX. This allows us to
update the NOTICE contents automatically when an APEX is updated.
Fixes: 135218846
Test: Built mainline modules, apex_test.go
Change-Id: Ic851b330fe93be1f602907d44ecc7886c3b0171b
If embed_notices or ALWAYS_EMBED_NOTICES is set, collect NOTICE files
from all dependencies of the android_app, merge them with the app's own
one (if exists), transform it to HTML, gzip it, and put it as an asset
in the final APK output.
Bug: 135460391
Test: app_test.go
Change-Id: I52d92e2fd19b3f5f396100424665c5cc344190d8
no_libgcc is no longer needed anywhere. Move all occurances to no_libcrt
and remove no_libgcc.
Test: build
Change-Id: I6dd49db71d05d7685aa90cc837627f65e6742d6d
We use libgcc as fallback for symbols not present in libclang_rt
builtins, however we didn't know what exact symbols were being used,
some may not be intended to fallback.
Create libgcc_stripped, which only contains unwind symbols from libgcc.
Bug: 29275768
Test: bionic-unit-tests
Change-Id: I5b349fa6138e51663bf3b67109b880b4356da8e8
Target SDK version is used for targeting an APEX to a specific set of
platform builds. Usually, the targeting is unrestricted (in case the
APEX can run on all platforms), or based on platform SDK version (e.g.
28 for P). However, when the platform is under development and SDK is
not finalized, the targeting should be much more fine-grained; the
APEX should be targeted to a very specific build that supports the same
set of APIs that the APEX was built against.
To support that, target sdk version is automatically set by the build
system. When the platform is released or SDK is finalized, the target sdk
version set to the SDK version number. If not, it is set to
<version_code>.<fingerprint> (e.g., Q.123456).
Note that the target sdk version set by the build system is used only
when the target sdk version is not explicitly set in
AndroidManifest.xml.
Bug: 130541924
Test: UNBUNDLED_BUILD_SDKS_FROM_SOURCE=true \
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true \
TARGET_BUILD_APPS=com.android.tzdata m
build.ninja has --target_sdk_version Q.$$(cat out/soong/api_fingerprint.txt)
Test: aapt dump badging out/dist/com.android.tzdata.apex | grep \
targetSdkVersion shows:
targetSdkVersion:'Q.6ee443d9ad5f0cca7a43cfa97b7fc62a'
Change-Id: I086230d787f01075c28fc3f0163550300fa00212
* Makes it more inline with prebuilt_etc;
* For shim apexes, prebuilt_apex modules have pattern of
com.android.apex.cts.shim.v1_prebuilt, but I would prefer
pre-installed shim to be: /system/apex/com.android.apex.cts.shim.apex
Bug: 128677967
Bug: 127789981
Test: m
Change-Id: I34e3e078733420b5cf777fd6e3ce4d8c5796b19b
The public key associated with an APEX is always included in the APEX.
Obviously, the public keys are no longer installed to
/system/etc/security/apex
Bug: 128344735
Test: m
Change-Id: I1e1aef1d32597a447b57d49ab80bbfb921fa8178
Arch-specific source can be specified for prebuilt_apex as follows.
arch: {
arm64: {
src: "myapex-arm64.apex",
},
},
A note on the implementation. The Src property was not tagged as
`android:"arch_variant"` as usual. Instead, multiple Src properties are
explicitly declared like
struct Arch {
struct Arm {
struct Src *string
}
...
}
Corresponding Src property is manually selected according to the
MultiTargets()[0].
This is because prebuilt_apex is mutated only for android_common, in
order to have the same arch variant with the apex module type.
Therefore, we can't rely on the arch_variant tag.
Bug: 127789981
Test: m (apex_test amended)
Change-Id: I77dbe626171d8975f549bdb4af3c487232cf05f7
public_key and private_key properties support :module syntax so that the
key pairs can be dynamically created during the build, which is useful
for one-time keys.
Bug: 128960614
Test: m (apex_test amended)
Change-Id: I249b1d29f247784193b0d733a7b6a20274ece105
Notice file for an APEX is created by merging notice files for the
modules included in it (plus the notice file for the APEX itself if
specified).
Notice files having the same content are not duplicated; it is emitted
only once.
Bug: 128701495
Test: m (apex_test is amended)
Test: m and inspect $(PRODUCT_OUT)/obj/NOTICE.txt to check there are
license entries for /system/apex/*.apex files
Change-Id: I169d91038291a6c71615de97cf5b03174afab5d4
apex_key, when with product_specific: true, is installed to
/product/etc/security/apex.
Bug: 128519063
Test: m (apex_test.go amended)
Change-Id: I39e8ac1c486c734dfe0555cd1874468d75e71f34
The manifest and androidManifest properties in the apex module type now
supports ":name" syntax.
Bug: 123857186
Test: m (apex_test amended)
Change-Id: Ic4e5a73cf73260d156ec61d07932ad07b2561413
Some test and other miscallaneous use-cases need apexs that are
installable but will not affect the installation of other artifacts
onto the device. For this purpose we added a test_apex type. These
test_apex targets create apex files and have all the normal attributes
but are not considered the source of any of their contents for the
device by the rest of the build-system.
Test: build and boot
Test: ALLOW_MISSING_DEPENDENCIES=true \
DIST_DIR=$ANDROID_BUILD_TOP/out/dist \
./art/tools/dist_linux_bionic.sh -j72 showcommands com.android.runtime.host
Bug: 123591866
Bug: 123892969
Change-Id: I7f50be0ac0425cd87868145e18bcee6962d472ef
relative_install_path for cc_library is respected by APEX.
relative_install_path for cc_binary is not yet respected because doing
it will break the path to the dynamic linker in the runtime APEX.
That change should be done along with changes in init, bionic, etc.
Bug: 123721777
Test: m (apex_test.go amended)
Change-Id: I855f8eda0d4255d563861ac96d0d3e2c669e9a2a
Some apex targets need to be able to change their contents based on if
they are host or target or what libc they are using. This adds support
for doing this using the standard 'target: {...}' idiom.
Test: m com.android.runtime.host
Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 123591866
Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
Some modules rely on symlink_preferred_arch to have expected files
present. This change makes apexs include these symlinks.
Test: m com.android.runtime.debug
pushd $(mktemp -d)
mkdir mnt
unzip $OUT/apex/system/com.android.runtime.debug.apex
sudo mount -o loop,ro apex_payload.img mnt
Ensure that mnt/bin/dalvikvm and mnt/bin/dex2oatd both exist and
are symlinks to mnt/bin/dalvikvm64 and mnt/bin/dex2oatd32
respectively.
Bug: 119942078
Bug: 122373634
Bug: 123079311
Change-Id: I47868fbedc5bdd3141a836c488f79e91e0a6ddfe
Add a dependency from a stubs lib to headers libs so that the headers
can be re-exported.
Bug: 122717287
Test: m; a test added to apex_test.go
Change-Id: I8d48c072815c6b02d343ef09cb44dfc6d1af8e64
A module can be built multiple times when it is referenced from one
or more APEXes. Sometimes, it is required for the module to behave
differently depending on the context; e.g., do A when built form
APEX M, do B when built for APEX N, and do C when built for platform.
The idea is to have a macro __ANDROID_APEX__ which is set to the
name of the apex that the module is built for. It is undefined when
the module is built for platform.
Bug: 122714993
Test: m (apex_test amended)
Change-Id: I11a89c6a0e799f4810194de7ef9ee472a71ca498
When PRODUCT_DEFAULT_DEV_CERTIFICATE is set to /vendor/foo/devkeys/test,
then the public/private key pairs for an apex_key is searched at
/vendor/foo/devkeys directory.
To be specific,
/system/timezone/Android.bp:
apex_key {
name: "timezone.key",
public_key: "com.android.tzdata.avbpubkey",
private_key: "com.android.tzdata.pem",
}
When PRODUCT_DEFAULT_DEV_CERTIFICATE isn't set, the keys are searched at
/system/timezone, which is the path where Android.bp is located.
With PRODUCT_DEFAULT_DEV_CERTIFICATE set to /vendor/foo/devkeys/test,
the keys are searched at /vendor/foo/devkeys.
Bug: 121224311
Test: m (apex_test updated)
Test: m with crosshatch (PRODUCT_DEFAULT_DEV_CERTIFICATE is set to
/vendor/google/...)
Test: m with cheets (PRODUCT_DEFAULT_DEV_CERTIFICATE is set, but there
is no apex key there. The product is with TARGET_FLATTEN_APEX := true)
Change-Id: I213bbb96c433d851f9cc982871459fd7fb4fe47d
If a lib is directly included in an APEX (via native_shared_libs
property) and the lib has stubs (via stubs.versions property), then the
ordinary non-stubs variant of the library is renamed to
<libname>.bootstrap in the makefile. At the same time, the stubs variant
of the lib becomes visible and it's name is <libname>.
This ensures that modules in Android.mk build against the stubs
variant thus preventing them from using private APIs in the lib.
The non-stubs variant, however, is used if the module explicitly has
set the new 'bootstrap' property to true. This is useful for building
some early binaries (such as init and vold) which need to run before
APEXes are activated. Since they can't use the bionic libs from the
runtime APEX, they should use the bionic libs left in the system
partition which is called the boostrap bionic.
Bug: 120266448
Test: m
Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I882b8aeb5b29460f07b4424e4f8eb844d6c9a9b0
This commit renames `_platform` suffix to `` (empty string) so that
non-apex variations are not renamed to `_core_shared_platform` or
`_vendor_shared_platform`.
This commit makes sure that `_core_shared` and `_vendor_shared` is
always under `$OUT_DIR/soong` regardless the usages from apex modules.
Furthermore, this avoids the confusing stale lsdump files (e.g. both
`_core_shared` and `_core_shared_platform exist) while creating
reference ABI dumps for VNDK ABI checks.
Bug: 121986692
Test: lunch aosp_arm64-userdebug; make # no more _platform variants.
Change-Id: Ic02a60ac45f982580349661c22331d114617fd92
This CL fixes the problem that when a lib is defined with stubs, the
stubs variantof the lib is installed to the APEX. This was happening
because the non-stubs variant is the last variant of the 'version'
variants and addFarVariationDependencies selects the first variant when
the 'version' variant isn't specified.
Fixing the problem by making the non-stubs variant (whose name is "")
the first variant.
Test: m (apex_test)
Change-Id: I1505fd2f29a0d70c916bad51000aa06f2b80b137
This change fixes following problem:
1) a native lib having stubs is defined.
2) the lib is included in an APEX.
3) a static binary is linking the lib from outside of the APEX.
4) then, the dependency from the binary to the lib is vanishing.
This is happening because cc.depsToPaths() mistakely does not
distinguish static lib deps from shared lib deps. For shared lib deps,
it creates two dependencies (one for stubs variant and the other for
non-stubs variant) and choose the stubs variant when the lib and the
current module is not in the same APEX (i.e. dependency to the non-stubs
variant is discarded). However, since we don't have stubs variant for
static library, it ends up having no dependency to the library if the
link is static.
Fixing the issue by skipping the variant selection routine when the link
is static.
Test: m (apex_test added)
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I21102a31cc5c0b105da2affdd035bd5cc571a6ab
use_vendor, when set to true, brings vendor variant of the native
libraries and binaries to the APEX.
Bug: 115707625
Test: m (apex_test updated)
Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
Now, symbols that are only to be visible to across APEXes can be tagged
as # vndk. Then when generating the stubs library, the tagged symbol
is included. The symbol is NOT included in other cases; build NDK stubs,
etc.
Bug: 120638081
Test: m (apex_test updated.)
Change-Id: Idb2b552badddfc26af113cc8d4b984788f478813
Otherwise, the force included headers might cause conflicting types
error with the symbols in the generated stubs source code. e.g.
double acos(double); // in header
void acos() {} // in the generated source code
Bug: 120266448
Test: m (apex_test also updated, and passing)
Change-Id: I717df990959d1b24ec515f0f52a4e28b94e92f32
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
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
