Scan on code base and found those API are not be used
anymore, and IWindowSession only be used in frameworks. Should be
able to remove them if needed.
Bug:111361793
Test: atest CtsWindowManagerDeviceTestCases
Test: atest CtsActivityManagerDeviceTestCases
Change-Id: Idbf680ae68d21e055d9ccfa33aea4a73891ddd14
If two views change, their common ancestor can send
a subtree_changed event. But the cache is dropping
events that come from views that it hasn't cached.
Now clearing the cache entirely when a node not in
the cache sends a subtree changed event, since we
don't know which nodes are descendents and which
may have changed.
I'm not thrilled with this change, since it may
degrade performance, but I want to fix the correctness
problem quickly.
Bug: 111554539
Test: atest AccessibilityCacheTest
Change-Id: Ib32d3622cddd7001663943eff71e823d21f5e500
Such that it gets executed after setSurface, in order that
mReqUsage has the correct flags set.
Test: Take trace, ensure that allocateBuffers actually allocates
in the right format/usage by ensuring that dequeueBuffer doesn't
trash them immediately again.
Bug: 111517695
Change-Id: I94b402d7b29d565155a77a2d09106246261712d2
The critical methods on this interface - like updateSession() - were already
void, so all we had to do were to "onewaywize" the other methods. We could
either refactor them to be truly async, or implement a blocking mechanism that
let them still be sync *and* oneway - because these methods are not in the
critical path, we opted for the latter, which is simpler and less risky.
Fixes: 73536867
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
Change-Id: I380430aa2a7805aed6f629afb360566fc5402abb
Root cause has been identified, but fix is too risky. Instead, we
remove the WTF for now and readd the fix as well as the WTF
in master.
Note that due to defensive programming, in case we land in the WTF
case, it doesn't cause any real bug.
Test: boots
Bug: 110834518
Change-Id: I0da1e48e420c3fcde0e818b7fe0527da9155a159
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
The documentation states " Setting to null indicates that this View is
not a pane." So make this behave consistently in that way..
Test: it builds!
Change-Id: Ied03a313b1fa1e26393f1497d63658acf6e297f4
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
First, depeprecate the setters for these flags.
Second, of those that it is possible, make them use actions instead.
This isn't possible with isScrollable because it maps to 6 actions,
so just have its setter do nothing instead.
Also fix up a bad unit test.
Bug: 37567816
Test: Ran CTS test suite for accessibiloty, which already test setting
and getting both flags and actions.
Also just ran testback to see if something terrible happened.
Change-Id: I76d9227987a25445485aab591e18f4e97324939f
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
