The snapshot script can now handle native shared libs in an SDK.
Bug: 138182343
Test: create following sdk module:
sdk {
name: "mysdk",
native_shared_libs: ["libc", "libdl"],
}
, then execute `m mysdk` and execute the update_prebuilt-1.sh as
prompted. Following directories are generated under the directory where
mysdk is defined at:
1
├── aidl
├── Android.bp
├── arm64
│ ├── include
│ ├── include_gen
│ └── lib
│ ├── libc.so
│ └── libdl.so
├── include
│ └── bionic
│ └── libc
│ └── include
│ ├── alloca.h
│ ├── android
│ │ ├── api-level.h
<omitted>
Change-Id: Ia1dcc5564c1cd17c6ccf441d06d5995af55db9ee
Adds an interface, CcLinkableInterface, for cc linkable dependencies
which come from other toolchains such as Rust.
Bug: 140726209
Test: Soong tests pass, rust modules still compile.
Change-Id: I7378a46fad94fd0b735746aaf4e265fd2c2c04d8
These files were generated by Make. This is an effort to converting make
to soong.
These files are created under a known location: $SOONG_OUT_DIR/vndk
- llndk.libraries.txt
- vndksp.libraries.txt
- vndkcore.libraries.txt
- vndkprivate.libraries.txt
- vndkcorevariant.libraries.txt
- vndk.libraries.txt: merged all of above with tags
The last one is used by 'check-vndk-list'.
(See the topic)
Others will be packaged by VNDK APEX of current VNDK.
(This is not merged yet. After landing, a follow-up CL will be
followed.)
Bug: 141019581
Bug: 141450808
Test: m check-vndk-list
Change-Id: I9a24f6975bd4b226a94f61a13d43857dcdce6b88
exportedDirs and exportedSystemDirs are now changed to android.Paths so
that we can later manipulate the paths via Rel(), etc.
Test: m
Change-Id: I6fb02ea4983bcebac351bc284f75b44885379e8f
Make build system respect ALLOW_MISSING_DEPENDENCIES, when building
architecture B products, and ignore targets with dependencies that
are not available for architecture B.
Bug: 142701187
Test: # Add a dummy Android.bp with a module only for arm64
$ m -j TARGET_PRODUCT=aosp_x86 TARGET_BUILD_VARIANT=userdebug
Change-Id: I64de33674732df8c286671c806a07bcd19862b80
When an APEX is built with uses_sdks, any depedndency from the APEX to
the outside of the APEX should be from the SDKs that the APEX is built
against.
Bug: 138182343
Test: m
Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
apex_available property can be appended differently per the linkage
type. This will be used to restrict certain libs (e.g.
libc_malloc_debug) to an APEX while allowing them to be statically
linkable from platform for testing purpose.
Test: m (apex_test amended)
Change-Id: I6dec23129c5ac93a3ef06fea28f26f240c0ba410
Older VNDK libraries are provided as vndk_prebuilt_shared modules. Those
are added to corresponding VNDK APEX as dependencies.
With VNDK APEX installed, VNDK libs are unnecessary. By the way, since
there can be vendor modules which depend on VNDK libs, Make targets are
still emitted with UNINSTALLABLE=true.
Android.mk has additional modules for vndk libraries which are named
with apex name as suffices. For example, if libfoo is a vndk library,
then libfoo.vendor is its vendor variant and it would be in
/system/lib/vndk. But with vndk apex, it has additional
libfoo.com.android.vndk.current variant.
Bug: 141451661
Bug: 139772411
Test: m (soong tests)
Test: boot with aosp_arm64 system image on Q vendor device
Change-Id: I269c28a4d4c4e2f1518bd51df558438fe5316774
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
The static properties don't make sense for cc_library_shared
modules, and the shared properties don't make sense for
cc_library_static modules. Move them into separate property
structs so they can be added conditionally.
Test: m nothing
Test: DefaultsTest
Change-Id: I0b0cedf9eba07deb721fae138ffa7bedcfbfe71e
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
Adds the corpus and dictionary properties to the cc_fuzz target.
Propagates these entries to the makefile backend via LOCAL_FUZZ_DATA, in
a similar manner to LOCAL_TEST_DATA.
Bug: 141026328
Test: m example_fuzzer, fuzz target should have adjacent corpus/dict
files.
Change-Id: If5add5a597cc479f4e084bdafbd0fc175cfd6321
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
Bug: http://b/137883967
With coverage enabled, native-bridge modules throw a SEGV_ACCERR.
Test: Successfully run the app linked in the bug on a coverage build.
Change-Id: I9f3622b7b6d3189337c445a26d6bf81c96820c2e
Ensure that it ends up in the bionic/ subdir in the Runtime APEX and is
symlinked from /system/lib(64). That makes it available in the default
(platform) linker namespace and no longer requires it to be accessible
through the runtime namespace. All this makes it consistent with how the
other Bionic libs are handled, and avoids the need for various special
cases in ld.config.txt files (to be cleaned up later).
With this there might no longer be a need for a linker namespace for the
Runtime APEX, and we could consider removing the kludge with the
/apex/com.android.runtime/${LIB}/bionic subdirectories and the special case
in getCopyManifestForNativeLibrary in apex.go. However, keeping it calls out
the special treatment of those libraries, and allows a namespace to be added
again if necessary.
Test: Build and boot on taimen_hwasan-userdebug
Test: adb shell /apex/com.android.art/bin/dexdump on taimen_hwasan-userdebug
Test: atest CtsCompilationTestCases on taimen_hwasan-userdebug
Bug: 140734238
Bug: 140790209
Change-Id: Ieb506bfa5d5c159db391273c7eba41d7909de286
"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
native_bridge modules may not have vendor variants because they are
used only for native_loader.
Bug: 140702618
Bug: 137709824
Test: lunch aosp_cf_x86_phone-userdebug && make
Change-Id: Ic9f4abff22597693e66eef520cd1101b5e8c8938
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
Usually, ".S" files are processes with the c preprocessor, and ".s"
files are not, so they don't have any dependency information, since it
is generated by the preprocessor.
But with the -xassembler-with-cpp flag, ".s" files are processed with
the preprocessor, so we should ask for dependency information from them.
Test: NINJA_ARGS="-t deps out/soong/.intermediates/external/sonivox/arm-wt-22k/libsonivox/android_arm_armv7-a-neon_core_static/obj/external/sonivox/arm-wt-22k/lib_src/ARM-E_filter_gnu.o" m
Test: treehugger
Change-Id: Iee7baeebc2b205b5a2f33e7c1705ea4a5b4fc95a
* changes:
Introduce inject_bssl_hash library property.
BoringSSL FIPS build - introduce extraLibFlags and use for STL libs.
Allow linker scripts when building objects.
Allow .o files as srcs.
Rationale: On non-bionic, stl.go currently adds system libraries to
ldFlags, this causes problems for partialLd rules. However adding the
same libraries to libFlags breaks some existing modules due to symbol
conflicts as the system libraries are linked before some module code.
Introduced a general mechanism for adding libraries to be linked
last rather than making this STL-specific.
Bug: 134581881
Bug: 137267623
Test: TH
Change-Id: I779f28c6586b3fea85cc6299b686e4fde95262d3
When the native coverage is enabled, APEXes (and files there) are built
for native coverage as well.
Bug: 138952487
Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv
find out -name "*.gcno" | grep DnsResolver shows files
Test: libnetd_resolv.zip is found under
$(TARGET_OUT)/apex/com.android.resolv/lib directory
Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
This change fixes a problem in sanitizerMutator where a module is linked
with of non-sanitized variant of a lib at build-time, but is linked with
the sanitized variant of the lib at run-time.
This happened because, for each sanitizer type, every shared libs are
split into non-sanitized and sanitized variants, and then either of the
variants are suppressed from Make so that it isn't installed to the
device.
This change fixes the problem by NOT splitting for shared libs; only the
sanitized variant is created if needed. Header libs, static libs and
shared libs for a few sanitizer types (asan/fuzzer) are however split
into two. This is because the static and headers libs become part of the
depending module, and asan/fuzzer require that the depending module and
the dependant module should be compiled for the same sanitizer.
Bug: 138103882
Bug: 138426065
Test: m com.android.runtime.debug
Check that libziparchive exists under both
/system/apex/com.android.runtime/[lib|lib64]
Change-Id: Ia447785c485c0d049e19477b32bc638bfe6f1608
When no-vendor-variant VNDK is enabled,the vendor variant of VNDK
libraries are not installed.This should not be fit for recovery module.
Recovery module deps should be always installed.
Bug: 138812833
Test: `adb reboot recovery;` recovery mode boot ok
Change-Id: I0c3b8ac0fb0176677ddd94ba7216dd068f2eb81b
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