The input method manager service now keeps track of whether or not
the ime was shown on the keyguard. This prevents activities behind
the keyguard from incorrectly showing the down-caret in the keyguard.
Bug:7498792
Change-Id: I0de01ec29cb544e902305b0f9d9fb94a73835e7b
The logic here was backwards, causing the (softer) fallback vibe
pattern to be applied if the notification specified a sound
(or DEFAULT_SOUND) and also DEFAULT_VIBRATE. The fallback
vibe should only play if you have *no* vibration set.
Bug: 7588655
Change-Id: Iecdd362729bccedf779b51cc9b90a12014328aff
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use same
vibration pattern but can be changed easily in future.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
Creating new surfaces for applications clears the allDrawn flag in the
AppWindowToken. If the app windows were animating when this happened
the animation would complete immediately resulting in jank. This fix
defers clearing allDrawn until the animation completes.
Bug 7326635 fixed.
Change-Id: I5abe3b9ecfbefb476de6a6c8acc394373cc11751
When a DeviceAdmin requests a device wipe due to a number of incorrect
password attempts, only primary user can wipe the device. Secondary users
can only remove themselves from the device.
Bug: 7554445
Change-Id: I24331cb4eff37571fcd792abb2efc794f7b3f2d2
When the ServerThread handles ACTION_SHUTDOWN intent it sometimes get
stuck on mStatsLock in NetworkStatsService.java.
0 com.android.server.net.NetworkStatsService$5.onReceive()
1 android.app.LoadedApk$ReceiverDispatcher$Args.run()
2 android.os.Handler.handleCallback()
3 android.os.Handler.dispatchMessage()
4 android.os.Looper.loop()
5 com.android.server.ServerThread.run()
This happens when the NetworkStats thread is already holding the
mStatsLock while updating NTP.
0 libcore.io.Posix.getaddrinfo()
1 libcore.io.ForwardingOs.getaddrinfo()
2 java.net.InetAddress.lookupHostByName()
3 java.net.InetAddress.getAllByNameImpl()
4 java.net.InetAddress.getByName()
5 android.net.SntpClient.requestTime()
6 android.util.NtpTrustedTime.forceRefresh()
7 com.android.server.net.NetworkStatsService.performPoll()
8 com.android.server.net.NetworkStatsService.access$100()
9 com.android.server.net.NetworkStatsService$2.onReceive()
10 android.app.LoadedApk$ReceiverDispatcher$Args.run()
11 android.os.Handler.handleCallback()
12 android.os.Handler.dispatchMessage()
13 android.os.Looper.loop()
14 android.os.HandlerThread.run()
Since the NTP update consists of several socket operations it may get
stuck long enough to trigger a System Server Watchdog even though the
socket timeout is set to 20 second.
Further, the NTP update doesn't actually need to be performed inside
the locks and an attempt to change this was made earlier, but the code
wasn't actually moved outside the locks.
Change-Id: Ib37a2b8c2d51a01adb7ff01764f82309433703f0
Turning off animations in the Developer options creates a ValueAnimator
duration scale of 0. This is used as the denominator in RampAnimator
which, if the numerator is also 0, sets mAnimatedValue to NaN. Rounding
NaN to the nearest int produces 0 which is then assigned to
mScreenBrightness in DisplayPowerState.
A copy mistake which assigned mTransitionAnimationScale as the default
value for mAnimatorDurationScale in WindowManagerService is also
fixed here.
Bug 7515609 fixed.
Change-Id: I39f8d0a7abdd5a1fe70d757fe95fbddaf7a0ed51
