It has been wrong to split ALL_VERSIONS into exclusive two sets of
before/after TARGET_PLATFORM_VERSION.
And PLATFORM_VERSION_ALL_CODENAMES supports all *active* list of
non-finalized codenames.
Bug: 152960049
Test: m
Exempt-From-Owner-Approval: cp from master
Merged-In: I78ca88758998e440bea72ba2d56d90eea3ec99ae
Change-Id: I78ca88758998e440bea72ba2d56d90eea3ec99ae
(cherry picked from commit 424175d72a)
Revert submission 1242911-sdk_version_variant
Reason for revert: b/153394225
Reverted Changes:
Ife99745fb:Use libnativewindow for platform variant of libagq...
I1bae84c43:Use libnativewindow for platform variant of androi...
I6e6021ed3:Use stl to depend on libc++
Ife99745fb:Use libnativewindow for platform variant of libRSS...
I2c9f439b9:Fix static dependency on libprotobuf-cpp-lite-ndk
Iff2aff9cf:Set sdk_version for cc_genrules used by modules wi...
I7d72934aa:Add sdk mutator for native modules
Ief378a007:Use sdk variant of Soong modules when LOCAL_SDK_VE...
Bug: 149591340
Change-Id: I798fa902c779469c6382b6699351e5d12bf14785
Fixes: 153394225
This partially reverts https://r.android.com/1278193. The propagated
symbol files contain all versions, even though only one is applicable
in a given SDK snapshot.
It's uncertain what repercussions this might have, but one is that if
we were to update a snapshot for a fixed version then it might change
because the symbol file contains new versions that aren't applicable.
Since the symbol file isn't actually needed at this point it's better
to wait with this step until the use cases for it are more clear.
Test: m nothing
Test: Create an SDK snapshot with Bionic libs, drop it into a
master-art tree without bionic/ in it, build ART APEXes, and check
that the Soong phase completes (specifically that the stubs are
detected even without symbol files).
Bug: 152481980
Change-Id: Ic79f89bc6d11d0b6552fa20791f5680ff9a40c0d
Necessary to make the APEX build logic treat the libraries as API
boundaries rather than dependencies to bundle.
The .so files in the snapshots are the compiled stub libraries in this
case. They are strictly speaking redundant since they can be generated
from the .map.txt files in the snapshots, but doing that would require
extending the cc_prebuilt_library(_shared) module types with a full
compiler pass etc, and that would break a lot of assumptions in the cc
package.
Test: m nothing
Test: Create an SDK snapshot with Bionic libs, drop it into a
master-art tree without bionic/ in it, build ART APEXes, and check
that the Soong phase completes (specifically no errors about various
APEX libs requiring libc that is not available to them).
Bug: 152481980
Change-Id: I31b928e6261198b6dd6f6b17196e714f07b64172
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Merged-In: If32f1b547e6d93e3955c7521eec8aef5851f908c
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
(cherry picked from commit 7406660685)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
Compiling native modules against the NDK disables platform features
like ASAN. For anything shipped on the system image there is no
reason to compile against the NDK. Add a new mutator to Soong that
creates a platform and an SDK variant for modules that set
sdk_version, and ignore sdk_version for the platform variant. The
SDK variant will be used for embedding in APKs that may be installed
on older platforms. Apexes use their own variants that enforce
backwards compatibility.
Test: sdk_test.go
Test: TestJNIPackaging
Bug: 149591340
Change-Id: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
Necessary to get correct prebuilts for many Bionic libs.
Cleaned up numerious "system_shared_libs: []" from test fixtures, since
they otherwise would need correction in the expected results, and it is
better to have a single test focused on testing system_shared_libs
propagation.
Test: m nothing
Bug: 152255951
Change-Id: If2e8a5296223e6281d833312660e8e9e4cd184c0
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
