Update Logo to water droplet

Credit: Santod for the picture
http://i60.tinypic.com/rbcjli.png

Change-Id: I2c30d2104b2804e7f962d1a3c1ce8966488aebe0
Merge "base: update link ring-notifications after read user settings" into kitkat3
add idea/studio config

this should allow opening this folder in idea/studio
and editing inside the IDE

Change-Id: If348d493d207d997dec89e04caf434e40fa2f209
Signed-off-by: Arnav Gupta <championswimmer@aokp.co>
Merge "add idea/studio config" into kitkat3
base: update link ring-notifications after read user settings

Change-Id: Ib424124dc20e38243e572333e323ba97aacb1111
JIRA: CYAN-3559
Issue: https://jira.cyanogenmod.org/browse/CYAN-3559
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
Fix FragmentTransaction replace() behavior

This is from AOSP Gerrit Review, was just Pushed, so not yet merged.
It is a definate problem though:
case OP_REPLACE should not remove only every other fragment.
It needs to be fixed. So here it is.
-----------------------------------

According to FragmentTransaction's reference, replace()
should be equivalent to remove()'ing every fragment in
a given container and then adding the specified fragment
to replace those that were removed.

Commit ee76efb74b5886f98cdfebfbefe9b69224e016fb broke
this intended behavior in the framework.

This patch makes it so that the removal loop doesn't
end prematurely. It also fixes an issue where the
replace operation would remove fragments regardless
of their container after encountering the first fragment
with a matching container ID.

Relevant issues:
http://b.android.com/43265
http://b.android.com/52112
http://b.android.com/53393
http://b.android.com/68856
http://b.android.com/70803

Change-Id: Ica4691746ab8979ed974a998e85324e4feacc5e3
Signed-off-by: Eddie Ringle <eddie.ringle@gmail.com>
Merge "Fix FragmentTransaction replace() behavior" into kitkat3
Remove settings gets from ViewConfiguration execution path

Change-Id: I3f29dafc9e178861910423e324d433fc1bc1e6a1
Merge "Remove settings gets from ViewConfiguration execution path" into kitkat3
[ActivityManager] Prevent potential deadlock from system error dialog and InputMethodManager.

Sympton:
When application crash in a special timing and system server's InputMethodManager is binding, deadlock may occur.

Root Cause:
Thread(1): When using InputMethodManager in system server, it will lock mH(handler) of InputMethodManager,
and sometimes it will call to InputMethodManagerService::showCurrentInputLocked and will call bindService at some condition,
then it will also lock ActivityManagerService.
Thread(2): When an application crashed, it will lock ActivityManager when showing crash dialog, inside the dialog,
it will call setEnabled of Button and lock mH of InputMethodManager.setEnable of TextView will lock IMM's handler.
So the deadlock happened as the flow: (2) lock AMS -> (1)lock mH -> (2)wait mH -> (1) wait AMS

Solution:
Reduce nested lock of error dialog: post message to let (2) lock mH after release AMS lock.

Change-Id: Id85c29406236db3b5fca9655fde1fcaf0afd1337
Merge "[ActivityManager] Prevent potential deadlock from system error dialog and InputMethodManager." into kitkat3
[ActivityManager] Prevent kill a restarted process again.

Root Cause:
Use removeTask with flag ActivityManager.REMOVE_TASK_KILL_PROCESS will set waitingToKill = "remove task"
to the target process when its setSchedGroup is not BG_NONINTERACTIVE.
Later the target process may be killed when applying oom-adj due to setSchedGroup has changed to BG_NONINTERACTIVE.
If the process is needed to restart, the process record will be resued.
Then the restarted process may be killed again because its waitingToKill is not null.

Solution:
Clean waitingToKill when process is dead.

Change-Id: I5ffb5388127f4221da4c700d3f1c224f7ca6e7b2
Merge "[ActivityManager] Prevent kill a restarted process again." into kitkat3
[ActivityManager] Avoid keeping restarting home when only home activity exists.

Root Cause:
When there is only home activity existed,
updating home apk will call forceStopPackageLocked to finish the activity.
Then activity history becomes empty, then home will be launched,
but its package is still target to close that results a loop.

Solution:
If home activity has been force-stopped, do not stop the same home activity again.

Change-Id: Icff12028d407873c2e6f50a06bcad231b908ccbd
Merge "[ActivityManager] Avoid keeping restarting home when only home activity exists." into kitkat3
HeadsUp: option to launch in floating window [1/2]

Change-Id: Ia8ffb4088f5b48b222a77ef486ba8b14e193c26f
Merge "HeadsUp: option to launch in floating window [1/2]" into kitkat3
Halo: Modify behavior

Don't ping when halo got "silent" notifications.

Change-Id: I54d16d8aefbf173e6edcdf4f2fc3e6cbf6f55420
Halo: Some Tweaks

Do not launch floating window when on default launcher
Do not launch in floating mode if notification is from the foreground app

Change-Id: I6eb2ff093dbc395bc2fb76176c42276f6bd4165b
Merge changes I6eb2ff09,I54d16d8a into kitkat3

* changes:
  Halo: Some Tweaks
  Halo: Modify behavior