Floating Window: Welcome back

* Port squashed jellybean floating window to kitkat.

Floating window contributors:
@drcmda
@beerbong
@D4rKn3sSyS

Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>

Merge notification manager service changes.

Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>

Change-Id: If3d6338f657915754bd6cb9cb987df62c17aa6d0

Conflicts:
	services/java/com/android/server/NotificationManagerService.java
Kill floating activities running in the same thread when tapping outside

This change makes all activities from the same app to be finished when we tap outside the halo window. Other apps running in different threads
(floating or not) won't be finished.

Port from here: https://github.com/ParanoidAndroid/android_frameworks_base/commit/f489f45ab2ba5dd4991c241917f7f4b0fd74b884

Change-Id: Ie6d6f46b2e23be60f991520ed480c2866fb2d0e3
Media process is crashing with NullPointer exception

Sometime, while creating thumnails list of media files in
compose MMS->attach file,  filepath may be null due to
synchronization issue.
Adding NULL check to avoid NUllPointer exception.

Change-Id: Id6cf5612a959b3ae15b44bc60dbbcbe40c624f09
CRs-Fixed: 636494
frameworks/base: Fix the random UI corruption

On low memory device, when a view goes to background. Its HW layer cache
will be destroyed to release memory. There is a very rare case that the
hardware render is not valid when destroy the layer, so the layer is not
destroyed and reused when the view comes to foreground. But the GL
context has changed, so the view is not rendered correctly due to its
HW layer cache. To fix this issue, destroy the layer in a safelyRun. Make
sure the layer is destroyed correctly.

Change-Id: I1c714e1d53db7353d5169e874a7cd0f527c3f67b
CRs-Fixed: 623239
frameworks/base: Fix change propagating issue

destroyLayer() function has been modified in kk. It is not correct
to propagate the UI corruption fix from jb to kk without considering
the new changes made in kk. This change is to make it align with
the new code in kk.

Change-Id: I34d11b230b9390fe8a989ab6f9c7d3a48d586205
WallpaperManager: add NULL pointer check for getCropAndSetWallpaperIntent

Originally the api 'getCropAndSetWallpaperIntent' does not check
whether the parsed parameter is a NULL pointer, as leads to the
whole app crash if it call this api with a null parameter accidentally.
A null pointer check logic is added into its original parameter check
logic, so that this API will throw an IllegalArgumentException if it
is parsed with a null pointer

Change-Id: Ib7de40e571419d09e1a744edc969eb7162766b75
Signed-off-by: houst0nn <houstonn@gmail.com>
NULL previous background bitmap upon changing wallpaper

Step to reproduce it on Nexus 10 with 4.4.2(KOT49H):
1. Long press on home screen.
2. Choose wallpaper from Wallpapers.
3. Select new wallpaper and set it.
4. Repeat step 1-3 several times.
See black background instead of the wallpaper.

There are two binder objects who hold reference to the
ImageWallpaper$DrawableEngine, which keeps the big chunk
bitmap from being recycled.
One is WallpaperService$IWallpaperEngineWrapper. The client
references went away slowly, maybe several minutes after
changing wallpaper. Then the finalizer has to been executed
to GC it.
The other one is WallpaperService$Engine$BaseIWindow. Don't
know who still held reference to it even after the window
was removed.
Anyway, let the bitmap be GCed first.

Change-Id: I27f6971a3edd26472b69e59b542b27fd7c8e7b90
Signed-off-by: jshe32X<jianchunx.shen@intel.com>
Signed-off-by: Guobin Zhang <guobin.zhang@intel.com>
Signed-off-by: houst0nn <houstonn@gmail.com>
Add TYPE_MAGNIFICATION_OVERLAY to InputWindowInfo::isTrustedOverlay()

This fixes a bug where a View with filterTouchesWhenObscured will have
all touches filtered when in magnification accessibility mode. This is
due to magnification being a separate Window over top of the running
Activity. The method onFilterTouchEventForSecurity in View will then
always return false when filterTouchesWhenObscured is enabled on the
View. By adding the magnification Window to the list of Trusted Overlays
we can ensure that touches will work properly with this property enabled.

Change-Id: I07706588a625682d05da5cb19f401139eb08a54c
Signed-off-by: houst0nn <houstonn@gmail.com>
Launch floating notifications from notification panel (long click)

 * Status bar - long click on notification select 'floating mode' option

fix derp in floating notification launch

Notification long press fix

Conflicts:
	packages/SystemUI/res/menu/notification_popup_menu.xml
	packages/SystemUI/res/values/pa_strings.xml
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
Recents: Launch as Floating App

Ported from JB 4.3
Based on hybrid (Aaron) and Halo (Jesus) implementation

Signed-off-by: Alexis Rico <sferadev@gmail.com>
Change-Id: I84f4d3928af5c6ddd96a9a173a1c24e85ff606dd
Conflicts:
	packages/SystemUI/res/values-ca/pa_strings.xml
	packages/SystemUI/res/values-es/pa_strings.xml
	packages/SystemUI/res/values/pa_strings.xml
Fix for launch app in floating mode from recents

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

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

Change-Id: Ib32e2c88033b1c143bd8dc8fa7394b002060d526

Conflicts:
	core/java/android/provider/Settings.java
	packages/SystemUI/res/values-de/pa_strings.xml
	packages/SystemUI/res/values/pa_strings.xml
	packages/SystemUI/src/com/android/systemui/recent/RecentsPanelView.java
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
SystemUI: Swipe to float for notifications and recents (Part3)
Misc. fixes to make it compile with my source.