1. Add var _ to declare the struct Import implement IDEInfo and
IDECustomizedModuleName interfaces
2. Modify var _, a typo case for struct Module implement Dependency interface
3. Add nil checking for Dependency interface implementation
4. Add more comment for developer
Bug: 121985695
Test: 1. m aidegen
2. $ANDROID_HOST_OUT/bin/aidegen framework
3. check import static android.Manifest.permission.BIND_VOICE_INTERACTION;
denpendency should be resolved in frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
Change-Id: Ia2d2d65b83a52d35ccb3927a36bcf686d5223e20
Soong build system modify the jar installed path to dexpreopt, however, the jar only contains dex without java information. This patch modify the jar collection from installed path to ImplementationJars.
Bug: 121231786
Test: 1. m aidegen
2. $ANDROID_HOST_OUT/bin/aidegen framework
3. check import static android.Manifest.permission.BIND_VOICE_INTERACTION;
denpendency should be resolved in frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
Change-Id: I8f24f3a3476e125d3fd808e0047db425e15046ac
This change fixes following problem:
1) a native lib having stubs is defined.
2) the lib is included in an APEX.
3) a static binary is linking the lib from outside of the APEX.
4) then, the dependency from the binary to the lib is vanishing.
This is happening because cc.depsToPaths() mistakely does not
distinguish static lib deps from shared lib deps. For shared lib deps,
it creates two dependencies (one for stubs variant and the other for
non-stubs variant) and choose the stubs variant when the lib and the
current module is not in the same APEX (i.e. dependency to the non-stubs
variant is discarded). However, since we don't have stubs variant for
static library, it ends up having no dependency to the library if the
link is static.
Fixing the issue by skipping the variant selection routine when the link
is static.
Test: m (apex_test added)
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I21102a31cc5c0b105da2affdd035bd5cc571a6ab
use_vendor, when set to true, brings vendor variant of the native
libraries and binaries to the APEX.
Bug: 115707625
Test: m (apex_test updated)
Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
When TARGET_FLATTEN_APEX is set to true, there is no single output file
for an APEX that other modules can reference via ":module" syntax.
Return nothing in that case.
Bug: 121221006
Test: TARGET_FLATTEN_APEX=true m
Change-Id: I556b55073720b16fd30fd133af58aac229e958c0
If dexpreopt is disabled inside dexpreopt_gen there won't be any installed files and the install directory won't be created, causing soong_zip to fail. Create the directory ahead of time.
Test: treehugger
Change-Id: Icf17d0bcd617eeeafdcd50ab56359fa8d6612822
When TARGET_FLATTEN_APEX=true, individual files in an APEX are exported
to make. However, because they lack LOCAL_SOONG_CLASSES_JAR,
soong_java_prebuilt.mk get confused and the build breaks.
Fixing the bug by correctly emitting LOCAL_SOONG_CLASSES_JAR and
LOCAL_SOONG_HEADER_JAR.
Test: TARGET_FLATTEN_APEX=true m
out/target/common/obj/JAVA_LIBRARIES/com.android.conscrypt.conscrypt_intermediates/classes.jar
Change-Id: I65ce86ec825f978a43715146bbd5c1d5af513de0
The dependency is added because the module that uses the sysprop library
needs generated code before it is built.
Test: m -j
Change-Id: I2858fc6fa6f2fe16afa2f4a7ae62746ba0f67e5c
Mainline modules are tightly coupled to the platform, and should
build against the current SDK from source and not prebuilts. Add
a flag UNBUNDLED_BUILD_SDKS_FROM_SOURCE to specify that a
TARGET_BUILD_APPS build should build the current SDK instead of
using the prebuilts.
Bug: 121194841
Bug: 121231426
Test: no change to out/build-aosp_sailfish.ninja
Test: forrest unbundled build
Test: forrest master apps build
Test: forrest mainline modules build
Change-Id: I45a40a335483dae2fe192721df9b31bdbab97ee5
Ie42edc5184f315f998db953594e425214b810e0e added system_shared_libs to
static libraries so that their exported headers can be referenced.
However, it also added unrequired dependencies, which is an
error-triggering issue for static executables.
This change addresses it by adding a condition to shared libs handling code
in binary.go.
Bug: 121152570
Test: cc_test.go, library_test.go
Change-Id: I1828442c4e496f8d815fccaeca970cd5766bdf5d
Port the dexpreopt logic from Make to the dexpreopt package in Soong,
and use it to dexpreopt Soong modules. The same package is also
compiled into the dexpreopt_gen binary to generate dexpreopt scripts
for Make modules.
This relands Ib67e2febf9ed921f06e8a86b9ec945c80dff35eb and
I462182638bd57b1367b5bfb0718e975c11ae66f7, along with multiple fixes
to depsfile generation in dexpreopt_gen that caused .odex files for
modules in defined make to be missing dependencies on boot.art, and
a fix to not dexpreopt and strip tests.
Bug: 119412419
Bug: 120273280
Test: no differences to dexpreopt outputs on aosp_sailfish system/,
only expected changes to dexpreopt outputs on system_other
(.vdex files for privileged Soong modules no longer incorrectly
contain .dex contents).
Test: OUT_DIR=$PWD/out m
Test: NINJA_ARGS="-t deps out/target/product/sailfish/obj/APPS/Contacts_intermediates/dexpreopt.zip" m
Change-Id: I6bb2c971cee65d2338839753aa0d84939f335b1b
Now, symbols that are only to be visible to across APEXes can be tagged
as # vndk. Then when generating the stubs library, the tagged symbol
is included. The symbol is NOT included in other cases; build NDK stubs,
etc.
Bug: 120638081
Test: m (apex_test updated.)
Change-Id: Idb2b552badddfc26af113cc8d4b984788f478813
If a symbol is tagged as # apex, then it is exported when gen_stub_libs
is invoked with --apex.
Bug: 120638081
Test: python3 cc/test_gen_stub_libs.py
Change-Id: I190bca35d1a4fb422b37d1be41a34de1ad64de6b
Otherwise, the force included headers might cause conflicting types
error with the symbols in the generated stubs source code. e.g.
double acos(double); // in header
void acos() {} // in the generated source code
Bug: 120266448
Test: m (apex_test also updated, and passing)
Change-Id: I717df990959d1b24ec515f0f52a4e28b94e92f32
When set to false, the apex is built but not installed. Useful for not
polluting the system image with test APEXes when doing mma.
Bug: 120960303
Test: add 'installable: false' to apex.test under system/apex/tests/Android.bp
m; check that out/..../system/apex/apex.test.apex does not exist.
Change-Id: I383d5cdcc8aec705b6a5778dbd07233471d289d0
MaybeRel was failing with an error when comparing an absolute out
path to a relative source path. Make it return false instead, and
add tests.
Bug: 119412419
Test: paths_test.go
Change-Id: I462182638bd57b1367b5bfb0718e975c11ae66f7
Port the dexpreopt logic from Make to the dexpreopt package in Soong,
and use it to dexpreopt Soong modules. The same package is also
compiled into the dexpreopt_gen binary to generate dexpreopt scripts
for Make modules.
Bug: 119412419
Bug: 120273280
Test: no differences to dexpreopt outputs on aosp_sailfish system/,
only expected changes to dexpreopt outputs on system_other
(.vdex files for privileged Soong modules no longer incorrectly
contain .dex contents).
Change-Id: Ib67e2febf9ed921f06e8a86b9ec945c80dff35eb
The runtime APEX is built for host as well as for target. Therefore
stubs libs should be available also for host.
Bug: 120670568
Test: follow the repro step shown in b/120670568#comment4
Change-Id: I350fe490848ae9ceb55aade0521bdfaf48ed083f
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
When the stubs variant of a library is dependend by a platform component
and the library is included in one or more APEX, the library is not
installed to the platform, because it is provided by APEX.
Bug: 120266448
Test: m
Test: add stubs: { versions: ["1"], }, to libnetd_resolv
then build netd. libnetd_resolv.so does not exist under /system.
Change-Id: I09b78e38df285033ef6e9c85f7ea4b0274e85070
Add a no_recover option that allows specifying which sanitizers in
diagnostics modes shouldn't recover. This can help debugging as we test
enabling sanitizers in new libraries since it'll cause tombstones to be
generated along with the diagnostics information.
Bug: 80195448
Bug: 110791537
Test: Compiled test module with this flag, checked compiler command.
Test: Test module crashed, tombstone contained diagnostics information.
Change-Id: Ie938923ef95716c2d49d6cd719ee223ad62755c6
