fix search textfield

Change-Id: I1255434e1e42973afd8d9907459dcd8795e96c4b

Conflicts:
	core/res/res/drawable-hdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-hdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-hdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-hdpi/textfield_search_selected_holo_light.9.png
	core/res/res/drawable-mdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-mdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-mdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-mdpi/textfield_search_selected_holo_light.9.png
	core/res/res/drawable-xhdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-xhdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-xhdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-xhdpi/textfield_search_selected_holo_light.9.png
	core/res/res/drawable-xxhdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-xxhdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-xxhdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-xxhdpi/textfield_search_selected_holo_light.9.png
fix search textfield

Change-Id: I1255434e1e42973afd8d9907459dcd8795e96c4b

Conflicts:
	core/res/res/drawable-hdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-hdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-hdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-hdpi/textfield_search_selected_holo_light.9.png
	core/res/res/drawable-mdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-mdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-mdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-mdpi/textfield_search_selected_holo_light.9.png
	core/res/res/drawable-xhdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-xhdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-xhdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-xhdpi/textfield_search_selected_holo_light.9.png
	core/res/res/drawable-xxhdpi/textfield_search_right_selected_holo_dark.9.png
	core/res/res/drawable-xxhdpi/textfield_search_right_selected_holo_light.9.png
	core/res/res/drawable-xxhdpi/textfield_search_selected_holo_dark.9.png
	core/res/res/drawable-xxhdpi/textfield_search_selected_holo_light.9.png
fix number picker blue line and highlight

Change-Id: I473c855a0e2cd068e62cd2ec4b807c04215b1c81

Conflicts:
	core/res/res/values/colors.xml
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

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/policy/KeyButtonView.java
SystemUI: Fix missing top task in recent panel.

If preloadRecentTasksList was not called or was called too
late and RecentsActivty already started and last top activity has
excludeFromRecents flag setted it might be missing
from recent application list.

Change-Id: Idf7153824805ceea9fcaf04ac645b73a5e93a4d9
fb: handle globalmenu in SlimActions not over Powerbutton anymore

We used till now a hacky workaround to show up the Power menu which worked
but is indeed not the best way. Last tweek on it broke 3rd party root application
which use similar hackish workaround.

Whatever make global menu over wm service available and call it from
SlimActions directly. This respects of course the usual security checks
if the device is provisioned etc

