Add weather header (1/4)

AICPfy:
It was a bitch to get the layout just like I want it.
Pushed bloody SystemUI like 30 times to test
PhoneStatusbar and layouts are done by me, rest is TeamEOS
so they get the credit of course

AICPfy -> AOSBfiy

Change-Id: I1dbddd01584717226dec5393994b1b99681c30f3
Signed-off-by: scott <scott@ubuntu>

Conflicts:
	Android.mk
	core/java/android/provider/Settings.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
HOVER: Don't treat touch outside event as true if is animating

- It needs to wait animation to be finished to start listen for touch outside
  and runs hide timer.

Change-Id: I744f1e4a1e5dc6fd30501e9fd6f793bf905dfd30
Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>
HOVER: Respect screen limits when adding view

As for what @Decad3nce reported here http://review.cyanogenmod.org/#/c/66654/
we shouldn't keep FLAG_LAYOUT_NO_LIMITS so view doesn't exceed the screen limits.

Thank you Adnan :)

Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>
Change-Id: Ifcbc4a1143362e1b7dd40e710126060688c894b9
SystemUI: add missing status bar image

Change-Id: Icaf4d179b538818f5782637d403de212d0e0a841
HOVER: Don't process and/or show foreground app notifications

- Don't show notification of foreground app
- Animate the ticker in this case so user can see it

Inspired from changes linked here https://gerrit.paranoidandroid.co/#/c/4453/10

Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>
Change-Id: I9f45e1641a7478c7e460c32133db00bd67f63e75
Signed-off-by: scott <scott@ubuntu>

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
Bye Bye Holo Blue Light

Change-Id: I2c2029dd4bedf8d733fd862f00445d8bfe8c9acf
SystemUI: Extend swipe helper (Part1)

I was not happy with long press on notifications and recents
to open apps in floating mode. The long press duration kinda
breaks the UI interaction flow, which prevented me from
actually using floating windows. Therefore, I've created a
private modification, which enables floating mode for
notifications and recents by swiping to the left. This
greatly improves usability without strongly deviating from
stock UI experience, in strict accordance with PA's
philosophy.  Changes are surgically implemented to keep the
probability of merge conflicts rather low. The code was
successfully tested on mako, hammerhead, tilapia, and manta.
Let the team discuss and decide whether or not this is a
worthy extension to PA.

Changes are split into two commits.

- Extending SwipeHelper:
SwipeHelper can now distinguish between directions LEFT,
RIGHT, UP, DOWN and can fire an abstract trigger 'event'. A
trigger direction can be specified and when a swipe in this
direction occurs dismissable children will not be dismissed,
instead they will be snapped back.  Whenever a child is
swiped far or fast enough in that direction an event is
triggered and the onChildTriggerd() callback is issued. This
callback was added to the SwipeHelper.Callback interface and
therefore requires all its implementations to realize this
method, such as probably Hover, which is sadly not open
source (yet?).

Change-Id: Ida06195913f022463d29ca22092e81fb8993ad50
Add on-the-spot user preference dialog

Change-Id: Ifb229f646f1a33b688970451056cab17b1652d07
Credit: PA
Signed-off-by: scott <scott@ubuntu>

Conflicts:
	core/res/res/values/probam_strings.xml
	core/res/res/values/probam_symbols.xml
SystemUI: Swipe to float for notifications and recents (Part2)

I was not happy with long press on notifications and recents
to open apps in floating mode. The long press duration kinda
breaks the UI interaction flow, which prevented me from
actually using floating windows. Therefore, I've created a
private modification, which enables floating mode for
notifications and recents by swiping to the left. This
greatly improves usability without strongly deviating from
stock UI experience, in strict accordance with PA's
philosophy. Changes are surgically implemented to keep the
probability of merge conflicts rather low. The code was
successfully tested on mako, hammerhead, tilapia, and manta.
Let the team discuss and decide whether or not this is a
worthy extension to PA.

Changes are split into two commits.

- Swipe recents for floating window:
Recents ScrollViews set separate trigger directions on
SwipeHelper (LEFT for vertical and DOWN for horizontal).
Directions are chosen as the opposite of the 'natural'
swipe-to-dismiss direction performed by the clear-all
button. onChildTriggered() will open the app in floating
window mode. To confirm this behavior for horizontal and
vertical recents views, separate settings confirmation
dialogs are shown with appropriate PA-style graphics (Gimp
sources on request).

