The module names are phony targets and we should avoid having file targets
depend on phony targets.
Instead the build system makes sure to use the file dependency with
PRODUCT_PACKAGES.
Change-Id: I8dc59d8f9ed92c146b8827d71278e27214e60f3a
Emit a warning when the static linker detects a shared library
has text relocations. Text relocations make it harder to
share pages across processes, and make it harder to use
certain memory protection features in, for example, SELinux.
This warning will turn into an error in a future change
(via --fatal-warnings)
References: http://www.akkadia.org/drepper/textrelocs.html
Change-Id: I3bc818e3ecdb8a4338668a9e816b6dc1081b7557
Based on existing setup, when EMMA_INSTRUMENT is used on a full
build, all Java modules will be processed with emma instrument
unless otherwise marked in their own Makefiles.
For the purpose of collecting code coverage, emma-instrument
all Java modules aren't that useful, instead, instrumenting all
the app packages is more useful. This change adds a new flag
EMMA_FULL_APP_INSTRUMENT, which can be used with a full build
to instrument all app packages.
Change-Id: Ie143fed49c23402b21f6cccac2ef25741726be45
init used to automatically execute hardware specific init.rc files from
init.<hardware>.rc. If the hardware specific init.rc file was installed
in recovery.img, various unwanted services would try to start, so init*.rc
was deleted when creating the recovery root directory.
init was recently modified to explicitly import init.${ro.hardware}.rc
from the default init.rc, rather than always trying to load it. Since
recovery replaces the default init.rc with a custom one, it will never
try to load hardware specific init files.
In addition, there are cases where we need to start hardware specific
services, for example watchdogd, so we need
init.recovery.${ro.hardware}.rc to be installed.
Modify the build rule to delete the default init.rc from the recovery
root directory so it can be replaced with the custom recovery init.rc,
but leave all the hardware specific init files in place.
Bug: 6953625
Change-Id: I5d9555e3d54d2f1d9f49fb981bd412c53741337e
Arrange to take $(BOARD_MKBOOTIMG_ARGS) and pass it to all invocations
of mkbootimg from within make, and to store it in the target_files so
it can be used by future invocations of img_from_target_files and
ota_from_target_files.
Bug: 6918260
Change-Id: I7130ac52e96bd51d4d8b80ca036635e1626f01f1
- the old behaviour was to override with default one, which makes
trying different sets of platform.zip difficult if default one exists
Change-Id: I4c8ac2e44d9e7b48f77d628cce3edb20fbdf27e4
- app_process is not in PDK, and this makes native debugging difficult
So provide symbol file instead of source
Bug: 6774048
Change-Id: I1a3a86cf64d8f1d22cdb3a22714f508de963099b
Set BUILD_EMULATOR to true when HOST_OS is linux.
Disable the emulator package target if BUILD_EMULATOR is not true.
Change-Id: I8987c0a091622baa0e861b451e635c4ddb148b29
Set BUILD_EMULATOR to true when HOST_OS is linux.
Disable the emulator package target if BUILD_EMULATOR is not true.
Change-Id: I8987c0a091622baa0e861b451e635c4ddb148b29
This parameter (which causes GCC to pull additional command line
parameters out of a file) is incompatible with ccache.
- With ccache 2.x, ccache will ignore this parameters, and potentially
compute invalid command line hashes since it is not reading the
parameter file
- With ccache 3.x, ccache will refuse to cache the files and error
with 'Unsupported compiler option'.
We still use the parameter file, but Make expands it instead.
Change-Id: I070c3877cbe2d058e1cf4754bac535e7f3498861
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
