There is this stupid fudge factor applied to window transformations
when doing a screen rotation animation. We need this when rotating,
but when not rotating it causes very visible artifacts. Historically
the non-rotation case only happened due to configuration changes, so
wasn't that big a deal. Now however that we use this when switching
users, it is more annoying. So get rid of it for such cases.
Change-Id: I6b343866c1bad9b16984b4a629917c2f1bb37b9e
...android.os.Parcel.nativeAppendFrom(Native Method)
The failing stack trace is:
11-20 20:29:04.365 19154 19170 E AndroidRuntime: java.lang.IllegalArgumentException
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.nativeAppendFrom(Native Method)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.appendFrom(Parcel.java:428)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1613)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.location.Location.writeToParcel(Location.java:903)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeParcelable(Parcel.java:1254)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeValue(Parcel.java:1173)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeMapInternal(Parcel.java:591)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Bundle.writeToParcel(Bundle.java:1619)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.os.Parcel.writeBundle(Parcel.java:605)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.content.Intent.writeToParcel(Intent.java:6660)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:763)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:230)
11-20 20:29:04.365 19154 19170 E AndroidRuntime: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:777)
This is odd because where we do Bundle.writeToParcel(), we are just writing the Parcel
we have with its current length. There is no way this should be able to fail like this...
unless the Bundle is changed while we are running?
Hm.
It looks like the location manager is holding on to Location objects which have a
Bundle of extras. It is that Bundle of extras that the crash is happening on.
And the bundle extras can be changed as it operates. And there are places where
the raw Location object is returned from the location manager, which means the
caller can be olding on to a Location object whose extras can be changed at any
time by other threads in the location manager.
So that seem suspicious.
This change should take care of all these places in the location manager, by
making sure to copy the location object before it goes out of the location
manager.
In addition, add some code to the activity manager to not bring down the entire
system if there is a problem trying to send one of these broadcasts. There is
no need, we can just skip the broadcast as bad.
Change-Id: I3043c1e06f9d2931a367f831b6a970d71b0d0621
Bug b/7638530 may be caused by a kernel deadlock when killing
processes under low memory conditions. Write to /proc/sysrq-trigger
to get a kernel log of blocked tasks before killing the system server.
Bug: 7638530
Change-Id: I60df324ad4affdadbf13650099dc4dfb38722420
The NFC process used to be only running as user 0,
and it may be calling into Bluetooth. Most of the
handover code has now moved to a separate process
running as the current user.
Fix the existing checks to take into account the
correct NFC UID, whatever user it is running as.
Bug: 7309141
Change-Id: I953cfb263a28aef7fe1be5880b053425dc359a29
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
This does some cleanup of the initial boot, especially when
booting in "no core apps" mode for encryption/decryption.
Change-Id: Ifb3949f580e52f54559e603c4b0b104f6bac2f6c
Also fix a little problem where the USER_STARTED broadcasts
were not being sent as ordered broadcasts(!).
Change-Id: I3aa3e0a9b3900967cdd2d115ee103371b0a50c41
- If a window was hidden while the configuration changed and then
changed back WindowManagerService would not know that the change
had ever happened and wouldn't notify the window of this. Most
windows wouldn't care but because Keyguard inflates layouts while
it is hidden...
Bug 7094175 fixed?
Bug 7501099 fixed!
Change-Id: If27f5f1d333602dac7719dd39dbdf3fe7954aa06
In alarm manager, print a summary of the top 10 alarms by time
being executed. Keep track of execution time (and wake count) of
each type of alarm for each application so this can be printed in
the summary (and used to compute the top 10 alarms). Rework how
the alarm summary stats are tracked so that we don't need to hold
on to the full Intent for each stat and can get the Intent information
at the time the alarm is sent rather than waiting for whatever Intent
comes back in the result.
Also in the battery stats: sort the kernel wake locks by time, add
a new section showing all partial wake locks across all applications
sorted by time.
Finally a new LocalLog class that is used by AlarmManager to log
important warning messages, so these can also be later found in
its dumpsys output.
Change-Id: Icc07810053e60fb623a49937e696819cb8352b06
This will continue to crash as before, but will show some useful
information in the exception.
Bug: 7450247
Change-Id: Ib3160a5f64154517791d165973c12294ecd09901
ACQUIRE_CAUSES_WAKEUP is supposed to be ignored if combined with
PARTIAL_WAKE_LOCK. Instead it was being carried out for any values
of the WakeLock level.
This change reverts behavior to closely match
previous releases of the framework by only honoring
ACQUIRE_CAUSES_WAKEUP for screen wake lock levels. The only
difference being that in previous releases ACQUIRE_ could have been
combined with PROXIMITY_SCREEN_OFF_WAKE_LOCK (it never was) and
now such a combination will ignore the ACQUIRE_ flag.
Bug 7532258 fixed.
Change-Id: I46e848d8fd1b57e54c63141bf3d4f353986b5bdf
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
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
