This reverts commit 380fc3615c.
Reason for revert: breaking one of internal targets
Change-Id: Ica96c44078e5a7f674410828af3ba851317775dd
Exempt-From-Owner-Approval: revert to fix build failure
When exporting Soong modules to Makefile, each VNDK snapshot module
whose version is BOARD_VNDK_VERSION has ".vendor" suffix. So makeLibName
should also return ".vendor", not the full vndk snapshot suffix like
".vndk.29.arm64.vendor".
Exempt-From-Owner-Approval: cherry-pick
Bug: 151274994
Test: manual build with snapshot
Change-Id: I48f606f90f6c5ca55d0a5bc29bad491c38a44f47
Merged-In: I48f606f90f6c5ca55d0a5bc29bad491c38a44f47
(cherry picked from commit 7ac1fa7823)
Even though use_vendor:true is prohibited, there is media.swcodec apex
which is still use_vendor: true and also needs to support Android10.
(min_sdk_version: 29)
Because LLNDK stubs were provided only for the current VNDK version,
media.swcodec couldn't be built against min_sdk_version: 29.
This change introduces additional versions for LLNDK stubs which are
enforced when an apex with use_vendor: true sets min_sdk_version.
To make things easier, the versions of LLNDK stubs are borrowed from its
implementation libraries.
Bug: 147450930
Bug: 149591522
Test: TARGET_BUILD_APPS=com.android.media.swcodec m
(with min_sdk_version: 29 set)
check if liblog/libc/libm/libdl stubs are 29
check if 29 stubs don't have new symbols.
Change-Id: I79946cbb4da6617138a96d2b254349d3a298e77b
This change ensures that the runtime dependencies between a
binary/shared library are correctly specified in the snapshot so that
the build can ensure that shared libraries are built before the targets
that use them.
It adds support for differentiating between references that are
required to refer to another sdk member (required) and those that may
refer to either an sdk member or a non-sdk member (optional). The
latter is used for shared library references as the libraries used by
an sdk member may be provided from outside the sdk. e.g. liblog is not
part of the ART module but is used by some members of the ART sdk.
Bug: 142935992
Test: m nothing
Change-Id: Ia8509ffe79b208c23beba1880fe9c8a92b732685
The sdk snapshot creates two prebuilts for each member one that is
versioned and one that is not. If they are both installed then they
lead to duplicate rules in make for creating the same installed file.
This change adds an installable property to cc modules that will
prevent the installation of the file and then adds installable: false
on the versioned prebuilt for cc modules.
Bug: 142935992
Test: m nothing
Change-Id: I4cb294c2b0c8a3f411eea569775835d9e41726d6
sdk_version is passed for relevant variants.
If not specified or "current",
it maps to "10000" for platform variants, and
"min_sdk_version" of the apex for apex variants.
Bug: 150860940
Test: m (soong test)
manually check build.ninja
Change-Id: I5102ab0c5086b5ad29d16ac45af55d32062167b4
Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
VNDK and vendor snapshot singleton work in a single thread, so globbing
in singleton results in ridiculus running time. Moving codes to
GenerateAndroidBuildActions to reduce running time.
Bug: 150406226
Test: VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: vendorSnapshotSingleton build time became 0.56s (from 10s)
Test: build.ninja building time became 1m11s (from 1m21s)
Change-Id: I4a081eef5847c62ca00280ca426f5b4e10f87b59
To build vndk-ext for product variants use `vndk.extends` property
with `product_specific: true` as for the vndk-ext for vendor
variants. For example:
cc_library {
name: "libvndk_ext_product",
product_specific: true,
vndk: {
enabled: true,
extends: "libvndk",
},
}
It will install the vndk-ext libs for product variants in
product/lib[64]/vndk/
Test: m nothing
Bug: 147778025
Change-Id: If1ee5be93c579abad302f44f18e6316f27e70019
When there is a runtime depedency (via runtime_libs property) to a
library providing stable C APIs, the dependency is considered as
crossing APEX boundary. Therefore, the requested lib doesn't need to be
made available to the APEX where the requesting lib is in.
Bug: 147813447
Test: m
Change-Id: I9cf8a5877850fb85b92c851e15fac921b8b7641b
Bug: 149075752
Test: tapas com.android.conscrypt com.android.tethering arm64
Test: m out/target/product/generic_arm64/{,symbols/}apex/com.android.{tethering,conscrypt}/lib64/libc++.so
Test: Verified that unwinder was dynamically linked to tethering's
Test: libc++ and statically linked to conscrypt's.
Test: lunch flame-userdebug && m
Test: Verified that unwinder was dynamically linked to /system/lib64/libc++.so
Change-Id: I98eed7cb4316962b19b5c12e150c224c25d0e91d
With kernel support being removed for execute-only memory layouts,
remove support for XOM until there's kernel support again.
This allows us to gain the code-size improvements from
"-z noseparate-code".
Bug: 147300048
Test: Compiled binaries no longer marked XOM by default.
Change-Id: Ie84bdd2ca025e8b14867008291bf9ce143b5e999
The APEX dependency is more correctly tracked. Previously, the
dependency was tracked while we gather modules that will be installed to
an APEX. This actually was incorrect because we skipped many dependency
types that we don't need to follow to gather the modules list, such as
the headers dependency.
Now, the dependency is tracked directly when a module is mutated for an
APEX. In other words, if a module is mutated for an apex X, then the
module will appear in the X-deps-into.txt file.
This change also changes the format of the txt file. It now clearly
shows why a module is included in the APEX by showing the list of
modules that depend on the module.
Bug: 146323213
Test: m
Change-Id: I0a70cf9cce56e36565f9d55683fdaace8748a081
This implements four modules (static/shared/header libraries, and
binaries) for vendor snapshot. These modules will override source
modules if BOARD_VNDK_VERSION != current.
Bug: 65377115
Test: 1) VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: 2) install snapshot under source tree
Test: 3) set BOARD_VNDK_VERSION and boot cuttlefish
Change-Id: I24ddb4c3aa6abeab60bbfd31bcbd8753e2592dc5
Vendor snapshot can be captured with "m dist vendor-snapshot". With
vendor snapshot and vndk snapshot, older version of /vendor and newer
version of /system will be able to be built together by setting
BOARD_VNDK_VERSION to past vendor's version.
Only vendor modules under AOSP are to be captured. In detail, modules
under following directories are ignored:
- device/
- vendor/
- hardware/, except for interfaces/, libhardware/, libhardware_legacy/,
and ril/
Test modules (cc_test, etc.) and sanitized modules are also ignored.
Bug: 65377115
Test: m dist vendor-snapshot
Change-Id: If7a2f6de7f36deee936930c0ccf7c47c4a0cebf6
cc_library_static {
name: "libfoo",
shared_libs: ["libbar"],
}
cc_library {
name: "libbar",
}
If libfoo is part of an APEX, then libbar is no longer considered as a
member of the APEX, because it isn't actually linked to libfoo.
To distinguish such a shared lib dependency from a static library from a
shared lib dependency from a shared library, a new dep type
SharedFromStaticDepTag is introduced. It is treated exactly the same as
SharedDepTag, except when we determine whether a dependency is crossing
the APEX boundary or not.
This allows us to check the apex_available property more correctly.
Previously, modules were incorrectly considered as being used for an
APEX due to the shared lib dependency from a static lib.
As a good side effect, this also reduces the number of APEX variants.
Specifically, on aosp_arm64, the number of the generated modules were
reduced from 44745 to 44180.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: I899ccb9eae1574effef77ca1bc3a0df145983861
(cherry picked from commit 931b676a69)
Change-Id: I899ccb9eae1574effef77ca1bc3a0df145983861
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
(cherry picked from commit fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
When SOONG_ALLOW_MISSING_DEPENDENCIES is set, it should be OK to miss
shared library variants.
Test: master-art manifest, use bionic stubs
Bug: 142935992
Change-Id: Ie0054acfef7c4406594a87378a7029380a9fda50
Some NDK stub libraries are tagged with "LLNDK" in lsdump_paths.txt
because they are not in NDK, and their base module names are in LLNDK.
This commit excludes those NDK stub libraries from lsdump path list.
Test: make findlsdumps
Bug: 147409497
Change-Id: I7a72758ba40d5f5bda8c436dd0b22e5efda03a32
This reverts commit 7cb4d378e7.
Test: m
Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist ./art/tools/dist_linux_bionic.sh -j80 com.android.art.host
(in the master-art-host branch)
Change-Id: I9beca73aafdf42f03bfa19cf1634b2641dac417b
This reverts commit 956305c61c.
Reason for revert: broke master-art-host branch
Exempt-From-Owner-Approval: reverting a bad change
Change-Id: Id7faed4ee85328c7c65847a3543ea9e67a3d50b3
This change fixes a bug that test modules (cc_test or its sub types) are
unconditionally considered as non-installable if they are configured to
not available for platform. The rationale behind the decision was that
an APEX variant of a module doesn't need to be installed to the device
because the variant will anyway be included in the APEX. However, it's
wrong for test modules. They are not included in the APEX, but should be
installed to /data/nativetest*.
One might think that we need to make the tests available for the
platform (i.e. apex_available: ["//apex_available:platform"]). This
however doesn't work if the libraries that the tests should link against
are configured to be not available for the platform, which currently is
the case for the ART tests.
Bug: 146995717
Test: m
Change-Id: I51843f5b4ea0a418c64c63784347231590cd3c35
We need to have a way to see the list of modules that directly or
indirectly contribute to an APEX. People find it difficult to determine
whether a module is included in which APEXes because APEX tracks
indirect dependencies as well as direct dependencies. Therefore, just
looking at Android.bp for the APEX itself doesn't give the answer.
This change adds a new make target <apex_name>-deps-info, which
generates out/soong/<apex_name>-deps-info.txt file that shows the
internal and external dependencies of the said APEX.
Here, internal means the dependencies are actually part of the
APEX, while external means the dependencies are still external to the
APEX.
Bug: 146323213
Test: m (apex_test amended)
Change-Id: I33d1ccf5d1ca335d71cd6ced0f5f66b8c3886d13
Define a field CCSrcs and other cc related flags in a type ccIdeInfo
struct and write them into out/soong/module_bp_cc_deps.json. AIDEGen
can use these data to generate CMakeLists.txt by Python for multiple
native projects in CLion IDE.
Bug: 141512319
Test: 1. export SOONG_COLLECT_JAVA_DEPS=false SOONG_COLLECT_CC_DEPS=true;m nothing
check
1). File out/soong/module_bp_cc_deps.json is generated.
2). In "JniInvocation_test" module: "path", "srcs",
"global_common_flags", "local_common_flags",
"global_c_flags", "local_c_flags", "global_c_conly_flags",
"local_c_conly_flags", "global_cpp_flags",
"local_cpp_flags" and "system_include_flags"
have been created.
Change-Id: I9292cc6373157ba68f013998a7364f84a70d5593
The cc library and cc binary (and other cc module types) are all
instances of cc.Module. So, to differentiate between them and make
sure that only appropriate library instances can be added to
native_shared/static_libs this adds a special sdkMemberTypes field to
Module which if set specifies the SdkMemberTypes the module supports.
If it is not set then the module type cannot be used in the sdk at all.
Corrects an issue with one of the tests where a prebuilt cc
library was added to the sdk instead of a source cc library.
Adds a new test to ensure that cc_library_(shared|static)_host module
types work with the sdk as well and another test to ensure that
cc_library can be used as either.
Bug: 142918168
Test: m checkbuild
Change-Id: I359cdbdd15328ca571f276d2b6ce9a229ebb2c86
When PRODUCT_PRODUCT_VNDK_VERSION is set to 'current', product
modules are enforced to use only VNDK libs from the system partition
as BOARD_VNDK_VERSION does to vendor partition.
Modules with 'vendor_available: true' create product variant as well
as core and vendor variants. The product variant as an image variant
is used for the modules in /product or /system/product.
It must not affect the current build behavior without
PRODUCT_PRODUCT_VNDK_VERSION set.
Bug: 134099726
Bug: 138966004
Bug: 144534640
Test: build without PRODUCT_PRODUCT_VNDK_VERSION set
Change-Id: I4d3585c110d84493e45bf76d550dc240bb26137f
Effectively adds the cc_defaults module type to the set that are
registered for tests that rely on cc default deps so needed to remove
a few references of that.
Test: m checkbuild
Bug: 146540677
Change-Id: I9df3d33a0cf3f6b22d270efed8366d0183eccaec
Java modules using SystemAPI can now link against platform owned
sysprop_library with public stub. This allows modules to use platform's
public sysprops (which should be regarded as an API) without any hidden
API usages, if using dynamic linking and boot class path.
This doesn't affect any vendor or odm owned sysprop_library.
Bug: 141246285
Bug: 145167888
Test: m
Change-Id: I99824fb24a75cc8282211c2ad6c6296ae9fca393
The logic in cc.Module.ImageMutatorBegin() to skip creating vendor
variants for native bridge modules stopped working when the image
mutator was moved before the arch mutator because the native
bridge variant hadn't been created yet. Move the logic to the arch
mutator to avoid creating native bridge variants for vendor variants.
Fixes: 146486214
Test: lunch aosp_cf_x86_pasan-userdebug && m SANITIZE_TARGET=address
Change-Id: I46cff4905f929c9989d005f0ceb01388d47323c1
This time, exclude NDK libraries instead of LLNDK libraries from the
package. This is necessary because there are libraries such as libvndksupport
which are LLNDK but are not accessible to apps.
Original commit message:
> Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true
> (e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their
> recursive library dependencies, including for example libc++ when depending
> on the platform libc++. This means unnecessary churn when we add a new
> dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow
> jni_libs clauses to be simplified, make the build system search for the
> recursive dependencies and automatically include them.
>
> This change allows us to remove code that was previously adding NDK libc++
> as a special case, as it is now covered by the generic code.
>
> Also fix some improper quoting that was exposed as a result of this change
> causing more files to be packaged than before.
>
> [1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22
Bug: 144430859
Test: atest CtsAppOpsTestCases
Test: atest FrameworksNetSmokeTests
Change-Id: I8311ede0b44d7e50b9f272912ead8ef07e82b074
Jooyung Han