AppOps: Add nfc enable control into AppOps

Check user permission before enabling nfc.

Change-Id: Ia84e33c299e4fdecfd66ee933d9e7d37ed29c340
AppOps: add permission check when enabing nfc

Add appops permission check for enable function.

Change-Id: Ie98be3e7b3cd9e72b0ad12cc1634d9cd1869a66c
Themes: Only kill launchers if overlays or icons changed

There is no need to kill the launcher for every coponent changed.
The only ones that really concern us in regards to killing launchers
are MODIFIES_OVERLAYS and MODIFIES_ICONS

Change-Id: I840b8e2ecd4b52a33f352809c5d3d2c7e92ce85e
perf: Send a boost hint when a key on the navbar is pressed

 * A lot of stuff happens, especially when invoking recents.
 * Get ahead of the storm by sending a boost hint before
   kicking off the animations.

Change-Id: I0cecd0c58f8bc8479ea44f63af796500d7b9d7d2
reimplement navbar cursor keys (1/2)

AOSBfied

Change-Id: Iffd8d7f98dc5ec3e5f208821e8eb09723f00b1df
Signed-off-by: Dirk Rettschlag <dirk.rettschlag@gmail.com>
NavBar: Fix FC (NPE) on Landscape
Return: Smart Pulldown [1/2]

Adds the ability to directly open the QS panel when there are
no notifications present in the notification panel.
This commit combines the enhancement by HardCorePawn for detectin
notification types for the same.

Credits: kufikugel, HardCorePawn

PS 2-4 : Cleanup

Change-Id: Idf7076eff47a9b02659e1e98e60fa474b3e7cbeb
SystemUI: Smart Pull-Down - Any Notification (1/2)

Change-Id: I1749d0e166df707f125e454a47826b6e4df531fc
Revert "HeadsUp: Fix dismiss on back key press."

This reverts commit 2aa1c08def25e61a12739cc34f371f99edc2670a.
Revert "SystemUI: Improve HeadsUp expanding performance."

This reverts commit e57896a0737a9602fd81a7be8a79b29510a04643.
Revert "HeadsUp: Only remove heads up if attached to window"

This reverts commit e149e4f16564955256159218b3e7725d96730210.
Revert "HeadsUp: Respect system decorations when adding view."

This reverts commit 11938cbe757345fe8169622bbff0388e61cd2b7d.
Revert "HeadsUp: Add heads up blacklist options. (1/2)"

This reverts commit f147075830d8130efdccff090166c6a7cb4468c1.
Revert "SystemUI: Expose heads up"

@28ed94629c4b9d8dca64dd0203805952bd500a0d
@6eb6bf8f3056ef0f253df6ecd0e1a108b09f3973
Fix NullPointerException in ListView

There is a NullPointerException in `handleHorizontalFocusWithinListItem()`
because `selectedView.findFocus()` returns null and then there is no null
check when when the assigned variable `currentFocus` is used, although
`View.findFocus()` states that it may return null.

Change-Id: I6897027e9a2a238d9283e6b9f5146198989fcac0
InputWrapper: opt out early if session == null

Change-Id: If111195ba6425ad6b8663601566f9f260738ec77
[Bitmap] Add null pointer protection in Bitmap_sameAs()

Symptom: SkBitmap::getAddr(int, int) may return NULL due to unrecognized config
(ex: kRLE_Index8_Config). This will cause memcmp method to crash. Since bm0 and
bm1 both have pixel data() (have passed NULL == getPixels() check), those 2
bitmaps should be valid (only unrecognized), we return JNI_FALSE to warn user
those 2 unrecognized config bitmaps may be different.

Change-Id: I6970c27de412110a3035d0a783112c4cd3ebc35b
Skip broadcasting to a receiver if the receiver seems to be dead

If an application that has a broadcast receiver is killed
during broadcasting, thread variable of ProcessRecord becomes null
so that IIntentReceiver#performReceive() is called
in BroadcastQueue#performReceiveLocked(). But if binder driver has not
noticed the death of the application yet, it can't throw
DeadObjectException. After that, binder driver notices. But it can't
notify DeadObjectException to the caller because performReceive() is
async call. So broadcasting keeps on waiting for finishing
performReceive() until timeout.

This change checks the death of the application before calling
performReceive() and skips broadcasting to the receiver
if the application has already died.

Change-Id: Ifa02b8b1a7e7b6fd314de90fedff5b7a5326825d
Frameworks: Heads up meets SlimKat....SlimKat meets Google IO [1/4]
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

Conflicts:
	core/java/android/app/Notification.java
	core/java/android/provider/Settings.java
	core/res/res/values/slim_strings.xml
	packages/SystemUI/res/values/slim_strings.xml
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/CommandQueue.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/tv/TvStatusBar.java
	services/java/com/android/server/pm/Settings.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