- Swipe status bar notification for floating window:
Analogous to recents, here the NotificationRowLayout sets
the trigger direction to LEFT. It also got its own
confirmation dialog together with new hint graphics. After a
child is triggered, the app is started in floating window
mode by performing a click causing the notification to
disappear (exactly as it would anyway, if the app would have
been opened in 'normal' full-screen mode).

thnx to @tattooboy for port this to AOSB

Change-Id: Ib32e2c88033b1c143bd8dc8fa7394b002060d526
Signed-off-by: scott <scott@ubuntu>

Conflicts:
	core/java/android/provider/Settings.java
	packages/SystemUI/res/values/probam_strings.xml
	packages/SystemUI/src/com/android/systemui/recent/RecentsHorizontalScrollView.java
	packages/SystemUI/src/com/android/systemui/recent/RecentsPanelView.java
	packages/SystemUI/src/com/android/systemui/recent/RecentsVerticalScrollView.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/NotificationRowLayout.java
Fix setting confirmation helper derp

AICPfy

Change-Id: I1773ffa95bd32b822a58ae522f0cc038ea4425e5
SwipeHelper: Ignore ACTION_OUTSIDE touches

  When using the swiper class within a layout like a notification container
  elsewhere the notification shade, when tapping outside even if the finger will
  not move is easy to detect an ACTION_MOVE event. That will consider it like a
  dragging event and the view swipes to left a bit on its own getting stuck
  until next touch. Break if tapping outside, so it doesn't go mistakely forward
  to ACTION_MOVE event case.

Change-Id: I07e5a3a95b8bbebeadcc97ba2d7d1cf787a37e61
Signed-off-by: BigBrother1984 <stevewatersy@gmail.com>
Derp Fix after swipe patch

https://github.com/AICP/frameworks_base/commit/c9faf123d351c0abcbb977dba19b9a0342421025
Signed-off-by: scott <scott@ubuntu>

Conflicts:
	packages/SystemUI/src/com/android/systemui/recent/RecentsPanelView.java

Change-Id: I31bb5d6bececf1aca7c29560a042ae26b45ef4f3
Do not launch floating window when on default launcher

We only do this when user is on the default launcher
because if the user was on a non-default launcher,
he/she must have been there for some purpose and we
do not want to throw him/her back to the default
launcher incase he/she exits the app with HOME button.
FWB: Option to hide weather icon in statusbar (1/2)

Credit AICP - LordClockan

Change-Id: Iefed1fb57dffbae04b7fb4dde7eac95b4e1f7844
Signed-off-by: scott <scott@ubuntu>
HeadsUp: Only remove heads up if attached to window

Attempting to remove mHeadsUpNoficiationView from the window manager
when it is not currently attached will throw an IllegalArgumentException
so we check if it is attached and if so remove it, otherwise carry on.

As well remove possible left children in statusbarview

Change-Id: Ida916eba496c4183e47288ef24a8a93c46a7eddf
SystemUI: improve one finger notification expansion

Sometimes the quick settings ribbon would eat the initial ACTION_DOWN
setting mInitialTouchY in the expand helper, but we are clearly not in a
notification that we can expand here. So only set the initial y point if
we are inside the notification scrollview.

Change-Id: I628553ac15cc6b4ee3c682fe46bd1d96c6bc154d
Revert "audio: Inform audio HAL if it is a voice call initiated by Telephony"

This reverts commit 69c312fd14d06cdae6213cdbdddbc851918b41fd.

Change-Id: I1130da5141d6116ad05d9466283fd3275fcbfd58
Revert "audio: Fixed dead lock in AudioService during volume change"

This reverts commit 2d99ad7f7f4bc2f9124a4fe505c2f8ea699ae74e.

Change-Id: I7c6f288b5761618ac13cd0d275e5d45c9f177c50
HeadsUp: Correctly add and remove the window

isAttachedToWindow() basically works to determine if the view was attached or not.

But on the boot up process when already addHeadsUpView is called but the system is not
fully up and a recreation happens (eg on TRDS...due that the UIModeManager is doing its work as soon as system is ready)
the view gets attached....but not removed on the recreation due that at this time isAttachedToWindow() will return false even though the
window was added.

To solve simply use a boolean instead of isAttachedToWindow()

Change-Id: Ib576a83cadc581683f2a5b0afc922c53b01888b7