HeadsUp: Fix resetHeadsUpDecayTimer.

    - If user has forced immersive mode through expanded desktop,
    we shouldn't hide the heads up notification quickly.

Signed-off-by: Roman Birg <roman@cyngn.com>
Signed-off-by: Adnan Begovic <adnan@cyngn.com>

Change-Id: I6ac015ce5c28216cafd3ce96f8d1993495b26897

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
HeadsUp: Respect system decorations when adding view.

    - FLAG_LAYOUT_IN_SCREEN ignores system decorations, so
    a heads up view in landscape would end up underneath the navbar

    - FLAG_LAYOUT_NO_LIMITS allows the window to exceed the screen
    limits all together

      Removing both these flags makes Heads Up respect both system
    decorations and the screen limits.

Change-Id: I6f111e1c5701d493979be0cb596f11bc1b437fda

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
SystemUI: Improve HeadsUp expanding performance.

Change-Id: Ifd31caca6d2eb2432772b6a63f6b545f8288f449
HeadsUp: Launch in floating window

Add some part of NotificationHelper
Credits to AOSPA team

Change-Id: I7001cebd69790b46b8dcfe9150c7ef104e5427a2

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/notification/NotificationHelper.java
HeadsUp: option to launch in floating window [1/2]

Change-Id: Ia8ffb4088f5b48b222a77ef486ba8b14e193c26f

Conflicts:
	core/java/android/provider/Settings.java
	packages/SystemUI/src/com/android/systemui/statusbar/notification/NotificationHelper.java
PhoneStatusBar: Readd headsup view when theme change occurs.

Change-Id: I5bbfa56650a1b2f9cd9c4365650f769bed009ab0

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
BaseStatusBar: Dismiss heads up on backpress.

Change-Id: I5b6191657cf0b74d825eb653a6e82c33e0527aad
Fix
Partial commit: Heads up meets SlimKat....SlimKat meets Google IO [1/4]

**Orignal commit can be found here:
https://github.com/SlimRoms/frameworks_base/commit/323ed77c5e5bd6d421beae1f8118eb580be5ecf1

First introduced from apple, showed as android version on PA as hover and now found
in android code as native implementation we want to do our interpretation of this feature.
Especially thanks PA and CM for some of the UX ideas.

We have basically split this feature in two parts.

1. Googles native integration. We keep it as is and use the native flags for it. Apps
   (in our case Dialer, Mms, Email per account) can force show a heads up notification
   if the notification is important. So basically same what was shown on Google IO the first
   time to the public. Eg the dialer on SlimKat is doing exactly the same now like google want it.
   Due that we use same flags like google every future app with heads up support will automatically
   show as heads up.

2. Give the user an ability to enable heads up mode for third party apps which do not have a native
   integration. Well first thought was on which apps a user would usally use it (keeping in minde the idea from google....heads up
   is for important notifications and for nothing more)? Right on chat, email
   or social apps. On all other apps it simply does not make sense at all. Which leads into the question why the
   current integrations are handling blacklists or whitelists and enable it per default for all apps. This
   is from UX point of view an absolutely no go (just imagine the user blacklists half of the 200 apps installed lol).
   Aside that parsing long lists is a peformance problem.

   So our attempt goes into another direction. Headsup for (native integration is another story) apps is disabled
   by default. We bind the information directly to the application package. So each app carries the information itself.
   The user can either enable it with a longlick in the notification drawer on the notification or in Settings->app->App info
   as well via a check box. As soon it is enabled for this app every notification from this app will show as heads up as long
   it is not an ongoing notification.

   In general on system signed apps the user is not allowed to change the heads up state. Thats nothing the user should
   decide....the system should do. Aside that it prevends user to enable heads up for eg IME selector etc etc.

Thats the basic concept behind. In addition to this concept following things were done.

- Introduce a new expanded notification flag. Apps can send it via extra metadata to force
  a expanded heads up notification is it is needed (eg dialer).
- Add a user option to enable always expanded on heads up notification
- Add a user option to set the timeout for the heads up view.
- Introduce a snooze button. Every heads up notification has a snooze button on the top right. If the user press it
  heads up is disabled for a certain time (like a do not disturb mode). The time length is user configurable in settings.
