This CL changes the build system to always look for shared JNI
libraries at their unsanitized install locations.
Bug: 38309771
Test: m -j40 && SANITIZE_TARGET="address" m -j40
Change-Id: Icb9d4f5365def6ea7a780553f455f41d2cb8b8bf
All the new features are turned off for now, since multiple branches and
products need to be verified before they can be turned on. So everything
should behave the same as today, except for no partition-based
warnings.
Instead of the current link type checks that happen during the build,
run as many as possible immediately after loading all the Android.mk
files. If we're allowing missing dependencies ('mm',
ALLOW_MISSING_DEPENDENCIES, tapas, etc), we'll defer the link type
checks to during the build. If we're not allowing missing dependencies,
we'll produce a better error message to the user about the missing
dependencies.
See core/main.mk for a description of the storage format.
This also remove the partition-based type checking. It hasn't worked all
that well, particularly with ASAN builds. The new VNDK checks will
handle the most pressing cases.
Test: Verify all link_type files and dependencies are the same:
grep link_type: out/build-aosp_arm64.ninja | sed -E "s/ rule[0-9]+//" | sort
Change-Id: Id643658b9d9e84f99f5db0d526aad88c1f5d3417
This CL moves the location of ASAN-ified libraries on disk in the
following manner:
/data/lib* --> /data/asan/system/lib*
/data/vendor/* --> /data/asan/vendor/*
There are a couple of advantages to this, including better isolation
from other components, and more transparent linker renaming and
SELinux policies.
Bug: 36574794
Bug: 36674745
Test: m -j40 && SANITIZE_TARGET="address" m -j40 and the device
boots. All sanitized libraries are correctly located in /data/asan/*.
Change-Id: Ic6ba8e43e31df2ea92b85fd60f572823b6883ba2
Add MIN_PLATFORM_VERSION and MAX_PLATFORM_VERSION to track
the range of releases that are expected to be released from
the current branch.
Also simplify version_defaults.mk by moving most of the code
to envsetup.mk.
Test: build/make/tests/envsetup_tests.sh
Change-Id: I4f19c31c267e202f8f5ba1384a8b4385d725f9d7
BOARD_VNDK_VERSION controls which version of the VNDK is used for the
build. We only support compiling against the current VNDK, and we don't
support installing old prebuilt VNDK libraries yet, so ensure this
variable is set to "current".
Once we support installing old prebuilt VNDK libraries, we'll also need
to disable building modules that use the VNDK.
Test: build-aosp_arm.ninja is the same before/after
Test: Ensure there are no boards that set BOARD_VNDK_VERSION
Test: Set BOARD_VNDK_VERSION := invalid
Change-Id: Ic26c9f44e356a0734f522b4538cb866d5b901d43
lunch can now take combos in the form:
$TARGET_PRODUCT
$TARGET_PRODUCT-$TARGET_BUILD_VARIANT
$TARGET_PRODUCT-$TARGET_BUILD_VARIANT-$TARGET_PLATFORM_VERSION
If all 3 are not specified the unspecified ones will take the
default values provided by the build system (eng, and currently
OPR1).
In addition, error handling for invalid products, variants and
versions is moved to the build system.
Bug: 34972208
Test: build/make/tests/envsetup_tests.sh
Change-Id: Ib0aaa98633448ba9bd8df911704c9cb3a8ebbe85
- TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE is the output directory of
RENDERSCRIPT_BITCODE (libclcore.bc) for vendors.
- It is only used if LOCAL_PROPRIETARY_MODULE := true specified for the
bitcode module.
Bug: 34396220
Bug: 34334222
Test: mm
Change-Id: I10237470eff0d8a693ce73313944e9b24595c5b7
Don't print the config in Kati when we've already printed it in soong_ui
or the make wrapper.
Test: m -j
Test: USE_SOONG_UI=true m -j
Change-Id: Ic6dce0ab29d584d85c6642c597f6e9dcd6ba9dca
We currently use static libraries without any source files to represent
header libraries, but Soong actually has cc_library_headers. So to
export those in a separate namespace from static libraries, implement
them in Make as well.
This also adds a nice pretty-warning / pretty-error macro that can be
used to print out standard warning messages pointing to the real source
file having the problem.
Test: Use a header library exported by Soong in a Make module
Change-Id: I3486539e247524cb82a20620745fc7be03014e14
Aggregates the different *TS testcases into two common folders,
one under each the host and product hierarchies.
Bug: 34715822
Test: `make cts -j` and checked the contents of both:
out/host/linux-x86/testcases/ &
out/host/linux-x86/cts/android-cts/testcases/
Change-Id: I7d5201998ddcb011ecc687c272a0d0a36da248b7
Also mark these variables as readonly so that later Android.mk cannot
change them.
Bug: 33607778
Test: build/tools/kati_all_products.sh -j12
Change-Id: I5f9a4df02bfdfd56549728f074bbb3fc251edb3d
There are no users left, so remove all of this.
Test: lunch aosp_arm-eng; m -j native
Test: build/tools/kati_all_products.sh on aosp and internal master
Change-Id: I32f5c8b470a43dd203d7e20c192167630e4e6888
Native coverage is enabled by setting NATIVE_COVERAGE to true
and specifying a list of paths in the COVERAGE_PATHS
environment variable. Files are exported to a zip file in the
target out directory.
Change-Id: I66a2ddd88e849bec1cc0cdae1b51fe18a007e2c3
HOST_PREFER_32_BIT was used during the switch to 64-bit host tools to
keep the SDK building as 32-bit, but is never set any more.
Change-Id: I874f89c7d1e9cd8c9d4c879048d81a4362ce4dce
This was printing all of the Soong modules in addition to the modules
defined in the ONE_SHOT_MAKEFILE. So replicate what we did with
MODULES-IN-* with GET-INSTALL-PATH-IN-* and update all the users.
Bug: 30191725
Change-Id: Ib1e4bf00f64d7a3e8cd91f44eaf1ff82fdfbf162
AUX is a new class, similar to TARGET
While TARGET defines toolchain for Application Processors
AUX is defining toolchains for arbitrary utility cores (DSPs, GPUs,
MCUs, etc). This allows building of non-android sources as part
of Android tree and avoid using prebuilts if source code is avaliable
Bug: 29635686
Change-Id: Ie755ea054b16c3e86369f5fb2ba6eb0b384af77f
Signed-off-by: Alexey Polyudov <apolyudov@google.com>
Build error when LOCAL_PROPRIETARY_MODULE, LOCAL_PRIVILEGED_MODULE,
and LOCAL_MULTILIB := 32 are set for a module in 64-bit build.
The patch adds path definition for
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS_PRIVILEGED
Change-Id: I2fe0c0f28fb7e4a27defd3a1b04f84c8b296294f
Fix the directory for secondary-architecture libraries under
sanitization. These incorrectly wrote into vendor/lib instead
of data/vendor/lib.
Bug: 29498013
Change-Id: Iee08422a1f7ad42cbe71a322347e98cb74e3ef7f
For AB devices, support flashing two system partitions for factory use.
The normal system image on one partition, but without dex preopt. And a
system_other image that just contains the odex files. The dex files will
not be stripped out of the system image, in case the second system
partition is wiped.
Setting BOARD_USES_SYSTEM_OTHER_ODEX := true in the BoardConfig.mk
enables this behavior.
One can control which directories are placed in system_other by the
SYSTEM_OTHER_ODEX_FILTER configuration variable. Currently we default
to only copying only app and priv-app odexs.
Bug: 29278988
Change-Id: I7f4e87da919e7dc6a89fd8c668193cd4e98631bc
Standardize symlinking /system/vendor -> /vendor for aosp_* devices,
since some /vendor binaries still use /system/vendor/... paths.
Support using a prebuilt vendor image and including it into all the
normal packaging steps.
Bug: 28987532
Change-Id: I27040e8a8d1df0777e16cd1e3c3a9f1b28695e96
am: 323396993c
* commit '323396993c6651b4b98974df9e9d53118f27a840':
Fix mm and mmm in Android.bp directories
Change-Id: I95d6bde7a0ea72b47779f1a5b0577ff423524b6f
mm and mmm were not parsing out/soong/Android.mk, so they were ignoring
all modules defined in an Android.bp file. Always include
out/soong/Android.mk when ONE_SHOT_MAKEFILE is set, and convert the mm
and mmm functions to build MODULES-IN-$DIR instead of all_modules so
that only the subset of modules defined in out/soong/Android.mk for the
requested directory are built.
Bug: 28986194
Change-Id: I6e1ff8cacfc668a4154a0d5937450db840bb7a6b
These are all either recently unused due to the removal of CFLAGS/etc,
or have been exported by Soong and are no longer necessary.
Change-Id: I5930d43fda21acc8202b3d8ea010fbefb6ae4cf1
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
A blank USE_CLANG_PLATFORM_BUILD= on the command line for make causes
confusion between make and kati. make ignores writes to variables set
on the command line, so envsetup.mk cannot set it to true,
USE_CLANG_PLATFORM_BUILD is still empty in soong.mk, and soong.variables
gets DeviceUsesClang: false. kati gets USE_CLANG_PLATFORM_BUILD= in its
environment instead of on its command line, so envsetup.mk when parsed
by kati sets USE_CLANG_PLATFORM_BUILD=true.
Error out early if USE_CLANG_PLATFORM_BUILD is not true or false after
attempting to set it to true if it is empty.
Change-Id: I0e2731315711db9a6ac6ea2bf49c88bccacd35f7
Support TARGET_2ND_ARCH as the binary translation arch.
See target/board/generic_x86_arm/BoardConfig.mk and
target/product/aosp_x86_arm.mk as example for the setup.
In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the
binary translation arch;
Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's
not a typical 64-bit multilib configuration.
In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to
install the TARGET_2ND_ARCH libraries. This also pulls in any dependency
libraries.
By default we don't install any TARGET_2ND_ARCH modules, unless it's
pulled in by PRODUCT_PACKAGES.
Bug: 27526885
Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009
(cherry-pick from commit 277e75a488)
1. Combined ~10 calls to the make build system to only one.
We added a phony target "dump-many-vars" to the build system to dump
"<var>=<value>" pairs. We then store the pairs as shell variables.
With this cache get_build_var/get_abs_build_var can just return
the shell variables instead of querying the build system.
2. Prune .git when we search for AndroidProduct.mks.
In internal source tree lunch time was reduced from ~15s to ~1.5s.
Bug: 27429759
(cherry picked from commit 08800fd905)
Change-Id: I862a0ec3c1aae97c552054dacec133e857042edf
1. Combined ~10 calls to the make build system to only one.
We added a phony target "dump-many-vars" to the build system to dump
"<var>=<value>" pairs. We then store the pairs as shell variables.
With this cache get_build_var/get_abs_build_var can just return
the shell variables instead of querying the build system.
2. Prune .git when we search for AndroidProduct.mks.
In internal source tree lunch time was reduced from ~15s to ~1.5s.
Bug: 27429759
Change-Id: I24e88598f6fab598ef26518885fd5e86e71a772d
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
(cherry picked from commit 9ecbf83259)
Change-Id: Iab2d36e20d7002568c3534e7781e9ac8ab21a4a9
These have been using SHARED_LIBRARIES, but aren't elf shared libraries.
Continue installing them to /system/lib[64], but do not apply any other
normal shared library logic to them.
(cherry picked from commit c6e194ffad)
Change-Id: I0041650af92cd8063ca33215010d5eff514a89bc
These have been using SHARED_LIBRARIES, but aren't elf shared libraries.
Continue installing them to /system/lib[64], but do not apply any other
normal shared library logic to them.
Change-Id: I3055ff86bb7b116c7107c41578ed6f0f304b1cf1
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
When searching device, product, or hardware, allow
find to follow symlinks.
Add KATI_EMULATE_FIND=false to allow disabling the find
emulator which changes findleaves.py behavior wrt
symlinks.
BUG=24605247
TEST=works with CL:783781 (without the find wrapper in that CL)
Change-Id: Ia9d0e4add391a56f34828a09a6cec3f435ccc548
When LOCAL_PROPRIETARY_MODULE is set to true when building an apk with,
LOCAL_PRIVILEGED_MODULE set to true, the path is unknown.
Add TARGET_OUT_VENDOR_APPS_PRIVILEGED to path definitions.
Change-Id: Icbbafba96b7880f51ca3afcee53d5f3dd5b86a45
Signed-off-by: Benjamin Pujol <benjamin.pujol@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
Many of these may not make a difference in the output images, but it's a
good idea to keep the make system as repeatable as possible.
Change-Id: I31804b8ad5805148ed08be7426a242a16f4d0df3
When BREAKPAD_GENERATE_SYMBOLS is set to true, package the breakpad
symbols into the target files zip thats generated with `make dist`.
Bug: 24165970
Change-Id: I11c0d9a9d9e159475bfdb7bc338f9e9ac60aeada
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
We still support HOST_OS=windows for the SDK host tools cross-builds, but
that's only when USE_MINGW is set when running under linux.
Change-Id: I37da87dc9fbbd69ba10ce4d7f2668ab3f6482d92
Sanitized RPATH now mentions /system/vendor/lib to preserve overlay
in the case when a sanitized version of a vendor library can not be
built.
Bug: 22199458
Change-Id: I3222d2e1d6c08fdd1e0404fcb7db347aa4a92bb7
A fully (or even mostly) asan-instrumented device will have 2 copies of each
shared library, which might not fit on system partition. Moving instrumented
libraries to /data.
Bug: 21785137
Change-Id: I64184261da2eb24a1382c67e4931c34a5a38b3c0
These directories are excluded in addition to OUT_DIR.
This can be useful if your build system has other output directories
beyond what OUT_DIR is set to.
Change-Id: I6d98a85bcc8c89279e939406a7fec32547e8922f
For historical reason, the aosp_* products were named full_*.
We keep the full, full_x86 and full_mips in case some tools still
reference these legacy names; But no reason the have the full_* product
names for the new 64-bit archs.
Change-Id: I240ed0c6ded0ded2d80603bd0c5ff24750999afc
Build additional images requested by the product makefile.
This script gives the ability to build multiple additional images and
you can configure what modules/files to include in each image.
1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile.
PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles.
Each makefile configures an image.
For image configuration makefile foo/bar/xyz.mk, the built image
file name
will be xyz.img. So make sure they won't conflict.
2. In each image's configuration makefile, you can define variables:
- CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm"
etc.
- CUSTOM_IMAGE_PARTITION_SIZE
- CUSTOM_IMAGE_FILE_SYSTEM_TYPE
- CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary
accepted by BuildImage() in tools/releasetools/build_image.py.
- CUSTOM_IMAGE_MODULES, a list of module names you want to include
in the image; Not only the module itself will be installed to proper
path in the image, you can also piggyback additional files/directories
with the module's LOCAL_PICKUP_FILES.
- CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to
the image. <dest> is relativ to the root of the image.
To build all those images, run "make custom_images".
Bug: 19609718
Change-Id: Ic73587e08503a251be27797c7b00329716051927
(cherry picked from commit 5fcf1094f9)
We don't have a toolchain for 64-bit windows.
This allows running `USE_MINGW=1 mm` in a directory that has a host
module with LOCAL_MULTILIB := both.
Change-Id: I31f981b38fb80b0d6582bab0a4bd580a3c654c91
USE_MINGW=1 mm didn't work in directories that contained target modules
because the build system would use the Windows locations and extensions
when trying to find the host GCC prebuilts. Windows is the target OS,
not the OS we're building from.
Change-Id: Ic994fed15388d0c7d393f71ba28fe7afdc659f5c
Build additional images requested by the product makefile.
This script gives the ability to build multiple additional images and
you can configure what modules/files to include in each image.
1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile.
PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles.
Each makefile configures an image.
For image configuration makefile foo/bar/xyz.mk, the built image
file name
will be xyz.img. So make sure they won't conflict.
2. In each image's configuration makefile, you can define variables:
- CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm"
etc.
- CUSTOM_IMAGE_PARTITION_SIZE
- CUSTOM_IMAGE_FILE_SYSTEM_TYPE
- CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary
accepted by BuildImage() in tools/releasetools/build_image.py.
- CUSTOM_IMAGE_MODULES, a list of module names you want to include
in the image; Not only the module itself will be installed to proper
path in the image, you can also piggyback additional files/directories
with the module's LOCAL_PICKUP_FILES.
- CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to
the image. <dest> is relativ to the root of the image.
To build all those images, run "make custom_images".
Bug: 19609718
Change-Id: Ic73587e08503a251be27797c7b00329716051927
(cherry picked from commit 5fcf1094f9)
Set "HOST_PREFER_32_BIT := true" only if "sdk" or "win_sdk" is among the
make command line goals, or it's a MinGW windows build, which only builds
host SDK tools.
Bug: 13751317
Change-Id: I8ec1a97a5d1af065a153b16523c2ee3434d0dd71
Since we switched to $(HOST_OUT)/lib64 for 64-bit libraries and
$(HOST_OUT)/lib for 32-bit libraries.
Change-Id: Ie43bc03c37e2ac8542412a7543a6af5d60c6f725
Since we switched to $(HOST_OUT)/lib64 for 64-bit libraries and
$(HOST_OUT)/lib for 32-bit libraries.
Change-Id: Ie43bc03c37e2ac8542412a7543a6af5d60c6f725
We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product
config makefiiles we actually get the placeholders in
PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its
BoardConfig.mk. We substitute the placeholder with the real
TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk.
With this change, we can support building vendor stuff to
system.img (the default) or a separate vendor.img.
Bug: 16515152
Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
