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
AudioService relies on a valid mmc in order to enforce the headset
volume limitation or not. There is a timeout to enforce the limitation
if no mcc is configured after boot.
Until this timeout is reached or a valid SIM is detected the headset
volume is not limited.
This change makes that the last known volume limitation state (enforced or
not) is persisted so that next time we boot, last known state is applied until
a new mcc is configured if any. In most cases, the mcc does not change from one
boot to the next and we do the right thing. If teh mcc does change, the correct
policy will be enforced when the mcc is detected or after the timeout.
Also fix a bug where the volume panel was not displayed if the limitation mechanism
is triggered at the first press on VOL+ key.
Bug 7455275.
Change-Id: Id0f2996d893d38c6a14f4f9e4a0e9e3be17ef127
...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
The button was already hidden, but there are lots of other
ways to get into QS that should check for USER_SETUP.
Bug: 7638795
Change-Id: Ib6c48fc02e833670768e7dc76e25c38097b88c18
At least one of these was getting spoofed in the wild.
We don't want to go too far this late in the game, but this is a good start.
bug:7622253
(cherry picked from commit 47918ae3b4e7ebb54711884e9ff9d0300591ab8b)
Conflicts:
core/res/AndroidManifest.xml
Change-Id: I118b31489fe7add5b8d69289cab9f4e8ab269495
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
If there's a charge problem (battery health/temperature out
of spec, or low charging current), the lockscreen and status
bar should not indicate that charging is occurring.
(Previously we showed "Charging" and a lightning bolt any
time the device was plugged in.)
Bug: 7509976
Change-Id: I27ec0e2cec1307fbc6ef262dd5181a4db6d3bed0
