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
no_libgcc is no longer needed anywhere. Move all occurances to no_libcrt
and remove no_libgcc.
Test: build
Change-Id: I6dd49db71d05d7685aa90cc837627f65e6742d6d
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
We use libgcc as fallback for symbols not present in libclang_rt
builtins, however we didn't know what exact symbols were being used,
some may not be intended to fallback.
Create libgcc_stripped, which only contains unwind symbols from libgcc.
Bug: 29275768
Test: bionic-unit-tests
Change-Id: I5b349fa6138e51663bf3b67109b880b4356da8e8
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
Since apex_key is used in number of apex_test host_supported modules it
is no longer a device only module.
Test: add new device target and check that the build does not fail
Change-Id: I6402e3b622d22ee0ca0e6af71dfd71a690938e49
* 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
public_key and private_key properties support :module syntax so that the
key pairs can be dynamically created during the build, which is useful
for one-time keys.
Bug: 128960614
Test: m (apex_test amended)
Change-Id: I249b1d29f247784193b0d733a7b6a20274ece105
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
