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
ApexModule is the interface for APEX-aware modules. The module type apex
uses the interface to get APEX-specific information from other modules,
such as the list of APEXs that a module should be built for.
A module that is included in an APEX will be built specificaly for the
APEX. This is especially required for shared libraries; we shouldn't
just copy the artifacts built for platform, because they may be linking
against private (=unstable) symbols that are not available to APEXs
which are basically unbundled.
This CL, as a first step, makes cc.Module an APEX-aware module type.
Bug: 112672359
Test: m apex.test; the built apex has all the direct and transitive
shared lib dependencies of the libs and executables listed in Android.bp
Change-Id: I21f6a586654779984f0f5154b2a08b2adbf2168b
Bug: http://b/109759970
Bug: http://b/91353691
There are no multiple-defintion errors after switching to clang-r339409
and libc++.
Test: m native-host-cross
Change-Id: I5576b3894ed1d88c9b2e5f4d92e1d3bfadfb029b
- Stop including libstdc++ headers.
- '-pthread' and 'static-libgcc' are unused when we pass -nodefaultlibs.
We didn't pass -nodefaultlibs for libstdc++.
- Use SjLj exceptions for 32-bit. libgcc_eh implements SjLj exception
model for 32-bit.
- Disable visibility annotations for libcxx and libcxxabi since we are
only going to support these as static libraries.
- Use Win32 threads. MinGW pthreads throws an error when building
libcxx since it's pthread_mutex_initializer is not constant (needs a
cast).
- Link libgcc_eh, which needs pthread, which in turn depends on
kernel32. Wrap the libraries with --start-group and --end-group and
remove duplicates.
Test: Build and test Windows binaries under Wine.
Change-Id: I8be51b004585e11ef51b7d5012f2a51330d1260f
To migrate the default compilation over to using
"core platform api" stubs we need to make the "before"
state as close to the "after" state as possible.
The stubs will include all "core libraries" so it
makes sense to include those that contribute to the
"core platform api": okhttp, bouncycastle and conscrypt.
(apache-xml is not included because it doesn't contribute
to the core platform API).
After this change all explicit dependencies to okhttp,
bouncycastle and conscrypt in situations where the
default boot classpath is used can be removed.
A knock-on of this change is that the conscrypt, bouncycastle
and okhttp targets need to be adjusted to explicitly
depend on core-oj / core-libart with no_standard_libs: true
to avoid a cycle.
Bug: 113148576
Test: treehugger
Change-Id: I1677af8d9d48fd026874ebce4c864f39ec1a5a3d
Now that we've got prebuilts of make, turn on logging so that
we can find all the users and convert them to the prebuilt.
We also build xmllint as part of the tree, so log uses of that
too.
Test: treehugger
Change-Id: I8a6a5d481dfc709dc0eb3424c51430bc54763c1e
https://android-review.googlesource.com/c/platform/build/soong/+/689585
added, but was skipped going into pi-dev-plus-aosp, as the pi-dev
version (which did not have these lld bits) was already merged there.
When pi-dev-plus-aosp was pushed to aosp-master, this got lost.
Merged-In is a random git_master change, since this needs to go
into pi-dev-plus-aosp too, but no further.
Bug: 78133793
Test: git diff aosp-master..master -- cc/config/arm64_device.go
Change-Id: Iea69a2c040d11249e43a76a78859944274ce6a92
Merged-In: I7799feac522a1097ec4271bd7868cd6bfe147ad9
Make needs to exclude all files that match a filespec except for
those specified in a list. Add a -X argument that overrides the
-x argument to allow files be included that were previously
excluded.
Bug: 69500920
Test: zip2zip_test.go
Change-Id: Icc8aebc788b53bcdde73a39c9c7cf3107a049251
Make sure that the minimal runtime gets applied to the rest
of the sanitizers we might use from ubsan.
Bug: 80195448
Test: Build success and checked build flags.
Change-Id: I31b211b80bb1068c153a9b65454a2605933c9568
Clang is always used now, so we can remove all the GCC checks. Removing
GCC-specific configuration will happen in the next CL.
Test: m
Change-Id: I4835ecf6062159315d0dfb07b098e60bff033a8a
There was no way to select a single source file from a genrule that
has multiple source files. Make Soong's genrule closer to Bazel
by supporting $(location) for input and outputs. Change the
label used for tools referenced through filegroups to the name
of the module instead of the name of the file, which means it
matches the string used in the tools property.
Also support :module format in the tools property in preparation
for deprecating the tool_files property and putting both files
and modules in the tools property.
Bug: 117354232
Test: genrule_test.go
Change-Id: Id31a4ac4ff7064076a576c1d8ffeb7c19fc6b9a4
Merged-In: Id31a4ac4ff7064076a576c1d8ffeb7c19fc6b9a4
(cherry picked from commit 098d22b5f6)
