In Make, vintf fragments are checked with assemble_vintf. Since vendor
APEXes can have vintf fragments, perform the same check with vintf
fragments in APEX.
Bug: 299034304
Test: m test.bad2.com.android.hardware.wifi
(should fail if its module type is `apex`)
Change-Id: I2f9ed50066b9b499b3562bfa51214c1e375d5747
`conv_linker_config validate` command is used to validate the linker
configuration embedded in APEX to detect common mistakes.
For example, when used in APEX, linker configuration can't set
provideLibs/requireLibs. For APEX, there are
provideSharedLibs/requireSharedLibs in APEX manifest for that purpose.
One might make mistake by setting provideLibs in linker config.
Now, when these unsupported properties are set, there'll be build-time
error like:
// set provideLibs key in com.android.art's linker config.
$ m com.android.art
...image.apex/etc/linker.config.pb: provideLibs is set. Use provideSharedLibs in apex_manifest
Bug: 264341796
Test: m com.android.art (see above)
Change-Id: Ibaf7322616ad333569e6d721680f3d72243402a2
As VNDK is in deprecation, any Vendor APEX which used use_vndk_as_stable
should copy former-VNDK libraries into its own APEX. However, libbinder
is not allowed to create APEX variant, so it should use libbinder_ndk
instead. This change is to temporalily allow Vendor APEX modules link
with libbinder in /vendor/lib, while any Vendor APEX modules using
libbinder transit into libbinder_ndk.
Bug: 296491928
Test: Cheetah build and boot succeeded
Change-Id: I40beb255bab658b75685e78f48e14520058616d6
Currently the product variable that is controlled by
APEX_GLOBAL_MIN_SDK_VERSION_OVERRIDE only overrides apexes, but it
doesn't apply to android_apps. This commit allows android_apps which set
updatable: true in their Android.bp to have their min_sdk_version be
overriden by this product variable.
Bug: 295311875
Test: go test
Change-Id: If3cb82a17cae4553b577dd1a4637ee13c3c95302
Since we no longer support "zip" APEX, we don't need "host" support.
For example, we don't need go/python binary support.
Bug: 279835185
Test: m
Change-Id: I6e8d2b205e42662f31866dc9ac7507524effd144
We want to make FULL_SYSTEMIMAGE_DEPS more accurate so that we can
remove the need for `m installclean`.
Currently, the compat symlinks are installed by adding them as
dependencies of other installed files. Doing this doesn't end up
propagaing the compat symlinks all the way to FULL_SYSTEMIMAGE_DEPS.
Add them to LOCAL_SOONG_INSTALL_SYMLINKS, which will cause them to
be propagated to FULL_SYSTEMIMAGE_DEPS.
Bug: 205632228
Test: Full build with a change to delete files not in FULL_SYSTEMIMAGE_DEPS from the staging dir
Change-Id: Idc7fc0a0dbf7c8ac3f0628c16413cd1df69a7821
Revert submission 2718295-colefaust_track_apex_compat_symlinks
Reason for revert: To validate if this change is causing the build breakage.
Reverted changes: /q/submissionid:2718295-colefaust_track_apex_compat_symlinks
Change-Id: I1896530219cf984efdf9ca7f4b14d8784367f242
We want to make FULL_SYSTEMIMAGE_DEPS more accurate so that we can
remove the need for `m installclean`.
Currently, the compat symlinks are installed by adding them as
dependencies of other installed files. Doing this doesn't end up
propagaing the compat symlinks all the way to FULL_SYSTEMIMAGE_DEPS.
Add them to LOCAL_SOONG_INSTALL_SYMLINKS, which will cause them to
be propagated to FULL_SYSTEMIMAGE_DEPS.
Bug: 205632228
Test: Full build with a change to delete files not in FULL_SYSTEMIMAGE_DEPS from the staging dir
Change-Id: I0600ccf8d863d5e29e044c82293ece730fc98d43
Source tree may include prebuilt vndk snapshot libs that are newer
than or equal to the PLATFORM_VNDK_VERSION.
Ignore those prebuilt vndk snapshot libs.
Bug: 296488609
Test: lunch cf_x86_64_phone-next-userdebug; m nothing
Change-Id: I3adaf3b7636f53884f08540959d2ec2fddfb6921
llndk.libraries.txt file is currently located within the VNDK APEX.
However, this file is still required even if VNDK APEX is deprecated.
This change removes llndk.libraries.txt from VNDK APEX, so it can be
installed within the system image.
Bug: 290160925
Test: aosp_cf build succeeded with llndk.libraries.txt in the system
image
Change-Id: I09a0a43babaa58ff16fc04ea71ab41ab68b54b70
For device build, rust defaults to dylib linkage for rustlibs deps. `dylibs` prop was provided for flexibility.
By removing it, we're enforcing users to either use the default linkage (dylibs for device and rlibs for host) or rlibs prop explicitly. This means no dylibs for host modules. This makes sense because host modules always uses rlib linkage against libstd. The flexibility with dylibs prop opened room for linkage collisions because the dependencies don't link against libstd the same way.
Test: go test
Change-Id: I2fc221daa8a9bb42bdcf6d9823c723a4ddabe7b5
Currently vendor APEX can link to VNDK when 'use_vndk_as_stable'
property is set as true. However, when VNDK is deprecated, all former
VNDK libraries should be included in the vendor APEX despite of property
value. This change ignores use_vndk_as_stable when VNDK is set as
deprecated.
Bug: 290318998
Test: aosp_cf_x86_64_phone with WITH_VNDK=false build checked that
Vendor APEX contains all required VNDK libraries within the APEX
Change-Id: I648277d734274e7852b3effc24e7780e55089f75
Adds dylib support for vendor and recovery images.
This changes the default linkage for vendor and recovery images to
dylib, which matches the platform default linkage. This also means that
by default, dylib-std variants are used for rlib dependencies.
Bug: 204303985
Test: Soong tests.
Test: m dist vendor-snapshot
Test: RECOVERY_SNAPSHOT_VERSION=current m dist recovery-snapshot
Change-Id: If84074b8615a70c45e7e162abeb853dc8c34d49a
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
This is to decouple profile generation from image configs. A boot image
profile is either for a mainline module or for the platform, which is
orthogonal to boot images.
Bug: 290583827
Test: m nothing
Change-Id: I0918f2fa945a2af1839f1a08ecede331c64d0317
The Modules() method was for the ART boot image in the ART APEX. It's no
longer needed because we don't install the ART boot image in the ART
APEX anymore.
Bug: 290583827
Test: m nothing
Change-Id: I674a5fa1ed18908413a64129df5947c7d26e638e
This CL is to prepare for the changes in http://r.android.com/2652081.
See the description of that CL for the reasons.
Some tests were set up in a fragile way and were easy to be broken when
the implementation changes. This CL is a pure test change that fixes
them.
This CL also removes TestNoUpdatableJarsInBootImage. That test checks
what should go to the ART boot image and what should go to the
platform one, which does not apply today because boot images are not
associated with mainline modules anymore: a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. In practice, we have ART jars in
the platform boot image, and we are going to add core-icu4j and
consrypt to the ART boot image, which is now for testing only.
Bug: 290583827
Test: m nothing
Change-Id: I22c45cbf6f853b030b68edb51197854e9c53a02e
We will deprecate flattened apexes. In this change, GSI-specific make
variable (PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES) is removed. The
variable was used to install both image/flattened apexes in the GSI, so
that it works on ro.apex.updatable devices and not-updatable devices.
Now, GSI will have only image APEXes in it.
Bug: 278826656
Test: lunch gsi_arm64-userdebug && m # no flattened apexes
Change-Id: Ie5fe505b9f2a6a1687252513788fd3e16bc147c5
deapexer doesn't need it.
Bug: 279858383
Test: presubmit
Test: m MODULE_BUILD_FROM_SOURCE=false droid
Change-Id: Ie8311c74682f366cf6aeebb669500d01675cd0bf
Bug: 285138555
Test: b build //build/bazel/examples/... --config=android
Test: b test //build/bazel/tests/... --config=android
Change-Id: I7350930d48ccd13e96bdb4f994f47071a0dde70f
Bug: 285138555
Test: b build //build/bazel/examples/... --config=android
Test: b test //build/bazel/tests/... --config=android
Change-Id: I11372cbc01b89d530a35f90375ca6fa87834edd2
This property allows modifying the variant version that is put into the
APEX manifest.
Bug: 285138555
Change-Id: I42b8c0ddad8822a0a329e99ec4ec62f8c3546ee9
This property allows developers to create multiple modules that provide
the same APEX implemenation with some differences. For example, an APEX
that targets the current SDK can be developed alongside an APEX that
targets a pre-S SDK. Common dependencies of these APEX modules can both
use the value of the apex_available_name property in their
apex_available lists and be packaged in either APEX module.
Bug: 285138555
Change-Id: Ia2cb027e2f19bd6d3d1c02e3d3742a0122a43c97
Since vendor APEXes are installed in vendor partition, there shouldn't
be system_file according to Treble. Instead, we can force-label / and
/apex_manifest.pb as vendor_apex_metadata_file so that apexd (and other
system components) can still read them.
Bug: 285075529
Test: m nothing (soong test)
Change-Id: Idb36b8c4c68b29e2235dbda38ee323d4b781e1d5
AndroidMk assumes that the app is the last file installed, and it uses
this assumption to populate the LOCAL_SOONG_INSTALLED_MODULE entry. This
CL moves the privapp_allowlist installation to before the app
installation to respect this assumption.
Bug: 242509786
Test: go test
Test: OUT_DIR=out.ref m nothing &&
cp aosp/2562351 && OUT_DIR=out.change m nothing &&
GOWORK=$PWD/build/bazel/mkcompare/go.work \
go run android/bazel/mkcompare/cmd -json \
<(sed -e "s/out\.ref/out/g" out.ref/soong/Android-aosp_cheetah.mk) \
<(sed -e "s/out\.change/out/g" out.change/soong/Android-aosp_cheetah.mk)
&& verify manually that the only diffs are related to the removal of
the prebuilt_etc module.
Change-Id: I95ec27070f575e79fb976de68493a219717ed89a
For a non-override android_app, we can assume that the privapp_allowlist
already contains the correct package_name, and so we don't need to
overwrite it in this case.
Bug: 242509786
Test: go test
Merged-In: I0f137e34cae3478dc8b9178d138121ff1d936f07
Change-Id: I0f137e34cae3478dc8b9178d138121ff1d936f07
