There are some code policies we want to enforce more strictly, but
it's hard to do so for third party code because we have to either
carry the diff burden or upstream the patch, and in the latter case
the turnaround time for fixes can be problematic, and sometimes
upstream won't accept changes (sometimes people just need to win the
obfuscated C contest).
We define ANDROID_STRICT for any code that we expect to be able to
make these policy fixes as we change policies.
Change-Id: I15faf62cec1932dd859a082f66942b2606d0ff45
It's a valid situation for all three of LOCAL_INIT_RC, LOCAL_INIT_RC_32,
and LOCAL_INIT_RC_64 to be used.
Bug: 26773181
Change-Id: If9661f93b1823279075fc3d55195f7a939e01b6f
When more than one makefile tries to copy a header to the same
destination, the warning is not clear, and hard to track down and assign
blame:
build/core/copy_headers.mk:15: warning: ignoring old commands for target `out/target/product/bullhead/obj/include/qcom/display/copybit.h'
With this change, the same behavior is kept, but the warning message is
more descriptive, and contains the offending Android.mk files:
build/core/Makefile:54: Duplicate header copy: out/target/product/bullhead/obj/include/qcom/display/copybit.h
build/core/Makefile:54: Defined in: hardware/qcom/display/msm8994/libcopybit/Android.mk hardware/qcom/display/msm8994/libcopybit/Android.mk
In this case, a $(CLEAR_VARS) is missing, so the same Android.mk file is
copying the same headers twice.
Bug: 27302058
Change-Id: Icf8f580ae71a78741db21c1d8f3213424459e637
Make sure my_src_jar is set up properly for host prebuilt jar when we
need to generate host .jack for host dalvik java libraries.
Change-Id: If85e27147cdc6e6a7a154c1cf308f9d0a71ff068
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
* When WITH_STATIC_ANALYZER is set and non-zero, and clang compiler is used,
call new clang ccc-analyzer or c++-analyzer.
* Otherwise, if WITH_SYNTAX_CHECK is set and non-zero,
call compiler with -fsyntax-only.
* Replace "--sysroot=path" with "--sysroot path", to work with ccc-analyzer.
* ccc-analyzer executes the original compilation command to generate
object files before calling clang with --analyze to do static analysis.
* When clang is called with --analyze, macro __clang_analyzer__ is defined.
BUG: 13287788
Change-Id: I5edb25b52998d871385dd000778db2ce83224078
With the change in [1], delta_generator now needs
libprotobuf-cpp-lite.so instead of libprotobuf-cpp-lite-rtti.so to
generate A/B payloads.
[1] commit ab5bd668f6be600a8cceb8772e426c0aa902a5e1
Bug: 27145830
Change-Id: Ib9a93bf0fbe7fa44fc5fb94668d17fa1a2e07b05
(cherry picked from commit fdd2693b65)
This changes the build system to provide the signapk tool with the
minSdkVersion of the APK being signed. signapk in turn will then use
SHA-256 instead of SHA-1 if minSdkVersion is 18 (JB MR2) or higher
(see c2c49ed0c1).
To avoid increasing incremental OTA update package sizes for already
released platforms, release build scripts disable the above logic when
signing target files ZIPs for pre-N platforms.
Bug: 25643280
Change-Id: I3f2faaf49c6fa392ffbf1ee9f30de476f9f73231
This configures Soong to build windows binaries, which requires support
for 64-bit windows binaries in BUILD_PREBUILT for USE_SOONG=true.
module_arch_supported.mk did not support 64-bit being the secondary
architecture when evaluating multilib conditionals. All other uses of
HOST_*_IS_64_BIT already check the proper version.
Change-Id: Iff664733e6991f4adbe8ddd620b091bbb55d1d86
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
*.o files that are passed in via LOCAL_GENERATED_SOURCES are added
directly to all_objects, they are not mixed with the normal_objects that
we track. So omit them from they my_gen_src_files list so that we don't
warn that they're unused.
Change-Id: I94b85504032e70fbcc00207d6200557700dd0a89
Building a module by name with make <module name>, or with mm or mma
through all_modules, should also build the .toc file so that future uses
of mm on modules that depend on this one can find the .toc file.
Bug: 26936761
Change-Id: Id0c592f0860a10b732b2b5b13c7e967c9bcb1c6b
This moved from lib/ to lib64/, but wasn't noticed because no one builds
with the profiler on by default.
Change-Id: I0155263b4a50437ea0864338fb34baefc3df59d2
This change enables build rules to specify:
LOCAL_JAVA_LANGUAGE_VERSION := 1.8
to enable -source 1.8 -target 1.8 for javac and
equivalent flags for Jack.
Bug: 26753820
(cherry-picked from commit cdfbe4a852)
Change-Id: I361c99dd599e7b4a041f02c9562e461da2b0502e
This was producing a number of unused source warnings for prebuilt files
using LOCAL_SRC_FILES_<arch>.
Change-Id: I48d1face7baf642f3ef17f957448ccb73788765f
Objective-C .m/.mm files were not being tracked, so they were showing
up as unused source files (on Darwin). They were also triggering an
internal build system warning because the new object list did not
match the current list.
Change-Id: I01fff8c5587fe168106c60782080d60744311f6f
config.mk needs to know TARGET_BUILD_PDK in order to select prebuilt
tools. Move the selection of TARGET_BUILD_PDK into config.mk.
Change-Id: I1f73c92917887f27259b2db64b3779a2fe0df162
This is a reland of 4c474617d4
This time, we use awk instead of sed, and the script works
on Mac.
For C++ code llvm-rs-cc defines two targets but it defines
three targets for Java. The sed script was updated to handle
both cases appropriately.
Bug: 26839129
Change-Id: I1bca7d253764554d552950e03deedabaa9b7f17e