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 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
The root cause is we can't unbind blue service when bluetooth isnot disbaled
Otherwise the bluedroid stack will be out of sync with bluetooth service
only unbind bluetoothservice, when bluetooth is at OFF state.
bug 7376846
Change-Id: If5a11926f77a1ac29e75cdddbf5e90d492179f43
Rely on behavior of already-released CountDownLatch instead of
clearing the reference.
Bug: 7290521
Change-Id: I787e673b97d18be412d5b37e279fbf1275b49151
(This relates to the new vibration fallback behavior, where
notifications that expect to make a sound should always
vibrate in vibrate mode. We should not vibrate if the
notification's sound is silent, but we should also not
vibrate if the notification uses the default sound and the
default is silent.)
Bug: 7537077
Change-Id: I08e149c8c00ef2d2f61e418d88a086cb5e9cf241
- 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 a different
vibration pattern.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
LocationManagerService was serially stuffing the same Location into
multiple Intents, which it would immediately hand off to
ActivityManagerService, running as a different thread in the same
process. LocationManager would continue to work with that Location
while ActivityManagerService worked with a Parceled version of it.
However, Location.mExtras is also a Bundle, and both
ActivityManagerService and LocationManagerService ended up working
with references to the same Bundle. ActivityManagerService needs
it in Parceled form (ie mParceledData != null), but
LocationManagerService was triggering Bundle.unparcel() when
referencing the data contained within.
As a result, LocationManagerService was able to trigger NPE (or
worse) in ActivityManagerService by manipulating the mExtras
member of a Location that was in the process of being reported to
listeners.
To resolve this issue, I copy-construct a new Location to report to
each listener. This should prevent ActivityManagerService and
LocationManagerService from referencing the same Bundle data, as
Location's copy constructor also copyconstructs the mExtras member,
rather than simply share references.
Bug: 7518371
Change-Id: I1a92615cba361831494447d5de085a8d910b6b2c
the root cause is the A2dp and Pbap service need receive STATE_TURNING_OFF intent
to shutdown cleanly. So we need send completely state transition intents
in user switch handler.
bug7403171
Change-Id: Ic92bc85c2b74ae7c95440b237ea8851771ee9f04