Remove rastakat ascii printing
Change ota zip nameing and shell date setup
Backup tool support
Let vendor handle tones and sounds
Add support for GNU Make 4.0 and support for OpenJDK*
Also fix python on other Linux systems

Squashed commit of the following:

commit e82095f53968611527ea75f459794ed6f2e76399
Author: Andrew Bartholomew <andrewb03@gmail.com>
Date:   Sat May 10 10:58:07 2014 -0400

    build: use /usr/bin/env to call python

    Hardcoding the path to python instead of env is not recommended.  This
    can break the build in some Linux environments that link /usr/bin/python
    to python3.

    Change-Id: I4c62eb391acc6d468ce24ac8640834e965e76e78

commit b772d437445c2ef9a54d4b42004b6672fab42354
Author: MrBaNkS <banksmi09@gmail.com>
Date:   Wed Jun 25 21:19:34 2014 -0500

    Add support for GNU Make 4.0 and support for OpenJDK*
Add support for Inline kernel building (Credits:CM)
envsetup: set OUT_DIR to an absolute path always

OUT_DIR was set to $(TOPDIR)out previously,
but $(TOPDIR) was null, so it was a relative path.
This broke releasetools, inline kernel building, etc
since they require absolute paths.
Fix it so that it is set to $(shell readlink -f .)/out
if $(TOPDIR) is null.

Also remove hacks which checked if (OUT_DIR) was out
and changed it to $(ANDROID_BUILD_TOP)/out to workaround
the aforementioned problem.

Change-Id: I459a3b1325a1bbea0565cd73f6acf160d4ed9b39

Conflicts:
	core/base_rules.mk
	core/tasks/kernel.mk

Change-Id: I52a7a6024f0f2b708c230e53c0152ed138726cc1
Fixed:Home Button & QS tiles not working without Gapps

Conflicts:
	target/product/large_emu_hw.mk
Runtime resource overlay, iteration 2

Support any number of overlay packages. Support any target package.

UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes

    <overlay targetPackage="com.target.package"/>

For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.

THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').

UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.

Zygote initialization
   Initial AssetManager object created
+    idmap --scan creates idmaps for overlays targeting 'android', \
           stores list of overlays in /data/resource-cache/overlays.list
   AssetManager caches framework-res.apk
+  AssetManager caches overlay packages listed in overlays.list

Android boot
   New AssetManager's ResTable acquired
     AssetManager re-uses cached framework-res.apk
+    AssetManager re-uses cached 'android' overlays (if any)

App boot
   ActivityThread prepares AssetManager to load app.apk
+  ActivityThread prepares AssetManager to load app overlays (if any)
   New AssetManager's ResTable acquired as per Android boot

SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.

LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.

When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.

Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:

    <overlay targetPackage="com.target.package" priority="1234"/>

Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.

Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.

The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.

        +------+------+-     -+------+------+
        | 0x01 |      |  ...  |      | 0x7f |
        +------+------+-     -+------+------+
            |                           |
        "android"                Target package A
                                        |
                       Pre-installed overlay B (priority 1)
                                        |
                       Pre-installed overlay C (priority 2)

Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
New Theme Engine [4/6]

Adds aapt for on device compiling of theme assets

Change-Id: I2f9f4b3e27ddf32b339694f9c6d3b75a12b700d9
ccache: Use system version over prebuilt

If there is a ccache binary on the
host system use it instead of the
AOSP prebuilt.

Change-Id: I4b1e030713be22167a12bd229a4e35eda7736cd2
Signed-off-by: Evan Anderson <evan1124@gmail.com>
build: no longer build emulator by default

This is just increasing build times when most people are not using it.
Let's speed up builds a bit.

Building emulator should still be possible by appending BUILD_EMULATOR=true
to the build command

PS2: Let's keep the darwin warning.

Change-Id: Ibd8e2b90455bd603a691c7b95466068b6fae212a
Signed-off-by: Andrew Warfield <hiasant@gmail.com>
build: Set ccache base to build top

This enables ccache sharing between different build tree paths.

Change-Id: I99636bdd2779a6ccf0649f027e35cf67df44b6ae
Merge tag 'android-4.4.4_r2.0.1' of https://android.googlesource.com/platform/build into kk

