Frameworks: Store dialpad showing state (1/2)

Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>
Lockscreen Notifications [1/2]

My try on making notifications easily accessable from lockscreen.
Credits to ChameleonOS, I got the notification listener permission and some small other stuff from their ActiveDisplay implementation.

Lockscreen Notifications allow you to manage all your notifications directly on the lockscreen.

Features:
- Pocket mode turn screen on when phone is pulled out of pocket and turn it off when phone gets back in pocket
- Hide low priority notifications
- Hide non-clearable notifications
- Allow dismissing even non-clearable notifications from lockscreen
- Just turn screen on when there's currently a notification pending
- Toggle between expanded and normal notification view by longpressing
- Wake on new notification
- Configure notification count displayed at once
- Privacy Mode: disable showing notification content.
- Blacklist apps - thanks to ChameleonOS for the original implementation and @Der-Schubi for bringing it to lockscreen notifications

This should still be considered as beta, even if it seems to work very well for me.

Change-Id: I4d72de71d36dc2f66ad7e3ce7a4442a931cf2982

Conflicts:
	core/java/android/provider/Settings.java
	packages/Keyguard/src/com/android/keyguard/KeyguardViewManager.java
	services/java/com/android/server/NotificationManagerService.java
Lockscreen Notifications: Fix NPE

E/AndroidRuntime( 3778): java.lang.NullPointerException
E/AndroidRuntime( 3778): 	at com.android.keyguard.NotificationViewManager.onScreenTurnedOn(NotificationViewManager.java:286)
E/AndroidRuntime( 3778): 	at com.android.keyguard.KeyguardViewManager.onScreenTurnedOn(KeyguardViewManager.java:825)
E/AndroidRuntime( 3778): 	at com.android.keyguard.KeyguardViewMediator.handleNotifyScreenOn(KeyguardViewMediator.java:1416)
E/AndroidRuntime( 3778): 	at com.android.keyguard.KeyguardViewMediator.access$2300(KeyguardViewMediator.java:104)
E/AndroidRuntime( 3778): 	at com.android.keyguard.KeyguardViewMediator$4.handleMessage(KeyguardViewMediator.java:1131)
E/AndroidRuntime( 3778): 	at android.os.Handler.dispatchMessage(Handler.java:102)

Fix NPE on first boot

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

Credit: PA

Conflicts:
	core/res/res/values/liquid_strings.xml
	core/res/res/values/liquid_symbols.xml

Conflicts:
	packages/DefaultContainerService/res/values-ku/strings.xml

Conflicts:
	core/res/res/values/axxion_strings.xml
	core/res/res/values/axxion_symbols.xml
Fix setting confirmation helper derp
Fix and and add Incoming Call in BG (Thanks SLIM)

Conflicts:
	core/java/android/provider/Settings.java
	packages/SystemUI/src/com/android/systemui/statusbar/notification/NotificationHelper.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/HeadsUpNotificationView.java
	packages/SystemUI/src/com/android/systemui/statusbar/tv/TvStatusBar.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

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
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

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
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

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java