[1/3] Subtle Vibration when outgoing call is connected

Other parts of these patches are on packages/services/Telephony & packages/apps/InCallUI repos

Change-Id: I5b4ba3db4e5d0507058a6be53e5ee722a6bd72c6
AudioService: fix cross deadlock in VolumeStreamState

Synchronize modifications of volume index by VolumeStreamState
class mutex instead of using synchronized methods.
This avoids possible cross deadlock when modifying volume on
two stream types simultaneously and one is slave to the other.

Bug: 13730145.

https://android-review.googlesource.com/#/c/94255/

Change-Id: I13406c71010ce0c2e2f08f660b6101f310396c98
Signed-off-by: houst0nn <houstonn@gmail.com>
Check for null in LocalSocketImpl.SocketInputStream.available()

Calling available() on a local socket after close() will cause a native
crash. Other methods that pass LocalSocketImpl.fd to native code copy
the fd and check for null.

https://android-review.googlesource.com/#/c/90900/

Change-Id: I2d0b573f34ae47a23009760bbb1c02933ab0a20e
Signed-off-by: houst0nn <houstonn@gmail.com>
Activity chooser "Always" button is not working

When ResolverActivity is created with a custom list of matching
applications (rList) as in NFC case, and the alwaysUseOption is
set to true, the prferredActivity is not saved even if the user
presses the "always" button.

When a list is provided the variable mBaseResolveList will be
!= null. This will set mOrigResolveList = null.

When an activity is choosen and one of the buttons are pressed
onIntentSelected is called. The first thing this method does
is to check mAdapter.mOrigResolveList != null, however in this
case mOrigResolveList is always null, and the value is not
saved as PreferredActivity.

This problem was introduced in
6d8dfbd8149942f25f2b9643a12f1fb38f3be834.

https://android-review.googlesource.com/#/c/95336/

Change-Id: I9eac41b7861b5e68ad3978af0dc0285f2a34eb88
Signed-off-by: houst0nn <houstonn@gmail.com>
Minor cleanup of UsageStatsService

code cleanup, whitespaces

https://android-review.googlesource.com/#/c/92738/

Change-Id: Idea0e29f347d14e48e87aad38a261d0493bd5fd3
Signed-off-by: houst0nn <houstonn@gmail.com>
Automatic Translation Import

Change-Id: I19aacae3c150690f64d414f002aa3b529bb5621d
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
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
Fix a NPE when putting a null-Bundle in an Intent

Happens frequently e.g. with GoogleAccountAuthenticator

Change-Id: I284bf153f40ee9cc3e70bce6efcc3b9e6706361b
Fix null pointer exception in PhoneWindowManager

mKeyguardDelegate is null and is causing fatal exception

Change-Id: Iae14b969b7ff9ab0003e615f2f82eaac65a77985
Keydispatching timeout while finish Activity

If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.

Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
Fix to NullPointerException on move back in ActivityStack.

In ActivityTask.moveTaskToBackLocked NullPointerException may occur
when moving back with only current Activity in stack. This due to a
condition that may trigger despite a TaskRecord being null and then
attempt accessing the TaskRecord.mOnTopOfHome variable.

TaskRecord task may be set to null when no resumed activity remain.

Resolved by assuring that flag mOnTopOfHome is instead set to false
for current TaskRecord in case where there are no remaining activities
above home.

The above bug has already been corrected in the following commit,
ada62fca51d314cefe2c5da4e007df5b9abf320d, but it does not set the
cottect value to mTopOfHome for the current taks, see below.

Variable mOnTopOfHome will not be set to false in situations where
stack is of size 1 or less and task is null, perhaps from already
having finished current activity.

To avoid current TaskRecord maintaining value mOnTopOfHome to true
after launching Home this variable is set to false.

Impact should not be major due to correction earlier that makes sure
that there is always a TaskRecord.mOnTopOfHome set to true above Home
activity but if not correctly set for current task still gives a
possibility of bad behavior.

Change-Id: Ie86ad99c188aaa05b0de9d58eaa16c42b6fc4341
Fix fatal exception due to missing looper for current thread.

While creating handler for the thread, there was fatal exception getting
thrown because the present thread does not have a looper. So passing the
applications looper to be used , while creating the handler to avoid this
exception.

Change-Id: Id2e3ed61f5691c8319eb7bc20ad970eb6758e765
(cherry picked from commit f5d1769b4357fb8d86fc31f7115b55b567a20ed1)
(cherry picked from commit d0a7c5833b90fe4d8fe8f968b53a7028720ffd8c)
WifiState: Don't aquire transitionwakelock in airplane mode

NetworkTransitionWakelock is for transition from Wifi to mobile.
It will cause device no sleep for 60s. There is no need to acquire
it in airplane mode.

Change-Id: I1487dc4787948d09e482f22e88d01768b54964da
PIE: Use case upgrade and bugfixes:

1.Play with navigation bar height instead of view state. Just set navbar height to 0, even because
  swipe gesture is disabled aswell so it will never be called. This way we handle just one var
  that is height. PhoneWindowManager will take care to calculate decors since it uses height (width
  in landscape) as a param in the calculation.
2.Remove dependency from last systemui flags. Right now before this patch, pie showed no matter if you
  were in forced or native immersive mode. That made us bring a couple of hacks to keep this marriage,
  but there is no need in the end cause PIE is an alternative way you have to enable. That means apps will (should)
  use their own immersive mode at first unless you have already PIE mode on. Not all apps hide navigation bar,
  that means they can not cover the entire screen height (portrait). That's why there is forced mode, to supply this
  cause force the app to go immersive. Last but more important, immersive API works again now :)
3.Cleanup some vars not used anymore, just need observing main immersive mode now.

Change-Id: Ia17bb7ede36d5a14c8508841e32910e6e9595310
Signed-off-by: Carlo Savignano <stevewatersy@gmail.com>
SystemUI: Add EdgeGesture service.

Based on code of PieService.

Change-Id: I5c66e2858c8ddbe9faa0e0640c50714c8d1d5e29
SystemUI: Use EdgeGesture service to trigger Pie

EdgeGesture service triggers Pie when detecting gestures on
the WHOLE edge, not just the center.

Patch Set 2: Better trigger values

Change-Id: Id7d9d7f6f5a37ca3696cdddf0da78c88c067970e
SystemUI: Position Pie at gesture's triggered position

As the EdgeGesture service is triggered at the whole screen
edge, place Pie at the gesture's triggered position, instead
of always positioning it at the center of the edge.

This might be controversial and a matter of taste, but in
particular on tablets it's sometimes hard to hit the exact
center of the edge and therefore gestures often fail. Could
also imagine enabling this feature on tablets only. Needs
some discussion...

Change-Id: Ife28ac434667148583b34bcccd11262c111b5a67
PhoneWindowManager: add ability to use EdgeGestureService for system gestures.

Update: Default to enabled

Change-Id: Id4e2c0d82f771cd1c20e9196fb6db347494cca69
PhoneWindowManager: EdgeGestureService: We don't have left navigation bar

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