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
Verify logic for transitive shared vs static deps to
ensure in Bazel that these are handled similarly.
Test: go test soong tests
Change-Id: I015935fa4d7eb1ac40666d47a8de8e48150a043e
* changes:
Dexpreopt ART jars and framework jars together.
Unify installDirOnHost and installDirOnDevice.
Remove the ability to install boot images by bootclasspath_fragments.
Prepare tests for dexpreopt changes.
We don't need this anymore because we are going to compile ART jars and
framework jars together.
Bug: 280776428
Test: m
Change-Id: I070157530449a1bb5779e25984c367df3dde7b36
After this change, there is a clear separation between tests that are
related to dexpreopt and tests that are not. The former uses
PrepareForTestWithDexpreopt, while the latter uses
PrepareForTestWithJavaDefaultModules. The benefit is that the latter
will no longer affected by any dexpreopt changes.
Bug: 280776428
Test: m nothing
Change-Id: Ib957765b9287d51c082e0a33cee17a6bb56daeef
* changes:
Special case platform variant of bootstrap libs
Select stub/impl per apex variant
For test apexes, base_apex_name is the api domain
Broaden the granularity of config_setting from apex_name to api_domain
Print default val if all vals in axis match default val
apex_test do not "override" the source apexes that they test. However,
similar to override_apexes, test apexes have the same path
(/apex/<apex_name>) on device. Instead of creating another property,
reuse the existing base_apex_name property. The use case for this will
be for creating selection statements for stub/impl selection.
Test: go test ./bp2build
Change-Id: I4b7548e0e0fc920e407e1c5e5c00e87efc6e70c9
so that Vendor APEXes don't embed the LLNDK prebuilts (which are just
stubs of LLNDK libraries).
Bug: 280697209
Test: m nothing (soong test)
Change-Id: I9e6c123e73fa0ab56d8494a01652ee32a9b6a6cd
Since these apps explicitly set com.android.cellbroadcast in their
Android.bp files, they do not need to be present in the baseline
apex_available map.
Test: m nothing
Bug: 281077552
Change-Id: Ibea86bfbc7e460e27c5e780b611674e66e9cf727
These libraries now set the correct apex_available in their Android.bp
files. Therefore, they do not a separate entry in the baseline
apexAvailable map.
Test: m nothing #passes
Bug: 281077552
Change-Id: Icf6b97c3bcc4bda96eefa14ba6d4bf10614bc378
These are not needed in this map since the Android.bp files for these
modules are created by pom2bp script
which explicitly set apex_available as ['//apex_available:apex',
'//apex_available:platform'].
Bug: 281077552
Test: m nothing
Change-Id: I53bb9a104b1e7a2535fe568e27431b1a48a885e3
This change allows override_android_app to use the same
privapp_allowlist as the non-override module so that they will always
remain in sync.
Test: go test ./java -v -run TestPrivappAllowlist
Test: go test ./apex -v -run TestApexWithApps
Test: m com.android.permission com.google.android.permission and verify
manually that apex_payload.img contains correct privapp_allowlist
Test: m com.android.permission before and after change &&
`diffoscope apex_payload_reference.img apex_payload_with_change.img`
&& verify that there are no semantic changes
Bug: 242509786
Change-Id: Ifdcb28af40763aed7a4aac9a7f681153554bc256
This effectively undoes both If6c3ee82d588e2742c85cef7244c090c93f38b8e
and I682e4f1f477f3024f7719dfaa67006ef335e0640. SDK variants are now
installed again, which will fix unbundled builds of cc_test modules.
The platform variants used by com.android.virt are now packagable
even though they are not installable.
Fix the original problem in b/194403710 by adding a flag to platform
variants of modules in apexes that are not platform available, and
using that to prevent install and packaging dependencies. That
allows the HideFromMake flag to go back to being used for preventing
install dependencies but not packaging dependencies.
Test: TestPackagingWithSkipInstallDeps
Test: TestFileSystemShouldInstallCoreVariantIfTargetBuildAppsIsSet
Test: TestFileSystemShouldSkipApexLibraries
Bug: 194403710
Bug: 268582372
Fixes: 274443025
Change-Id: If5418df3ddbb940bd631caebdf38daa81e71f40e
Prevoiusly, we were partially correcting for override modules in
bp2build/mixed builds in some but not all places. Now we always check
for override modules and ensure that Bazel_module properties are
propagated properly for override modules.
Bug: 279609939
Test: go test soong tests
Change-Id: I5445aa71f4c8013315415a2ca9ab9c6b3be6bce0
As-is, dexpreopt config and bootjar is in the dir including
DeviceName(). It causes unnecessary dexpreopt invocation when target is
changed repeatly. To avoid it, rename dir to common name.
Bug: 278833696
Test: m
Change-Id: I2818d9ae09e6c22ca6989cc8efdb70b470ec502c
If a library contributes to an API surface, it will have only a single
copy on device. Therefore, we should disallow installation to muliple
apexes/platform.
There are some exceptions to this rule today, and they have been relaxed
using allowlists.
Bug: 277651159
Test: go test ./apex
Change-Id: Ice3023ecd28412a2610d8b98628cb727b58c5c3b
The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. In Soong, this will be
enforced using some graph walk which is not easy to port to Bazel.
However, we might need to revisit this when we build the enforcement
mechanism in Bazel. We likely need a `test_for` on the top level
apex_test Bazel rule so that the test apex is _allowed_ to link against impl
of the library it is trying to test.
(This CL retricts this to cc_library, I can expand this to other modules
if this is the right approach.)
Bug: 277651159
Change-Id: Iaeec22c5626df79a33785c766ed29102b1da403e
For now ext4 is the only supported fs_type.
Bug: 279689445
Test: m apex.apexd_test_erosf
Test: m apex.apexd_test_f2fs
Change-Id: Idd1b2e61e25110da6d3805b082195e6ec031f573
This reverts commit 9551384f65.
5bedfee448 is a better solution for the
same problem.
Bug: 279247159
Test: m checkbuild (presubmit)
Change-Id: Ifd3117a4450b5275c09258d1ce896adb41a75158
These should be handled by Makefile dependency (LOCAL_REQUIRED_MODULES).
Bug: 278832320
Test: build and see symbol files
Change-Id: I80ad9d8e7e8384e2ae3537cc681bc1d1b327d04c
If any of apexes in apex_available is an apex_test, then that name will
be propagated down from that apex to each apex variant. This metadata
will be used to enforce that stub libraries cannot have more than one
apex_available.
This logic is necessary so that bp2build can select the correct
stub/impl.
(To avoid replicating this complexity in Bazel, we should consider
dropping the test apexes in Bazel BUILD files, next CL)
Bug: 277651159
Test: go build ./apex
Change-Id: I63617c1dc2a2d5c9cd7758c416fec7b4db1f10a7
Apexer rule with symbol files causes "no build rule" error when the apex
is replaced with prebuilt.
Bug: 251299786
Test: m checkbuild (presubmit)
Change-Id: I7390f72c321beaeb49fcee4e02a219c07f184664
Teach rustc to generate object files instead of a linked executable
for binary and shared library crates. This lets us skip the lengthy
Rust compilation phase when only the C++ dependencies of these crates
have changed.
This works using a Python script that replaces the linker invoked by
rustc and converts the linker command line into a rspfile that can be
used during the link phase. The script makes certain assumptions about
how rustc invokes the linker, but since we control the version of Rust
we use, we can update the script if those assumptions ever break. I've
asked the Rust developers about adding an official way to do this so
hopefully we won't need to rely on this hack in the future.
The rustc rule for Kythe has been altered to pass linker=true, somewhat
consistent with the main rustc rule, which now doesn't invoke the actual
linker either. `m xref_rust` still succeeds, but hopefully we can find
someone who knows more about the rest of the Kythe pipeline who can let
us know whether it should still work. Otherwise, let's use this CL as
an opportunity to find out whether the rest of the pipeline is happy
with linker=true, since otherwise we will find it hard to maintain the
Kythe rule in the future.
Change-Id: Ifb9c8689c1bd78c0afcf6fdfd111140d20377536
Updatable apexes should set a min_sdk_version that is not current. This
enforcement does not exist today, but will soon be added to the build
system. In preparation for that, cleanup the min_sdk_version property
used in this unit test.
Test: go test ./apex
Bug: 221087384
Change-Id: I8a163595f85cb0f8dabccc3321ef210215675714
Updatable apexes should set a min_sdk_version that is not current. This
enforcement does not exist today, but will soon be added to the build
system. In preparation for that, cleanup the min_sdk_version property
used in this unit test.
Test: go test ./apex
Bug: 221087384
Change-Id: Idabc4c6f20e134b38ed0ae3ce68f6b7d54d7a13c
.. as a validation for apex.
apex_sepolicy_tests checks the contents of the apex against
precompilec_sepolicy. This is to avoid common mistakes in file_contexts.
For example, etc/vintf directory should be read-able by servicemanager.
Bug: 267269895
Test: m com.google.cf.wifi (with wrong file_contexts entry)
Change-Id: Ic363345df43e5b2108b07de787f5f6817bbe6af4
libc_hwasan is a new library in the runtime apex that lives in
bionic/hwasan/libc.so and is symlinked to /system/lib64/hwasan/libc.so.
This is chosen by the linker if an app or binary requires HWASan
support.
Bug: 276930343
Change-Id: If331744ad84241ad99a41805ea3110d37cf9b0af
Otherwise when other modules use the apex as data (for example, in
tests) they get the full path from the root of the workspace to the
apex.
Fixes: 276416485
Test: atest timezone_data_e2e_tests:com.android.tests.apex.TimezoneDataHostTest#testStageActivateUninstallApexPackage -- --abi x86_64 then tree out/host/linux-x86/testcases/timezone_data_e2e_tests
Change-Id: Id740856794770df2edc55dfff5f6f938fc31d0c5
There are no tests to verify the generated action for the canned fs
config entries, so add some.
Also update the prop's docstring to reflect the actual logic.
Bug: 275209284
Fixes: 275280970
Test: soong tests
Change-Id: I37f2a8640bf4c307068a77db7a635c9bbeb9f38f
