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
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
If we do not call untether, NetworkController will still think
that wlan0 is part of the LOCAL network, and thus any attempt to
use wlan0 for anything else is doomed to fail.
Bug: 27917299
Change-Id: Ibb63f6b477b85b92281d9667adf8af148deb266c
Previously, if frame extended beyond screen, override inset was set
to zero for corresponding dimension. This caused issues while dragging
down in vertical split-screen because navigation bar inset was not
included.
This CL sets override inset value as a difference between corresponding
content area dimension and screen dimension.
Bug: 27970692
Change-Id: I5bd16077a7deb039516bc9e11aa58315f809455a
When passing tempTaskBounds != null but tempInsetBounds == null,
we ended up using the stack bounds to calculate the insets, which
is really wrong. First fallback onto tempTaskBounds, and then the
stack bounds.
Bug: 27887505
Change-Id: I66ee0da1415a67af824f4c63b56644d590728813
This is to make it easier to test on debuggable builds. Debuggable
platform builds trade off being as close as possible in behavior to
non-debuggable builds and being more testable/debuggable. Thus,
debuggable platform builds make no security guarantees and it is thus
acceptable to disable this security mechanism on debuggable platform
builds to help with development/testing/QA.
Bug: 27327503
Change-Id: I19340b95f08c57ff2aba59a08babb6a941c93c3a
