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
- In PWM, make sure to read the height values after the new
configuration has been applied.
- Reset all navigation bar button icons when density changes.
- Adjust height of notification bar.
- Reload divider height values in SysUI and WM.
- Snap divider handle to a new position after loading the
new configuration, as the snap points change.
Bug: 26844819
Bug: 27450471
Bug: 27921696
Change-Id: I9e28f0c49f6367c5fcfac010e7a6e98a42e85996
When calculating the frame for non-fullscreen windows, we incorrectly
used the wrong bounds to calculate the frame, which lead to wrong
positioning.
To fix this, we use the inset bounds, which we consider the source
of truth for all layout related aspects, to calculate the frame,
and then offset everything by the difference between the inset bounds
and the task bounds to position them correctly.
Bug: 28012565
Bug: 27860956
Bug: 27441808
Change-Id: I90d45054e0bcce78d021ad2cd20e5ef7f79ded3d
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
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
Since Lollipop, routes are isolated within Networks. Flushing a
Network's DNS cache whenever that same Network's routes are updated
doesn't provide any benefit. Any system components depending on this
behaviour need to uncovered and fixed.
Additionally, clean up no-longer-used flushNetworkDnsCache(). This
should be replaced, when needed, by a proper binder interface to netd.
Change-Id: I34bf79e4839da014d466058a876d754209d0c007
Set up a none transition for the relaunching apps, and add them
to mOpeningApps so that display unfreeze wait for these apps to draw.
bug: 27834014
Change-Id: Id8f98c8160bdb92e93fbf948fde1d3bfece4eaa9
...for monitoring content providers
- Improve media provider change reporting so that observers can
avoid spurious reports of the top-level content directory changing.
- Fix a bug where collected content changes while a job was running
were not being properly propagated to the next job.
Change-Id: I29e3c2960e6fec75b16ee3ee6588d47342bf8c75
If we do this, we will fail to adjust the proper IME target
to make it visible. Accomplish relative ordering of IME and
Docked Divider in WindowLayersController instead.
We need to take care that adjustSpecialWindows won't push windows
down if they are already positioned above the highest application
layer. We also take care to not adjust the IME if the docked divider
isn't really visible.
Bug: 26387930
Change-Id: I26ca36c4f7ecf9d97f44e15c67df82b8154a169c
Visible apps could have sub levels within the visible category.
Scores between 101 and 199 should be attributed to visible
category instead of perceptible.
bug: 27987575
Change-Id: I2dbe8af65e6829bafc86ffb5222a5f1aeac2d8b4
This means a rotation is started while we have a transition pending,
and startFreezingDisplayLocked() called mAppTransition.freeze() to
cancel the transition by setting it to TRANSIT_UNSET but ready
immediately. Screen unfreeze will wait for mOpeningApps to empty.
handleAppTransitionReadyLocked() will remove the app from
mOpeningApps once it's drawn, and allow screen to unfreeze.
We don't add the app to mOpeningApps if the transition is neither
set nor ready. We don't have any transtition and the app won't be
removed from mOpeningApps.
bug: 27784481
bug: 27391256
Change-Id: Id2c0759732593121769c402ae0c6edde3ebc7dc6
This reverts commit ebe9c0dbebbd8c2a23a76ff827b90e66ce3813bf [1],
because it caused a regression that IME window becomes transparent on
the lock screen (Bug 28013209).
[1]: I7d406cc88aae40a8b22c1fc1d856ccb7b6bb4558
Bug: 26387930
Bug: 28013209
Change-Id: I11243703030e34b917136b69a35245e9ef73c87c
Seems that there are two mutually exclusive requests about how IME
switcher visibility should be controlled.
A. Requests like Bug 19496012. We should show the IME switcher
as a quick access to "Show input method" setting when a physical
keyboard is attached via wireless connections that do not have
clear connection/disconnection affordance (e.g. Bluetooth
keyboards).
B. Requests like Bug 25432652. We should not have a rule like A
when a physical keyboard is attached with clear
connection/disconnection affordance (e.g. USB wired keyboards,
2-in-1 convertible tables w/ magnetic contacts).
Currently satisfying both requests at the same time is really difficult
because InputDevice does not have such an attribute. Even with such an
attribute, it's still an open question about how to deal with two or
more keyboards. As a short term solution, this CL add an overlayable
config so that each device can configure which strategy to apply as the
default behavior.
Bug: 26245853
Change-Id: Id2aef6597916422ea63435ae9c31a9a9b5ddf5b8
