When a java_sdk_library module is added, both impl jar and permission
xml files are packaged together.
For example, when a java_sdk_library "foo" is listed, following two
entries will be in an APEX package.
/javalibs/foo.jar
/etc/permissions/foo.xml
Bug: 145474221
Test: m com.android.cronet
deapexer list com.android.cronet.apex
Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
Effectively adds the cc_defaults module type to the set that are
registered for tests that rely on cc default deps so needed to remove
a few references of that.
Test: m checkbuild
Bug: 146540677
Change-Id: I9df3d33a0cf3f6b22d270efed8366d0183eccaec
This fixes an issue that arises when deduping cc build component
registration code.
The sanitize_runtime_deps and sanitize_runtime post deps mutators were
not previously added when running cc tests. That meant the tests were
not actually testing the same behavior as at runtime.
Adding the mutators breaks the TestFuzzTarget test as the mutator adds
libclang_rt.ubsan_standalone-aarch64-android as a dependency of libc++
and the former is not available.
This fixes the test by adding the missing dependency as a cc prebuilt
shared library.
Test: m checkbuild
Bug: 146540677
Change-Id: Ie13c7e6fcefef7d9cb1cc5364be3dc563ce40de5
The cc.GatherRequiredDepsForTest() method returns some default module
definitions that are required when using cc module types like
cc_library. Previously, the registration of the module types and
mutators needed to process those default definitions was duplicated
in the test config initialization.
This change removes that duplicated code and replaces it with calls
to cc.RegisterRequiredBuildComponentsForTest(ctx) which registers all
the required build components.
Test: m checkbuild
Bug: 146540677
Change-Id: I80b6913c5691ff164ce9d308b9e1da24940f2d42
The registration of module types and singletons is duplicated between
init() functions that register them for use in the build runtime and
test context creation code that registers them for testing.
This is a proof of concept for a mechanism that will allow the code
to be shared. It defines a RegistrationContext interface that is
implemented by both the TestContext and the new initRegistrationContext
type. An instance of the the latter is available through the
InitRegistrationContext variable.
The intent is that the registration of the module types and singleton
types will be extracted from the init() function into a separate
function that takes a RegistrationContext parameter. That method is
called from init() passing in the InitRegistrationContext and from a
test passing in the TestContext. Something like this:
func init() {
RegisterBuildComponents(android.InitRegistrationContext)
}
func RegisterBuildComponents(ctx android.RegistrationContext) {
ctx.RegisterModuleType(....)
....
}
A test would do something like this:
ctx := android.NewTestContext()
RegisterBuildComponents(ctx)
Test: m nothing
Change-Id: I97173cabb6d6cf7ce98fdb5f73418438b1997b35
It's not yet supported by bundletool and blocks other testing (see
attached bug).
This is a partial revert of
https://android-review.googlesource.com/c/platform/build/soong/+/1183459/
Test: out/dist/mainline_modules_arm64/com.android.tzdata-base.zip
Test: checked content doesn't have apex_pubkey
Bug: 146460014
Change-Id: I268caa9f9736ba1913145a1ce1065f6f5179a6db
The filesystem object was available through ModuleContext.Fs(), but
gives too much access to the filesystem without enforicing correct
dependencies. In order to support sandboxing the soong_build
process move the filesystem into the Config. The next change will
make it private.
Bug: 146437378
Test: all Soong tests
Change-Id: I5d3ae9108f120fd335b21efd612aefa078378813
Run the imageMutator between osMutator and archMutator so that
different arch variants can be set for the different partitions.
Bug: 142286466
Test: m checkbuild
Change-Id: I65d05714b75aa462bf9816da60fdc2deda4de593
Merged-In: I65d05714b75aa462bf9816da60fdc2deda4de593
(cherry picked from commit 9c8f687584)
The rules for apex certificate:
1. <unspecified>: use <default app cerficicate>
2. name: use <default app cerficiate dir>/<name>(.x509.pem|.pk8)
3. :module: use specified by <module>
Certificates can be overridden by PRODUCT_CERTIFICATE_OVERRIDES.
Currently, 1) and 2) aren't overridden by PRODUCT_CERTIFICATE_OVERRIDES,
which should be.
Bug: n/a
Test: m (apex_test.go amended)
Change-Id: Icbdf4979613ef10127ecc02f3debd6a798460532
In case that an apex module depends on a module with stubs directly
*and* indirectly, the build system should follow the deps graph further.
Note that WalkDeps() visits deps in DFS and it won't visit again visited
modules.
Bug: n/a
Test: m (apex_test.go amended)
Change-Id: I1a6f135dbda6d1eb641575a3fbbc9bbee0622076
This change fixes a bug that LOCAL_PATH for modules included in an APEX
is set to the path of the APEX bundle, not to the path of the embedded
module. For example, LOCAL_PATH of libconscrypt included in
com.android.adbd was set to /system/core/adb instead of
/external/boringssl. This caused a problem that NOTICE file in
/external/boringssl is not tagged to libconscrypt, but the NOTICE file
for adbd is.
Fixing the problem by recording the module directories of the included
modules and emitting it in LOCAL_PATH.
Bug: 145347092
Test: Settings -> About Phone -> Legal Information -> Third-party
license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is
OpenSSL.
Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
Use the empty string for the core image variant so that modules
added to imageMutator do not change their build directory.
Bug: 142286466
Test: m checkbuild
Change-Id: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
Merged-In: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
(cherry picked from commit 72d685ee7f45e5393be44ae4159edf083ac918de)
APEXes with "legacy_android10_support" will have apex_manifest.json for
compatibility as well as apex_manifest.pb.
Bug: 143951586
Test: m (soong tests)
Change-Id: I019252aee5a9423f4b180ba1026e6e99c9961437
AndroidMkEntries now returns multiple AndroidMkEntires so that a module
can emit multiple Make modules if needed.
Bug: 128708192
Test: m
Change-Id: I56b6f76d22943b80329951c5acb80a1b932441ad
The two were missing.
Bug: 145678884
Test: m out/dist/mainline_modules_arm64/com.android.tzdata-base.zip and
inspect the content
Change-Id: I7e244561f59e5adce56b6a64f363a413faa106f2
Move the ImageMutator to be registered just after the archMutator
in preparation for moving it between osMutator and archMutator.
Requries updating variants in a few tests that now run the
ImageMutator.
Bug: 142286466
Test: no change to build.ninja
Test: all soong tests
Change-Id: Ia9d2a7bc0e225bedec3c9a83ea04f471a931bf47
GSI targets are supposed to have both 'flattened' and 'unflattened'
APEXes. By adding 'flattened' APEX as REQUIRED moduled for 'unflattened'
APEX, both will be installed togetther.
This is done by a new variable PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES,
which is set only for GSI targets.
Bug: 137802149
Test: lunch aosp_arm64-userdebug && m
resulting apex images under /system/apex
and flattened apexes under /system/system_ext/apex
Change-Id: I336e2674e427b358542e0045b2a49dfa3d84095b
This change fixes the problem that when an apex module is overridden by
another override_apex, the <apex_name>-file_contexts are duplicated when
creating the system-level file-contexts.
Fixing this by not emitting the file_context info for the overridden
apex.
In doing so, OverridableModule interface was extended to have
GetOverriddenBy() method which can be used to test whether a module is
an overridden one or not.
Bug: 144338929
Test: m (apex_test amended)
Test: add "override_apex {name:"com.googlge.android.tzdata",
Change-Id: I5e9401c32899bb9987c90cba4185f571dc1a87f0
base:"com.android.tzdata"}" and the build is successful
When flattened, the Make module for an APEX is a phony package for the
files in it. There is no output (either implcit or explicit) there.
Bug: 144338929
Test: m
Test: check the generated Android-<target>.mk file
Change-Id: I86df3b69f402a7e2d94bafa39f2aad3312d8c28b
Previously, it was defaultable only for cc_library. Now, it is
defaultable for all module types.
Bug: 128708192
Test: m
Change-Id: If248f593da6f4b724bf889ccd7f2e077d48069b5
This change is to make it easier to add new fields to the struct.
transitiveDep field is added to distinguish apexFiles coming from
transitive dependencies of the APEX. We will later use the info to
reduce the size of bundled APEXes by replacing the transitive deps with
symlinks to the corresponding files in the system partition outside of
the APEX.
Bug: 144533348
Test: m
Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
This build rule is specific to platform APEXes.
For non-platform APEXes, MakeAsSystemExt() is not applied.
This fixes the cases of "soc_specific: true" apexes which fails to
build.
Bug: 139053989
Test: m nothing (soong tests)
Change-Id: I98d0257499647ab41cdaa62a3671d89addbdf833
Exempt-From-Owner-Approval: got +1 before rebasing
Avoid having to pass ModuleFactoryAdaptor to every call to
RegisterModuleType in a test by wrapping RegisterModuleType.
Test: all soong tests
Change-Id: If8847d16487de0479cc3020b728256922b3cadba
When an override_apex named Foo overrides an apex module named Bar, the
Make modules from Foo have Foo as their suffix. Previously the suffix
was Bar for both of the overriding and the overridden APEXes, causing
name conflicts in the Make side.
Bug: 144338929
Test: apex_test.go
Change-Id: I1396910ab294ba5f5e0585af6d37f1eab9460250
For platform APEXes, file_contexts should point a file under
/system/sepolicy.
Bug: 144732805
Test: m
Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
prebult_etc module type does not respect prefer32, i.e. its primary arch
is 64-bit on 64/32-bit device even when built with TARGET_PREFER_32_BIT
is true. However, the apex module type respects prefer32 and therefore
when TARGET_PREFER_32_BIT is true its primary arch becomes 32-bit. Then
the problem is that the apex tries to depend on 32-bit variant of the
prebuilt_etc modules which don't exist.
Fixing the problem by force using the first arch of the device when
adding dependencies to prebuilt_etc modules.
Bug: 144532908
Test: choosecombo 1 aosp_arm64 userdebug; TARGET_PREFER_32_BIT=true m;
Change-Id: I7642c57b05a837495587bbe4d3589d8549607862
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.
Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
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
Dario Freni