APEXes are ETC type, which should be overridden via
LOCAL_OVERRIDES_MODULES. This change fixes a bug that
LOCAL_OVERRIDES_PACKAGES was used for APEXes.
Bug: 140792287
Test: m
Test: add com.google.android.tzdata to PRODUCT_PACKAGES and build.
/system/apex/com.google.android.tzdata.apex exists, but
/system/apex/com.android.tzdata.apex doesn't.
Change-Id: Id65743b36e0b706d6ffd8cae0597cc0a42a83fb7
If some apex module can be installed for both flattened and unflattened,
flattened apex should be installed to system_ext partition.
So add MakeAsSystemExt func to change the partition from system to
system_ext.
Bug: 139053989
Test: m -j
Change-Id: I3e3430413a9045d96130af99e249567b1a26ed7e
If a JNI lib is depended on by an APK that is included in an APEX, the
lib is embedded inside the APK.
This change also fixes a bug that APKs are not mutated for APEXes.
Bug: 144135069
Test: m (apex_test.go amended)
Change-Id: I21ac24412b30c05afc03385655c6b196130dffe3
If a JNI lib is depended on by an APK that is included in an APEX, the
lib is embedded inside the APK.
This change also fixes a bug that APKs are not mutated for APEXes.
Bug: 144135069
Test: m (apex_test.go amended)
Change-Id: Icf490d2701a7ede8bcad7e671fc72be9c8d7c01e
This reverts commit bf0e47648a.
Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true
is fixed by inspecting the environment variable and not generating
boot image in case it is set.
Dexpreopt artifacts for the libcore part of the boot class path are
now packaged in the ART apex. The system image still contains
dexpreopt artifacts for the full set of boot class path libraries
(both libcore and framework); the libcore part will be removed and
boot image extension will be used in a follow-up CL.
Since this is specific to the ART apex and makes no sense for other
apexes, the implementation adds a boolean flag "is ART apex" rather
than a new apex module property.
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds a third "art" variant.
Test: m
Test: m art/build/apex/runtests.sh
Bug: 144091989
Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
For Q compatibility, .json files are also bundled.
Three different apex_manifest files are built from input.
- apex_manifest.json: Q-readable .json file
- apex_manifest_full.json: input + dependency
- apex_manifest.pb: apex: converted from apex_manifest_full.json
apexer will handle these files.
Bug: 143654022
Test: m
Change-Id: I9697094057f0c0543282b1b46b7535cf21431176
These files were highly coupled with vndk version, so having them inside
the corresponding VNDK APEX is reasonable.
These files are used by linkerconfig and libnativeloader. In the future,
they reference these files from and VNDK APEX.
Bug: 141450808
Test: m com.android.vndk.current
Change-Id: I055a979d2636ddd8844a0afff81f6ba441f7965e
When use_vendor is used, native modules are built with
__ANDROID_VNDK__ and __ANDROID_APEX__, which may cause
compatibility issues. (e.g. libbinder)
Even though libbinder restricts its availability via
'apex_available' property and relies on yet another macro
__ANDROID_APEX_<NAME>__, we restrict usage of "use_vendor:" from
other APEX modules to avoid similar problems.
Bug: 142684427
Test: m -j
Change-Id: Ibc781de2efcd20cb6688a183b08e908a8a6e2593
Create variant of image, zip or flattened according to
TARGET_FLATTEN_APEX and payload type.
If payload type is zip, only zip variant is created because flattened
apex is not supported. And if payload type is image, image and flattened
variants are created.
Bug: 139053989
Test: m -j
Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
This reverts commit d5df949385.
Bug: 143594594
Bug: 143593500
Reason for revert: Some builds are failing.
Change-Id: I69986b472bce39266095e526fcd7ef5f48ece85e
Exempt-From-Owner-Approval: Going back to green.
Since apex_vndk deals with its own dependencies, it should not follow
dependencies while packaging.
Bug: 139772411
Test: TARGET_VNDK_USE_CORE_VARIANT=true m com.android.vndk.current
see if there are unexpected libs in the apex
for example, android.hardware.audio.common@2.0.so should not be
included in the apex since it is not listed as "must use vendor
variant".
Change-Id: Ibada600b3099fb19630d1e327a2e09cd26b2deb0
While modifying the CTS shim apex packages, it was observed that the
output of the image content file is not necessarily sorted, which in
turn can cause failure when checking the file against a whitelist.
Bug: 138429615
Test: Succesfully built a modified version of CTS Shim v3 that was
previously failing because of the issue this CL fixes.
Change-Id: I901859ae08feb6012f34b851e125977e1c0100d9
This patch adds dexpreopt files for the libore part of the
bootclasspath to the ART apex.
Since this is specific to the ART apex and makes not sense for other
apexes, the patch does not add a new module property, but only a
boolean flag denoting that this is an ART apex.
Dexpreopt artifacts packaged into the ART apex differ from those that
are packaged in the system image: it inludes only the libcore part of
bootclasspath jars, but not the framework part. When the boot image
extension is implementd, dexpreopt artifacts for the libcore jars will
be removed from the system image (but for now they are both in the
apex and in the system image).
Build rules for the new set of dexpreopt artifacts are created using
a new variant of the global boot image config. Previously we had two
variants: "default" (for the system image) and "apex" (for the
JIT-zygote experiment). This patch adds the third "libcore" variant.
Test: m
Test: m com.android.art deapexer \
&& find $ANDROID_BUILD_TOP -type f -name 'com.android.art.*.apex \
| xargs deapexer | grep boot \
Expect to find dexpreopt/$ARCH/boot-art*.{art,oat,vdex} files.
Test: m art/build/apex/runtests.sh
Change-Id: I353ef90304bc5e18c3055ea379b3b223e5c38948
With VNDK APEX, the location of VNDK lib is changed.
But vndk libs of older VNDK versions still depend on old location.
For current VNDK version, those hard-coded references will be fixed.
TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk
Bug: 143192278
Bug: 142912195
Test: m com.android.vndk.current and check if /system/lib/vndk
OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current
Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
When an APEX is built with uses_sdks, any depedndency from the APEX to
the outside of the APEX should be from the SDKs that the APEX is built
against.
Bug: 138182343
Test: m
Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
Older VNDK libraries are provided as vndk_prebuilt_shared modules. Those
are added to corresponding VNDK APEX as dependencies.
With VNDK APEX installed, VNDK libs are unnecessary. By the way, since
there can be vendor modules which depend on VNDK libs, Make targets are
still emitted with UNINSTALLABLE=true.
Android.mk has additional modules for vndk libraries which are named
with apex name as suffices. For example, if libfoo is a vndk library,
then libfoo.vendor is its vendor variant and it would be in
/system/lib/vndk. But with vndk apex, it has additional
libfoo.com.android.vndk.current variant.
Bug: 141451661
Bug: 139772411
Test: m (soong tests)
Test: boot with aosp_arm64 system image on Q vendor device
Change-Id: I269c28a4d4c4e2f1518bd51df558438fe5316774
APK in a flattened APEX is installed as 'ETC' class module, instead of
the 'APP' class. This is to prevent Make from doing app-specific
amendments (e.g. such as adding module name after my_module_path)
to the paths and filenames which are all correctly set in the Soong
side.
Test: add `installable:true` to development/samples/Snake/Android.mk
and add 'Snake' to the `apps` property of an APEX. The build is
successful.
Test: build the APEX on a device with TARGET_FLATTEN_APEX=true
The APK is at system/apex/<apexname>/app/Snake/Snake.apk
Bug: 142537672
Change-Id: I314bf1ab7abd4d4a4e9fa210442c004f54d8ccca
This fixes the bug: flattened apex is installed under
/system/apex/<soong module name> not /system/apex/<apex name>.
Flattened apexes can be seen as pre-activated under /system/apex, which
is bind-mount to /apex. Therefore, install dir for flattend apex should
be the same with the activation point(or mountpoint) of non-flattened apex.
When apex_name: is set, it should be used as its name instead of name:.
This change also emits makevar APEX_FILE_CONTEXTS_INFOS which is list of
pairs(<apex_name>:<file_contexts>) and is used by sepolicy to modify
file_contexts files for flattened apexes properly.
Bug: 123314817
Bug: 142300241
Test: add a test apex module(foo) with apex_name(foobar)
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m foo
Test: see if the apex is installed correctly(/system/apex/foobar)
Test: see if the file_contexts for foo is correctly modified
Change-Id: I97a07de5cc772cd1d91e95ae059d282038028916
The check doesn't make sense for host.
Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist
./art/tools/dist_linux_bionic.sh -j110 com.android.art.host
is successful
Change-Id: Icdb4bb557a83b3c8044e6c73721dab47c56888a1
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
