Experimental force_dark prototype mode. Enabled
by setting debug.hwui.force_dark to true.
Test: verified nothing changes without prop being set
Change-Id: Ib02f3f1a9c591cab1f312b827451f04c782c2f41
Now both KeyEvent and MotionEvent will contain displayId. This will help
with dispatching input events to specific displays. There are use cases
where a particular input device is used for a specific display only, and
it sends key events to the system. This will help with those usages.
Test: atest view.MotionEventTest view.KeyEventTest
Bug: 64258305
Change-Id: I75891037617ed60820d60736216a0d615ab5e3b0
Before applying this patch, when a show-when-locked immersive app is
showing, the system bars would quickly show and hide, which are
redundant to the user.
The root cause is that, for nav bar, we have a policy to show nav bar
if the width and height of status bar are MATCH_PARENT and status bar
has no PRIVATE_FLAG_KEYGUARD. When keyguard is becoming status bar,
its keyguard flag would be removed first, and then the height would
be changed to the bar height. So the nav bar would be shown between
these events. For status bar, we force showing it when it is expanded
by checking its width and height are MATCH_PARENT or not.
To fix the issue, this change introduces a new private flag which
indicates that the status bar window is now in an explicit expanded
state. We check this flag instead of checking the width and height of
status bar.
This change also fix a bug that: when AOD is enabled, if the
foreground app has FLAG_SHOW_WHEN_LOCKED, FLAG_TURN_SCREEN_ON, and
FLAG_FULLSCREEN, clicking on the power key would make it show the app
again instead of AOD. (not 100%, but chances)
Bug: 80147982
Test: 1. go/wm-smoke
2. Launch a show-when-locked turn-screen-on immersive app on
AOD, and see if any system bar flashes.
3. Launch a show-when-locked turn-screen-on immersive app on
lockscreen, and see if any system bar flashes.
4. a. Enable AOD in Settings.
b. Open a show-when-locked turn-screen-on immersive app.
c. Click on power key, and see if AOD shows.
5. Launch an immersive app and drag down the status bar, see
if nav bar keeps there as long as status bar is expanded.
Change-Id: Ie885d504eb73ae8a86736b2c3ed4fb03eb9f739e
Otherwise there is a big performance hit in all kinds of
situations where we do operations with the region, specifically
when:
- updating input windows
- insetting the cutout during layout
- touch dispatch
Test: DisplayCutoutTest, WmDisplayCutoutTest
Bug: 110464019
Bug: 110452325
Change-Id: I94a25c3794ecd33b8b7204ca308ac91623498f13
The current issue is that Views that have either the horizontal or
vertical scroll bars enabled will intercept mouse interactions that
entire the region where the scrolling thumb would be even if the View
cannot actually scroll because it's content isn't larger than it.
This is fixed by only intercepting mouse interactions in the scroll
thumb region if there is something to scroll.
Bug: 110375792
Test: None yet
Change-Id: Ib638b4ac88375f55bc80ba2a66d945a16ecd6d22
Increase alpha from 15 to 30% for the track and use Google Material
Grey 200 for the thumb. Fix the geometry so that the track and thumb
don't extend off the edge of the screen.
Bug: 80258942
Change-Id: I43e603e5fffb8a05f486af35194c801060dd0b51
(cherry picked from commit 97b00cbc039a090659aed75e47a172a70222b02f)
If there is no visibility change, when the stopped state
changed from true to false, there is no valid surface to use.
Bug: 80170221
Test: Sample app in bug link
Test: atest ViewRootImplTest
Change-Id: I2324ed32980aae5a3ec2efbd612e6c143c9a0022
Previously, there was a time window between when an IME starts new
input and when the IME issues an IPC IMM#setImeWindowStatus() so that
WindowManagerService (WMS) can be notified about the new IME target
window.
With this CL, it is now guaranteed that WindowManagerService (WMS) is
always notified about the new IME target window before IME starts
interacting with that window.
Note that WMS is not using notified IME target window yet hence there
should be no user-visible behavior change.
Bug: 110531072
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I032b91ce722a16b17518a5d88015c574d7d3e51b
In InputMethodManagerService, windowGainedFocus() is a superset of
startInput(). If the window specified to windowGainedFocus() is
already seen in IMMS#mCurFocusedWindow, windowGainedFocus() just works
like startInput(). If the window specified to windowGainedFocus()
does not match to IMMS#mCurFocusedWindow, then it takes care of
everything we need to change the IME target window including tasks
that startInput() does. The reason why we still have startInput() is
just because my previous CL [1], which unified windowGainedFocus() and
startInput() with keeping the existing behavior, did not intend to
change the existing behavior.
Now that we are going to enforce true traceability between input
session and target application window, IMMS#windowGainedFocus() is
what we want to always rely on.
Bug: 110531072
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I24feedf9ef5aca90ef947f4f2aa3e78365fd8c8a
- Not allow to add as transient view if it still has a parent.
(The normal usage of addTransientView should be after removeView)
- If a view container is not attached, its transient view should
not be attached.
- If a transient view is already detached from parent, no need
to detach again when removing the transient view.
Bug: 109814657
Test: atest FrameworksCoreTests:ViewGroupTransientViewTest
Change-Id: I243cc292e4aaba987d48eeb202559de866a8c208
TextServicesManager always sets null to the "locale" parameter in
ITextServicesManager#getCurrentSpellCheckerSubtype then
TextServicesManagerService always ignores that parameter. It can be
safely removed.
Bug: 110275412
Test: Manually verified that spell checker still works
Change-Id: I5d85089899b0bd077f69971d77095859086a8d52
AFM should not block the UI thread when calling AFMS; this CL is a
"low-hanging fruit" change that makes oneway call from the existing functions
that return void.
Test: mmma -j ./frameworks/base/apct-tests/perftests/autofill/ && \
adb install -r $OUT/data/app/AutofillPerfTests/AutofillPerfTests.apk && \
adb shell am instrument -w -e class android.view.autofill.LoginTest \
com.android.perftests.autofill/android.support.test.runner.AndroidJUnitRunner
Test: CtsAutoFillServiceTestCases
Bug: 73536867
Change-Id: I09e84b797153cd02d3c02262994a2be1f38639ea
These are particular useful when the service created a wrong authentication
result.
Bug: 77641784
Test: manual verification
Change-Id: I420c8ff88137b9e410cbaff56f10a6a70d8311e5
AxEvents should be intialized.
Bug: 80251305
Test: Verified by displaying notifications which generate pane related
events.
Used testback to display all info related to an event.
Before this fix, much of that info was not annotated, now it is.
Change-Id: I832fee743c69dc16a050f35e733f0742771df245
If draw() invokes postDraw that sets the next callback, the
callback will never be invoked.
Test: Long-swipe-up from navigation bar
Change-Id: If2e4dfff8a845b73fa77426305d5ece1921857e5
Fixes: 109701914
On Android O, when an autofill service returned a null FillResponse the
app session would be done, unless a manual autofill request was made (and this
method was used to implement that logic).
But on Android P the workflow was improved so that when the service returns
a null FillResponse, the session remains in a "semi-dead" state where a new
server-side session is created whenever a view that hasn't been "seen" by the server yet is focused, and this new workflow makes the old logic obsolete.
Test: atest CtsAutoFillServiceTestCases
Bug: 73536867
Bug: 70046972
Change-Id: I9c819ba97b2a9a9de70e60fa9ebe433fb3b7fca8
b/77478095
1. AccessibilityEvent.singleContentChangeTypeToString() doesn’t print new change types.
2. AccessibilityEvent.singleWindowChangeTypeToString() doesn’t print WINDOWS_CHANGE_PIP.
Also, updated javadoc and @IntDef for content_change_type.
Test: built it.
Change-Id: I14933d4130eab8449bb1e185c1cafa4b456c01a5
* no-arg #start()
* remove no-op #destroy method
* fix a Java-imposed quirk that you can't draw a
currently invalid RenderNode, forcing bottom-up
recording for no particular reason
Test: builds
Change-Id: I28b41c83b4f7f9ddced843b0d57e9ac510d40ae5
doclava was accidentally suppressing all these broken links
in @see tags. This CL fixes issues so we can start enfocing
checks for broken @see links.
Test: make docs
Change-Id: If7830ece85f8d1f27c991eae282230814726e115
Exempt-From-Owner-Approval: Fixing @see javadoc link issues that are currently completely broken
...and logs a warning when it's not called from the UI thread.
Fixes: 79159377
Test: atest CtsAutoFillServiceTestCases
Change-Id: I2976dbe294db695796a2a9db9600a333ffb66f26
doclava was accidentally suppressing all these broken links
in @see tags. This CL fixes issues so we can start enfocing
checks for broken @see links.
Test: make docs
Exempt-From-Owner-Approval: Fixing @see javadoc link issues that are currently completely broken
Change-Id: I767e9fb9842494e5eccef2a7bdeee3877c488b5d
If an app crashes during Keyguard transition, make sure to keep
Keyguard transition
Test: AppTransitionTests
Test: go/wm-smoke
Change-Id: I80b80952f93d2b5611754f05a3dc333905cd1c86
Fixes: 80132133
