This allows us to change `logpersist.start` to `sh_binary` and unblocks
breakpad symbol uploading
Test: convert logpersist.start to sh_binary and verify symlinks are correct
Change-Id: I1b86c512df73a336205ca35216445a08e43bb879
Add a ToMakePath() method that returns a new path that points out
out/ instead of out/soong/, and replace the
"$(OUT_DIR)/" + path.RelPathString()
pattern with
path.ToMakePath().String()
Bug: 141877526
Test: m checkbuild
Change-Id: I391b9f2ed78c83a58d905d48355ce9b01d610d16
Create a new type InstallPath that is similar to OutputPath to
differentiate intermediates output paths from installed output
paths.
RelPathString is a poorly defined, undocumented function that is
primarily used to get an install path relative to out/soong to
generate an equivalent install path for Make relative to $(OUT_DIR).
Move it to InstallPath for now, and fix the one remaining user on
OutputPath.
Add a method to create an NDK install path so that ndk_sysroot.go
doesn't have to do it manually with PathForOutput.
Bug: 141877526
Test: m checkbuild
Change-Id: I83c5a0bd1fd6c3dba8d3b6d20d039f64f353ddd5
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
All APEXes need to ship w/o libbinder since it does not offer a stable
wire protocol. Removing this since nothing adds a libbinder dep here.
Bug: 139016109
Test: build
Merged-In: Ic6a3fcb68054d8c7a5f2f64795a0e2889ce1abe8
(cherry picked from commit 1c3108d629)
Change-Id: Ic6a3fcb68054d8c7a5f2f64795a0e2889ce1abe8
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
The return value is true if TARGET_FLATTEN_APEX is true,
TARGET_BUILD_APPS is false and the module is flatten variant.
Only the module name of flattened variant is appended with
".flattened" as suffix.
Test: m -j
Bug: 139716748
Change-Id: I966a178b43c5d08bd69d19e97e59456aa66d9d28
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
Remove the mention to the (APEX) manifest (`apex_manifest.json`) from
this field's documentation, as `Apex_name` is neither read from nor
written to that file.
Test: n/a
Change-Id: Ia0dfac4f35f1ea697f379bcb19dd11af8705a0a0
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
If payload type of APEX is zip, flattened variant and non-flattened
variant create the same MK rules (it's build error). So only
non-flattened variant case, MK rule is created.
And if a.flattenedConfigValue is true, soong don't mutate variants. So
when a.flattenedConfigValue is true, MK rule should be created.
This CL is a partial revert of 4c04713871
Bug: 139716748
Test: m -j com.android.art.host
Change-Id: I37b2fa17e203fb668a0255cda37f10fcfadb3f85
The NOTICE files are missing from prebuilt apexes, and it turns out they
were excluded when building bundles.
Bug: 140317706
Test: Ran build_mainline_modules.sh and checked bundle base modules.
Change-Id: I92c4231f2007e1d8cd9c2bd044201458803c0fd7
Merged-In: I92c4231f2007e1d8cd9c2bd044201458803c0fd7
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
The apexBundle module is mutated flattened variant and unflattened
variant. So we can install flattened apex and unflattened apex at the
same time with adding {Apex module name}.flattened to PRODUCT_PACKAGES.
Bug: 139716748
Test: m -j && Add com.android.art.debug.flattened to PRODUCT PACAGES and
check system/apex/com.android.art.debug directory
Change-Id: I0d8c9a155e47c5d0ff13e2f55d4080d91ef5093d
This commit switches the build rule for APEX nativeTests from
`$(BUILD_PREBUILT)` to `soong_cc_prebuilt.mk`. Since these are not real
prebuilts, `soong_cc_prebuilt.mk` should be sufficient.
Using `soong_cc_prebuilt.mk` also fixes a problem reported by prebuilt
ELF checker because `LOCAL_SHARED_LIBRARIES` are not generated for
nativeTests.
Bug: 139525855
Test: lunch aosp_walleye-userdebug && make check-elf-files
Change-Id: I7bfc29f9c2708896dad4e7cfc214480e1205a51e
"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
So far a very basic version.
In case there is a diff, soong will emit an error message with a command
to resolve the diff. Example:
New unexpected files were added to com.android.apex.cts.shim.v3. To fix the build run following command:
system/apex/tools/update_whitelist.sh system/apex/shim/build/default_shim_whitelist.txt out/soong/.intermediates/system/apex/shim/build/com.android.apex.cts.shim.v3/android_common_com.android.apex.cts.shim.v3/com.android.apex.cts.shim.v3-content.txt
Test: m checkbuild
Bug: 139125405
Change-Id: I57e694f394c56105dc7363a684983605c7bf5e7d
This includes a few changes that make AndroidMkEntries more resemble
AndroidMkData, especially in terms of how extra entries are added.
Most importantly it can now have multiple custom functions.
Test: Soong tests
Change-Id: Ibf9102624d16d0c1c9894a2794fc7c797bb34c9a
Builtin APEXes (/system, ...) don't need hashtree.
So if we remove hashtree from builtin APEXes we can save more space in
/system.
However, this change only affects to the apex bundles which are built
from source, not from prebuilts.
Removing hashtree from prebuilts will be handled in a follow CL.
Bug: 139957269
Test: m
Test: see if /system/apex/*.apex have hashtree
Change-Id: Id755382b2153bf6bbaf2c480f3bbb91b6f62a564
Allow modules to depend on the flattened flavor of an APEX package
using `module.{flattened}` (returning the output install path of the
flattened APEX).
Also add this flattened output install path as an implicit output
dependency of a flattened APEX phony module.
Test: m checkbuild
Bug: 139277987
Change-Id: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
Merged-In: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
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 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
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
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
For some APEX packages (i.e. the Runtime Testing APEX), the set of
files to copy can be so large that the copy commands (which are part
of the Ninja shell command executed for an APEX package) may exceed
the maximum length of argument to the exec() functions (ARG_MAX). To
work around this limitation, record these copy commands in a Ninja
response file (rspfile) and `source` this file in the Ninja command to
execute them.
Test: m nothing (`apex/apex_test.go` amended)
Test: m com.android.runtime.testing (with CL https://android-review.googlesource.com/c/platform/art/+/1008034/ cherry-picked)
Bug: 129534335
Change-Id: I09ff2d9cf66bfd4cbc12cb724a45d455d08da0b2
