This patch switches everything over to ParcelFileDescriptor, but the
important part of the change is changing FileBridge.getClientSocket to
return a ParcelFileDescriptor. Previously, it returned a raw
FileDescriptor that was closed by FileBridge, and the only non-test
caller of that function was taking it and constructing a
ParcelFileDescriptor from it, which would also attempt to close the fd,
leading to an fdsan abort.
Bug: http://b/162811367
Test: atest FileBridgeTest
Test: treehugger
Change-Id: I724ea7601bb072c98895f68abc08bb0e339d1db0
(cherry picked from commit 4c392e8057)
This reverts commit ae03031efe.
Reason for revert: Merge the reverted patch by accident.
Bug: 162627132
Change-Id: Ic2f072730050cb47926cec6ed24af7ef9e5e7055
This reverts commit f21c885ca7.
Reason for revert: Have regression b/168268396.
Needs to pull out from Nov. builds.
Bug: 162627132
Change-Id: I29fa3937d1655a0cc7591abcfa2067f4fb2b2bcb
The application may get Resources instance from Resources.getSystem()
and context.getApplicationContext().getResources(). Since fixed
rotation is introduced that allows an activity to start in a different
rotation than the current display, when using getConfiguration() and
getDisplayMetrics() of these Resources instances, the orientation
and metrics need to be the same as current display is rotated.
Otherwise the app may show unexpected UI layout.
Although it is not recommended to use global resources/config for
activity. One of the goal of fixed rotation transform is to simulate
the app is started in a rotated environment, so this CL makes the
configuration and display metrics of system resources are consistent
with application and activity for compatibility.
About WindowProcessController and ActivityStackSupervisor:
The process configuration passed to LaunchActivityItem may be
associated from activity. if the sequence number of configuration
is overridden by activity, the configuration may be ignored when
launching the activity because the sequence number isn't larger
than the previous process configuration. Although there will be a
ConfigurationChangeItem later to update correct state, the app may
get the intermediate state with old configuration and metrics.
About ResourcesManager and DisplayAdjustments:
There are 2 new fields appWidth and appHeight added to
DisplayAdjustments#FixedRotationAdjustments because the display
metrics from Resources.getSystem() is independent from activity
configuration. Only window manager knows the rotated size, so
the values need to send to client and then ResourcesManager takes
the adjustment to change the global display metrics.
About WindowToken:
When fixed rotation is applied on the token, send the
FixedRotationAdjustmentsItem first so the later configuration
change can pick the adjustment at ActivityThread. And because the
registration of activity configuration only occurs on add/remove
activity, if it is only switching to another existing activity in
different orientation, the process configuration still needs to
be updated.
About ActivityThread:
The code flow for a rotated activity (DA = display adjustments):
- Launch new activity
handleLaunchActivity: override app DA
handleConfigurationChanged: adjust global display metrics by DA
performLaunchActivity
createBaseContextForActivity: override activity DA
- Resume existing activity
handleFixedRotationAdjustments: override app and activity DA
handleConfigurationChanged: adjust global display metrics by DA
handleResumeActivity
Also some minor corrections:
- Fix wrong display metrics adjustment that xdpi and ydpi should
not be swapped because they are physical attributes.
Bug: 167564038
Test: atest DisplayAdjustmentsTests
AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
WindowProcessControllerTests#testProcessLevelConfiguration
DisplayContentTests#testApplyTopFixedRotationTransform
Change-Id: I60bedc7e09f54683d5e857ccc51402d5d144cd9e
Merged-In: I60bedc7e09f54683d5e857ccc51402d5d144cd9e
Bug: 166149440
Test: manual (flash automotive device with all system bars and show/hide
insets using WindowInsetsController), atest InsetsStateTest
InsetsStateControllerTest
Change-Id: I500b2fb0129739c6fc609561377d90cca6e45f7e
The display frame is used to limit the windows boundary. The frame is
the same as the parent frame in most cases if the window is not
attched. However, if a window doesn't have any layout related
window/sysui flags and the soft input mode is not ADJUST_RESIZE, the
display frame doesn't need to be inset by IME (but the parent frame
does).
Fix: 163435784
Test: atest ViewRootImplTest DisplayPolicyLayoutTests
Merged-In: Ia61933120027642d1f0e0a490546071ca2b6c853
Change-Id: Ia61933120027642d1f0e0a490546071ca2b6c853
When there is an insets animation, we will stop updating insets source
frames until the animation is done. The previous logic didn't update the
frames within the requested state while the animation is done. And the
frames was relied by InsetsPolicy while playing transient bar animation.
If the frames don't match the display, the insets would be wrong, and
the animation wouldn't be played correctly.
Fix: 161134197
Test: atest InsetsControllerTest
Merged-In: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Change-Id: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Previous logic in onStateChanged notifies insetsChanged based on the
change of mLastDispatchedState, which can make us dispatch redundant
insets changes to the app.
In this CL, we only notifies insetsChanged if mState is really changed
in onStateChanged -- we use the final mState (after updateState and
applyLocalVisibilityOverride) to compare with the one before changing.
Fix: 161924448
Test: atest InsetsControllerTest WindowInsetsControllerTests
Test: Swipe up to home while IME open and see if there is any jank
Merged-In: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
Change-Id: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
When there is an insets animation, we will stop updating insets source
frames until the animation is done. The previous logic didn't update the
frames within the requested state while the animation is done. And the
frames was relied by InsetsPolicy while playing transient bar animation.
If the frames don't match the display, the insets would be wrong, and
the animation wouldn't be played correctly.
Fix: 161134197
Test: atest InsetsControllerTest
Change-Id: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Previous logic in onStateChanged notifies insetsChanged based on the
change of mLastDispatchedState, which can make us dispatch redundant
insets changes to the app.
In this CL, we only notifies insetsChanged if mState is really changed
in onStateChanged -- we use the final mState (after updateState and
applyLocalVisibilityOverride) to compare with the one before changing.
Fix: 161924448
Test: atest InsetsControllerTest WindowInsetsControllerTests
Test: Swipe up to home while IME open and see if there is any jank
Change-Id: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
We use same reference from TextView to set the initial
surrounding text. The actual surrounding text may be
modified before retrieval since the mSurroundingText
is mutable. Use a copy of subText should avoid this
concurrent issue.
Bug: 160390184
Test: atest FrameworksCoreTests:EditorInfoTest
Change-Id: I6082a4cae2fcdc4c529dc14e2e5e7a45ab1aae4d
In the legacy layout world, if a window has FLAG_FULLSCREEN, then its
stable insets won't be affected by status bar. This CL makes the layout
logic compatible.
Fix: 160593171
Test: InsetsStateTest InsetsControllerTest ImeInsetsSourceConsumerTest
Change-Id: I59717e699470273e2462c1ad864e00bb9a126677
If the local state and mLastDispatchedState are the same, the logic in
onStateChanged will skip updating the requested state. This could be an
issue, for example, a new focused window requested to hide status bar,
but status bar has already been hidden by the previous focused window,
so the new focused window will never send the requested state to server.
This can easily happen when an immersive activity is re-created due to
the configuration change.
This CL updates the requested state if any visibility within it is not
the same as the requested visibility of the source consumer, while
receiving controls.
Fix: 160854328
Test: atest InsetsControllerTest
Test: Swipe to show transient bars after rotating an immersive activity
Change-Id: I5d9acb1b59252fa80e66070db86b2555764588da
Fixes a flicker that occurs during transitions between windows.
This happens for two reasons:
1.) Control is immediately transferred to the new window, and the
previous window didn't get a chance to play the animation.
This is addressed by adding logic to keep control on the
exiting window for the duration of the transition - similar to
what we do with the target for z-ordering purposes.
2.) Upon the input connection being severed, the InputMethodService
immediately hides its window, preventing any animations whenever
the input connection changes
This is addressed by moving hiding of the surface into the
controlling windows - where upon receiving control, we now
trigger removal of the IME surface if we don't show it.
Additionally:
- Now ensures that any requests from the ImeInsetsSourceConsumer
ensure that they come from the window that is currently served
by IMM.
- Removes the transparancy clause from isImeTargetFromDisplayContentAndImeSame
to match the updated IME target computation in DisplayContent in [1].
[1]: Iedd5f7407926167f4891ce9b7e9a79e22751e668
Fixes: 153145997
Fixes: 150902448
Test: atest WindowInsetsAnimationControllerTests
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: Open app with IME, press HOME button, verify IME smoothly animates away
Test: Open Messages, open a thread, open IME. Click search icon, verify IME opens in the search activity
Change-Id: I4910c2a06cc67b0470477b245fc1de54b75f10f9
Add null checks in both ContextWrapper and before obtaining
ContextImpl#getOuterContext.
Test: atest ContextTest#testIsUiContext_ContextWrapper
fixes: 160037462
Change-Id: Ic6a71dd9ac4b195d219d6e5431f2f2b199a400fa
These tests run fine in isolation (verified both on a physical Pixel 3
and on a Cuttlefish emulator via acloud), but are flaky in presubmits.
Bug: 159764993
Test: Presubmit
Change-Id: Ia27e05543e2647c42e06a684a3ae5c11c074a5fb
Merged-In: Ia27e05543e2647c42e06a684a3ae5c11c074a5fb
(cherry picked from commit 9d296cdd98)
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Merged-In: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
