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
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
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
A new module type 'apex_key' is defined to specify public and private
key pair for APEXs. An APEX can refer to the module via the property
'key'. When building the APEX, the private key from the key module is
used to sign it. In addition, the public key from the key module is
automatically installed to /system/etc/security/apex.
Bug: 115721587
Test: m apex.test; m
/apex/com.android.example.apex@1 exists
Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
Files under /bin and all directories in an APEX now have x (executable)
bit set correctly.
Bug: 117580281
Test: m apex.test, push it to /data/apex and reboot.
adb shell ls -al /apex/com.android.example.apex@1 shows that the
directories have x bit set
Change-Id: I76e4188d86dc9cdf65e9f8e52be1981e25441a6e
Don't directly iterate over the copyManifest map to generate the copy
commands. Iterating over a map in golang isn't guaranteed to give
consistent order. This causes the apex build rules to be executed even
when there is no source file change.
Fix the issue by creating a sorted list of the key and then iterate over
the list.
Bug: 117453592
Test: m apex.test; m.apex.test nothing is built during the second
build
Change-Id: I329a91ec0b6a34cbe745bf9a9ceb0843b63c200c
Now, APEX-aware modules (the ones implementing android.ApexModule
interface) are created with multiple variants for each APEX that they
are included.
For example, if a module is included (either directly or indirectly -
via static linking) to two APEXs, the module is built separately for the
two APEXs (and of course separately for platform). This is a first step
to limit the symbol visibility to the modules built for APEXs; platform
private symbols and libs shouldn't be allowed for them.
In addition, the build system now tracks transitive dependencies of
the modules in APEXs. For example, if
native_shared_lib_modules:["libFoo"] then libFoo and its dependencies
are all automatically included to the APEX.
Bug: 112672359
Test: m apex.test; the built apex has additional libs (such as liblog,
libc++, ...) that are dependencies of the ones specified in Android.bp
Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