PS
- derp
PS
- puh I just should go sleeping :(

Change-Id: Ia12ce467cee0d60741079b3fa2c78449d707a09f

Conflicts:
	core/java/android/view/IWindowManager.aidl
	core/java/android/view/WindowManagerPolicy.java
fb: unbreak recents animations on thumbnail click or dismiss recents screen

We load now correctly the recents screen and preload the first task on press
down off any key to get always recents without issues up. We cancel only
if any other key was pressed. I discovered during I am working on new recents
that this solves all issues but has one downside that if he user dismiss he recents
screen or click on one of the thumbnails to bring the choosen app to forground
that of course the last thumbnail is not cleared. Due that the entry animation
and some other things depent on what is currently preloaded we need to cancel
first task to have always in all cases the right animation.

Fix it with just calling cancelPreloadingFirstTask() if the user either
clicked on one of the thumbnails or dismissed the recents screen.

PS
- do the same when all thubmnails are swiped away
PS
- derp

Change-Id: I786c05d929f6a02b6d4928fc4a96aeb9a8e2d03e
Appears black screen fix for a while

This issue is side-effect of added google patch on KK MR1.

Fix a couple of issues with mOpeningApps.
https://android.googlesource.com/platform/frameworks/base/+/a8ee262c04749db4f32f73d2b9e7f58989c4638b%5E%21/#F0

[Reproduce path]
Settings -> Location -> Location OFF -> Location ON -> "Location consent Dialog" Popup-> "Agree btn" press
-> Black screen appears for a while

Change-Id: I14efdce87e8d78d38f9aae48568f69937e4fe1fa
Perform NTP lookup at Mobile data connections

If NITZ isn't supported by the current carrier the Android framework
relies instead on a remote NTP server to set the system clock. The
NetworkTimeUpdateService class polls for NTP time during the first 4
minutes after boot, failing to get NTP time within these minutes will
increase the polling interval to 24 hours. Hence, if a data connection
isn't activated directly after boot it can take a long time for the
system clock to be updated. To prevent this situation, NTP lookup is
scheduled as soon as a Mobile data connection has been established.

Change-Id: I046e0330147e7ace4b720a7e70f9d5047d42cfe6
AssetManager cookies should be int32_t and not void*.

Cookies are really indices into vectors and arrays, so
they don't need to be void*. We choose int32_t instead
of size_t to allow their width to be well specified.

(cherry picked from commit ebfdd0f467e39c3af8d92cade78263935340acb7)
(cherry picked from commit a7fa2e592e2e579e5acdb903dba83fc074ebc215)
(cherry picked from commit a9d5701b034ed2d9771b3f0943e1add00741d7cd)

Change-Id: I2aed3db568b6fdc487bf99e2c5dd123206736fda

Conflicts:
	include/androidfw/AssetManager.h
	libs/androidfw/AssetManager.cpp
Fix dest == src bugs in Matrix.cpp.

The main bug was that the AutoJavaFloatArray autoSrc was not passing in
read only. This meant that the destructor overwrote the data which
the autoDst AutoJavaFloatArray had written in it's destructor.
This case only happened if src == dest and the arrays were copies.
Also improved performance by passing in read only a few other places.

Bug: 12570144

Change-Id: Idc8764087dc165433c584b87a0f9d4ed0ec795e8
Fixed race condition in Spinner.DialogPopup on null reference.

NullPointerException is triggered when DialogPopup is
dismissed due to object mPopup being null when not showing.
Race condition is triggered when dialog is dismissed before
touch event to dismiss dialog has been processed properly.

Fixed by adding a null check prior to accessing mPopup object.

Change-Id: I3c4fe9c279d92a7103fb4f68189d1d42beedc606
[ActivityManager]: Fix the activity visibility state not sync between ActivityManager and WindowManager

Symptom:
When press Home key to home screen, user is able to see the activity's window shown on top of wallpaper and below launcher(widgets).

Root Cause:
The ensureActivitiesVisibleLocked() is called pretty often (for example when a new process bound).
If the top activity "B" was finishing, then the previous activity "A" should be visible.
Therefore, the activity "A" window will be set to visible and then launched activity "A", but it does not updates the visible state in ActivityRecord for "A".
There has a timing issue that if a new activity "C" is started, "C" becomes the new top activity and be resumed.
In that case, Activity "A" window will remain visible even if it is behind a full screen activity "C" because the ActivityRecord.visble of "A" is still false, so the window visibility won't be update.
So when user press home key and back to launcher, the surface of activity "A" will be composed on top of wallpaper.

Solution:
Updates ActivityRecord.visible to true for "A". After "C" is started, the "A" will be called WindowManagerService.setAppVisibility() to set invisible, then called onStop() when execute ensureActivitiesVisibleLocked() again.

Change-Id: I536ba04b95d8d274fea6d679a6493e620bc981e2
GpsLocationProvider: look for config file in /etc/gps.<ro.hardware.gps>.conf

The property ro.hardware.gps can be specifid to allow a single system
image to work with differrent GPS chips.  The HAL layer will use it to load
/system/lib/hw/gps.<ro.hardware.gps>.so.  Add support to GpsLocationProvider
to use the same property to find /etc/gps.<ro.hardware.gps>.conf, falling
back to /etc/gps.conf if the property is not set or the file is not present.

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

Change-Id: Ib962b2cd62c991fe4d6f3b6b27b5d97c9ec653b0

Conflicts:
	core/java/com/android/internal/util/slim/ImageHelper.java
	packages/SystemUI/src/com/android/systemui/SearchPanelView.java
	packages/SystemUI/src/com/android/systemui/recent/Recents.java
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java
	packages/SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java
	policy/src/com/android/internal/policy/impl/PhoneWindowManager.java
clean up commits