Make jgrep, cgrep, resgrep not recurse into 'out' directory.

Change-Id: Ieadfe63075aacccb637ddafe6518f5fad62dcd02
Signed-off-by: Anatolii Shuba <x0158321@ti.com>
gettop: fix symlink detection

Summary: We must use the -P flag for pwd to properly get $PWD from the environment *with* symlinks. Otherwise symlink
detection is broken and anything we do using $(gettop) at the top of a symlinked path won't work properly. I noticed this
issue while running on a system that has a SSD RAID symlinked to my android build home directory, which is ~/ssd_storage.
The top in this instance is a symlink, which means that gettop() returns my home path, or the path above the symlink
directory (but not the symlinked directory). This is a major issue in case developers choose to use $(gettop),
$ANDROID_BUILD_TOP, or $T (doesn't really matter either way).

Test Plan: Create a symlink and sync android source into the path. Open up the symlink, run envsetup.sh, and check
$(gettop) output.

While this isn't the best solution, it fixes an issue without creating new issues.

Change-Id: I65bc345753805e6161098d2af6e0bee0b07d37b1
Vibra: emulator: compile and stage vibrator.goldfish

Following the new vibrator hardware module implementation, the
goldfish vibrator module is no longer integrated in the default
vibrator implementation and therefore needs to be explicitly built
for the emulator.

This patch is related to others in:
 - hardware/libhardware
 - hardware/libhardware_legacy
 - frameworks/base
 - device/generic/goldfish

Change-Id: I844279f5535289f079d412fdc44c5cb3c9c1130c
Signed-off-by: David Wagner <david.wagner@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 94611
Vibra: compile and stage vibrator.default on all targets

Add the vibrator.default package to all targets deriving from
generic_no_telephony, i.e. virtually all targets.

This change is related to other changes in:
 - hardware/libhardware
 - hardware/libhardware_legacy
 - frameworks/base
 - device/generic/goldfish

Change-Id: Ic8464844e12f7d31ca49597dfc4995b13e9ff419
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: David Wagner <david.wagner@intel.com>
Author-tracking-BZ: 94611
Merge "Make jgrep, cgrep, resgrep not recurse into 'out' directory."
Merge "Vibra: emulator: compile and stage vibrator.goldfish"
Merge "Vibra: compile and stage vibrator.default on all targets"
build: rename aarch64 target to arm64

Rename aarch64 build targets to arm64.  The gcc toolchain is still
aarch64.

Change-Id: Ia92d8a50824e5329cf00fd6f4f92eae112b7f3a3
Merge "build: rename aarch64 target to arm64"
Load compiler environment for a second arch.

This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.

2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.

3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.

Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30

Conflicts:
	core/combo/TARGET_linux-arm.mk
Set up rules to build static libraries for TARGET_2ND_ARCH

The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.

Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
Set up rules to build shared libraries for TARGET_2ND_ARCH

The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.

Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
Replace all references to LOCAL_GENERATED_SOURCES with my_generated_sources

Now the RS generated sources are only appended to my_generated_sources.

Bug: 11654773
Change-Id: If8dbf3c08fed0b9945dd32b8c809331c17c4bc85
Support to build executables for TARGET_2ND_ARCH

By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true

Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
Make sure to install the .odex when running "make <module_name>"

Change-Id: I64195294dad15b7d379d667f4c4738c2808fd384
Support arch-specific LOCAL_ variables

With those variables, you can set up different values for TARGET_ARCH
and TARGET_2ND_ARCH.
Also fixed a couple of variables.

Bug: 11654773
Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b

Conflicts:
	core/base_rules.mk
Merge "Load compiler environment for a second arch."
Merge "Set up rules to build static libraries for TARGET_2ND_ARCH"
Merge "Set up rules to build shared libraries for TARGET_2ND_ARCH"
Merge "Replace all references to LOCAL_GENERATED_SOURCES with my_generated_sources"