When the activity locally recreates itself, nothing
on the server side is able to prepare preserving windows,
or replacing windows. The activity was trying to defer
removing the old window, but it was just waiting
until the new one was created, not until it was drawn,
thus resulting in a flicker. It's easy to backpack on the
existing replacement infrastructure.
Bug: 28221875
Change-Id: I55fc4ca78e9e11809473fedd8b30b6a6350cf852
It's possible for a call to updateConfiguration() to happen in the middle
of performTraversals(), after the measure phase has happened, but before
the layout phase. During the configuration call, it's possible for views to
have requestLayout() called on them. This can result in the request flag
not getting cleared, because views that have had layout requested, but which
have not yet been measured, may not be told to layout.
The correct flow should be that any code path causing requestLayout() (which
could be anything that calls out to user/app code) should happen before the
measure phase (or cause a second measure to occur). For now, causing the second
measure to occur is a low-risk simple change that fixes the immediate problem.
Issue #28152259 Calling requestLayout from inside View.onConfigurationChanged can cause problems
Change-Id: I3b532eeacc3784d8d21193d01ddd7fa15ac0684e
This CL allows getChildVisibleRect to optionally always call the
view's parent. The previous version attempted to optimize the call
by not calling further up the view heirarchy when the rect isn't
visible in the current view.
The call is hidden and the previous behaviour is preserved to limit
the bits of code that this change affects.
Bug: 28514727
Change-Id: I49550ed4082bcbdcfe4643b962b50f3308092525
If the insets change, "mWidth/mHeight" won't change
as it's based on the window frame (not the surface size),
we need to track when the insets change and call
HardwareRenderer.setup with the new values.
Bug: 28257246
Bug: 28368990
Change-Id: Ida304b57c4671d010d1cf7b370674c9453841c97
The current mechanism to sync InputMethodService#mIsFullscreen to
InputMethodManager#mFullscreenMode is really fragile because
1. Currently the state change is notified via
InputConnection#reportFullscreenMode(), where InputConnection is
designed to be valid only while the IME has input focus to the
target widget.
2. In favor of performance InputMethodService (IMS) calls
InputConnection#reportFullscreenMode() only when #mIsFullscreen
changed. If InputConnection#reportFullscreenMode() failed, there
is no recovery mechanism.
3. Screen oriantation change is likely to cause Window/View focus
state change in the target application, which is likely to
invalidate the current InputConnection.
What our previous workaround [1] did for Bug 21455064 was actually
relaxing the rule 1 only for InputConnection#reportFullscreenMode().
However, my another CL [2] made the lifetime check of InputConnection a
bit more strict again, which revived the issue as Bug 28157836.
Probably a long-term fix would be to stop using InputConnection to sync
that boolean state between IMS and the application. However, it's too
late to do such a refactoring in N, hence this CL relaxes the rule 1
again keeping it as secure as possible.
The idea is that we allow InputConnection#reportFullscreenMode() to
update InputMethodManager#mFullscreenMode regardless of whether
InputConnection is active or not, as long as the InputConnection is
bound to the curent IME. Doing this as a short-term solution is
supporsed to not introduce any new risk because the active IME is
already able to mess up the InputMethodManager#mFullscreenMode by
calling InputConnection#reportFullscreenMode() on any other active
InputConnection. Bug 28406127 will track the long-term solution.
[1]: Id10315efc41d86407ccfb0a2d3956bcd7c0909b8
da589dffdd
[2]: If2a03bc84d318775fd4a197fa43acde086eda442
aaa38c9f1a
Bug: 28157836
Change-Id: Iba184245a01a3b340f006bc4e415d304de3c2696
Since the field might be null, we can't just read and write the
object directly. Use Parcel's convenience methods to do so safely
instead.
Bug: 28427070
Change-Id: I6460c9cb43dc6da97d5fd9edeaa78bdaaf105446
Clarifying region used for magnification as "magnificationRegion",
both in the public API and in the code. There's been significant
confusion about what "magnfifiedRegion" means. Removing
"availableRegion" from everywhere except where it's required, as
that region was identical to magnified/magnification region.
Trying to shut down magnification was a complex situation where
animations in progress and new magnification requests were tricky to
handle correctly. It was not possible to guarantee that the
magnification callbacks were unregistered consistently. There were
at least two situations that led to phone restarts:
1. If a triple tap was detected between unregistering the callbacks
and shutting down the input filter. In this case the magnification
request would go through.
2. If an animation had just started when magnification was turned
off, so the current magnification was 1.0 but the animator was
about to change it. In this case the callbacks would be unregistered,
and then the animator would start changing the magnification.
This change makes registering and unregistering magnification atomic.
It also makes MagnificationController stick around indefinitely once it
is created, registering and unregistering as needed to support
magnification gestures and services that control magnification. Services
that merely query the status of magnification no longer register for
callbacks.
One part of shutting down is turning off the animation and guaranteeing
that it won't try to make further changes. Adding a flag to
SpecAnimationBridge and a lock in that class so we can guarantee that
nothing happens when we aren't registered for magnification callbacks.
Also reconfiguring all accessibility options when a service stops to
make sure that only the features required by the current configuration
are enabled.
Bug: 27497138
Bug: 27821103
Change-Id: If697cbd34b117d82c8eee1ba7d0254089ee4241d
* changes:
Unhide getHdrCapabilities and HdrCapabilities.
Plumb HDR capabilities to Display
Revert "Revert "Hook up HDR capabilities from native SurfaceControl""
When reusing a ViewRoot and DecorView as we do with preserveWindows
there are two issues with SurfaceHolders. First, we update the
SurfaceHolder callbacks when we call ViewRootImpl.setView. In the
case of preserved window relaunch, the DecorView is reused and there is
no call to setView. We need the ActivityThread to notify the ViewRoot
that something has changed. Secondly, we were assuming the only time
a new surface would be created for the purposes of SurfaceHolder
notification was when we previously did not have a valid surface.
Instead we need to check if the native Surface object has changed each time we
get a result from relayout.
Bug: 28331264
Change-Id: If1b4aab9b2ba579fa040e2a3ab4471842476d82f
This reverts commit ee34ef1633.
This API is no longer needed by webview since 51.0.2704.22.
So remove this API. Note that this system API has never shipped
so it's ok to simply remove it.
Original description:
> Expose setDrawGLFunctionDetachedCallback to webview
>
> Add WebViewDelegate.setDrawGLFunctionDetachedCallback system API that's
> used for webview to receive the functor detach callback.
>
> BUG: 27709981
> Change-Id: Ie6b5e445c0090a181f94fcd2ec1ea77095c9cb03
BUG: 27709981
Change-Id: I9920dbedc6a280b4a19a8715832c4d2f64a7a7be
Currently it does not use a ClassLoader to read
any super state, which can cause crashes for
custom views using the class but on a different
class loader.
BUG: 27790353
Change-Id: I4f4d1d72f213f2481606673643c0e56c23d34bc6
When choosing what window parameters to pass on
to child windows, we need to respect the manually set
FLAG_HARDWARE_ACCELERATED from Window.setFlags() in
addition to the activity manifest value, and the value
from setWindowManager. Given that we pass the value
on to child windows from when setWindowManager is called,
I think it makes sense to pass it when setFlags is
called.
Bug: 27099358
Bug: 23036374
Change-Id: Ie018841aadd270910fe0f8bc5a5ddca3bfbee69b
Adds setSustainedPerformanceMode(boolean) API for applications to set
the mode for a given window. The mode will be disabled automatically when the
window is no longer in focus.
Bug: 28150358
Change-Id: Ibe8bc564eeaaccbcaad5c4f792cda16da931dffd
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
