Original Commit Message:
"""
Rename modules that are APEX-only
The renamed modules are only available for APEXes, but not for the
platform. Use the <module_name>.<apex_name> syntax to correctly install
the APEX variant of the modules.
"""
Reason for revert: Build Cop - Breaks about 15 AOSP targets, with high confidence due to these changes being the only non-robot changes in those builds.
Reverted Changes:
I190ce2d10:Use apex_available property
I990e0a67e:Use apex_available property
I0d1295683:Revert "Avoid duplicated classes for boot dex jars...
I5fb725403:Find the jar libraries in APEX from the correct pa...
I322b1efcc:Rename modules that are APEX-only
Ifa2bd0f8f:Use apex_available property
Iac6533177:Use apex_available property
Ie999602c6:Use apex_available property
I2a3d73397:Use apex_available property
Ic91bcbb9a:Use apex_available property
Ia6c324eed:Use apex_available property
I964d0125c:Use apex_available property
Change-Id: I48b998629b0676cd7353e6844fd87585e0e42989
Java modules using SystemAPI can now link against platform owned
sysprop_library with public stub. This allows modules to use platform's
public sysprops (which should be regarded as an API) without any hidden
API usages, if using dynamic linking and boot class path.
This doesn't affect any vendor or odm owned sysprop_library.
Bug: 141246285
Bug: 145167888
Test: m
Change-Id: I99824fb24a75cc8282211c2ad6c6296ae9fca393
This change is to add granularity for disabling
of the fuzzer from running on host, device or both.
Bug: 145824604
Test: make haiku successfully completes after change
Change-Id: I686b439e36c622108f7b5b3e3f4738b8295320a7
The logic in cc.Module.ImageMutatorBegin() to skip creating vendor
variants for native bridge modules stopped working when the image
mutator was moved before the arch mutator because the native
bridge variant hadn't been created yet. Move the logic to the arch
mutator to avoid creating native bridge variants for vendor variants.
Fixes: 146486214
Test: lunch aosp_cf_x86_pasan-userdebug && m SANITIZE_TARGET=address
Change-Id: I46cff4905f929c9989d005f0ceb01388d47323c1
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
Previously, the compat configs from static dependencies were all written
to compat/compat_config.xml, putting at the mercy of jar file merging and
so potentially losing some config.
Now the annotation processor writes a compat_config.xml for each Java
class that exports config, we we merge them together here with a new
tool.
Test: m
Change-Id: I28c12ff648a01aaad214701fca4f09743638b11b
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
Previous CL Ia9b34aa92ebb1b4de96ea0f8f290d798be19b2cf introduced
asymmetry in handling "boot" and "apex" boot images: in JIT-zygote
experiment, though the "apex" boot image was installed, the "boot"
boot image was still used for generating dexpreopt configs.
It is unclear why this asymmetry was needed at that point; it seems
incorrect to use different boot images for dexpreopting and for
installing on device. After recent changes the asymmetry started
breaking walleye_jitzygote-userdebug on git_rvc-release, because APK
dexpreopt commands refer to inexistent boot image files.
Test: lunch aosp_walleye-userdebug && m
Test: cherry-pick CL in internal, walleye_jitzygote-userdebug boots
Change-Id: Id877c10269cf79caf6ae74b1dc169a31e6a2211b
This time, exclude NDK libraries instead of LLNDK libraries from the
package. This is necessary because there are libraries such as libvndksupport
which are LLNDK but are not accessible to apps.
Original commit message:
> Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true
> (e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their
> recursive library dependencies, including for example libc++ when depending
> on the platform libc++. This means unnecessary churn when we add a new
> dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow
> jni_libs clauses to be simplified, make the build system search for the
> recursive dependencies and automatically include them.
>
> This change allows us to remove code that was previously adding NDK libc++
> as a special case, as it is now covered by the generic code.
>
> Also fix some improper quoting that was exposed as a result of this change
> causing more files to be packaged than before.
>
> [1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22
Bug: 144430859
Test: atest CtsAppOpsTestCases
Test: atest FrameworksNetSmokeTests
Change-Id: I8311ede0b44d7e50b9f272912ead8ef07e82b074
Enable jacoco for ike.jar to set up code coverage. ike will be
shipped in mainline module com.android.ipsec
Bug: 146012420
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true SKIP_BOOT_JARS_CHECK=true WITH_DEXPREOPT=false
Change-Id: I886551d980c0d9651b11c80051f17609bb3531d8
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)
It needs to be an implicit input for it to work consistently.
Test: m GooglePermissionControllerUnitTests
Bug: 145011263
Change-Id: Ib71d768e750faa5b577652e79a18d05929bde52f
This reverts commit 2812df4edb.
This is no longer required as we have
I6463ebc59cf7fd861b812999d7a79c387bbb3335.
hostdex files are available even when the module doesn't have
"//apex_available:platform"
Bug: 128708192
Test: m
Change-Id: I0d1295683222bc9cdbb82630e61ab3421c717daf
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
Previously, android_app targets for which a.shouldEmbedJnis(ctx) = true
(e.g. CtsSelinuxTargetSdk25TestCases) would need to specify all of their
recursive library dependencies, including for example libc++ when depending
on the platform libc++. This means unnecessary churn when we add a new
dependency to libc++ (e.g. libunwind [1]). To avoid the churn and allow
jni_libs clauses to be simplified, make the build system search for the
recursive dependencies and automatically include them.
This change allows us to remove code that was previously adding NDK libc++
as a special case, as it is now covered by the generic code.
Also fix some improper quoting that was exposed as a result of this change
causing more files to be packaged than before.
[1] https://android-review.googlesource.com/q/topic:%22libunwind-so%22
Bug: 144430859
Change-Id: I3d6fbcce75bc108a982eb7483992a4b202056339
The clang-r370808 upgrade contains a change to LLD allow PT_LOAD
segments to reside at non-multiples of the page size in the resulting
object file. https://reviews.llvm.org/rL369344
While this helps reduce the alignment waste and resulting image size, it
has interesting implications for execute only memory (XOM): The runtime
loader will now load code or data from other segments into pages with
different protections than intended.
This would partially defeat execute only (XOM) text sections as the
segment could now overlap with previous and following sections. This
might allow for code or data from the preceding and following sections
(like .eh_frame, and .data.rel.ro) to be executable, and either ends of
.text to be readable.
When the runtime loader (linker[64]) `mmap`s segments from *.so files,
the file offset parameter (see `man 2 mmap`) MUST be a multiple of the
page size. Since the updated LLD can now pack segments in a file (which
helps minimize resulting object file size) (previously, the segment
offsets were page aligned), this has interesting implications.
To appreciate the current bug, consider the following output from
`readelf` before this patch is applied, but after the toolchain upgrade:
```
$ readelf -lSW $OUT/symbols/apex/com.android.runtime/lib64/bionic/libc.so
...
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
...
[13] .eh_frame PROGBITS 000000000002e7c0 02e7c0 013374 00 A 0 0 8
[14] .text PROGBITS 0000000000042b40 041b40 09ecb4 00 AX 0 0 64
[15] .plt PROGBITS 00000000000e1800 0e0800 001f30 00 AX 0 0 16
[16] .data.rel.ro PROGBITS 00000000000e4740 0e2740 005208 00 WA 0 0 32
...
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R 0x8
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x041b34 0x041b34 R 0x1000
LOAD 0x041b40 0x0000000000042b40 0x0000000000042b40 0x0a0bf0 0x0a0bf0 E 0x1000
LOAD 0x0e2740 0x00000000000e4740 0x00000000000e4740 0x006720 0x006720 RW 0x1000
...
01 .note.android.ident .note.gnu.build-id .dynsym .gnu.version .gnu.version_d .gnu.version_r .gnu.hash .dynstr .rela.dyn .rela.plt .rodata .eh_frame_hdr .eh_frame
02 .text .plt
03 .data.rel.ro .fini_array .init_array .dynamic .got .got.plt
...
The above output tells us:
1. .text will wind up in the third (02) segment.
2. The third segment will be (LOAD)'ed as (E)xecutable.
3. Because the file (Offset) of the first segment (0x41b40) is NOT a
multiple of the page size, it cannot be passed as the `offset` to
`mmap`. As such it will be rounded down to the first multiple of the
page size, 0x41000.
4. The preceding section (.eh_frame) will be loaded in the preceding
segment (01). It occupies file (Off)set range [(0x2e7c0):0x41b34].
0x41b34 is not explicit in the output, instead you must use the
formula:
Off + Size == End
ie.
0x2e7c0 + 0x13374 == 0x41b34
(This happens to match (FileSiz) of the second segment, which makes
sense as .eh_frame is the final section in the second segment.)
5. mmap'ing file offset 0x41000 when loading the second segment will
include 0x4c0 bytes (0x42000 - 0x41b40) from .text, now mapped as
readable (oops). Suddenly code from .text is now readable (and thus
scannable for gadgets for ROP chains).
6. mmap'ing file offset 0x41000 when loading the third segment will
include 0xb34 bytes (0x41b34 - 0x41000) from .eh_frame, now mapped as
executable (oops). Suddenly data from .eh_frame is now executable
(and thus a potential gadget for ROP chains).
7. mmap'ing file offset 0xe2000 when loading the third segment will
include 0x8CO bytes (0xe3000 - 0xe2740) from .data.rel.ro, now mapped
as executable (oops). Suddenly data from .data.rel.ro is now
executable (and thus a potential gadget for ROP chains).
8. mmap'ing file offset 0xe2000 when loading the fourth segment will
include 0x730 bytes (0xe0800 + 0x1f30 - 0xe2000) from .plt, now
mapped as readable (oops). Suddenly data from .plt is now readable
(and thus scannable for gadgets for ROP chains).
All these oops' could be avoided if the linker placed .text+.plt at page
size aligned file offsets, which is what `-Wl,-z,separate-code` code
does. After this patch, we have:
```
$ readelf -lSW $OUT/symbols/apex/com.android.runtime/lib64/bionic/libc.so
...
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R 0x8
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x041b34 0x041b34 R 0x1000
LOAD 0x042000 0x0000000000042000 0x0000000000042000 0x0a0be0 0x0a0be0 E 0x1000
LOAD 0x0e3000 0x00000000000e3000 0x00000000000e3000 0x006720 0x006720 RW 0x1000
```
In the future, we could go back to tightly packing segments in the
binary if the runtime loader was improved to detect the previously
stated problem, and `memset` over the problematic ranges of the freshly
`mmap`ed pages (implying additional startup cost for reduced binary
size). This might save ~6 KB from each native binary, which adds up to
~17 MB for an AOSP image.
Also, prefer
-Wl,--execute-only
rather than
-Wl,-execute-only
Bug: 139945549
Bug: 146144180
Test: readelf -lSW $OUT/symbols/apex/com.android.runtime/lib64/bionic/libc.so
Change-Id: I64527e034ca3c71565ea52ed06f81f75d5216627
Reported-by: Ryan Prichard <rprichard@google.com>
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Java libraries with hostdex: true are available for the platform even if
it doesn't have "//apex_available:platform" in the apex_available
property. Note that the java libraries are still prevented from being
installed to the device.
Bug: 128708192
Test: m
Change-Id: I6463ebc59cf7fd861b812999d7a79c387bbb3335
When a boot classpath java library is directly or indirectly included in
APEXes, multiple variant of the library exist. When running the
hiddenapi tool, we need to eliminate the duplication, otherwise the tool
will complain.
Previously, we simply choose the platform variant of the java library
among the multiple variants. However, if the java library is marked not
available for the platform (i.e. "//apex_available:platform" is not in
the apex_available property), the platform variant does not exist and
thus it is not fed into the hiddenapi tool, which causes missing
references in the tool.
To solve the problem, the platform variant is selected only for the java
libs that are available for the platform. For those libs that are not
available for the platform, we choose one variant of it using a
heuristic; skip testing APEXes and choose com.android.art.release among
the com.android.art.* variants.
Bug: 128708192
Test: m
Change-Id: I33bf297eb3029696ae3504a011486210708fb2c2
The main purpose of apex_available is to prevent a module from being
installed to the system partition (or being statically linked to
something that is installed to the system partition). It's not the goal
to prevent host tools from using the modules.
However, since both host and device variants are not mutated for
platform when the module is not available to platform, the host tools
that depends on those modules couldn't be built. To solve the problem,
the platform variation is NOT skipped for the host variants.
Bug: 128708192
Test: m
Change-Id: I1d662cd6d165581f344138d872329a15bfc43d17
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
Jiyong Park