override_apex module type is used to override existing apex module with
certain properties overridden. Currently, only the 'apps' property is
overridable.
Bug: 144338929
Test: m
Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
apex.go is too big. Separate the build rule and android.mk generation
logic into builder.go and androidmk.go, respectively. prebuilt_apex is
moved to prebuilt.go as well.
No refactoring has been made other than the splitting.
Test: m
Change-Id: I839ab0a1ba2b70ce82d98ac1fa8e3534808b5fd3
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
ApexPropreties are added in InitApexModule() and they are supposed to be
defaultable. To be defaultable, InitApexModule() should be called before
InitDefaultableModule().
Bug: 144332048
Test: m (soong test added)
Change-Id: I6c90ed3b66a086292a4c0ecb37c61f83769e62bd
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
__ANDROID_APEX__ was defined with the name of apex module.
-D__ANDROID_APEX__=com.android.foo
But in this way, conditional compilation is not easy since comparing
macro's string value is not supported in C/C++.
(There's no usages of this value in source tree.)
In most cases, modules can check if __ANDROID_APEX__ is defined to see
if they are compiled for apex.
For modules which should behave differently according to which apex they
are included, they can check __ANDROID_APEX_<NAME>__.
Bug: 142582178
Test: m (soong tests run) && boot device && TH
Change-Id: I0f5e3e9463ccd96cbba333a8bdd648470c5c912d
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
