Currently, these preferences can only be changed through 'cmd autofill', but
moving them to the Settings provider will let us manage them through the
Settings -> Developer Options screen:
- AUTOFILL_LOGGING_LEVEL
- AUTOFILL_MAX_PARTITIONS_SIZE
- AUTOFILL_MAX_VISIBLE_DATASETS
Test: manual verification
Test: atest CtsAutoFillServiceTestCases FrameworksCoreTests:SettingsBackupTest
Bug: 65700540
Change-Id: I6c864d032bc0b2c3b7c24f300af37883adbaf0d0
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
When SurfaceControl is created with creating variable
in updateSurface(), sizeChanged is also set.
So, setSize() is called, and it blocks UI thread
until the transaction is handled in SF.
There is no need to resize in the creation time,
because size is already set when creating SurfaceControl.
Test: systrace any app including SurfaceView
Change-Id: I65028b4d0d0ba2b75fbe089c98a11a56b6c08104
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
