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
ed023eca73 introduced a new (better) way
of exporting make vars from singletone. apex_keys_text singletone is
switched to the new method.
Test: inspect out/soong/make_vars-<target>.mk
Check SOONG_SOONG_APEX_KEYS_FILE is set
Change-Id: Ia218852ba9ae40070cb6c99340d97e0c77d19841
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
Add an empty DepsMutator to ModuleBase so it doesn't have to be
implemented on every module that doesn't need it.
Test: all soong tests
Change-Id: I545a832a0dbf27386d3080377a75ea482cd9ce59
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
Add a dependency from a stubs lib to headers libs so that the headers
can be re-exported.
Bug: 122717287
Test: m; a test added to apex_test.go
Change-Id: I8d48c072815c6b02d343ef09cb44dfc6d1af8e64
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
A module can be built multiple times when it is referenced from one
or more APEXes. Sometimes, it is required for the module to behave
differently depending on the context; e.g., do A when built form
APEX M, do B when built for APEX N, and do C when built for platform.
The idea is to have a macro __ANDROID_APEX__ which is set to the
name of the apex that the module is built for. It is undefined when
the module is built for platform.
Bug: 122714993
Test: m (apex_test amended)
Change-Id: I11a89c6a0e799f4810194de7ef9ee472a71ca498
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
This commit renames `_platform` suffix to `` (empty string) so that
non-apex variations are not renamed to `_core_shared_platform` or
`_vendor_shared_platform`.
This commit makes sure that `_core_shared` and `_vendor_shared` is
always under `$OUT_DIR/soong` regardless the usages from apex modules.
Furthermore, this avoids the confusing stale lsdump files (e.g. both
`_core_shared` and `_core_shared_platform exist) while creating
reference ABI dumps for VNDK ABI checks.
Bug: 121986692
Test: lunch aosp_arm64-userdebug; make # no more _platform variants.
Change-Id: Ic02a60ac45f982580349661c22331d114617fd92
This CL fixes the problem that when a lib is defined with stubs, the
stubs variantof the lib is installed to the APEX. This was happening
because the non-stubs variant is the last variant of the 'version'
variants and addFarVariationDependencies selects the first variant when
the 'version' variant isn't specified.
Fixing the problem by making the non-stubs variant (whose name is "")
the first variant.
Test: m (apex_test)
Change-Id: I1505fd2f29a0d70c916bad51000aa06f2b80b137
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
Setting the property to false prevents the key from being installed.
Useful for testing keys.
Bug: 122042717
Test: add 'installable: false' to the apex_key
'com.android.apex.test_package.key'. mma under
/system/apex/apexd/apexd_testdata. The key is not found under
out/target/product/..../system/etc/security/apex
Change-Id: Ibf70e4e8ea5e73432d06b1c4050df531eaafc85e
