The entire APEX (which is a zip file) is signed with the apk signer.
Certificate can be specified via the 'certificate' property just like
ordinary apps. Note: multiple additional certificates are not supported.
Bug: 115721587
Test: m apex.test
Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the
certificate info
Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
Test: system/apex/apexer/runtests.sh on a master source tree
Test: system/apex/apexer/runtests.sh on a master-art source tree
Bug: 113373927
Bug: 112458021
Change-Id: Ie23eab3f7e4961ebbe011b1fe25ce819f99767a2
This commit replaces versioner host binary (built just-in-time) with
a prebuilt binary under `prebuilts/clang-tools/${OS}/bin/versioner`.
This is a part of the effort to switch to clang-r339409b.
See also.
https://android-review.googlesource.com/c/platform/bionic/+/799321
Bug: 113263746
Test: make checkbuild
Change-Id: Ia845e1c01d8b8084d00bdc4af706e867e1599863
A cc_library or cc_library_shared can be configured to have stubs
variants of the lib.
cc_library_shared {
name: "libfoo",
srcs: ["foo.cpp"],
stubs: {
symbol_file: "foo.map.txt",
versions: ["1", "2", "3"],
},
}
then, stubs variants of libfoo for version 1, 2, and 3 are created
from foo.map.txt. Each version has the symbols from the map file where
each symbol is annotated with the version that the symbol was introduced
via the 'introduced=<ver>' syntax. The versions don't need to be in sync
with the platform versions (e.g., P for 28). The versions are local to
the library.
For another library or executable to use the versioned stubs lib, use
the new 'name#ver' syntax to specify the version:
cc_binary {
name: "test",
....
shared_libs: ["libFoo#2"],
}
Internally, a new mutator 'version' is applied to all cc.Module objects.
By default, a variant named 'impl' is created for the non-stub version.
If the versions property is set, additional variations are created per a
version with the mutable property BuildStubs set as true, which lets the
compiler and the linker to build a stubs lib from the symbol file
instead from the source files.
This feature will be used to enforce stable interfaces among APEXs. When
a lib foo in an APEX is depending on a lib bar in another APEX, then bar
should have stable interface (in C lang) and foo should be depending on
one of the stubs libs of bar. Only libraries in the same APEX as foo can
link against non-stub version of it.
Bug: 112672359
Test: m (cc_test added)
Change-Id: I2488be0b9d7b7b8d7761234dc1c9c0e3add8601c
APKs that are preopted to system_other should not be stripped.
For now, don't strip any APKs.
Bug: 118592830
Test: m PrintSpooler; zipinfo $OUT/system/app/PrintSpooler.apk | grep classes.dex
Change-Id: Ife8a5fe4ff90e5e00ec24f43e089d9b3aa552fc0
Stop writing out ninja files, as they become very large, especially when
multiplied by the number of defined products.
Test: treehugger
Change-Id: Id9529d14040acb72a0188e58b5db2911f142071e
filename property is an optional property that specifies the name of the
installed file which is by default name of the module.
This will be used to APEXs to have ./etc/ld.config.txt files for their
own.
Test: m (prebuilt_etc_test.go added)
Change-Id: Ic8d0c0044c5bc2c6c33117fe2c19ef6ad75451a8
This (effectively) reverts commit 3c979c3348.
core_platform_current is the new default when no_framework_libs: true
so doesn't need to be specified anywhere.
Bug: 113148576
Test: build
Change-Id: I6bb6c1a0ea24437c8253dc5d8fabd37edabc9d3e
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
Support for safe ICF was added to LLD in LLVM r337429. This reduces
the size of sailfish system.img by 7.6MB.
The address-significance tables created by Clang to support LLD's
implementation of safe ICF are incompatible with ld -r. Therefore we
need to pass -fno-addrsig to the compiler to prevent it from creating
an address-significance table when building a cc_object.
Change-Id: I83e28741e6b3cdf09566447d2658ce48594f2074
This detects whether this is enabled, makes sure the other necessary
flag is set to provide a suitable location, and suppresses the
requirement for a previous_api.
Test: making a new libcore target using this
Bug: 73448108
Change-Id: Ifea3a060011a58e3288050c6c5d98b205abe25fc
Privileged APKs need to store their dex files uncompressed so they
can be verified and mapped directly out of the APK.
Also track whether the module will be dexpreopted or not in order
to determine if the dex file should be stripped before signing.
Test: SystemUI.apk contains an uncompressed dex file
Change-Id: I4dca86c7f8778595882405b34adcf2a7bae03c67
Add soong build restrictions for libcore targets to stop
other targets depending on internals.
Test: cd build/soong/; ./build_test.bash --products aosp_arm
Bug: 113148576
Change-Id: I2c15924fbecaf0c2076d08de65814a6dcb790e73
This reverts commit d30b940dff.
Reason for revert: sed -i requires an argument on mac, break build on mac.
Change-Id: Iba2db061ae888d265e02b750e50959019cf0f168
This is achieved via the compiler flag -ffixed-x18 for non-LTO builds
and the linker flag -plugin-opt -mattr=+reserve-x18 for LTO builds.
This change should be reverted once we upgrade past LLVM r340889
which does this by default on Android.
Bug: 112907825
Bug: 111759196
Change-Id: I05473ddbb98319d87d442425b4d715647eae3a38
soong.config is not cleared between builds, which can cause
problems when switching between an ndk build and a platform build.
Bug: 118398924
Test: OUT_DIR=out_ndk DIST_DIR=dist build/soong/scripts/build-ndk-prebuilts.sh
Change-Id: Ifc03a0c25f46625375cdda5723e4a09d7d8050d5
If provided (--prefer-integrity=true/false), the script will set the
value in the the manifest. The script will fail if the value mismatches
the original in the manifest, if any.
Test: scripts/manifest_fixer_test.py
Test: aapt dumps the attribute and observe
Bug: 112037137
Change-Id: I2b333a7c0747dbcbed4d419f1c9ed46d4a4c98e9
The change fixes the problem that multiple APEXs having native component
(shared lib or executable) can't be built with an error similar to this:
error: bionic/linker/Android.bp:298:1: failed to find variation "com.android.art" for module "libclang_rt.builtins-aarch64-android" needed by "ld-android"
This is happening because the dependency to the built-in library is
arch-specific but apex.go ignores it. Specifically, let's assume that
32-bit variant of libFoo depends on libX while 64-bit variant of libFoo
depends on libY. Also assume that libFoo is included in two APEXs: apex1
(which is 64-bit) and apex2 (which is 32-bit). Then apexDepsMutator
records that libFoo shall be split into apex1 and apex2, while libX will
be only split into apex1 and libY will be split into apex2.
The problem is that, during apexMutator, both 32 and 64-bit varants of
libFoo are split into apex1 and apex2. As a result, a dependency to
apex2 variant of libX and a dependency to apex1 variant of libY are
requested, which don't exist.
Fixing this issue by using module's name AND target string as the key.
So, only the 32-bit variant of libFoo is split into apex1 and 64-bit
variant of libFoo is split into apex2.
Test: have following module somewhere. `m` is successful.
apex {
name: "com.android.art",
manifest: "manifest.json",
file_contexts: "file_contexts",
binaries: ["dex2oat"],
key: "apex.test.key",
target: {
android: {
// Prefer the 32-bit versions of these binaries.
compile_multilib: "prefer32",
},
},
}
Change-Id: I562b7be8e7c0325bd8d728dbee2ddcae608c181a
Without the annotation args the check API fails for
APIs that use visibility annotation args.
Bug: 117936519
Bug: 113148576
Test: build
Change-Id: Ie9d2116c7f255634de72de9a448f5c378c11c457
Add arch_variant to the genrule srcs property so that cc_genrule
modules can vary the srcs and outs by architecture.
Test: cc/genrule_test.go
Change-Id: Idb17013e137d7ca21ca4cfc3e4c1fa7d89977043
