If we don't check "current", it won't be checked even in the finalized
branch.
If we don't check "preview", it should be done during the SDK
finalization. It'd be better done before the SDK finalization regarding
that setting min_sdk_version is to get approval from deps library owners.
Bug: 177833148
Test: m (soong tests)
Change-Id: I712b61cfe5a134fbb69c73956d26fb3a1e5c011e
This reverts commit 556b2ad77e.
Original change-id: Ib1b2f0dd2f9ae85b1545c6cc5bb4c5bbdfac1c15
Reason for revert: Add excutable permission to the gen_ndk_backedby_apex.sh.
Test: TARGET_BUILD_APPS=com.android.adbd m dist apps_only
Change-Id: Ib587ba200cd7f2f61d478452b43c329d72b2de06
Add gen_ndk_usedby_apex.sh script to generate NDK API list used by Mainlain modules when modules get build.
Test: TARGET_BUILD_APPS=com.android.adbd m dist apps_only
Change-Id: Ib1b2f0dd2f9ae85b1545c6cc5bb4c5bbdfac1c15
Bug: 176171716
Test: build_mainline_modules.sh and ensure that the ART boot image is
built: `find out -type f -name '*.art'` is nonempty for every arch.
Change-Id: Ibc45581eef2b205c750a30709780cf659ba7cfa1
Currently, when a module is included in an APEX, the dependencies of the
modules are listed in LOCAL_REQUIRED_MODULES of the APEX. There are two
purposes for this:
1) for native dependencies, they are installed to
$(TARGET_OUT)/apex/<apexname> directories which isn't packaged as an
*.img. However, as a side effect of the installation, their symbol files
are placed under $(TARGET_OUT)/symbols directory to aid debugging.
2) to implement the symlink optimization. When the APEX is not
updatable, the dependencies are not included inside the APEX, but
installed directly to /system partition because the same files might be
used outside of the APEX. The files in the APEX are replaced with
symlinks to the system copy.
So far, the module name like "libfoo" was directly used in
LOCAL_REQUIRED_MODULES. This becomes problematic when only a single arch
variant of the module is used by the APEX. The build system will install
both arch variants to the system partition.
This change fixes the problem by appending ":32" or ":64" suffix
when composing LOCAL_REQUIRED_MODULES.
Bug: N/A
Test: m
Test: Cherry-pick I285c5d1bb9b27265c8589f2588d95eafa324d412 and its
dependencies from internal master. `m nothing` doesn't show the artifact
path requirement error.
Change-Id: I78feae1d5b18f93b0f984d3b1558812fd1689a96
With the addition of the compile_dex property to the
java_import module it becomes possible to include a
java_import module in an apex. This change allows the
dependency and adds a test.
Bug: 177228901
Test: m nothing
Test: new TestApexWithJavaImport
Change-Id: I9336dade1857109e2fd21f7d57e1dc4abc4a402c
Dexpreopt and boot jars package check all require access to dex
implementation jars created for java_library and java_sdk_library. They
were available when building from source but not when building from
prebuilts, even though they are embedded within the .apex files that
are referenced from prebuilt_apex.
This changes adds support to prebuilt_apex to export the dex
implementation jars and updates java_import to use those exported dex
implementation jars.
In a source build dexpreopt/boot jars package check access the apex (or
platform) specific variant of a java_library, e.g. core-oj, from which
it retrieves the dex implementation jar path.
After this change in a prebuilt build dexpreopt/boot jars package check
behave in the same way except in this case they retrieve the dex
implementation jar path from the apex (or platform) specific variant of
the java_import, e.g. core-oj.
The work to export files from a `.apex` file for use by other modules
is performed by a new `deapexer` module type. It is not used directly
in an `Android.bp` file but instead is created implicitly by
`prebuilt_apex`,
In order to do that this contains the following changes:
* Adds a new `dexapexer` module type to handle the exporting of files
from the `.apex` file.
* Adds an exported_java_libs property to prebuilt_apex to specify the
set of libraries whose dex implementation jars need exporting.
* Creates apex specific variants of the libraries listed in the
exported_java_libs property.
* Adds the set of exported files to the ApexInfo to make them available
to the apex specific variants.
* Prevents the prebuilt_apex variants from being merged together as
they will not be compatible.
* Modifies java_import to use the exported file for variants of a
prebuilt_apex.
* Adds a ninja rule to unpack (using deapexer) the contents of the
prebuilt_apex's apex file, verify that the required files are present
and make them available as outputs for other rules to use.
* Some minor refactorings to support these changes.
* Adds tests to cover prebuilt only, prebuilt with source preferred,
and prebuilt preferred with source.
Test: m nothing
Bug: 171061220
Change-Id: Ic9bed81fb65b92f0d59f64c0bce168a9ed44cfac
For the platform libc++ STL, remove the
-Wl,--exclude-libs,libunwind_llvm.a argument, which is redundant with
the same argument in deviceGlobalLdflags.
Bug: http://b/153025717
Test: device boots
Change-Id: Idd7791d52f74aab2d5f59419fb75f841fc29a2eb
android_filesystem modules can be included in APEX via the new
`filesystems` property. The filesystem images are placed at
./etc/fs/<modulename>.img.
Bug: 172413888
Test: m nothing
Change-Id: I215ca7a32ff1988a0de4e1f71397684e189839ea
The APEX symlink optimization is a build-time trick to save the
storage/RAM usage of APEX by replacing some files in APEX with symlinks
to the files in the system partition. The optimization however is
automatically turned off for 'updatable: true' APEXes because doing the
optimization for them will hide the sys-health implication until when
the APEXes are built unbundled (i.e. prebuilt) and thus the
optimization is impossible.
TARGET_FORCE_APEX_SYMLINK_OPTIMIZATION forcibly disables the safety net.
When it is set to true, the symlink optimization is done regardless of
the 'updatable' property. This is useful for some of the devices like Go
where most APEXes (even the 'updatable: true' ones) should be
effectively non-updatable.
Bug: 175630508
Test: TARGET_FORCE_APEX_SYMLINK_OPTIMIZATION=true m and check that
updatable APEXes have symlinks to system libs
Change-Id: I26f72e5d5ebccc2d1e09c2a2f743db14937eb39a
The NDK build in downstream branches with prebuilt apexes break
with multiple rules to copy the apex after
I8038ed5c6f05c989ac21ec06c4552fb3136b9a7a renamed SkipInstall to
HideFromMake, which is shadowed by an existing HideFromMake method.
Call through from the existing HideFromMake as a quick-fix for the
build.
Fixes: 175911330
Test: NDK build
Change-Id: Id475671d5dad888913bfb1af2e4be1f2454c3211
This fixes a regression in https://r.android.com/1515154 when building
the host ART APEX (com.android.art.host).
Test: art/build/apex/runtests.sh
Bug: 166468760
Change-Id: I39a00019b7bfa77a865e7287c66add3566b34d87
Refactor the apexInfoMutator to delegate the work to an implementation
of ApexInfoMutator and then move the existing functionality into the
apexBundle.ApexInfoMutator(). This will allow a follow up change to
customize the behavior of this mutator for prebuilt_apex modules.
Test: m nothing
Bug: 171061220
Change-Id: I7ccd55818e02a606c5494e215f4370b635ddd0a5
This change fixes a bug that headers are not re-exported from stub
variants of a library, if the headers are not from header libs, but from
shared or static libs. This is because only header lib dependencies
are respected for stubs variants.
The fix is as follows. 1) dependencies to the shared/static libs are
added even for stubs variants. 2) instead, in depsToPaths, they are
treated like header libs (i.e. don't contribute to linkFile) for the
stubs variants.
Bug: 174558745
Test: m
Change-Id: Iab6c77e7817055d0f2d09cb114186b30164fc231
Generally ...DepsMutator methods add dependencies between modules but
the apexDepsMutator does not which can be confusing. This renames
apexDepsMutator to apexInfoMutator and adds some extra documentation to
clarify its function. It also renames the registered name for the
mutator and its associated providers from apex_deps to apex_info.
Test: m nothing
Bug: 171061220
Change-Id: Ic074a281215b23e982448ccff7ac075236123bee
This CL fixes a bug that rust_ffi_shared libraries can't be included in
an APEX either directly (via native_shared_libs property) or indirectly.
Bug: 175105284
Test: m
Change-Id: I2e2d3e11b3901f3412b9725e47a8ebf31f93847b
1. Soong can now detect PRODUCT_COMPRESSED_APEX flag
We don't want APEX to be compressed on all devices. Only those that
have explicitely set PRODUCT_COMPRESSED_APEX flag.
2. Handle "compressible" field in soong build rule
On devices that supports APEX compression, all APEX will be
compressed by default. If any apex does not want to be compressed,
they will need to state that by setting "compressible" field to
false
3. Can use apex_compression_tool to compress APEX
Note we compress the APEX after it has been signed. That way, when
we decompress we will get a signed APEX.
4. Place the compressed APEX in system with .capex extension
This makes it easy to identify. We still preserve the original
extension so that when we decompress, we can just rename by cuttif
off the .capex extension.
Note: with this change, we can create a system image with compressed
APEX, but we cannot boot with it since platform doesn't know how to
handle .capex files. Platform support will be added on follow up CLs.
Bug: 172911362
Test: OVERRIDE_PRODUCT_COMPRESSED_APEX=true m (apex_test.go)
Test: observed $OUT/system/apex has .capex files
Change-Id: I20ac4c4ceb521924c751a6017f979b2d808fdded
The property is used to exclude some shared and static libs when the
module is built for an APEX.
Bug: 166468760
Test: m
Change-Id: I0dcaa4ae94c01aa00dc5539c60d3054c57fd8824
