fb: correct power menu navring icon

had a small jump in it when activated

Change-Id: Ibfb3fc1dbdc6b4d95f366df85dea0d2dfa6f404c
fb: fetch navbar glow color from color.xml

better for new theming engine which will come in future

and now I will start doing again usefull patches lol. Just
needed to do something other.

Change-Id: I35dde45e47c59a2407c191d0077f0adb91f32381
Fix: external storage problem NavRing and NavBar applications

If the user binds an app which is located on the
external sdcard and is rebooting the button icon
will be left blank because the navring/navbar is already
constructed before the sdcard is mounted. To avoid
this we listen to the app available intents.
If it is not available the ring target/navbar button shows the none icon.
 When available it shows the
correct app icon. So that the user can clearly see
this app is accessable or not. As well when the
user goes into mass storage mode or does
unmount the sdcard or whatever case could
happen that the application is not there.

Reference:
https://review.slimroms.net:8443/#/c/12364/
https://review.slimroms.net:8443/#/c/12363/

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

Change-Id: Ib5ee29f1b30cff50d4c64f059259666a7618c090
fb: color system icons on navring like the other by default

otherwise it does not fit with the default rin targets

Conflicts:
	packages/SystemUI/src/com/android/systemui/SearchPanelView.java

Change-Id: Ief15a39b30517bb182bdb7d33cb9d87a8f0ecbad
fb: allow navring to show without assisten application

this commit adresses two problems

1. If the user does not install google now eg the navring does not
show up anymore even when other targets are assigned. Due that we moved
the disable/enable controll completley into searchpanelview which
calls DelegateHelper to disable it we just can remove the check
here in BaseStatusbar

2. On camera widget the navring is disabled and gets enabled afterwards.
This is of course a problem if we do not have targets assigned at all.
To fix it check for existend targets on the navigation ring

Change-Id: I1aa83fc8274995d9c1e9b88c76977977589502a6
fb: cleanup and let the navring stay and not

dimiss on targetchange....user seems to like it more
this way.

Change-Id: I73b36ef7a09dc08615fef522a8913a53b27b4763
fb: enable navbar for hw key devices

we moved this part into PhoneWindowManager which controlls the navbar.
Due that we allow on all devices a navbar the check on PhoneStatusBar
is not needed and prevend the navbar on comming up on hw key devices

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

Change-Id: I836fde1476caff1ca527299b2dacd260928db197
Upstream updates from AOSP relevant for Slim navbar

Change-Id: Ia8e62c154f5cc64fada5eead8b76c9bdc7d8d5d7
fb: slightly adjust navigationring background drawable size

for custom icons to fit the system icons

Conflicts:
	packages/SystemUI/src/com/android/systemui/SearchPanelView.java

Change-Id: Ieb4bbb6f2378a18bd03d95761b6f871fd950d1df
fb: navigationbar use always slimactions and add contentdescription

No need to use the AOSP implementation at all...we can send all actions
over SlimActions....so remove AOSP implementation and clean up

As well add contentdescription for accessibility events like talkback
for ppl who are not able to see. Gives the user all information back
needed.

Change-Id: I8f82f1139f1248d9cf8e762d6669bb75ae4e205f
fb: small cleanup and fixes in navbar transitions

this commit fixes several things

- cleanup: no need to go every time trough all calculations if back
button is not present

- force to set alpha value for backbutton on disableflag
changes (merge derp from 4.4.1 merge)

- new introduced workaround from google to animate the altbackkey->backkey
on password lockscreen should not depend on home button view existence and
should only call for the respective disable flags which are always present
from the system. As well which is needed for our navbar call the animation
values from whatever button is existend which behaves like home (so all buttons
only recents and back button not)

whatever still to do if the user uses password as keyguard method
google introduced a workaround to give the altbackicon->backicon
same transition then all other icons....but this workaround is not
really good working and has off timings compared to the other buttons.
Will be fixed in a seperate patchset and should be submitted back to
google as well.

Change-Id: I2c3135b7eb3b87042b757c422f77ef9f5ed280a3
fb: add theme switch (TRDS) to navbar and navring

and show toast if a mode is running wich does not support
lightsensors

- rebase

Conflicts:
	core/java/com/android/internal/util/slim/SlimActions.java
	core/res/res/values/slim_strings.xml
	core/res/res/values/slim_symbols.xml
	packages/SystemUI/src/com/android/systemui/SearchPanelView.java

Change-Id: I171b0098d73090f76717b4180ab7989328b97382
fb: disable navigation bar camera button if widget carousel is enabled

Beside that the animation which starts when dragging the camera icon
to the left is broken if the user has enabled carousel animation like
tablets it does not feel natural even when we use the right animation for it.

So diable the camera button in this case and allow only swiping the camera widget on carousel mode

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

Change-Id: Iaf39a7874de4a47cac2adb20323efa3bcc54814c
fb: handle for our navigation bar recentspreload in the button

Recents screen is since some time wonky. With new hardwarekey rebinding
it showed now only more how wonky it is due that home button does not
cancel the preload always to keep the hwkey button logic alive.
As well a problem is that if you bind recents to whatever other navbar
button the preload takes no effect at all (is only binded from google to
the recent tagged view)

Whatever to solve this let the buttons itself decide dependend on the
action if a preload or cancelpreload is needed an peform the action.

This solves all the weird recent screen behaviours and we will need it for
the new recents screen which is in development as well

It looks a bit weird to aquire the statusbar service here for this but in the
button itself there are not much other alternatives. In theory we could set listeners
like google but instead to all buttons and fetch the action from there to decide but
this gives a problem to get if it was a longpress recents or a normal press recents.

So this way seems to be ok.

Change-Id: I9b3b08356f72840399eaabd0be8b0c3fdf09a4bd
fb: Handle navbar heights correct on dpi changes + more (1/2)

Till now we set the height in px in the settings. Which is a problem
especially on multiDPI roms like we are when the user afterwards changes
the dpi due that it isn't calculated correct anymore on the new dpi.

This commit does
- save the dp value in provider and calculate the real px in fb
- clean up the settings stuff for it + do it a bit nicer (only settings part
  where we do not set the value for the listview)
- as well this commit disables movable navbar for tablets (we may will enable
  it in future but it needs a lot more work to have it on tablets correct working)
- add Converter class for common methods we always use....till now only px->dp
  and dp->px method

Conflicts:
	core/java/com/android/internal/util/slim/ImageHelper.java
	packages/SystemUI/src/com/android/systemui/recent/Recents.java
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

Change-Id: If7911aed6711d6b0f0105799a8da9e73c820ad52
Frameworks: fix navbar and pie icons for tablets and RTL

well due that we use a completly other attempt then googles navbar we do not
need to rely on different sized icons for portrait and landscape. So just a square
icon fits our needs perfect (which is so or so everwhere in AOSP default to use square ones).

Whatever recents pie feature showed us that we still forgot to size the pictures for our tablets
and as well for RTL user.

So let us do it now to fix any resizing issues on navbar and or SlimPie

Change-Id: I5257b789a5450754a296141b0af63d2eacaa87c9