Remove Heads Up (1 of 2)

Squashed removal of heads up feature

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/QuickSettingsController.java
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/Notification.java
	core/java/android/provider/Settings.java
	core/res/res/values/slim_strings.xml
	packages/SystemUI/res/values/gummy_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/policy/HeadsUpNotificationView.java
	services/java/com/android/server/am/ActivityStack.java
	services/java/com/android/server/am/ActivityStackSupervisor.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
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
SystemUI: improve one finger notification expansion

Sometimes the quick settings ribbon would eat the initial ACTION_DOWN
setting mInitialTouchY in the expand helper, but we are clearly not in a
notification that we can expand here. So only set the initial y point if
we are inside the notification scrollview.

Change-Id: I628553ac15cc6b4ee3c682fe46bd1d96c6bc154d
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
fb: Show heads up at the bottom of the screen (1/2)

Due of user requests and indeed especially on hw key devices for a better
workflow we add an option to show heads up notifications on the bottom instead
of the top.

Animation we leave as is due that if it slide from the bottom into the screen it happens
to often that the user accidentaly interacts with it. If it comes from the top of the
container we add, the user has enough time to realize it. Sometimes a ms can make a big difference.

As well this commit fixes the wrong gap on the top if user boots up directly
into immersive mode.

PS:
- if IME keyboard is showing show the heads up on the top to do not disturb the typing.
PS:
- NPE if updatePosition is called to early from the system.

Change-Id: Iea7fbe466808531a9351cf4048570b8f56eb698e

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
fix build
SystemUI: Separate system bar BGs for themes

This commit separates the navigation bar background colors from the
status bar background colors which allows more modular theme-ability.
Backwards compatibility for the old system bar values is still
preserved, but the new values are to be prioritized.

Thanks to Arz Bhatia for the suggestion.

Change-Id: Ibe579d16ea35ca5bdcfe9f98143c3f91cd24900f

Conflicts:
	packages/SystemUI/res/values/cm_colors.xml
	packages/SystemUI/src/com/android/systemui/statusbar/phone/BarTransitions.java
Framework: Make the dialog divider color themeable

The holo blue color might not be suitable for some themes. This commit
swaps out the background of all titleDivider elements to use another
resource. This has no difference from the perspective of the user of a
"stock" build but this is huge for theme users.

Thanks to Arz Bhatia for the suggestion.

Change-Id: Icb917220accac3ad38770067120a7b1be894961a

Conflicts:
	core/res/res/layout/dialog_custom_title_holo.xml
	core/res/res/layout/dialog_title_holo.xml
	core/res/res/layout/dialog_title_icons_holo.xml

Conflicts:
	core/res/res/layout/alert_dialog_holo_dark.xml
SystemUI: Replace CompassTile RotateAnimation with tweening

Change-Id: I53b2155232122ae5dbed611db3865e0ffdbde37e
Move 3rd party wallpaper pickers to the front

This is a feature request from Steve so here you go!

Change-Id: Iac6a26c7b51752d65026a871712c3590caa926d9
Include default wallpaper in LockscreenWallpaperPickerActivity

Change-Id: I0e3d46688bdb257bc32e10d9255dfc4fbf7beb4c
Add navbar background preview to ThemesContract

Change-Id: Id3ed43c86649b1757fec7f3fc7dee2d2730258e2
Ensure to add Persistent Apps to LruProcess List on app restart

This change will ensure to add Persistent Apps to mLruProcesses
if not already present while restarting.Previously, on some
occasions, the process was not getting added to the list
resulting in SecurityException as this process was not found
in the mLruProcesses.

Change-Id: I26813a794e01aae316dffd3cf2bb38ab66ac69a9
Wifi: Fix 2 ip addresses issue

Invoking the function clearInterfaceAddresses to clear
the initial IP first when change the "IP Settings"
for the select AP.

Change-Id: I38f6614e66cc3cf8d84e03c19d2d4badb1b16108
CRs-Fixed: 683307
NetworkManagementService: Change exception type thrown on IPv6

Changed the exception type thrown from IllegalStateException to
RemoteException whenever the IPv6 tethering rules fail to apply. The
IllegalStateException is not caught by the caller causing the JVM
to crash. By throwing RemoteException, the caller will catch and
print and error message instead of crashing.

CRs-Fixed: 662171
Change-Id: I92fadd43479a330f09bb20f699a4b9852123ab68
Broadcast upstream interface change event independently for IPv4 & IPv6

On change in tethering upstream interface for IPV4 or IPV6 address,
broadcast an intent with the information viz iface name, ip address
type and update type(i.e add or delete).

Change-Id: I69339dc0cfe3ceb566eb1891e264ccfd07785b48
CRs-Fixed: 680728
Revert " Audio: SetForceUse config check in AudioService"

This reverts commit 0af88afe6dc16760b57afa74ca42e40fbe6ff9cf.

- During playback over BT using the Google Play Music app,
  if BT is disconnected through the app and playback is resumed,
  it continues over BT and not the speaker.
- The original commit forces playback to continue over BT
  although it is disconnected.
- Reverting the commit fixes this issue and the issue
  addressed by the commit is also not observed after reversion.

CRs-Fixed: 679301
Change-Id: Ic4d0f13615c696a12401f7a8a58651b88f31e99b
[View] Clear Hardware-Layers before system destroys HardwareRenderer​.

Symptom: Sometimes HardwareLayer display is corrupted.

Root Cause: In some cases, ViewRootImpl destroys HardwareRenderer​ without
clearing HardwareLayers in the view hirarchy. If the system trims memory fully
and kill the glContext at the same time, HardwareLayer may corrupt.

Solution: Clear Hardware-Layers before system destroys HardwareRenderer​.

Reproduce steps: Modify the cache's trim memory mechanism to make it easier to
trim fully, HardwareLayers implemented in app will easily be corrupted.
Modification of the cache is not required but make it easier to reproduce.

Change-Id: If57c802cdacf8dc37cbbcc199e74f9482834f981