Such that all it's goodness can also be used in context when
ViewRootImpl isn't available, like the SystemUI controller used
for Car and Split
Test: InsetsControllerTest
Fixes: 154631128
Change-Id: I54a3f8a34810472d9273e4627a7811b7abd0863f
Bug: 152983829
Bug: 119066174
Test: make; flash and boot
This was already renamed to RecordingCanvas, which is in the graphics
package. It was revived in the old location to temporarily support apps
that were relying on the old name. Currently go/nonsdk-dash shows no
usages, neither via runtime logging nor via static analysis.
RecordingCanvas also cannot refer to this hidden class in the view
package once graphics is its own mainline module. Remove the hidden
class, which was the original plan anyway.
Restore RecordingCanvas' constructor back to private, since it had been
changed to protected as part of the revived DisplayListCanvas.
Change-Id: I7ae1fa043811e361efa6c28753a92bb9c30a7198
Using byte for display port is error prone since ports
are in the range [0, 255] and bytes have the range [-128, 127].
This way we need to downcast from int to byte in order to write a
value to display port and also we need to call Byte.toUnsignedInt
every time we want to consume it.
Test: m services
Bug: 153334857
Change-Id: I4dce87c0a411c5d447f62cc5564eb4b8a8fb75f0
JNI calls aren't free and we don't need to burn one
to call update with the values we just passed in.
Bug: 152501005
Test: Existing tests pass
Change-Id: Iaf272edb03d4ec195b75e9ef7e6c122604025dcb
This error showed because DecorContext uses application context
to get WindowManager. This CL changes to use PhoneWindow to obtain
WindowManager instance. Also refactor ctr to obtain context from
PhoneWindow.
Bug: 152806048
Test: manual - enable strict mode and check the error log not shown.
Test: atest DecorContextTest
Test: atest MemoryTests#testActivityRecreation
Change-Id: I1d416b9cdb015c9bc3553571041f3b14bb9da5da
CL[1] intends to reset served view and restart input state when focus to
the next window, which the main idea is try to make the lifecycle of the
input connection can more aligned with the window focus change.
However, this behavior change unexpectedly breaks Gboard
TranslatesUIExtention that will closeExtensionView when
onFinishInputView -> onDeactivate called, while launching language
selection dialog.
Remove the reset logic as the lifecycle of input connection still
needs to break down.
[1]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 152373385
Test: To make sure not break Bug 148489857 and Bug 148788569, following
auto / manual test to verify:
- Auto: atest FocusHandlingTest#testKeyboardStateAfterImeFocusableFlagChanged
- Manual:
1) Build / install EditTextVariations
2) Select menu -> Direct-Reply, make sure Notification comes up.
3) Tap EditText on Notification, verify soft-keyboard is visible.
Change-Id: If20cdb43ecd013c330c5e16c73e9af972bd89f33
1. Avoid a seperate IPC querying in to system-server
to initialize the mUseBLAST flag.
2. Avoid calling property_get_bool with each BufferQueue
creation.
Instead we piggy-back both values inside addWindow return values.
Bug: 152501005
Test: Existing tests pass
Change-Id: If130560a8230f8d399cf7631264d551522939faa
Add test to verify that requestedVisibleAwaitingControl starts
animation. This is followup test for comment in commit
I958fc5747382109aa2f21bc1067a28746e7242d8
Bug: 154440912
Fix: 153577930
Test: atest ImeInsetsSourceConsumerTest
Change-Id: I08db27151605ac53b0575b08343b5a75dc2e5fc2
* changes:
Rollback chooser menu to version Q behavior for accessibility button (2/n).
Rollback chooser menu to version Q behavior for accessibility button (1/n).
This sets the most-recently created view on a shellroot
to be used as the "accessibility" window. This allows
each shellroot to have 1 window that accessibility sees.
Bug: 152368950
Test: atest AccessibilityWindowQueryTest#testWindowDockAndUndock_dividerWindowAppearsAndDisappears
Change-Id: Ice2820e11544ccdf7a3e600f918eac0ffb506548
@SystemApi requires @hide, so @TestApi is needed for these to
be visible to CTS testing
Test: methods visible to CTS test
Bug: 152052560
Change-Id: Icd7f82f3859a1deccd41d2279d8f9722a42df957
Allow separate Activities to handle the multiple-target case for the hardware and software shortcuts. Migrate from an extra to an explicit class so the Intent dispatch will launch the correct Activity for the particular shortcut.
Bug: 151294664
Test: manual test
Change-Id: I54bb1d3ab91e2757c465e8763786d0234f6d4ea8
The previous solution used a different transaction from the one used in
SeamlessRotator#finish. So the transaction might be applied in an
unexpected order between here and there when the target frame number is
reached.
This CL reverted the previous solution. Instead, we don't dispatch the
leash if it is not ready. For the client, it won't play the animation
until obtaining the leash.
Fix: 154195854
Test: Rotate device to change the orientation in Camera, and see if
navigation bar stays visible.
Test: Check if transient bar can be shown/hidden/aborted as expected.
Test: Make sure b/153104643 stay fixed.
Test: atest InsetsPolicyTest
Change-Id: I29f80f1c77615b0a3cde38df265220f48d66f117
This change is to prevent misuse of window context from app
and leads to performance drop on system by limit the numer of window
context an app can use. Code snippet below is a sample to cause
this issue:
```
Rect getBounds() {
Context windowContext = context.createWindowContext(...);
return windowContext.getSystemService(WindowManager.class)
.getCuttentWindowMetrics().getBounds()
}
```
This method could be invoked dozens of times and produce dozens of window
tokens. It would slow down the speed of window traversalling. These
token won't be removed until system server has been GC'd.
Test: atest WindowContextTests WindowContextPolicyTests
fixes: 152934797
Bug: 153369119
Change-Id: I927e85a45c05c4d90b51a624ea408ff3a3ffce93
