If there's a symlink as the destination to one of these macros,
currently we'll write to the destination of that symlink instead of
overwriting the symlink. We've run into this a few times when a module
is added to replace a symlink that used to exist via
LOCAL_POST_INSTALL_CMD. These have required manual discovery, and
additions to CleanSpec.mk files:
http://android-review.googlesource.com/143334
Use `rm -f` for single-file targets to remove the destination before
copying. On Linux, `cp --remove-destination` can work, but is not
supported by Darwin or acp.
There may still be problems with dependencies when symlinks are
involved, since ninja will use the destination of the symlink to check
whether it is up to date. But at least with this change, if any
dependency gets regenerated, we'll properly reset the file.
Change-Id: I6d3ac0bd9ced5e21a0ff9dad0eaff012a7bc9c75
When the build type changes (for example, from "shamu-userdebug"
to "shamu-user"), the build system doesn't delete all files
and start over. Rather, build artifacts from the old build type
are reused for the new build type.
This is problematic for the recovery SELinux policy, which differs
between build types. Reusing a userdebug policy on a user build
is inappropriate and could lead to security bugs.
Force the deletion of the recovery SELinux policy when changing
build types, so it can be properly regenerated. This is consistent
with how we treat the normal SELinux policy (see commit
a8b3d54101).
Change-Id: I4ebafe3712dc121644828f6538865061aad58cc0
And everything special-cased on that. Add a warning if USE_NINJA is
set to let users know that it no longer changes anything.
Change-Id: Ib8739151fe26ea6bf8f76b7ac2b8f4097dab0b47
We may have devices with OEM-specific properties but without an OEM
partition (e.g. the properties might be set by init based on hardware
SKUs). For such devices, we supply --oem_no_mount to skip mounting the
OEM partition in the updater-script. The option is only meaningful when
-o (--oem_settings) is specified.
Bug: 27359929
Change-Id: Ic08396e478a82be4188e980e704b33b4f704a8d7
Modify the compiler flags for Jack and javac.
This has the following effects:
1) Generally, some of the type inference rules changed.
2) javac: bytecode is generated with the v52 major version (not v51)
3) jack: Java 8 language features are supported.
The javac / dx toolchain does not support Java 8 language features.
Bug: 26753820
(cherry picked from commit fda1ace26116a6677cc77c92c24e5259817fb86e)
Change-Id: I07769de473775d95b13feb38c0eb37086eb120f7
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
The actual clang compiler called for static analysis is decided
by build/core/binary.mk, not the one given to --use-analyzer.
BUG: 13287788
Change-Id: I58105c20b56ce17ddf329a275c750d14284d1e25
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
Add --downgrade flag to ota_from_target_files.py script. It allows
generating an incremental OTA that updates from a newer build to an
older one (based on timestamp comparison). "post-timestamp" line in the
metadata file will be replaced by "ota-downgrade=yes". A data wipe will
always be enforced, so "ota-wipe=yes" will also be included in the
metadata file.
Bug: 26883782
Change-Id: Iaa05f662d948b7ab632a9fbb7051cc3f8bf68c21
Sandy Bridge actually doesn't have all of these options. For example AVX is only
available on the higher-end SKUs (not on Celeron G550).
Change-Id: Ib595a9a6b464626d0c88525c6aaa4d69176645cc
Pass -w dupbuild=err to ninja to make defining multiple rules to build a
file an error instead of a warning. Proceeding with the build would
result in undefined behavior, and nobody notices the warning.
Change-Id: Iadac88f8835121a8685bff835acba638100bb654
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
Many Brillo repositories need to share a common .clang-format file to
ensure the same formatting rules. This patch moves the .clang-format
file already in system/core/metricsd to a common location to be shared
by other Brillo repositories.
Bug: 27121653
TEST=symlink from system/update_engine, ran clang-format.
Change-Id: Ie04a5a9cf54b9cc24f180fe3896501db4d883a64
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
