When an apex key is marked as 'installable: false' and the build is
debuggable, the pubic key file for the apex key is bundled with the APEX
that is signed with the key.
This eliminates the need to install the public keys for the
testing-purpose APEX in the system partition.
Bug: 122047804
Test: m
Change-Id: Ifa5914891463dbf4c21484ea440836521b2f90b1
Setting the property to false prevents the key from being installed.
Useful for testing keys.
Bug: 122042717
Test: add 'installable: false' to the apex_key
'com.android.apex.test_package.key'. mma under
/system/apex/apexd/apexd_testdata. The key is not found under
out/target/product/..../system/etc/security/apex
Change-Id: Ibf70e4e8ea5e73432d06b1c4050df531eaafc85e
This change fixes a bug that the 'required' property of a module is
ignored when the module is using a shared from an APEX. This is
happening because LOCAL_REQUIRED_MODULES is overwritten (with := instead
of +=) when ApexesProvidingSharedLibs is not empty.
Fixing the bug by appending ApexesProvidingSharedLibs to
AndroidMkData.Reuired so that it is handled in android/androidmk.go
Test: m
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
and make sure that system/bin/vold_prepare_subdirs exist.
Change-Id: Ie57bca480ba4198b4da0df1c73e92fa42b5ebda8
Apex modules with installable: false are not installed, so the
dist rule copies from LOCAL_BUILT_MODULE instead of
LOCAL_INSTALLED_MODULE. If LOCAL_BUILT_MODULE_STEM is unset,
LOCAL_BUILT_MODULE will have the module name as the stem,
resulting in an incorrect file copied to the dist directory.
Set LOCAL_MODULE_STEM instead of LOCAL_INSTALLED_MODULE_STEM,
which also covers LOCAL_BUILT_MODUL_STEM.
Fixes: 122277867
Test: tapas test1_com.android.tzdata && m dist
Change-Id: I0af0c5adcac478a1ce68c4625203fd9bd56bf94d
This way we don't appear hung at:
No need to regenerate ninja file
Change-Id: I8dbdaa2c1b1c5a6a73187d0e6061f363b62e10c9
Fixes: 122251150
Test: m nothing
We weren't defaulting args.Stderr to os.Stderr, so we had been calling
fmt.Fprintln with `nil`.
Test: soong_zip --ignore_missing_files -C test/ -f abc -o test.zip
Change-Id: I0421f4bfb07fa36edf86c68ffc847995777c8221
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
Jiyong Park