This commit adds support for compiling rust rules inside the sbox
sandbox. To compile a rust module with sandboxing enabled, the entry
point to the crate must be specified via the `crate_root` property, and
all input sources and compile-time data must be specified via the `srcs`
and `compile_data` properties.
Bug: 286077158
Change-Id: I8c9dc5cf7578037a583b4be2e2f73cf20ffd4408
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
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
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.
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
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
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
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
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
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
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
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
For vendor apexes, use_vndk_as_stable: true means the apex is tied with
the current VNDK version while min_sdk_version: N means the apex should
work with N+ VNDK versions. Setting both properties together doesn't
make sense.
Bug: 274396342
Test: m nothing (soong tests)
Change-Id: I00dcac43f95ce6a90b3f3273ae4611a300ea5028
Vendor APEXes can be updatable unless it sets "use_vndk_as_stable:true".
When "updatable:true", it should meet the "updatable" requirements like
"should set min_sdk_version".
Bug: 274396342
Bug: 274041915
Test: m nothing (soong tests)
Change-Id: I746d8941c21e883c1eba3e1f1e5a414a67db071a