Android 4.4.4 Release 2.0.1
JustArchi's ArchiDroid Optimizations V3

     _             _     _ ____            _     _
    / \   _ __ ___| |__ (_)  _ \ _ __ ___ (_) __| |
   / _ \ | '__/ __| '_ \| | | | | '__/ _ \| |/ _` |
  / ___ \| | | (__| | | | | |_| | | | (_) | | (_| |
 /_/   \_\_|  \___|_| |_|_|____/|_|  \___/|_|\__,_|

Copyright (C) 2014 Łukasz "JustArchi" Domeradzki
----------------------------------------------------------------------------------------------------------------
This is the squashed commit of countless hours spent on trying to optimize Android to the maximum and push it to the limits.
Please give proper credit if you decide to cherry-pick this commit. It includes countless number of full builds and tests, almost 200 hours spent on compiling and testing
----------------------------------------------------------------------------------------------------------------
WARNING! These modifcations are pretty DANGEROUS and may cause problems during compiling or running. You may also need to implement some fixes on your own.
----------------------------------------------------------------------------------------------------------------
Pre-requirements:
- GCC 4.8, both androideabi and armeabi, these can be added to your local manifest (roomservice.xml). You can use:
1. Google's GCC toolchain from official google's repo -> https://android.googlesource.com/platform/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.8 and https://android.googlesource.com/platform/prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.8
2. Linaro 4.8 (proposed) -> https://github.com/JustArchi/Linaro/tree/4.8-eabi and https://github.com/JustArchi/Linaro/tree/4.8-androideabi
3. SaberMod -> https://github.com/SaberMod
4. Eventually you can also change TARGET_GCC_VERSION back to 4.7, but 4.8 is highly proposed for performance boost.

- (Optional) Target user, instead of userdebug. You should build with user variant instead of userdebug, as user variant enables odexing and disables additional debug modules, i.e. dalvik debugging. This can be done by multiple ways, i.e. using proper lunch command (i.e. lunching cm_i9300-user instead of cm_i9300-userdebug) or "brunch device user", such as "brunch i9300 user", if you have this commit -> omnirom@687c588
----------------------------------------------------------------------------------------------------------------
Important notes:
- ART doesn't work in Android KitKat 4.4.2 with GCC 4.8. This can be fixed with this commit -> JustArchi/android_art@8354d2d
- If building with custom toolchain like Linaro, it may be possible that kernel won't build right away with "unknown cpu architecture" error. It may require some additional fixes, such as this commit -> JustArchi/android_kernel_samsung_smdk4412@6965f2f for smdk4412 kernel. Eventually, just use Google's arm-eabi and Linaro's arm-linux-androideabi, this way you'll build kernel with Google's toolchain and rest of the ROM with Linaro.
- In some cases stock kernel may not boot when built with GCC 4.8. It looks like this commit -> JustArchi/android_kernel_samsung_smdk4412@803cd15 may help, but don't commit it unless required.
- Due to O3 optimization, code is significantly larger and may cause problems with oversized images especially for older devices. For example, I couldn't apply O3 because building TWRP recovery failed due to the fact that it didn't fit on recovery's block in my device. In such case you have two options. You may use a hack and manually increase size of the blocks in your BoardCommonConfig.mk, so compiler doesn't yell about that (but you obviously can't flash such images), or you need to go back either to O2 or Os, up to you.
----------------------------------------------------------------------------------------------------------------
Important changes:
- Added missing Cortex-A9 CPU variant (-mcpu=cortex-a9)
- Disabled global workarounds for Cortex-A8, they're applied only when you're targetting Cortex-A8 CPU now (-Wl,--fix-cortex-a8)
- Bumped GCC version to 4.8 from default 4.7, as it performs much better than default 4.7 and gives excellent results
- Optimized for speed yet more all instructions - ARM and THUMB (-O3)
- Optimized for speed also parts which are compiled with Clang (-O3)
- Turned off all debugging code (-DNDEBUG)
- Performed loop invariant motion on trees. It also moved operands of conditions that are invariant out of the loop, so that we can use just trivial invariantness analysis in loop unswitching. The pass also includes store motion (-ftree-loop-im)
- Created a canonical counter for number of iterations in loops for which determining number of iterations requires complicated analysis. Later optimizations then may determine the number easily (-ftree-loop-ivcanon)
- Performed induction variable optimizations (strength reduction, induction variable merging and induction variable elimination) on trees (-fivopts)
- Tried to reduce the number of symbolic address calculations by using shared “anchor” symbols to address nearby objects. This transformation can help to reduce the number of GOT entries and GOT accesses on some targets (-fsection-anchors)
- Assumed that loop indices do not overflow, and that loops with nontrivial exit condition are not infinite. This enables a wider range of loop optimizations even if the loop optimizer itself cannot prove that these assumptions are valid (-funsafe-loop-optimizations)
- Allowed the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. This is only applied to target ARM, nothing has been changed in this matter apart from more precision in warnings (-fstrict-aliasing)
- Placed each function and data item into its own section, this is required for -Wl,--gc-sections (-ffunction-sections -fdata-sections)
- Moved branches with loop invariant conditions out of the loop (-funswitch-loops)
- Attempted to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization most benefits processors with lots of registers (-frename-registers)
- Re-ran common subexpression elimination after loop optimizations are performed (-frerun-cse-after-loop)
- Didn't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions (-fomit-frame-pointer)
- Made a redundant load elimination pass performed after reload. The purpose of this pass is to clean up redundant spilling (-fgcse-after-reload)
- Ran a store motion pass after global common subexpression elimination. This pass attempts to move stores out of loops (-fgcse-sm)
- Eliminated redundant loads that come after stores to the same memory location, both partial and full redundancies (-fgcse-las)
- Constructed webs as commonly used for register allocation purposes and assigned each web individual pseudo register. This allows the register allocation pass to operate on pseudos directly, but also strengthens several other optimization passes, such as CSE, loop optimizer and trivial dead code remover (-fweb)
- Performed tail duplication to enlarge superblock size. This transformation simplifies the control flow of the function allowing other optimizations to do a better job (-ftracer)
- Optimized GNU linker, which significantly reduces launching time and memory usage. This is especially visible during booting process, which is a few seconds faster than usual (-Wl,-O1)
- Applied special --as-needed flag to GNU linker. The flag tells the linker to link in the produced binary only the libraries containing symbols actually used by the binary itself. This not only improves startup times (as the loader does not have to load all the libraries for every step) but might avoid the full initialization of things, which we're not even physically able to use (-Wl,--as-needed)
- Performed global optimizations that become possible when the linker resolves addressing in the program, such as relaxing address modes and synthesizing new instructions in the output object file (-Wl,--relax)
- Sorted the common symbols by alignment in descending order. This is to prevent gaps between symbols due to alignment constraints (-Wl,--sort-common)
- Enabled garbage collection of unused input sections, thanks to -ffunction-sections and -fdata-sections (-Wl,--gc-sections)
----------------------------------------------------------------------------------------------------------------

For more information, support, troubleshooting and discussion about my optimizations, please refer to my thread on XDA -> http://forum.xda-developers.com/showthread.php?t=2754997