fb: Fix wrong IME state handlings on keyboard switches

We assumed that calling updateFromSettingsLocked(true) is in all value changes
a possible way to simplify the process. In reality this fails when the user
switches eg between 2 IME keyboards several times due that we call every
time

                        mIPackageManager.setApplicationEnabledSetting(imm.getPackageName(),
                                PackageManager.COMPONENT_ENABLED_STATE_DEFAULT,
                                PackageManager.DONT_KILL_APP, mSettings.getCurrentUserId(),
                                mContext.getBasePackageName());

which results in wrong mCurMethodId which ends in method calling which should not be called
and result in an NPE and hotreboot due of dieing service.

To fix it go only for showinputmethod feature the old way and restore for all other
value changes AOSP behaviour and check specifically if enabledChanged is true or not
based on the getEnabledInputMethodsStr() method during we lock on mMethodMap

Thanks for the detailed report to Natakranta

Change-Id: Iff1f598a57cfd1f0fc45a2c4ebca1a43dfeb02d6
fb: do not block home button if incoming call is a background call

The user want to navigate ahead if it is a call in background.
So we allow it.

Change-Id: If40b8abba05b600191bfc1403f197e624fd7a360

Conflicts:
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
Keyguard: update correctly track title and info if screen turns on

AOSP issue - Force update both if screen turns on.

Change-Id: I3d3198534c3ccdaa0ad2f40a967cc092a7dc0a0c
Keyguard: don't try to fetch the badgeIcon if remoteClientPackage == null

Logcat shows....if client is lost there is no need to force an exception due that remoteClientPackage
in this case is null.

Change-Id: I80e612610f93c9d70c854b2fcb8fbf0c0d8f9e2a
LN: beautify

Change-Id: Ia330fe8f37c3c5ce3998093c0ac3b1212d9463d1
NavTargets : Show highlight for google search

- Show highlight for google now icon
- Update launching logic to upstream
- Don't hideTargets in doFinish

Change-Id: I6027bc30b4bc98bf1dbadd9cb02e46349745bfbb
Framework: Launch HOVER notification in fullscreen [1/2]

Launch in fullscreen (new default) or floating window when not from foreground app

Change-Id: I96dd273e2993bd1393eb4d272b06e669bebeda33

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
Framework: Animate the Ticker when HOVER require Fullscreen mode

Change-Id: I73bc1e9f596e07605ed109870d4a7fc7c00a188e
Framework: Statusbar brightness control [1/2]

    Ported to AOSPA from N5X CM11 Based by @AragaoAnderson

Change-Id: I2f5ba16f69ee057a1fc14075673611cb742d567c

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
Framework: Launch music player on headset connect [1/2]
Launches the default music player when a headset is connected

    Ported to AOSPA from N5X CM11 Based by @AragaoAnderson

Squashed commits:

*AudioService: Restore volumes after boot and when a headset is plugged
*Move 'start music player on headset connection' option out of DSPManager
*Fix up 'launch player on headset connection' option.
*Launch music player on headset connect

Change-Id: Ic2fd1f7c726dc4a6922dfa5cc0ac5badd11d0c0d
Framework: Filter spam notifications

    Ported to AOSPA from N5X CM11 Based by @AragaoAnderson

Change-Id: I34df2d73b66308acbada257b946160c86063d396
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

Change-Id: I81a7473ca48eb5fd91263ec63c82957d8b3ad17b

Conflicts:
	core/java/android/app/IActivityManager.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/ExpandHelper.java
	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/am/ActivityStack.java
	services/java/com/android/server/am/ActivityStackSupervisor.java

Conflicts:
	core/java/android/app/Notification.java
	core/res/res/values/n5x_strings.xml
	packages/SystemUI/src/com/android/systemui/statusbar/notification/HoverLayout.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	services/java/com/android/server/pm/Settings.java