Update Roboto fonts to Android L versions

Change-Id: I541694b159e32bb90c1889e894c4352e43f3ce40
StatusHeader: night begins two hours earlier, at least its dark outside

Change-Id: Ic044b26f7820828c11c5a3baa2ad22269c8dac02
Don't unnecessarily set LayoutParams on children

Setting LayoutParams on children triggers requestLayout
which can be expensive and result in significantly lower
framerate for children layouts that don't need it. When
requestLayout method is invoked the needToMeasure boolean
will be true, this is what we'd like to avoid unless
it is actually needed.

BUG: https://code.google.com/p/android/issues/detail?id=72733

Change-Id: Id5d8f3431b5f943b1279eae41ee43d32a99514fc
Signed-off-by: Jacob Abrams <satur9nine@gmail.com>
Bye Bye Holo Blue Light

Change-Id: I2c2029dd4bedf8d733fd862f00445d8bfe8c9acf
Revert "base: Volume button wake: simplify logic"

This reverts commit e7da4e5d3a43f06fa14e37247f105a3850c11f8f.
Revert "listview: ensure active views are filled prior than scrap views"

This reverts commit 949778342a92979122ebba273dbf004422142f9b.
Make sure we clean up

pruneDeadThumbnailFile need to close its cursor
in a finally block to avoid leak resouces.

Change-Id: I2646b91970e47ee80a721a2452215b7cae149d10
MountService: Check for null pointer when looking for vold code

* There is actually no code path that will set an event into
  NativeDaemonConnectorException, so any reference to the event code
  will result in a null pointer exception, taking down MountService and
  the rest of the system with it.

Change-Id: Id62f724953aacc363b3455584c6a3ad1381c6138
Fix NullPointerException in ListView

There is a NullPointerException in `handleHorizontalFocusWithinListItem()`
because `selectedView.findFocus()` returns null and then there is no null
check when when the assigned variable `currentFocus` is used, although
`View.findFocus()` states that it may return null.

Change-Id: I6897027e9a2a238d9283e6b9f5146198989fcac0
Fix PreferenceActivity's isMultiPane on single-pane screens

isMultiPane returns true incorrectly on single-pane screens when under a
preference header.

Change-Id: Ic17e939c257ea4c8db02e69bb961432e9deb0d39
fix wrong transparent computation when background is transparent

1. when a view is set to be WILL_NOT_DRAW, it would check if the background is
null or not, to change mPrivateFlags follow rules:
    a) background is null, add the flag PFLAG_SKIP_DRAW
    b) background is valid, remove PFLAG_SKIP_DRAW and add PFLAG_ONLY_DRAWS_BACKGROUND
so when flag has PFLAG_ONLY_DRAWS_BACKGROUND, it must exclude PFLAG_SKIP_DRAW.

For transparent region computation, the function gatherTransparentRegion check
"non-PFLAG_SKIP_DRAW" case firstly, but it's wrong for PFLAG_ONLY_DRAWS_BACKGROUND
case,since it always has no PFLAG_SKIP_DRAW, it will always match the "if" part and
never go to the "else if" part, and always be taken as a non-transparent region
without checking background properties, which is wrong behavior.

So check PFLAG_SKIP_DRAW and PFLAG_ONLY_DRAWS_BACKGROUND here at the same time to
get the correct transparent computation.

2. In applyDrawableToTransparentRegion, getTransparentRegion of Drawable returns null
sometimes if subclass not implemented, so add opacity check here to make sure get the
correct transparent region.

3. Visibility change can also influence transparent region computation, so request
layout here to make sure the correct result.

Change-Id: I0978e022add002b94541b14c149ec8990e728ac7
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Reviewed-on: http://android.intel.com:8080/130698
Reviewed-by: Yao, Yong <yong.yao@intel.com>
Tested-by: Chen, HuaqiangX <huaqiangx.chen@intel.com>
Signed-off-by: Jian Luo <jian.luo@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 120472
PorterDuff Mode comment is inconsistent for SRC_OVER, DST_OVER

I removed Rc.

Change-Id: If3aae9b6e5612358ec7308e633ee91239e3f2af2
Signed-off-by: NoraBora <noranbora@gmail.com>
Fix Swipe to Notification
App sidebar: fix icon label

Before : https://drive.google.com/file/d/0B6HSD0BaBeKoNnVPUGFhZmVqVUE/edit?usp=sharing
After : https://drive.google.com/file/d/0B6HSD0BaBeKoUDJrTGUtNFRuMzQ/edit?usp=sharing

don't cherry-pick this if you don't have any problem.

Change-Id: Iafcfad21c1c4345986f9648c3909296b842a3768
Hover: exclude from insecure lockscreen (1/2)

Enable/disable hover notifications from insecure lockscreen

Change-Id: I9235d8dac32359dff692f6f9c821c715fefe9cde

Conflicts:
	packages/SystemUI/src/com/android/systemui/statusbar/notification/Hover.java
Framework: Rewrite Quiet Hours (2/3)

Added:
	New Toggle States.
		Toggle is now aware
		of if quiet hours
		is truly enabled or not.
		Enable "force" mode
		on click: turns quiet hours
		on / off
		Double-click to return
		to "timed" mode.

	New Features:
		Wifi Connected Requirement
		Battery Charging Requirement
		Individual day times

        Completely rewrote quiet hours
                to reduce system calls.
                No more calendar objects
                or checking three preferences
                and comparing their values
                on each quiet hours check.
                Reduce that to ONE preference
                check per preference

PS2: Ensure booted before firing intent

Change-Id: I61ef5afa32c5ff883129b9362423af7f724c5ac1

Conflicts:
	core/java/android/provider/Settings.java
	services/java/com/android/server/BatteryService.java
	services/java/com/android/server/NotificationManagerService.java
ActiveDisplay : update with Slim QuietHours rewrite
Allow subclasses to override bindPreferences().

Allows them to modify adapter behaviour.

Change-Id: I6767e3988740b674fbdf40a903cd2ef3949ca7db
Listview: check if we need to animate it, else skip processing

Change-Id: Ie3db4f945263746e748b404c45880a82d93ad2e2
Port : 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/ActivityManagerNative.java
	core/java/android/app/IActivityManager.java
	core/java/android/provider/Settings.java
	packages/SystemUI/AndroidManifest.xml
	packages/SystemUI/src/com/android/systemui/ExpandHelper.java
	packages/SystemUI/src/com/android/systemui/SwipeHelper.java
	packages/SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.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/pm/Settings.java