These additional binary types are useful for some apexs. Add the
ability to include them. Due to the nature of the resulting artifacts
only py binaries with embedded launchers and host go binaries are
supported.
Test: m com.android.support.apexer
Bug: 119332365
Bug: 119332362
Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
This reverts commit aa65e17016.
Reason for revert: Not compatible with PRODUCT_PACKAGES, and so has very limited use.
Change-Id: Ib141d3984a6f12bb50989e66037494c466b066f1
This new module type replaces the inherit-package function in make by
allowing developers to override the name, the certificate, and the
manifest package name of an android_app module.
Bug: 122957760
Fixes: 123640028
Test: app_test.go + BrowserGoogle
Change-Id: Iefe447e7078b25039233221361ef95c83a29973a
Flattened apexs were not including symlinks. This could cause expected
files not to be present.
Test: lunch aosp_marlin-userdebug
m droid
stat $OUT/system/apex/com.android.runtime.debug/bin/dalvikvm
Bug: 124924906
Change-Id: I04e696602b776b383bf7198eb19220353df74192
Host apexs don't have a system-image associated with them so we need
to include all libraries, including those with stubs.
Test: ./art/test/testrunner/run_build_test_target.py -j50 art-linux-bionic-x64-zipapex
Bug: 125417922
Change-Id: Ie76e6a34e8be1057b29e2e005597c3e4b5fb1f9c
By default, if a lib is included in an APEX, all its direct and indirect
dependencies are also included in the same APEX. However, when one of
the dependencies have stable API (i.e. has stubs: {...}) then the lib
having stable API and its dependencies are not included in the APEX.
However, the problem here is that the lib having stable API might not be
installed on the system, thus causing error at runtime. This can happen
if there is no other module in the platform that depends on the lib.
This change fixes the problem by adding such libraries as external
dependencies so that they are also installed on the device along with
the APEXes using them.
Bug: 124831003
Test: m installclean; m com.android.resolv
libbinder_ndk, libvndksupport are found under system/lib
Change-Id: I457e03ff3fce37e0890c64d911e6e0ea6d0c6dd6
apexkeys.txt is a text file having APEX-to-keys mappings. The file is
included in the target-files package where it is used when re-sign the
APEXes with release keys.
Each line of the file consists of 5 fields:
1) name: file name of the APEX
2) public_key: the public key for the apex_payload.img of the APEX
3) private_key: the private key used to sign the apex_payload.img
4) container_certificate: the certificate used to sign the APEX zip
container
5) container_private_key: the private key used to sign the APEX zip
container
Bug: 124406181
Test: m out/soong/apexkeys.txt and inspect the content
Test: TARGET_BUILD_APPS=com.android.tzdata m dist and make sure
out/dist/apexkeys.txt exists
Change-Id: I1daa13ec50956323b97e15e8df7f1fbe5ea21d63
The manifest and androidManifest properties in the apex module type now
supports ":name" syntax.
Bug: 123857186
Test: m (apex_test amended)
Change-Id: Ic4e5a73cf73260d156ec61d07932ad07b2561413
The properties are no longer required as an APEX module is mutated with
required sanitizers which are gathered by scanning the sanitizers that
are enabled for its direct dependencies.
Bug: 124128094
Test: m on marlin
The extractor libs are found under /system/apex/com.android.media
Merged-In: I55961d400dcbac067a5c0dcecb90e399d4991a70
Change-Id: I55961d400dcbac067a5c0dcecb90e399d4991a70
(cherry picked from commit abda0eb76b)
Zip apex files are not really installed so should not ever be
flattened. Unfortunately we didn't send this information to make which
would still unzip everything.
Test: ALLOW_MISSING_DEPENDENCIES=true
./art/tools/build_linux_bionic_tests.sh com.android.runtime.host
Bug: 124333446
Change-Id: I3eda579f8c40f768f1ef2be867967f436396cd4c
AndroidManifest.xml file can be specified via the 'androidManifest'
property in the apex module type. It can be used to have a custom
AndroidManifest.xml that have additional tags (such as <uses-sdk> or
<uses-feature>) for precise targeting.
The property is optional; if unspecified, then one is auto-generated as
before.
Bug: 123857186
Test: m apex_test_build_features
Change-Id: Id7ee0471661887cfa11124cbaa3beea8cffcdda4
Zipapex's cannot be flattened so do not prevent them from being built
even if TARGET_FLATTEN_APEX is set.
Test: lunch aosp_arm-eng;
ALLOW_MISSING_DEPENDENCIES=true \
./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 124333446
Change-Id: I4bef65cce100136a8f7852692e841b62ed9e399f
It is used to configure an apex to prefere specific sanitizer variants
if available. For example, if a lib is with sanitize: {cfi: true} then
an APEX with prefer_sanitize: {cfi: true} will use the sanitized variant
of the lib.
Bug: 124128094
Test: m on marlin
extractor libraries are found under /system/apex/com.android.media
Change-Id: I858778eef78c5791cdeb497c7c11688cb128b5fe
Some test and other miscallaneous use-cases need apexs that are
installable but will not affect the installation of other artifacts
onto the device. For this purpose we added a test_apex type. These
test_apex targets create apex files and have all the normal attributes
but are not considered the source of any of their contents for the
device by the rest of the build-system.
Test: build and boot
Test: ALLOW_MISSING_DEPENDENCIES=true \
DIST_DIR=$ANDROID_BUILD_TOP/out/dist \
./art/tools/dist_linux_bionic.sh -j72 showcommands com.android.runtime.host
Bug: 123591866
Bug: 123892969
Change-Id: I7f50be0ac0425cd87868145e18bcee6962d472ef
We were marking any libraries included in any apex (including
non-installable apex's like com.android.runtime.host) as
uninstallable. This could cause phones to become unbootable if these
apex's are modified.
Bug: 123892969
Test: m droid && boot device.
Change-Id: Ief9004bbe7b106ee8f52715ce5bd7bb5accec290
94427265d1 broke the flattened APEX
by not updating moduleNames
Test: TARGET_FLATTEN_APEX=true m
Files are under /system/apex
Change-Id: I14b1a6f8b2244d35e1accdf9888cfef65f4b0a03
When an APEX is non-installable, the make rules for the APEX files in
the APEX are not emitted as they will never get installed.
androidMkForType() is refactored so that make rules for the APEX files
are created in a separate function androidMkForFiles().
Test: m checkbuild tests
Bug: 123290268
Change-Id: Ibe8817d1e9c6312fb5c6f986dced8aa3e823664a
Build rules for both flattened and non-flattend APEXes are created
regardless of TARGET_FLATTEN_APEX. The selection is made in AndroidMk.
This allows other module to reference an APEX via :module syntax
irrespective of TARGET_FLATTEN_APEX.
Bug: 123780484
Test: TARGET_FLATTEN_APEX=true m out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen/art-check-debug-apex-gen.dummy
with aosp/891696 applied
Change-Id: Ia49415ec3d18cfc5081461be76900c73ea803dca
relative_install_path for cc_library is respected by APEX.
relative_install_path for cc_binary is not yet respected because doing
it will break the path to the dynamic linker in the runtime APEX.
That change should be done along with changes in init, bionic, etc.
Bug: 123721777
Test: m (apex_test.go amended)
Change-Id: I855f8eda0d4255d563861ac96d0d3e2c669e9a2a
apex will normally place libc and some other system libraries into a
separate directory. This is to ensure that early startup works
correctly. Some apex targets want to have these libraries at the
normal places however.
Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 123591866
Bug: 120266448
Change-Id: Ib5a67a43fe3eea6188b4df9215e743f1634045f3
Some apex targets need to be able to change their contents based on if
they are host or target or what libc they are using. This adds support
for doing this using the standard 'target: {...}' idiom.
Test: m com.android.runtime.host
Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host
Bug: 123591866
Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
Some modules rely on symlink_preferred_arch to have expected files
present. This change makes apexs include these symlinks.
Test: m com.android.runtime.debug
pushd $(mktemp -d)
mkdir mnt
unzip $OUT/apex/system/com.android.runtime.debug.apex
sudo mount -o loop,ro apex_payload.img mnt
Ensure that mnt/bin/dalvikvm and mnt/bin/dex2oatd both exist and
are symlinks to mnt/bin/dalvikvm64 and mnt/bin/dex2oatd32
respectively.
Bug: 119942078
Bug: 122373634
Bug: 123079311
Change-Id: I47868fbedc5bdd3141a836c488f79e91e0a6ddfe
This fixes a problem that APEX is unconditionally mutated for all
sanitizer types. This can make an APEX to include sanitized version
of a lib even when SANITIZE_TARGET is not set. It can happen when lib X
is directly depended on by an APEX (e.g. via native_shared_libs) and X
has a sanitized variant due to the dependency from another library Y
which is force sanitized (via 'sanitize' property). In that case,
regardless of lib Y is in the APEX or not, the APEX chooses the
sanitized variant of lib X since the dependency from APEX to the lib is
created with AddFarVariationDependency.
Fixing this problem by mutating the APEX for a sanitizer type only when
the device is requested to be sanitized.
Bug: 122717287
Test: add libnetd_client to com.android.runtime APEX.
Inspect build.ninja to verify that libnetd_client.so in the runtime APEX
is not a sanitized one.
Change-Id: I918bc8407137d74c5456142b3a29de13df68c0b3
If native-bridge/ndk translation is supported for a config the build
system will know about 2 copies of binaries, one for each ABI. We only
want to actually install the 'Native' (non-translated) ABI into the
apex in these situations.
Test: lunch aosp_cf_x86_phone-userdebug
m showcommands com.android.runtime.debug
examine the command output to make sure only a single copy of
dex2oat is being installed.
Change-Id: I9480e52855fd9f5564a579099309fb38f1c50367
Master-art configurations do not have frameworks/base and therefore do
not have hidden API flags. Pass --no-force-assign-all to `hiddenapi`
when frameworks/base does not exist to disable the corresponding
assertion. This enables us to enforce the assertion on non-master-art
builds and also get rid of logspam about missing flags on ART buildbots.
Test: art/tools/buildbot-build.sh on master-art
Bug: 123143676
Change-Id: I074d9554fb11dab3eef904016375730520107ec2
soong_java_prebuilt.mk sets LOCAL_MODULE_SUFFIX := .jar. Therefore, we
need to remove .jar suffix from LOCAL_MODULE_STEM, otherwise, we
will have .jar.jar suffix.
Bug: 123092860
Test: TARGET_FLATTEN_APEX=true apex.test
Check /system/apex/apex.test/javalib/core-oj.jar is there.
Change-Id: Ie19b20523753ec32ab16266f63d26c4df685cc34
This change first introduces the interface "Sanitizeable" that
module types other than cc.Module can use to be handled by the sanitizer
mutator. APEX module, by implementing the interface, gets sanitizer
variants.
In doing so, sanitizer.go is refactored so that modules have explicit
dependencies to the runtime sanitizer libraries. This allows the runtime
library to be packaged into the APEX when required. This also completes
the dependency graph; updating the prebuilt sanitizer runtime will
trigger rebuilding of modules using the runtime.
Bug: 120894259
Bug: 121038155
Test: SANITIZE_TARGET=hwaddress m apex.test
Test: TARGET_FLATTEN_APEX=true SANITIZE_TARGET=address m
Change-Id: Ia91576ff48cda3c996350308b75bf83fcf7c23d7
This reverts commit 769e50b3c9.
Reason for revert: Likely causing build failure on aosp_x86_64-eng in aosp_master:
"build/make/core/base_rules.mk:271: error: art/build/apex: MODULE.TARGET.SHARED_LIBRARIES.com.android.runtime.host.libart-compiler already defined by art/build/apex."
Change-Id: I83b7caa04b2648e4e4914aae2fa5878516634eed
The unstripped file for libraries in APEXes are available via
out/target/product/<device>/symbols/apex/<apex_name>/path_to_lib.
This change make the symbol files available by installing the individual
files in APEXes to the directory where the APEXes will be mounted at
(i.e. runtime directory which is /apex/<apex_name>). Note that the files
are not actually packaged to a filesystem image; they are installed just
to create the symbol files under the out directory where developers can
use them for debugging.
Bug: 120846816
Test: m com.android.runtime.debug
There are unstripped files under
out/target/product/walleye/symbols/apex/com.android.runtime.debug
Change-Id: Ib182e2bf8787b7669ccba13814491db35370f468
When PRODUCT_DEFAULT_DEV_CERTIFICATE is set to /vendor/foo/devkeys/test,
then the public/private key pairs for an apex_key is searched at
/vendor/foo/devkeys directory.
To be specific,
/system/timezone/Android.bp:
apex_key {
name: "timezone.key",
public_key: "com.android.tzdata.avbpubkey",
private_key: "com.android.tzdata.pem",
}
When PRODUCT_DEFAULT_DEV_CERTIFICATE isn't set, the keys are searched at
/system/timezone, which is the path where Android.bp is located.
With PRODUCT_DEFAULT_DEV_CERTIFICATE set to /vendor/foo/devkeys/test,
the keys are searched at /vendor/foo/devkeys.
Bug: 121224311
Test: m (apex_test updated)
Test: m with crosshatch (PRODUCT_DEFAULT_DEV_CERTIFICATE is set to
/vendor/google/...)
Test: m with cheets (PRODUCT_DEFAULT_DEV_CERTIFICATE is set, but there
is no apex key there. The product is with TARGET_FLATTEN_APEX := true)
Change-Id: I213bbb96c433d851f9cc982871459fd7fb4fe47d
This change fixes a bug that when built with TARGET_FLATTEN_APEX=true,
apex manifests are installed without being renamed to
apex_manifest.json.
Test: TARGET_FLATTEN_APEX=true
Test: /system/apex/*/apex_mnifest.json exist
Test: device boots to the UI
Change-Id: Ib8baeb475babbf4faf6cc073e266bb3038ac1b2d
If a lib is directly included in an APEX (via native_shared_libs
property) and the lib has stubs (via stubs.versions property), then the
ordinary non-stubs variant of the library is renamed to
<libname>.bootstrap in the makefile. At the same time, the stubs variant
of the lib becomes visible and it's name is <libname>.
This ensures that modules in Android.mk build against the stubs
variant thus preventing them from using private APIs in the lib.
The non-stubs variant, however, is used if the module explicitly has
set the new 'bootstrap' property to true. This is useful for building
some early binaries (such as init and vold) which need to run before
APEXes are activated. Since they can't use the bionic libs from the
runtime APEX, they should use the bionic libs left in the system
partition which is called the boostrap bionic.
Bug: 120266448
Test: m
Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I882b8aeb5b29460f07b4424e4f8eb844d6c9a9b0
It is a list of <module_name>:<manifest_name> pairs. When the module
name of an APK or an APEX matches with <module_name>, then its app
manifest name is overridden to <manifest_name>.
<module_name> and <manifest_name> can be patterns as in
com.android.%:com.mycompany.android.%.release
Note that, in case of APEXes, the manifest name refers to the name of
the zip container. The apex manifest name (which is specified in
apex_manifest.json) is not overridden.
Test: m with PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES for
1) an APK in Android.mk
2) an APK in ANdroid.bp
3) an APEX
and check that manifest names are modified as specified
Change-Id: Ie58882d90884695e893944c43d9c8803b283e93d
Executables under /system/bin are configured as (uid:gid)=(root:shell)
by fs_config.cpp. Therefore, an executable that is moved/copied from
/system/bin to an APEX should be configured as such.
Test: adb shell ls -al /system/bin/linker
/apex/com.android.runtime/bin/linker shows
-rwxr-xr-x 1 root shell 1133528 1970-01-01 09:00 /apex/com.android.runtime/bin/linker
-rwxr-xr-x 1 root shell 1133528 1970-01-01 09:00 /system/bin/linker
Change-Id: Ibb698aab237362fed312da2af809cceead8a1092
When an apex key is marked as 'installable: false' and the build is
debuggable, the pubic key file for the apex key is bundled with the APEX
that is signed with the key.
This eliminates the need to install the public keys for the
testing-purpose APEX in the system partition.
Bug: 122047804
Test: m
Change-Id: Ifa5914891463dbf4c21484ea440836521b2f90b1
Apex modules with installable: false are not installed, so the
dist rule copies from LOCAL_BUILT_MODULE instead of
LOCAL_INSTALLED_MODULE. If LOCAL_BUILT_MODULE_STEM is unset,
LOCAL_BUILT_MODULE will have the module name as the stem,
resulting in an incorrect file copied to the dist directory.
Set LOCAL_MODULE_STEM instead of LOCAL_INSTALLED_MODULE_STEM,
which also covers LOCAL_BUILT_MODUL_STEM.
Fixes: 122277867
Test: tapas test1_com.android.tzdata && m dist
Change-Id: I0af0c5adcac478a1ce68c4625203fd9bd56bf94d
use_vendor, when set to true, brings vendor variant of the native
libraries and binaries to the APEX.
Bug: 115707625
Test: m (apex_test updated)
Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
When TARGET_FLATTEN_APEX is set to true, there is no single output file
for an APEX that other modules can reference via ":module" syntax.
Return nothing in that case.
Bug: 121221006
Test: TARGET_FLATTEN_APEX=true m
Change-Id: I556b55073720b16fd30fd133af58aac229e958c0
When TARGET_FLATTEN_APEX=true, individual files in an APEX are exported
to make. However, because they lack LOCAL_SOONG_CLASSES_JAR,
soong_java_prebuilt.mk get confused and the build breaks.
Fixing the bug by correctly emitting LOCAL_SOONG_CLASSES_JAR and
LOCAL_SOONG_HEADER_JAR.
Test: TARGET_FLATTEN_APEX=true m
out/target/common/obj/JAVA_LIBRARIES/com.android.conscrypt.conscrypt_intermediates/classes.jar
Change-Id: I65ce86ec825f978a43715146bbd5c1d5af513de0
When set to false, the apex is built but not installed. Useful for not
polluting the system image with test APEXes when doing mma.
Bug: 120960303
Test: add 'installable: false' to apex.test under system/apex/tests/Android.bp
m; check that out/..../system/apex/apex.test.apex does not exist.
Change-Id: I383d5cdcc8aec705b6a5778dbd07233471d289d0
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
By implementing SourceFileProducer interface, output of an apex module
can be included in tests (via ':modulename' syntax in 'data' property)
Bug: 120055902
Test: replace apexd_testdata/* with :apex.test in
system/apex/apexd/Android.bp. m apex_file_test.
out/host/linux-x86/nativetest/apex_file_test/ has apex.test.apex in it.
Change-Id: I8b721a68e0edc65a3e674febeed485e06b96bc24
apex { name: "foo", native_shared_libs: ["mylib"] }
cc_library { name: "mylib", shared_libs: ["other_lib"],
stubs: { versions: ["1"]}, }
This is causing build error due to missing variant for other_lib.
This is happening because the stubs variant of mylib is added to apex
foo instead of the non-stubs variant. Because stubs variant does not
have any further dependencies, other_lib is not included to the APEX and
is not built for it.
Fixing this issue by specifying the version variant when adding a lib to
the dependency of an APEX, so that non-stub variant of the lib is
depended on.
Test: m (apex_test updated)
Change-Id: I972b6dcbce11942f83a76212715ba915534ec3df
This change fixes the bug that when a module is defined with sub_dir,
then build breaks when the module is included in an APEX.
This was happening because, for example when we have a prebuilt_etc
module having sub_dir set to "foo/bar", then only etc/foo/bar is added
to the canned_fs_config file and other intermediate directories (etc,
etc/foo) are not added. e2fsdroid however expects that every directories
to be listed.
Fixing the problem by adding parent directories when adding a directory
to canned_fs_config.
Bug: 120600179
Test: m (a new test case added to apex_test)
Change-Id: If712ff65761a7e1e3216371bb2eb7acf9cb5dc9e
