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
To build the platform for ASAN, we do
`m && SANITIZE_TARGET='addresss' m`
However, at the end of the second build, the system partition could have
conflicting APEXes; prebuilt APEXes from the first build and
source-built APEXes from the second build. Since the file names for the
prebuilt and the source-built are different (e.g.
com.google.android.media.apex v.s. com.android.media.apex), we end up
having two files for the same APEX. This is confusing apexd at runtime
and the device fails to boot.
To fix this, when building a non-prebuilt APEX, the prebuilt APEX might
have been installed by the previous build is deleted.
Bug: 138146044
Test: lunch aosp_cf_x86_pasan; m && SANITIZE_TARGET='address' m
check that out/target/product/vsoc_x86/system/apex has
com.android.*.apex only.
Change-Id: Ib5a021a297cf0173ea5a3b50e9398b1cf295c558
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
This change fixes a bug that a symlink in the bin/* directory of an APEX
is not added to the fs_config file.
Bug: 137918291
Test: choosecombo aosp_x86_arm
TARGET_FLATTEN_APEX=false m com.android.runtime.debug is successful
Change-Id: Ib10b635f08e03b18e8ad5407d8de6bac2c85326d
If a test module with a `test_per_src` property set to `true` is
included in an APEX module, add all the variants for mutator
`test_per_src` as dependencies of the APEX module (not just the
first one).
This is done by adding variation "" of mutator `test_per_src` when
adding a test dependency to an APEX module, which creates an indirect
dependency of the APEX module on all the `test_per_src` variants of
the test module. When generating outputs for the APEX bundle, fetch
and include the set of test outputs from the "" variant.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
This change fixes a bug that APEX prebuilts are auto-disabled in
platform builds (i.e. non-unbundled builds).
Bug: 137282010
Test: m com.android.conscrypt
check that the apex is from prebuilt directory
Merged-In: I935ef3896e80864bdcc1ca5f6fc12b63c9588c0d
(cherry picked from commit 895e224d8f)
Change-Id: I935ef3896e80864bdcc1ca5f6fc12b63c9588c0d
This change introduces NativeBridgeRelativePath and
NativeBridgeSecondaryRelativePath product variables to
make relative path to native_bridge binaries configurable.
It also removes moves information about native bridge
host architecture to Target and sets it during decodeTargetProductVariables
Test: make PRODUCT-cf_x86_phone-userdebug dist
Change-Id: Ie736e81eae507e1775566ce9f29135011b12af27
This change fixes two problems:
1) the prebuilt apexes are force disabled for the unbundled builds
because we need to build the modules from the source then
2) the dependencies from an sdk_library module to
*.stubs.{public|system|tests} are not added for the unbundled build
because the stubs modules are disabled.
Bug: 137282010
Test: unbundled mainline builds are successful
Test: build com.android.media and inspect the jar file to see if
hiddenapi flags are there
$ cd out/dist/mainline_modules_arm
$ unzip com.android.media.apex apex_payload.img
$ mkdir -p mnt
$ sudo mount -o ro,loop apex_payload.img mnt
$ dexdump2 mnt/javalib/updatable-media.jar | grep hiddenapi
shows results
Change-Id: I2c00af07aac4a15770d3acab011a36e2e4803bfc
Some prebuilt APEXes are enabled with scudo, which causes crash on
devices with asan.
Bug: 137216042
Test: build walleye_hwasan and check if apexes are not from prebuilts
Merged-In: Ic436ad06e724af952d99fb8e66358a595450eb84
(cherry picked from commit 3b98a509f1)
Change-Id: Ic436ad06e724af952d99fb8e66358a595450eb84
When the device does not support non-flattened APEX (i.e.
TARGET_FLATTEN_APEX is set to true), then ignore the prebuilt_apex
modules even when `prefer: true`.
Bug: 136251130
Bug: 136662772
Test: build marlin, and check if /system/apex has flattened APEXes
Merged-In: I9f3dfefc3bd357d6750fbb1e418937d095720b04
(cherry picked from commit 0a573d798f)
Change-Id: I9f3dfefc3bd357d6750fbb1e418937d095720b04
Bug: 137015854
Test: m
Test: build cf_x86_phone and ensure there is no dangling symlink
/system/lib/arm/libm.so
Change-Id: I0f5efdb9e1f5e4e213ca4ebaa28ace0a130b36a6
Instead of circumventing the limitation of Prebuilt implementation by
picking a source path itself, it now uses the same mechanism as
archMutator and replaces the source path in advance so that Prebuilt
always sees the corrent source path.
Because this requires the Apk field to be a string pointer, the single
source prebuilt implementation is being updated to be reflection-based.
Test: Soong unit tests, m soong_docs, TreeHugger
Change-Id: I2304f15e32d632f74f95f0d9e9bf1f75ff3e2225
For APEXes to share C++ native libraries, we need a new kind of depedency
between APEXes: "providing" APEXes and "using" APEXes. To reflect this
dependency two new properties are added.
provide_cpp_shared_libs: bool
this indicates that the current APEX module provides the native C++ shared
libs to other APEXes.
uses: []string
this indicates that the current APEX module uses the native C++ shared
libraries from APEXes listed.
With these two, "using" APEXes can omit shared libraries in its APEX
bundle and use them from the "providing" APEXes.
Note that without corresponding changes in ld.config.txt, this won't
work.(The linker namespaces should be configured so that user APEX can
access provided libs.)
Bug: 136975105
Test: m nothing (this will trigger soong's test)
Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
Instead of outputting an aggregated NOTICE file as an intermediate build
resource to allow Make to include it in the final system-wide NOTICE,
process and embed it as an asset in the final APEX. This allows us to
update the NOTICE contents automatically when an APEX is updated.
Fixes: 135218846
Test: Built mainline modules, apex_test.go
Change-Id: Ic851b330fe93be1f602907d44ecc7886c3b0171b
If embed_notices or ALWAYS_EMBED_NOTICES is set, collect NOTICE files
from all dependencies of the android_app, merge them with the app's own
one (if exists), transform it to HTML, gzip it, and put it as an asset
in the final APK output.
Bug: 135460391
Test: app_test.go
Change-Id: I52d92e2fd19b3f5f396100424665c5cc344190d8
apexMutator only modifies the currently visited module, it can
visit modules in parallel.
Test: builds
Change-Id: I7d0ad142f5161742bd25dc57bac64c0f4a733ecf
I found these while trying to build an aosp_arm system image with RBE,
which only makes the sources that you depend on available to every rule.
The hardcoded prebuilts/sdk path is a bit unfortunate, but that's
currently hardcoded as a default in the script as well.
Bug: 130111713
Test: treehugger
Test: build a system image with RBE
Change-Id: I4415563017e053749788b0a537a48d61a2161935
Add an empty GenerateAndroidBuildActiosn to DefaultsModuleBase
so that every defaults module doesn't need to provide one. This
will also allow adding an implementation in the next patch.
Test: m checkbuild
Change-Id: I13554bdb3a287c2f18e1efab74d4f08a1ba8620c
blueprint.BaseModuleContext is the set of methods available to all
module-specific calls (GenerateBuildActions or mutators). The
android package split the same functionality across baseContext (nee
androidBaseContext), BaseModuleContext, and BaseContext.
Consolidate all of them into android.BaseModuleContext.
Test: m checkbuild
Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
There are cases where a module needs to refer to an intermediate
output of another module instead of its final output. For example,
a module may want to use the .jar containing .class files from
another module whose final output is a .jar containing classes.dex
files. Support a new ":module{.tag}" format in any property that
is annotated with `android:"path"`, which will query the target
module for its ".tag" output(s).
Test: path_properties_test.go, paths_test.go
Test: no unexpected changes in build.ninja
Change-Id: Icd3c9b0d83ff125771767c04046fcffb9fc3f65a
When HWASAN is enabled, the runtime is conceptually part of Bionic (and
mutually depends on it), so it needs to be treated in the same way as the
Bionic libs.
Now there are only two copies of the runtime: the one in
/system/lib64/bootstrap (which won't be used by ordinary processes) and the
one in the runtime APEX.
This reduces the size of the HWASAN system image and fixes an issue where
multiple copies of the HWASAN runtime were being loaded into 64-bit binaries in
APEXes because the linker namespace for the binary is different from the one
for its dependent libraries outside of APEXes. HWASAN only supports loading
one copy of the runtime per process, so this was causing such binaries to
crash on startup.
Change-Id: I228896e193a035e6dfba9f6e28d0b2e12fc163ea
apexkeys.txt now correctly lists prebuilt APEXes with keys specified as
PRESIGNED.
This change also fixes a bug that non-installable APEXes are listed in
the file.
Bug: 131130235
Test: m out/soong/apexkeys.txt and check that
com.android.apex.cts.shim.apex is listed there with PRESIGNED keys.
Merged-In: Ib6d391a82864714743a1cc59cd655bea917b5073
Change-Id: Ib6d391a82864714743a1cc59cd655bea917b5073
(cherry picked from commit a41f12a6fa)
This commit allows a module to opt in for ABI checks even when it is
not an LLNDK/VNDK module.
Bug: 131421213
Test: Add `header_abi_checker { enabled: true, }` to some module
Change-Id: Ie09d262e651cbb44d7d0eba652f55dc1e1e52962
Target SDK version is used for targeting an APEX to a specific set of
platform builds. Usually, the targeting is unrestricted (in case the
APEX can run on all platforms), or based on platform SDK version (e.g.
28 for P). However, when the platform is under development and SDK is
not finalized, the targeting should be much more fine-grained; the
APEX should be targeted to a very specific build that supports the same
set of APIs that the APEX was built against.
To support that, target sdk version is automatically set by the build
system. When the platform is released or SDK is finalized, the target sdk
version set to the SDK version number. If not, it is set to
<version_code>.<fingerprint> (e.g., Q.123456).
Note that the target sdk version set by the build system is used only
when the target sdk version is not explicitly set in
AndroidManifest.xml.
Bug: 130541924
Test: UNBUNDLED_BUILD_SDKS_FROM_SOURCE=true \
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true \
TARGET_BUILD_APPS=com.android.tzdata m
build.ninja has --target_sdk_version Q.$$(cat out/soong/api_fingerprint.txt)
Test: aapt dump badging out/dist/com.android.tzdata.apex | grep \
targetSdkVersion shows:
targetSdkVersion:'Q.6ee443d9ad5f0cca7a43cfa97b7fc62a'
Change-Id: I086230d787f01075c28fc3f0163550300fa00212
* Makes it more inline with prebuilt_etc;
* For shim apexes, prebuilt_apex modules have pattern of
com.android.apex.cts.shim.v1_prebuilt, but I would prefer
pre-installed shim to be: /system/apex/com.android.apex.cts.shim.apex
Bug: 128677967
Bug: 127789981
Test: m
Change-Id: I34e3e078733420b5cf777fd6e3ce4d8c5796b19b
In case of shim apexes, we prebuilt all of them, but only need to
install v1 to a system partition.
Bug: 128677967
Test: manually checked that non-installable prebuilts don't end in /system
Change-Id: I112432abfd8f03cc7d7379ea3cab3f5491ace49c
android/soong/common was renamed to android/soong/android long
ago, but the pctx package path was still "android/soong/common".
This required all users of rules defined in android/soong/android
to import "android/soong/android" and then
pctx.Import("android/soong/common").
Test: m checkbuild
Change-Id: I20d096522760538f7cfc2bec3d4bfeba99b275d4
The public key associated with an APEX is always included in the APEX.
Obviously, the public keys are no longer installed to
/system/etc/security/apex
Bug: 128344735
Test: m
Change-Id: I1e1aef1d32597a447b57d49ab80bbfb921fa8178
Arch-specific source can be specified for prebuilt_apex as follows.
arch: {
arm64: {
src: "myapex-arm64.apex",
},
},
A note on the implementation. The Src property was not tagged as
`android:"arch_variant"` as usual. Instead, multiple Src properties are
explicitly declared like
struct Arch {
struct Arm {
struct Src *string
}
...
}
Corresponding Src property is manually selected according to the
MultiTargets()[0].
This is because prebuilt_apex is mutated only for android_common, in
order to have the same arch variant with the apex module type.
Therefore, we can't rely on the arch_variant tag.
Bug: 127789981
Test: m (apex_test amended)
Change-Id: I77dbe626171d8975f549bdb4af3c487232cf05f7
Notice file for an APEX is created by merging notice files for the
modules included in it (plus the notice file for the APEX itself if
specified).
Notice files having the same content are not duplicated; it is emitted
only once.
Bug: 128701495
Test: m (apex_test is amended)
Test: m and inspect $(PRODUCT_OUT)/obj/NOTICE.txt to check there are
license entries for /system/apex/*.apex files
Change-Id: I169d91038291a6c71615de97cf5b03174afab5d4
Move the logic from ctx.ExpandSources into android.PathsForModuleSrc
and ctx.ExpandSource into android.PathForModuleSrc, and deprecate
them. When combined with the pathDepsMutator this will let all
properties that take source paths also take filegroups or genrule
outputs, as long as they are tagged with `android:"path"`.
Test: All soong tests
Change-Id: I01625e76b5da19240e9649bf26a014eeeafcab8f
This change fixes the problem that symbol files for APEXes are installed to
incorrect path when TARGET_FLATTEN_APEX is set to true or the canonical
name of an APEX is different fro the module name of the APEX.
For the case when TARGET_FLATTEN_APEX is true, LOCAL_SOONG_SYMBOL_PATH
is set to point to the runtime path of a file (e.g. /apex/<name>/*).
For the case of the different canonical and module names, apex_name
property is added to explicitly specify the canonical name
Bug: 120846816
Test: m and inspect that symbol files exist under
$(PRODUCT_OUT)/symbols/apex/com.android.runtime/
Change-Id: Idfec88d6a30a18c225b0d87b868b9f1e0a617e38
Add `android:"path"` to all properties that take paths to source
files, and remove the calls to ExtractSource(s)Deps, the
pathsDepsMutator will add the necessary SourceDepTag dependency.
Test: All soong tests
Change-Id: I488ba1a5d680aaa50b04fc38acf693e23c6d4d6d
These additional binary types are useful for some apexs. Add the
ability to include them. Due to the nature of the resulting artifacts
only py binaries with embedded launchers and host go binaries are
supported.
Test: m com.android.support.apexer
Bug: 119332365
Bug: 119332362
Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
This reverts commit aa65e17016.
Reason for revert: Not compatible with PRODUCT_PACKAGES, and so has very limited use.
Change-Id: Ib141d3984a6f12bb50989e66037494c466b066f1
This new module type replaces the inherit-package function in make by
allowing developers to override the name, the certificate, and the
manifest package name of an android_app module.
Bug: 122957760
Fixes: 123640028
Test: app_test.go + BrowserGoogle
Change-Id: Iefe447e7078b25039233221361ef95c83a29973a
Flattened apexs were not including symlinks. This could cause expected
files not to be present.
Test: lunch aosp_marlin-userdebug
m droid
stat $OUT/system/apex/com.android.runtime.debug/bin/dalvikvm
Bug: 124924906
Change-Id: I04e696602b776b383bf7198eb19220353df74192
Host apexs don't have a system-image associated with them so we need
to include all libraries, including those with stubs.
Test: ./art/test/testrunner/run_build_test_target.py -j50 art-linux-bionic-x64-zipapex
Bug: 125417922
Change-Id: Ie76e6a34e8be1057b29e2e005597c3e4b5fb1f9c
By default, if a lib is included in an APEX, all its direct and indirect
dependencies are also included in the same APEX. However, when one of
the dependencies have stable API (i.e. has stubs: {...}) then the lib
having stable API and its dependencies are not included in the APEX.
However, the problem here is that the lib having stable API might not be
installed on the system, thus causing error at runtime. This can happen
if there is no other module in the platform that depends on the lib.
This change fixes the problem by adding such libraries as external
dependencies so that they are also installed on the device along with
the APEXes using them.
Bug: 124831003
Test: m installclean; m com.android.resolv
libbinder_ndk, libvndksupport are found under system/lib
Change-Id: I457e03ff3fce37e0890c64d911e6e0ea6d0c6dd6
apexkeys.txt is a text file having APEX-to-keys mappings. The file is
included in the target-files package where it is used when re-sign the
APEXes with release keys.
Each line of the file consists of 5 fields:
1) name: file name of the APEX
2) public_key: the public key for the apex_payload.img of the APEX
3) private_key: the private key used to sign the apex_payload.img
4) container_certificate: the certificate used to sign the APEX zip
container
5) container_private_key: the private key used to sign the APEX zip
container
Bug: 124406181
Test: m out/soong/apexkeys.txt and inspect the content
Test: TARGET_BUILD_APPS=com.android.tzdata m dist and make sure
out/dist/apexkeys.txt exists
Change-Id: I1daa13ec50956323b97e15e8df7f1fbe5ea21d63
The manifest and androidManifest properties in the apex module type now
supports ":name" syntax.
Bug: 123857186
Test: m (apex_test amended)
Change-Id: Ic4e5a73cf73260d156ec61d07932ad07b2561413
The properties are no longer required as an APEX module is mutated with
required sanitizers which are gathered by scanning the sanitizers that
are enabled for its direct dependencies.
Bug: 124128094
Test: m on marlin
The extractor libs are found under /system/apex/com.android.media
Merged-In: I55961d400dcbac067a5c0dcecb90e399d4991a70
Change-Id: I55961d400dcbac067a5c0dcecb90e399d4991a70
(cherry picked from commit abda0eb76b)
Zip apex files are not really installed so should not ever be
flattened. Unfortunately we didn't send this information to make which
would still unzip everything.
Test: ALLOW_MISSING_DEPENDENCIES=true
./art/tools/build_linux_bionic_tests.sh com.android.runtime.host
Bug: 124333446
Change-Id: I3eda579f8c40f768f1ef2be867967f436396cd4c
AndroidManifest.xml file can be specified via the 'androidManifest'
property in the apex module type. It can be used to have a custom
AndroidManifest.xml that have additional tags (such as <uses-sdk> or
<uses-feature>) for precise targeting.
The property is optional; if unspecified, then one is auto-generated as
before.
Bug: 123857186
Test: m apex_test_build_features
Change-Id: Id7ee0471661887cfa11124cbaa3beea8cffcdda4
Zipapex's cannot be flattened so do not prevent them from being built
even if TARGET_FLATTEN_APEX is set.
Test: lunch aosp_arm-eng;
ALLOW_MISSING_DEPENDENCIES=true \
./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 124333446
Change-Id: I4bef65cce100136a8f7852692e841b62ed9e399f
It is used to configure an apex to prefere specific sanitizer variants
if available. For example, if a lib is with sanitize: {cfi: true} then
an APEX with prefer_sanitize: {cfi: true} will use the sanitized variant
of the lib.
Bug: 124128094
Test: m on marlin
extractor libraries are found under /system/apex/com.android.media
Change-Id: I858778eef78c5791cdeb497c7c11688cb128b5fe
Some test and other miscallaneous use-cases need apexs that are
installable but will not affect the installation of other artifacts
onto the device. For this purpose we added a test_apex type. These
test_apex targets create apex files and have all the normal attributes
but are not considered the source of any of their contents for the
device by the rest of the build-system.
Test: build and boot
Test: ALLOW_MISSING_DEPENDENCIES=true \
DIST_DIR=$ANDROID_BUILD_TOP/out/dist \
./art/tools/dist_linux_bionic.sh -j72 showcommands com.android.runtime.host
Bug: 123591866
Bug: 123892969
Change-Id: I7f50be0ac0425cd87868145e18bcee6962d472ef
We were marking any libraries included in any apex (including
non-installable apex's like com.android.runtime.host) as
uninstallable. This could cause phones to become unbootable if these
apex's are modified.
Bug: 123892969
Test: m droid && boot device.
Change-Id: Ief9004bbe7b106ee8f52715ce5bd7bb5accec290
94427265d1 broke the flattened APEX
by not updating moduleNames
Test: TARGET_FLATTEN_APEX=true m
Files are under /system/apex
Change-Id: I14b1a6f8b2244d35e1accdf9888cfef65f4b0a03
When an APEX is non-installable, the make rules for the APEX files in
the APEX are not emitted as they will never get installed.
androidMkForType() is refactored so that make rules for the APEX files
are created in a separate function androidMkForFiles().
Test: m checkbuild tests
Bug: 123290268
Change-Id: Ibe8817d1e9c6312fb5c6f986dced8aa3e823664a
Build rules for both flattened and non-flattend APEXes are created
regardless of TARGET_FLATTEN_APEX. The selection is made in AndroidMk.
This allows other module to reference an APEX via :module syntax
irrespective of TARGET_FLATTEN_APEX.
Bug: 123780484
Test: TARGET_FLATTEN_APEX=true m out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen/art-check-debug-apex-gen.dummy
with aosp/891696 applied
Change-Id: Ia49415ec3d18cfc5081461be76900c73ea803dca
relative_install_path for cc_library is respected by APEX.
relative_install_path for cc_binary is not yet respected because doing
it will break the path to the dynamic linker in the runtime APEX.
That change should be done along with changes in init, bionic, etc.
Bug: 123721777
Test: m (apex_test.go amended)
Change-Id: I855f8eda0d4255d563861ac96d0d3e2c669e9a2a
apex will normally place libc and some other system libraries into a
separate directory. This is to ensure that early startup works
correctly. Some apex targets want to have these libraries at the
normal places however.
Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 123591866
Bug: 120266448
Change-Id: Ib5a67a43fe3eea6188b4df9215e743f1634045f3
Some apex targets need to be able to change their contents based on if
they are host or target or what libc they are using. This adds support
for doing this using the standard 'target: {...}' idiom.
Test: m com.android.runtime.host
Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 123591866
Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
Some modules rely on symlink_preferred_arch to have expected files
present. This change makes apexs include these symlinks.
Test: m com.android.runtime.debug
pushd $(mktemp -d)
mkdir mnt
unzip $OUT/apex/system/com.android.runtime.debug.apex
sudo mount -o loop,ro apex_payload.img mnt
Ensure that mnt/bin/dalvikvm and mnt/bin/dex2oatd both exist and
are symlinks to mnt/bin/dalvikvm64 and mnt/bin/dex2oatd32
respectively.
Bug: 119942078
Bug: 122373634
Bug: 123079311
Change-Id: I47868fbedc5bdd3141a836c488f79e91e0a6ddfe
This fixes a problem that APEX is unconditionally mutated for all
sanitizer types. This can make an APEX to include sanitized version
of a lib even when SANITIZE_TARGET is not set. It can happen when lib X
is directly depended on by an APEX (e.g. via native_shared_libs) and X
has a sanitized variant due to the dependency from another library Y
which is force sanitized (via 'sanitize' property). In that case,
regardless of lib Y is in the APEX or not, the APEX chooses the
sanitized variant of lib X since the dependency from APEX to the lib is
created with AddFarVariationDependency.
Fixing this problem by mutating the APEX for a sanitizer type only when
the device is requested to be sanitized.
Bug: 122717287
Test: add libnetd_client to com.android.runtime APEX.
Inspect build.ninja to verify that libnetd_client.so in the runtime APEX
is not a sanitized one.
Change-Id: I918bc8407137d74c5456142b3a29de13df68c0b3
If native-bridge/ndk translation is supported for a config the build
system will know about 2 copies of binaries, one for each ABI. We only
want to actually install the 'Native' (non-translated) ABI into the
apex in these situations.
Test: lunch aosp_cf_x86_phone-userdebug
m showcommands com.android.runtime.debug
examine the command output to make sure only a single copy of
dex2oat is being installed.
Change-Id: I9480e52855fd9f5564a579099309fb38f1c50367
Sundong Ahn