Before this change, a PRE_BOOT_COMPLETED receiver could try calling
back into the system to ask for AccountManager details, only to be
told the user wasn't unlocked yet. If the broadcast code was probing
in a loop, it would force us to wait around for the 60-second ANR
timeout. Since typical devices have ~7 PRE_BOOT receivers, this
would delay BOOT_COMPLETED and other operations, like mounting the
SD card, for up to 7 minutes.
Bug: 28024024
Change-Id: Ibf8611e6fe94b0deb5ae5715c86f897ff6779088
* changes:
Remove the highlight on the overview button in the screen pinning dialog
Fixing bad regression in alt-tab layout.
Workaround to ensure that a SystemUI process is always available.
Tracing for cert collection in PackageManagerService was only
catching one of a couple usages. Move tracing lower in the
call stack to ensure tracing exists for all calls.
Also added a new tag to differentiate between verifying v1 & v2
signatures.
Bug: 27502465
Change-Id: Ie29f326e44f32cdbea1572714689c82f07ca12ba
Also, allow "productivity_mode" config to be enabled via intent extra
as a developement aide.
Bug: 28006206
Change-Id: I7be8d96a0e924f9ce8023347e051d28d69a0eec9
Use the lock from AccessibilityManagerService in
MagnificationController, since the two services call each other with
locks held.
Bug: 27725795
Change-Id: Iaed6749bf217210457325c3912da0f7aa0f6319a
We've seen evidence that the logcat binary can end up wedged, which
means we can eventually starve system_server for FDs. To mitigate
this, wrap logcat using the timeout utility to kill and clean up if
it takes too long to exit.
Bug: 27994717, 28021719, 28009200
Change-Id: Ieed1460d89598628a5db868645fd305d0e9054ed
Apparently we schedule ranking updates all the time, so the job gets pulled
to the end of the queue, and can get starved. This change makes sure we
don't schedule multiple updates by leaving it in the queue. If a job in the
queue behind hte update request needs to send an update it will jsut
request one anyway, so we shouldn't miss updates.
Bug: 28015158
Change-Id: Id5b9d05ea6eb35e610ee34651e4cde8cddd4ae66
Using an unresponsive app [while (true) { Thread.sleep(1000) }]
produces NPE:
WindowManager: Window Manager Crash
WindowManager: java.lang.NullPointerException: Attempt to read
from field 'android.view.IWindow
com.android.server.wm.WindowState.mClient' on a
null object reference
WindowManager: at com.android.server.wm.WindowManagerService
.requestAppKeyboardShortcuts
(WindowManagerService.java:10628)
Which puts down SysUI (and requires restarting SysUI).
Protect against this by checking for nulls. The end result
is that the dialog is no longer shown for unresponsive apps
and SysUI does not break.
Bug: 27914463
Change-Id: I37f0b0d5980f6ddc50f3bb778582d23ee1c7e9c3