- We had a bunch of user which want to use heads up in a more intrusive way. Current default behaviour is that a heads up
  shows up if the user did not push the heads up of this app into background. This is due that the system assumes if the user
  put it into background he or she do not want to be disturbed by notifications of this app at the moment. Of course in the moment
  the user interacted with the background notification heads up is activated again. This leads like google suggested in a very
  good non intrusive way. Well but some user use it in another way (especially on immversive mode) and want to be notified on every
  notification update of this app via heads up. Due of this understandable other user behaviour we add an option for it to allow
  this scenario.
- Detect direction of the swipe. Left swipe will dismiss the notification (if it is not a non clearable). Right swipe will just
  hide the heads up and the notification is still in background accessable in the notification drawer.

Other then that some fixes were done as well (eg utilize the back button, correctly handle the hiding of the heads up,
handle action buttons on heads up view correctly, fix several expanded desktop and immersive issues
and some other issues the AOSP implementation currently has)

To summarize...heads up this way is very non intrusive and especially we do not need a bunch of settings or blacklists.
So it is pretty straight forward, fast, clean and user friendly.

Some visual examples:

https://plus.google.com/107859134357373490612/posts/bJABHs1aNMj

Change-Id: I81a7473ca48eb5fd91263ec63c82957d8b3ad17b

Conflicts:
	core/java/android/provider/Settings.java
	packages/SystemUI/res/values/slim_strings.xml
	packages/SystemUI/src/com/android/systemui/ExpandHelper.java
	packages/SystemUI/src/com/android/systemui/SwipeHelper.java
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/tv/TvStatusBar.java
SystemUI: Clear disappearing children and remove HeadsUp on recreate.

    - Since some views animate in and out of visibility
    the call to removeAllViews on the mStatusBarContainer may still
    keep a reference to the view.

    - Also remove mHeadsUpNotificationView from the window manager if
    it's not null.

Change-Id: I5ced26e0f36362e89779bd7c6dac4d8235e0c0e9

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
Slim Heads up: change behaviour of back key

Currently back key hides the heads up. We change it that the back key is still
working for the app which has focus and not for the heads up at all.

Reasons:

1. A lot user requested this due that they often hide the heads up during they work
   on the phone, simply due that the back button is often pressed on a normal workflow.
   The results is indeed that a lot heads up windows are missed excidentaly.

2. First I thought to make it optional. But there is another big reason to do it this way. Current
   behaviour is that the heads up view gets focus...and that we dispatch the back key only. Thing is
   that other key events are still rooted to the heads up window. Well most things a user will not see.
   But eg on apps with input field some keys on the IME keyboard do not work during the heads up is showing
   which is a big no go when we assume that heads up needs to be as much non intrusive as possible.

That being said we remove the dispatch override and give the heads up window FLAG_NOT_FOCUSABLE flag
which will bypass any key events to the window behind which had focus before the heads up showed up.

FLAG_NOT_TOUCH_MODAL we can remove due that FLAG_NOT_FOCUSABLE automatically enables the FLAG_NOT_TOUCH_MODAL flag.

Change-Id: Ied4c7d2dd5b99f89af958f01db980a36d431bbc3
SystemUI: fix crash when opening camera and headsups is disabled
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.

Change-Id: Ida916eba496c4183e47288ef24a8a93c46a7eddf
Remove non intrusive incall ui

Change-Id: I76067c8be0b432782efbf28c8f7008b43d8846b5

Conflicts:
	core/java/android/provider/Settings.java
fb: Incoming Call in Background (3/3)

Patch ported from 4.2 which was done by our lovely HCP. A
very popular one so we bring it back and adapt it to 4.4

Allows user to set that Incoming Call UI will remain in background
if screen is on. Instead, a notification is added to StatusBar, which
can be used to bring up the Incoming Call UI. Ringtone and vibration
still occur as per system settings.

This has the same effect as apps marked as "immersive". It prevents
the incoming call from backgrounding the current activity.

Change-Id: I1eb0ae6b10ba02c3f1df95265d26a6c61db74aab

Conflicts:
	core/java/android/provider/Settings.java
Revert "Hover : we use non intrusive ui.."

This reverts commit 5d421781a624932fef887e409377445468b6a2a7.