All commands must produce their output files, or they'll trigger
rebuilds the next build.
Test: m com.android.apex.cts.shim.v3; repeat; "ninja: nothing to do"
Change-Id: If30e9d90ce3efc0689cd04ac62cc8207f3a38dd5
Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes
the apkcerts.txt to have empty keys for those APKs, which
confuses the signing tools. Set LOCAL_CERTIFICATE for them.
Also refactor the Certificate support to avoid introducing
duplicated handling for presigned certificates.
Bug: 147765187
Test: m apkcerts-list
Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
This change fixes a bug that license info for non-flattened APEXes are
not captured in /system/etc/NOTICE.xml.gz file. For non-flatted APEXes,
we have been creating NOTICE.html.gz file by concatenating all the
license infos of the modules that contributes to the APEX and embedding
the file into the asset directory of the APEX. Then at runtime, the info
is shown through the "Google Play System Update Licenses" UI. However,
this was problematic because the UI only shows license info for the
Google-signed APEXes, leaving OEM-signed APEXes (a.k.a. optional
modules).
The problem is now fixed by associating a merged license file with each
APEX and exporting them to Make, so that the merged license files are
included in the partition level /system/etc/NOTICE.xml.gz file
regardless of whether the APEX is a Google-signed one or not.
This also fixes a bug that license info entries are created for the
runtime paths /apex/<apex_name>/<path_to_a_file>, which is not necessary
as they are already included in the license info of the containing APEX.
Bug: N/A
Test: Go to Settings->About Phone->Legal information and check
that a) /system/apex/*.apex files are shown and b) /apex/<apex_name>/*
files are not shown
Change-Id: I2c25c803b6a4c39b24bb3f724502699382fab50c
This change fixes a bug that symlinks to the system partition are
created in /system/apex/<apex_name> directories even when the APEXes are
non-flattened. The symlinks are needed only for flattened APEX (of
course regardless of whether the APEX is a primary one or not).
Bug: N/A
Test: examine /system/apex directory manually
Change-Id: I00bb1423d0a2497408f05e49767b42437210bab8
This reverts commit 230e241f58.
Reason for revert: This is a revert of a revert. Downstream problem has been fixed and have been validated locally and via Forrest build.
Change-Id: I89c51d25b3adb818ea44a983d0ac681a88790d8c
Symlinks to system libs should be created for flattened apex regardless
that it is primary or not.
For example, GSI installs non-primary flattened apexes as well. These
flattened (non-primary) apexes could be activated on non-updatable
devices.
Bug: 148195518
Test: GSI runs on P
Change-Id: I238b226473d923e03280b1b28dd0d5d1f77ae74a
This reverts commit 5df3b11f78.
Reason for revert: re-land with a fix
Fix a broken soong test
Add implicit dependency (libprofile-clang-extra) to make a test pass.
Bug: n/a
Test: m
Change-Id: I0b179199bc032501354f8e24782837453781bd8c
VNDK APEX is supposed to contain "vendor" variants of VNDK libraries.
This is different from normal APEXes which have "apex" variants.
Bug: 146758869
Test: build / flash / boot
Change-Id: I5e035678c337334092616b58d2e0e404788a6639
Exempt-From-Owner-Approval: Got ORV, but rebased with resolving merge conflicts.
This reverts commit 014a85712d.
Reason for revert: Caused vendor/google/build/build_mainline_modules.sh to fail with `Error: minSdkVersion (10000) is greater than maxSdkVersion (30)`.
Bug: 130541924
Change-Id: Ifa233bf40a674481d21b61ee816c5fdde8201080
Use codename.fingerprint format for minSdkVersion if it is unset
in the manifest and
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true.
Using a utility function in sdk.go to check whether to apply
api.fingerprint.
BUG: 130541924
Change-Id: I748a25c419033bf54b63171d334644fcd0ecc78f
This reverts commit 31c65d4fe4.
Bug: 144533348
Test: checkout master-art-host and run
ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host
the result is successful
Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
This means everything that goes into apexes need to be
explicitly labeled to be available for apex.
Whitelist the current offenders. This list should be
trimmed down.
Bug: 147364041
Test: m
Test: multiproduct_kati -only-soong
Exempt-From-Owner-Approval: cherry-pick from internal
Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
(cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
Used in coverage builds.
Test: NATIVE_COVERAGE=true \
EMMA_INSTRUMENT_FRAMEWORK=true \
EMMA_INSTRUMENT=true \
m nothing
Change-Id: I6309d8149fce016eb9689326eeae221914e4c3bb
This means everything that goes into apexes need to be
explicitly labeled to be available for apex.
Whitelist the current offenders. This list should be
trimmed down.
Bug: 147364041
Test: m
Test: multiproduct_kati -only-soong
Exempt-From-Owner-Approval: Just added more whitelist entries
Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
For post-Q modules, we can avoid building the hashtree also in the
unbundled build case, since the device will regenerate the hashtree
locally. This CL simplifies the logic so that the build rules apply
regardless of the build being bundled or unbundled -- after all, bundled
build are only really valid for development purposes.
Fix: 147600151
Test: unit test;
m com.android.conscrypt and manual inspection of apexer invocation
(option no_hashtree not present)
m com.android.neuralnetworks and manual inspection of apexer invocation
(option no_hashtree present)
Change-Id: Ib4cc6149d3beac5df7e23a65a3b7ee6b0d68e395
This reverts commit 7cb4d378e7.
Test: m
Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist ./art/tools/dist_linux_bionic.sh -j80 com.android.art.host
(in the master-art-host branch)
Change-Id: I9beca73aafdf42f03bfa19cf1634b2641dac417b
This reverts commit 956305c61c.
Reason for revert: broke master-art-host branch
Exempt-From-Owner-Approval: reverting a bad change
Change-Id: Id7faed4ee85328c7c65847a3543ea9e67a3d50b3
For each APEX, <apexname>-installed-files.txt is dist'ed to show the
list of files and their sizes that are included in the APEX.
Bug: 147605944
Test: m dist and examine the txt files
Change-Id: I565479523e51280fc88d5fbf8ea3f48ac0ae9fee
Previously, both overridden APEX and overriding APEX were installed
together when TARGET_FLATTEN_APEX is set to true. This was because the
Make modules for flattened APEXes are phony where
LOCAL_OVERRIDES_MODULES isn't respected.
Fixing the problem by letting apex_manifest.pb for the overriding APEX
to override all modules for the overridden APEXes.
Bug: 147384966
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m dump-files | grep
mediaprovider shows
: out/target/product/coral/system/apex/com.google.android.mediaprovider/apex_manifest.pb
: out/target/product/coral/system/apex/com.google.android.mediaprovider/apex_pubkey
: out/target/product/coral/system/apex/com.google.android.mediaprovider/javalib/framework-mediaprovider.jar
: out/target/product/coral/system/apex/com.google.android.mediaprovider/lib64/libfuse.so
: out/target/product/coral/system/apex/com.google.android.mediaprovider/priv-app/MediaProvider/MediaProviderGoogle.apk
only
Change-Id: I6dc3fc7aaee0474cbad9fadbfce765be4b751328
This change fixes a bug that jacoco-report-classes-all.jar does not
include info for APK-in-APEX such as the MediaProvider apk in
com.android.mediaprovider APEX.
Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for
the APKs included in APEXes. Secondly, the Make modules for the embedded
APKs are now built with soong_app_prebuilt.mk to correctly import the
jacoco file into the Make world.
Bug: 147296855
Test: execute the following command in internal master.
$ choosecombo cf_x86_phone userdebug
$ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m
The result shows that there is a path as follows:
out/target/product/vsoc_x86/jacoco-report-classes-all.jar
out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk
out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk
out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar
Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
When prebuilt_apex overrides/replaces other apex, the same symlinks need
to be created as well.
Bug: 143192278
Test: 1. add prebuilt_apex with vndk apex
with overrides set as ["com.android.vndk.current"]
2. m <prebuilt apex>
3. check if vndk symlinks are created
Change-Id: I8ee9c981ea9c7202ccf5143b3f43e6848773cd63
When a module is included in an APEX and the module is not directly
installed to the system partition, the 'required' property of the module
is lost. The APEX containing the module now carries the property from
its dependencies.
Bug: 146549048
Test: m
Change-Id: Ie21cc7b8420c6126c855e66c2363644de4a7ef42
It will be used to build a shim apex with zeroed hashtree for use in CTS
tests.
Test: builds
Bug: 145670581
Change-Id: I6f84850fefb3b58a1c2e8328242920d64a61e733
Bug: 144477678
Test: verified that apex_build_info.pb is populated and included in the
final apex.
Change-Id: Iecbc2a68a82595eee32aaa26d11a7253daf89f69
We need to have a way to see the list of modules that directly or
indirectly contribute to an APEX. People find it difficult to determine
whether a module is included in which APEXes because APEX tracks
indirect dependencies as well as direct dependencies. Therefore, just
looking at Android.bp for the APEX itself doesn't give the answer.
This change adds a new make target <apex_name>-deps-info, which
generates out/soong/<apex_name>-deps-info.txt file that shows the
internal and external dependencies of the said APEX.
Here, internal means the dependencies are actually part of the
APEX, while external means the dependencies are still external to the
APEX.
Bug: 146323213
Test: m (apex_test amended)
Change-Id: I33d1ccf5d1ca335d71cd6ced0f5f66b8c3886d13
Some devices require VNDK using core library list, but this is dependent
to system image rather than VNDK version. This change removes VNDK using
core variant library list file from VNDK APEX, and also remove VNDK
version from its filename.
Bug: 142599349
Test: m -j passed && aosp_cf_x86_go_phone booted
Change-Id: Ibc53b8dfc9d38e14bbaa878154034d25a6d34089
Create an APEX variation of a module only when it is either directly
included in an APEX or the dependency to the module demands that the
module should be included. For example, a non-static dependency to a
java library no longer creates an APEX variant of the library.
Bug: 146907857
Test: m (apex_test amended)
Test: cat out/soong/build.ninja | grep "Module:" | wc -l
reduced from 47132 to 45881
Change-Id: Icd79fb4b60668d852b9f018343b934b5e42a8eda
Permission XML file for java_sdk_library is generated by
java_sdk_library itself now.
And, build rule is switched to android.WriteFile since "echo -e" is
not supported from build server. (-e is printed to output)
Bug: 145474221
Test: m com.android.cronet and check its permissions xml file
also, m org.chromium.net.cronet.xml (created dynamically)
Change-Id: Iffb119151c49bc4fe6c4386fa267cca193f37dbc
Two APEXes (i18n, art) requires compat symlinks and these symlinks are
created via ld.config.txt module's POST_INSTALL_CMDS.
$ m installclean
$ m ld.config.txt
$ tree $OUT/system
.../system
├── bin
│ ├── dalvikvm -> /apex/com.android.art/bin/dalvikvm
│ └── dex2oat -> /apex/com.android.art/bin/dex2oat
├── etc
│ └── ld.config.txt
└── usr
└── icu -> /apex/com.android.i18n/etc/icu
By the way, ld.config.txt is going to removed since linkerconfig
generates it on device.
So, we're moving symlink creation from ld.config.txt(rootdir/Android.mk)
to APEXes' POST_INSTALL_CMDS.
$ m installclean
$ m com.android.i18n
$ tree $OUT/system
.../system
├── apex
│ └── com.android.i18n.apex
└── usr
└── icu -> /apex/com.android.i18n/etc/icu
$ m installclean
$ m com.android.art
$ tree $OUT/system
.../system
├── apex
│ └── com.android.art.debug.apex
├── bin
│ ├── dalvikvm -> /apex/com.android.art/bin/dalvikvm
│ └── dex2oat -> /apex/com.android.art/bin/dex2oat
Bug: 143192278
Test: m && boot (since these two apexes are bootstrap apexes)
Change-Id: Ib29ea9f9ac40e74f78cd530e7daef8c51292fd24
java_import doesn't support dex jar which is necessary to be packaged in
an APEX. Supporting this would require non-trivial work. By the way
java_import is not used and there is a workaround.(defining java_library
and static-linking with it)
We drop the support for `java_import` in APEX.
Bug: 139175488
Test: m (soong tests amended)
Change-Id: I924386571079090c701276d87f665ce7fbb6f074
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
With VNDK APEX, the location of VNDK lib is changed.
But vndk libs of older VNDK versions still depend on old location.
For current VNDK version, those hard-coded references will be fixed.
TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk
Bug: 143192278
Bug: 142912195
Test: m com.android.vndk.current and check if /system/lib/vndk
OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current
Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
When an APEX is built with uses_sdks, any depedndency from the APEX to
the outside of the APEX should be from the SDKs that the APEX is built
against.
Bug: 138182343
Test: m
Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
apex_available property can be appended differently per the linkage
type. This will be used to restrict certain libs (e.g.
libc_malloc_debug) to an APEX while allowing them to be statically
linkable from platform for testing purpose.
Test: m (apex_test amended)
Change-Id: I6dec23129c5ac93a3ef06fea28f26f240c0ba410
With __ANDROID_APEX_<NAME>__ definition, native modules may have
different behavior when it is built for a specific apex module.
Previously, the name is passed as value of definition __ANDROID_APEX__
like -D__ANDROID_APEX__=com.android.foo. But it is difficult to do
conditional compilation with it.
Now, since the name is incorporated into definition itself, it gets
easier to set #ifdef condition.
Bug: 142582178
Test: m (soong test added)
Change-Id: I3c90c789fa692a19addf2e5a7c8d4cc571cde112
Older VNDK libraries are provided as vndk_prebuilt_shared modules. Those
are added to corresponding VNDK APEX as dependencies.
With VNDK APEX installed, VNDK libs are unnecessary. By the way, since
there can be vendor modules which depend on VNDK libs, Make targets are
still emitted with UNINSTALLABLE=true.
Android.mk has additional modules for vndk libraries which are named
with apex name as suffices. For example, if libfoo is a vndk library,
then libfoo.vendor is its vendor variant and it would be in
/system/lib/vndk. But with vndk apex, it has additional
libfoo.com.android.vndk.current variant.
Bug: 141451661
Bug: 139772411
Test: m (soong tests)
Test: boot with aosp_arm64 system image on Q vendor device
Change-Id: I269c28a4d4c4e2f1518bd51df558438fe5316774
APK in a flattened APEX is installed as 'ETC' class module, instead of
the 'APP' class. This is to prevent Make from doing app-specific
amendments (e.g. such as adding module name after my_module_path)
to the paths and filenames which are all correctly set in the Soong
side.
Test: add `installable:true` to development/samples/Snake/Android.mk
and add 'Snake' to the `apps` property of an APEX. The build is
successful.
Test: build the APEX on a device with TARGET_FLATTEN_APEX=true
The APK is at system/apex/<apexname>/app/Snake/Snake.apk
Bug: 142537672
Change-Id: I314bf1ab7abd4d4a4e9fa210442c004f54d8ccca
This fixes the bug: flattened apex is installed under
/system/apex/<soong module name> not /system/apex/<apex name>.
Flattened apexes can be seen as pre-activated under /system/apex, which
is bind-mount to /apex. Therefore, install dir for flattend apex should
be the same with the activation point(or mountpoint) of non-flattened apex.
When apex_name: is set, it should be used as its name instead of name:.
This change also emits makevar APEX_FILE_CONTEXTS_INFOS which is list of
pairs(<apex_name>:<file_contexts>) and is used by sepolicy to modify
file_contexts files for flattened apexes properly.
Bug: 123314817
Bug: 142300241
Test: add a test apex module(foo) with apex_name(foobar)
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m foo
Test: see if the apex is installed correctly(/system/apex/foobar)
Test: see if the file_contexts for foo is correctly modified
Change-Id: I97a07de5cc772cd1d91e95ae059d282038028916
The check doesn't make sense for host.
Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist
./art/tools/dist_linux_bionic.sh -j110 com.android.art.host
is successful
Change-Id: Icdb4bb557a83b3c8044e6c73721dab47c56888a1
This allows us to change `logpersist.start` to `sh_binary` and unblocks
breakpad symbol uploading
Test: convert logpersist.start to sh_binary and verify symlinks are correct
Change-Id: I1b86c512df73a336205ca35216445a08e43bb879
Add a ToMakePath() method that returns a new path that points out
out/ instead of out/soong/, and replace the
"$(OUT_DIR)/" + path.RelPathString()
pattern with
path.ToMakePath().String()
Bug: 141877526
Test: m checkbuild
Change-Id: I391b9f2ed78c83a58d905d48355ce9b01d610d16
Create a new type InstallPath that is similar to OutputPath to
differentiate intermediates output paths from installed output
paths.
RelPathString is a poorly defined, undocumented function that is
primarily used to get an install path relative to out/soong to
generate an equivalent install path for Make relative to $(OUT_DIR).
Move it to InstallPath for now, and fix the one remaining user on
OutputPath.
Add a method to create an NDK install path so that ndk_sysroot.go
doesn't have to do it manually with PathForOutput.
Bug: 141877526
Test: m checkbuild
Change-Id: I83c5a0bd1fd6c3dba8d3b6d20d039f64f353ddd5
This change reverts following three changes to remove the no_apex
property. no_apex: true is equivalent to apex_available:
["//apex_available:platform"].
Revert "fix: "no_apex" can be put in defaults"
This reverts commit cc372c5b1d.
Revert "Add no_apex check for static library"
This reverts commit 2db7f46d0c.
Revert "Add no_apex property"
This reverts commit 4f7dd9b4db.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Ia4b094e371e9f8adff94ae6dc3ebb8e081381d4e
apex_available property controls the availability of a module to APEXes.
For example, `apex_available: ["myapex", "otherapex"]` makes the module
available only to the two APEXes: myapex and otherapex, and nothing
else, even to the platform.
If the module is intended to be available to any APEX, then a pseudo
name "//apex_available:anyapex" can be used.
If the module is intended to be available to the platform, then another
pseudo name "//apex_available:platform" is used.
For now, if unspecified, this property defaults to ["//apex_available:platform",
"//apex_available:anyapex"], which means the module is available to everybody.
This will be reduced to ["//apex_available:platform"], when marking for
apex_available for existing modules are finished.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Id4b233c3056c7858f984cbf9427cfac4118b2682
VNDK APEX should be named after the version of VNDK libs.
For example, if vndk_version is 29, then the apex name should be
com.android.vndk.v29. If vndk_version is not set or is 'current', then
the platform vndk version is implied.
This is done with setting "apex_name" with proper name.
Bug: 139774701
Test: m (soong test added)
Change-Id: I918252f12ccd351886030fe9139a020d6cf1ff32
All APEXes need to ship w/o libbinder since it does not offer a stable
wire protocol. Removing this since nothing adds a libbinder dep here.
Bug: 139016109
Test: build
Merged-In: Ic6a3fcb68054d8c7a5f2f64795a0e2889ce1abe8
(cherry picked from commit 1c3108d629)
Change-Id: Ic6a3fcb68054d8c7a5f2f64795a0e2889ce1abe8
For now, apex_name is used only for flattened apex.
Even if apex_name is set, the activation point of unflattened is
determined by 'name' in apex_manifest.json.
This change make apex_name as priority.
If apex_name is set, then use this for apex name
- update name in apex_manifest.json to apex_name
- do not check if key filename matches (use apex_name as key name)
This can be useful if soong wants to rename apex module. Simply setting
apex_name has the same effect of renaming "activation point" of apex.
But: 139774701
Test: m (soong test)
Change-Id: I8ea3645e4aa8f317997bc1443ec308ed0595b1c2
The return value is true if TARGET_FLATTEN_APEX is true,
TARGET_BUILD_APPS is false and the module is flatten variant.
Only the module name of flattened variant is appended with
".flattened" as suffix.
Test: m -j
Bug: 139716748
Change-Id: I966a178b43c5d08bd69d19e97e59456aa66d9d28
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
Translated second architectures now go in NativeBridgeArch instead
of DeviceSecondaryArch.
This reapplies I568046330abc002d4eed582cb999b62a5eaba790 with
ctx.Config().HasMulitlibConflict() added to fix the NDK build,
which has arm64, arm, x86_64, and x86 architectures enabled.
Test: m checkbuild
Test: OUT_DIR=out_ndk build/soong/scripts/build-ndk-prebuilts.sh
Test: no change to build.ninja or Android-aosp_cf_x86_phone.mk
Change-Id: Iadcafbd64bfb9579ae7c86914927c43a062b0c8e
Remove the mention to the (APEX) manifest (`apex_manifest.json`) from
this field's documentation, as `Apex_name` is neither read from nor
written to that file.
Test: n/a
Change-Id: Ia0dfac4f35f1ea697f379bcb19dd11af8705a0a0
Vendor variant is now divided into several vendor.{version} variants,
depending on their intended usages:
vendor.{BOARD_VNDK_VERSION}: vendor and vendor_available modules
vendor.{PLATFORM_VNDK_VERSION}: VNDK modules in the source tree
vendor.{snapshot_ver}: VNDK snapshot modules
This also affects exported module names from Soong to Make. But to
maintain backward compatibility, ".{BOARD_VNDK_VERSION}" suffix will not
be emitted for modules having version BOARD_VNDK_VERSION, so that vendor
modules still can be referred as-is.
Bug: 65377115
Bug: 68123344
Test: clean build and boot blueline
Change-Id: Ib9016a0f1fe06b97e9423fd95142653a89a343fa
If payload type of APEX is zip, flattened variant and non-flattened
variant create the same MK rules (it's build error). So only
non-flattened variant case, MK rule is created.
And if a.flattenedConfigValue is true, soong don't mutate variants. So
when a.flattenedConfigValue is true, MK rule should be created.
This CL is a partial revert of 4c04713871
Bug: 139716748
Test: m -j com.android.art.host
Change-Id: I37b2fa17e203fb668a0255cda37f10fcfadb3f85
The NOTICE files are missing from prebuilt apexes, and it turns out they
were excluded when building bundles.
Bug: 140317706
Test: Ran build_mainline_modules.sh and checked bundle base modules.
Change-Id: I92c4231f2007e1d8cd9c2bd044201458803c0fd7
Merged-In: I92c4231f2007e1d8cd9c2bd044201458803c0fd7
Ensure that it ends up in the bionic/ subdir in the Runtime APEX and is
symlinked from /system/lib(64). That makes it available in the default
(platform) linker namespace and no longer requires it to be accessible
through the runtime namespace. All this makes it consistent with how the
other Bionic libs are handled, and avoids the need for various special
cases in ld.config.txt files (to be cleaned up later).
With this there might no longer be a need for a linker namespace for the
Runtime APEX, and we could consider removing the kludge with the
/apex/com.android.runtime/${LIB}/bionic subdirectories and the special case
in getCopyManifestForNativeLibrary in apex.go. However, keeping it calls out
the special treatment of those libraries, and allows a namespace to be added
again if necessary.
Test: Build and boot on taimen_hwasan-userdebug
Test: adb shell /apex/com.android.art/bin/dexdump on taimen_hwasan-userdebug
Test: atest CtsCompilationTestCases on taimen_hwasan-userdebug
Bug: 140734238
Bug: 140790209
Change-Id: Ieb506bfa5d5c159db391273c7eba41d7909de286
The apexBundle module is mutated flattened variant and unflattened
variant. So we can install flattened apex and unflattened apex at the
same time with adding {Apex module name}.flattened to PRODUCT_PACKAGES.
Bug: 139716748
Test: m -j && Add com.android.art.debug.flattened to PRODUCT PACAGES and
check system/apex/com.android.art.debug directory
Change-Id: I0d8c9a155e47c5d0ff13e2f55d4080d91ef5093d
This commit switches the build rule for APEX nativeTests from
`$(BUILD_PREBUILT)` to `soong_cc_prebuilt.mk`. Since these are not real
prebuilts, `soong_cc_prebuilt.mk` should be sufficient.
Using `soong_cc_prebuilt.mk` also fixes a problem reported by prebuilt
ELF checker because `LOCAL_SHARED_LIBRARIES` are not generated for
nativeTests.
Bug: 139525855
Test: lunch aosp_walleye-userdebug && make check-elf-files
Change-Id: I7bfc29f9c2708896dad4e7cfc214480e1205a51e
"apex_vndk" is a variant of "apex" module.
apex_vndk {
name: "com.android.vndk",
..
}
This rule is used to produce a VNDK APEX per vndk version.
It supports automatic inclusion of vndk libs.
If "vndk_version" property is set, the prebuilt vndk libs of
the version will be included in the apex bundle.
apex_vndk {
name: "com.android.vndk.v29"
vndk_version: "29",
...
}
Otherwise, platform's vndk version is used.
This will replace /system/{lib}/vndk-{ver} and vndk-sp-{ver}.
Bug: 134357236
Bug: 139772411
Test: m com.android.vndk
Change-Id: Ib5c86e625839389670d13c683a7427198ef6852f
New property "apps" is added to APEX soong module. This property
configure a list of APKs to package inside APEX payload. For each
android_app module package it's APK into /app/$(android_app module Name)
directory.
Bug: 139906763
Test: m -j
Change-Id: Ic6655f211951af08097c76e157a07ebc52425718
So far a very basic version.
In case there is a diff, soong will emit an error message with a command
to resolve the diff. Example:
New unexpected files were added to com.android.apex.cts.shim.v3. To fix the build run following command:
system/apex/tools/update_whitelist.sh system/apex/shim/build/default_shim_whitelist.txt out/soong/.intermediates/system/apex/shim/build/com.android.apex.cts.shim.v3/android_common_com.android.apex.cts.shim.v3/com.android.apex.cts.shim.v3-content.txt
Test: m checkbuild
Bug: 139125405
Change-Id: I57e694f394c56105dc7363a684983605c7bf5e7d
This includes a few changes that make AndroidMkEntries more resemble
AndroidMkData, especially in terms of how extra entries are added.
Most importantly it can now have multiple custom functions.
Test: Soong tests
Change-Id: Ibf9102624d16d0c1c9894a2794fc7c797bb34c9a
Builtin APEXes (/system, ...) don't need hashtree.
So if we remove hashtree from builtin APEXes we can save more space in
/system.
However, this change only affects to the apex bundles which are built
from source, not from prebuilts.
Removing hashtree from prebuilts will be handled in a follow CL.
Bug: 139957269
Test: m
Test: see if /system/apex/*.apex have hashtree
Change-Id: Id755382b2153bf6bbaf2c480f3bbb91b6f62a564
Allow modules to depend on the flattened flavor of an APEX package
using `module.{flattened}` (returning the output install path of the
flattened APEX).
Also add this flattened output install path as an implicit output
dependency of a flattened APEX phony module.
Test: m checkbuild
Bug: 139277987
Change-Id: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
Merged-In: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
If no_apex module is static library, this module is not included to
filesInfo. So add a check tat the static library is no_apex among
indirect dependencies.
Bug: 139016109
Test: m -j
Change-Id: I46ddf099715aea0e088027a1141e282969cef0e1
This will check if direct deps of android.Module type is "Enabled()".
Previously, this is checked only if a module calls VisitDeps*()
functions in GenerateAndroidBuildActions().
Most modules call VisitDeps*() in GenerateAndroidBuildActions(),
but some modules don't. For example, "apex" module calls
WalkDepsBlueprint() or VisitDirectDepsBlueprint() since it
exceptionally depends on non-android.Module modules.
Therefore, when an apex module depends on disabled(enabled:false) module,
build fails with panic, which is fixed by this change.
Test: m # runs soong tests
Change-Id: I81c5c148bbd51a253d2904690eb76ae7b6df1a0f
Automerger Merge Worker