Currently, we are dumping information on ViewRootImpl, but it doesn't
include some of the critical pieces. Add attachinfo information. Also,
attach a dump of a variable that determines whether the input events
will be dropped.
Example of newly added piece of dumpsys:
mPausedForTransition=false
...
mAttachInfo= AttachInfo:
mHasWindowFocus=true
mWindowVisibility=0
mInTouchMode=true
mUnbufferedDispatchRequested=false
Bug: 173675649
Test: adb shell dumpsys activity -v all
Change-Id: I7b8801436f74a123bf96735de30b238146413545
Some stuff changed underneath, so we can do a little bit
of housekeeping
Bug: 169035082
Test: nothing changed
Change-Id: I70c668d5760cd6fb9ddfd56720e0b712bd7520fc
Some apps still use these fields. Remove them can make the app's
behavior unexpected. Although they shouldn't use these hidden APIs, it
won't cause any trouble if we bring the fields back. The user experiance
can keep the same.
NoNonSdkCheck: Revert Non-SDK API change
Fix: 174657478
Test: Steps in the bug.
Change-Id: I8da15ba3f66d20b4ac599db32539acb76d279978
SAW permission is added to the shell to allow it to create
TYPE_APPLICATION_OVERLAY windows during testing.
Test: atest CtsWindowManagerDeviceTestCases:HideOverlayWindowsTest
Bug: 159616727
Change-Id: I503cd8da24ff4d2b928f930ac61090e6782c1546
Currently, inputflinger would send an ACTION_POINTER_UP event with
AKEY_EVENT_FLAG_CANCELED when we have at least 2 pointers down and
one becomes the accidental touch.
In ViewGroup, if we have FLAG_SPLIT_MOTION_EVENTS, it may split a
multi touch event into some single touch events to the target childs,
so we should also check the cancel flag in order to prevent it trigger
the accidental click on the child view.
Bug: 161655782
Test: enable twoshay, test accidental touch on RecyclerView
Change-Id: Iba864361ca3361e4a720dbe0eb0b39d42a6dc5b2
For the attaching the nav bar to the app during quick switch, we
reparent the leash of the nav bar to the app the user swipes from and
restore it back when the quick switch gesture is finished.
There is a callback IRecentsAnimationController.finish() which seems to
be a good timing to restore the nav bar. However, it doesn't work well
in the live tile mode.
In the live tile mode, the overview won't call
IRecentsAnimationController.finish() until a new task is started and
this is why we need to add this API.
Bug: 139273001
Test: make
Change-Id: Iabea2fb222a2dacd57207b74d1778f93237268ea
1. Use Transaction API instead of SurfaceControl
2. Removed recoverMemory flag from Tranaction request APIs
3. Deleted a lot of unused code
Test: Split Screen + PIP
Change-Id: I91762453afadd79626f6fb2d8ba162054a011584
In WSA, we are sometimes using the global transaction. This will make
things difficult when trying to handle synced transactions for blast
sync. We need to make sure all changes on WSA that can happen during a
sync are put on the sync transaction so they can all be applied by the
client at the same time.
Also cleaned up some unused functions in SurfaceControl.
Test: Split and PIP
Change-Id: Ic1abc3c009c38d00593f80a4e03f895c026364e2
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
Deprecates the following
- IPinnedStackListener#onConfigurationChanged, switched to use
onConfigurationChanged callback in WMShell
- IPinnedStackListener#onDisplayInfoChanged, switched to use
DisplayChangeController
Bug: 174702196
Test: atest WMShellUnitTests
Change-Id: Id2161883bd520c99888a561ae058154da06ecb51
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Turns out this can just be checked when the transition starts.
However, added a flag so that shell knows.
Bug: 162500279
Test: enable shell transitions, lock screen, then open camera and
close camera.
Change-Id: I57703ed8040172496f7091cdae11489df8724c53
Adds the ability to register a listener that gets informed about
SF' jank classifications via the TransactionCompleted interface
Bug: 174755489
Test: FrameTimelineTest
Test: Register listener, ensure data flows back
Change-Id: I3021cd75856b62e579e30f7bb3e5b2c3a61038c5
1. Define and implement new APIs to set and get the stroke width
and color of the A11y focus rectangle.
2. New an AccessibilityFocusApperanceData variable with the default
value in the A11yUserState class, and it would be used in the A11y
framework.
3. When A11y services sets the stroke width and color of the focus
rectangle, A11yUserState will apply the same value through
A11yServiceConnection and notify this change to A11yManager.
4. When A11y services customized the data is disabled, reseting the
data in the A11yUserState and notifying this change to A11yManager.
5. When the ViewRootImpl gets the A11yFocusDrawable, it changes the
strokewidth and the color of this drawable based on the value from
A11yManager.
Bug: 141144573
Test: a11y CTS & unit tests
Change-Id: I1493f17f7cc25744e1435c9070218c6f7efa8bcf