This causes the compiler to emit some additional debug infomation that
will be used for sampling PGO. These debug infomation will get stripped
so it only affects intermediate files.
Test: build
Bug: 79161490
Bug: 153039105
Change-Id: Ie4d1d5ffbd311ba6e268cb94a618f5272be246ef
Merged-In: Ie4d1d5ffbd311ba6e268cb94a618f5272be246ef
(cherry picked from commit ceb5b76c91)
If a lib has stubs, that means the library provides stable C APIs and
the APIs are guaranteed to be maintained in a backwards compatible
manner. Then there is no reason to have the same library in VNDK,
because VNDK is for libraries (usually having C++ interfaces) where API
stability across the yearly releases is hard (or impossible) to be
guaranteed.
This change triggers an error when the build system finds a VNDK lib
which has stubs defined. Users are suggested to make the lib an LLNDK
one.
Bug: 151303316
Test: m
Change-Id: Id305196a9d5a6fc7e7f9c02f3fa076859dc9a282
It looks like sometime in late February our Mac builds started taking
~10 minutes longer than before. On my local workstation the Soong tests
were taking >25 minutes before completing (likely because I don't have
the older SDKs installed, and we iterate from older to newer to find the
oldest installed SDK).
Most of this time was spend running the `xcrun` tools to interrogate the
system about which Mac SDKs are installed and where the tools are. This
will never change during any build or test, so wrap it all in a
sync.Once so that we only ever call them once.
And remove the macSdkPath variable, which has been unused for years and
no longer works (as we don't allow the use of xcode-select during the
build).
Bug: 153010389
Test: prebuilts/build-tools/build-prebuilts.sh on a Mac
Change-Id: I39b2d49739e628e4c11bec4805b25039115d2fd0
Merged-In: I39b2d49739e628e4c11bec4805b25039115d2fd0
(cherry picked from commit 6ba5367a70)
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
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: vendor/google/build/build_mainline_modules.sh
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
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
It looks like sometime in late February our Mac builds started taking
~10 minutes longer than before. On my local workstation the Soong tests
were taking >25 minutes before completing (likely because I don't have
the older SDKs installed, and we iterate from older to newer to find the
oldest installed SDK).
Most of this time was spend running the `xcrun` tools to interrogate the
system about which Mac SDKs are installed and where the tools are. This
will never change during any build or test, so wrap it all in a
sync.Once so that we only ever call them once.
And remove the macSdkPath variable, which has been unused for years and
no longer works (as we don't allow the use of xcode-select during the
build).
Bug: 153010389
Test: prebuilts/build-tools/build-prebuilts.sh on a Mac
Change-Id: I39b2d49739e628e4c11bec4805b25039115d2fd0
platform.
The NOTICE file generation depends on the NOTICE targets for all static
library dependencies. If such a dependency didn't have
//apex_available:platform it didn't get any AndroidMk entry and hence
no NOTICE target via soong_cc_prebuilt.mk. If it was then depended upon
by a binary or library that is accessible to platform, the NOTICE
dependency failed.
Normally such a dependency is invalid, but there are corner cases where
binaries go neither into platform nor any APEX module, and they can
legitimately have such dependencies (cf. b/152241137).
With this CL requests to skip installation of such a static libraries
are ignored so that they get AndroidMk entries, which will always have
LOCAL_UNINSTALLABLE_MODULE set.
Test: "m simpleperf_ndk" with https://r.android.com/1273016, which
removes //apex_available:platform from libs that simpleperf_ndk
depends on statically.
Bug: 152241137
Bug: 149217815
Change-Id: If36e85dd16ade56d4ec1d6744811df5a15b6242c
For VNDK-Lite devices, which doesn't define BOARD_VNDK_VERSION, VNDK
APEX is built with only VNDK-Sp libraries with core variants.
Bug: 141908078
Bug: 152353068
Bug: 151635128
Test: TH
Change-Id: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
A library may have both VNDK variant and stubs. getRefAbiDumpFile should
differentiate its vendor and core variants.
Bug: 152277104
Test: Add dumps to platform/ and vndk/ ; make libselinux.vendor libselinux
Change-Id: Iad038cf4cd3eccc3dfbef13fab67da044498ce77
Merged-In: Iad038cf4cd3eccc3dfbef13fab67da044498ce77
(cherry picked from commit 27d235f918)
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
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
A library may have both VNDK variant and stubs. getRefAbiDumpFile should
differentiate its vendor and core variants.
Bug: 152277104
Test: Add dumps to platform/ and vndk/ ; make libselinux.vendor libselinux
Change-Id: Iad038cf4cd3eccc3dfbef13fab67da044498ce77
The macro is required only for apex variants regardless of useVndk.
Before the enforcement of LLNDK sdk version, the macro was not passed to
vendor variants.
Bug: 151689896
Test: TARGET_BUILD_APPS=com.android.media.swcodec m
libbase in swcodec apex is linked with liblog#29
(compiled with __ANDROID_SDK_VERSIO__=29)
Merged-In: I57fa4afe027eb39b98bd94d534be9ebe11713f19
Change-Id: I57fa4afe027eb39b98bd94d534be9ebe11713f19
(cherry picked from commit 24282778ee)
Exempt-From-Owner-Approval: cp from aosp
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
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.
Merged-In: I79946cbb4da6617138a96d2b254349d3a298e77b
Change-Id: I79946cbb4da6617138a96d2b254349d3a298e77b
(cherry picked from commit 380fc3615c)
Use the result of regex.ReplaceAllString()
Bug: 149591522 (not directly related to this)
Test: m (with new unit test)
Merged-In: Ifce07547ccc067f1ee5bd8467c2fb7d7f8387b8e
Change-Id: Ifce07547ccc067f1ee5bd8467c2fb7d7f8387b8e
(cherry picked from commit b04a4997b8)
This causes the compiler to emit some additional debug infomation that
will be used for sampling PGO. These debug infomation will get stripped
so it only affects intermediate files.
Test: build
Bug: 79161490
Change-Id: Ie4d1d5ffbd311ba6e268cb94a618f5272be246ef
