Adds a config resource to configure the main display's cutout and
dispatches it from the LocalDisplayAdapter.
WindowManager's DisplayContent then transforms it to match the current
rotation.
Also fixes an issue in EmulatedDisplayCutout where the Path was never
reset and changes the color to black. Also fixes the RoundedCorners
overlay such that it can layout within the cutout area.
Test: atest CoordinateTransformsTest DisplayContentTests
Bug: 65689439
Change-Id: If39c8ea3cb55c761517f270dcca292682c0918ad
* changes:
Clipping to the top roundness when scrolling
Made the notification side paddings consistent
Changing messaging style and overall visual adoption
Improved the MessagingStyle API with Person
Added People to the Notification API
The messaging style is changed to a bubble-less design.
In addition are we also updating a few spacings in
order for it to look nicer / more balanced.
Test: manual
Change-Id: I43326bd8a23cd1f1d5964d2d6740fde99d29c7e4
- MOTION_TRACKING capability defines a camera with accurate lens calibration
values, accurate timestamps relative to the inertial sensors, and ability
to limit exposure time to 20ms max.
- Add android.lens.poseReference for supporting gyroscope-centered lens calibration
data for MOTION_TRACKING.
- Minor changes to some docs formatting.
Test: Builds
Bug: 63629224
Change-Id: Ic303240890c709725f60e69dfff76beea4a0ef91
Removing suggestions to get information from events that
can instead be extracted from the node hierarchy.
Clarifying window change and announcement.
Comment changes only. I'm trying to steer developers to
use the APIs as we currently thing about them, but I'm
not changing any behavior.
Test: make
Change-Id: Ieecedbb98bdf11cf0cf4a29856db497986faaca6
Such resource id is useful to help the autofill service heuristics to figure out
the meaning of the labels without relying on their localized text. For example,
the id could be "username", while the text could be "Nome do usuario".
Test: atest CtsAutoFillServiceTestCases:LoginWithStringsActivityTest
Fixes: 71552872
Change-Id: I13f7080fb3c67f91492a113115ffa43d185d192a
TYPE_WINDOWS_CHANGED events have meant that "something"
changes with the system windows, so a single event would be
fired for a single small window change or a bunch of window
changes. Services were required to cache the windows and
compare the old ones to the new ones to find out what
changed.
Since AccessibilityEvents are intended to communicate
changes to the UI, this CL sends one TYPE_WINDOWS_CHANGED
for each window that has changed, and provides a way to
get the source of the changing window. It also adds a
windowChangeType field, which contains flags to indicate
what exactly has changed for the window.
Bug: 62231686
Test: Run all a11y unit and cts tests
Change-Id: I6c48e74da26be5ea485ac114a37f3c404a74940e
Some private or package-private members have been marked as @SystemApi,
which do not make sense as they aren't accessible to apps due to the
access modifier. Having annotation on such members hasn't been harmful,
but will soon trigger CTS failures when we do the exact match for
SystemAPIs; a runtime entity annotated as @SystemApi have to exist in
the documented API (e.g. system-current.txt). So, removing the bogus
annotations.
Bug: 67891551
Test: m -j does not require m update-system-api
Change-Id: I0083475ef5435cf9a582c2ce1be469c92328fe69
Also minor fixes on isFieldClassificationEnabled() to make sure it's ignored
when not called by the service app and its calls are properly synchronized.
Test: atest CtsAutoFillServiceTestCases:LoginActivityTest#testGetAutofillServiceComponentName
Fixes: 70678279
Change-Id: I58ccb313d22c30af907f3da62f727f067240fa66
Currently PointerIcon.load and PointerIcon.getSystemIcon do not
check if the hotspot position is within the bounds of the underlying
bitmap. The check is performed only in PointerIcon.createFromParcel
which is called in the system server process and the resulting
exception might be hard to trace to the root cause.
Bug: 70862454
Test: android.widget.cts.PointerIconTest
Change-Id: I7f19cc9fc60b7bf72ad53403c203087201a5810c
These zero-sized views tend to make keyboard navigation
difficult for users since focus "disappears" sometimes.
This takes a best-effort approach for focus requested
prior to layout: If a View hasn't been laid-out and is
asked to take focus, it will act as though this size
constraint doesn't exist. Then, upon layout, it will
defocus itself if it still has no size.
Bug: 32072305
Test: Added CTS View_FocusHandlingTest#testSizeHandling
Change-Id: I82fee246bdf4964fe744142876da88ae79e491f0
When the AutofillService returns a null FillResponse for onFillRequest(),
AutofillManager was ignoring any further view calls backs (other than a manual
request to start a session) to optimize performance by avoiding unnecessary
IPCs to system_server (and then from system_server to the Autofill Service
process).
But this optimization has a drawback: it makes it harder for the service to
handle cases where the activitity dynamically added new views after a view
has been focused.
This CL offers a compromise to fix both problems: it removes the optimization
for notifyViewEntered() calls (as that's what triggers autofill), but still
ignores the other calls once the session is on finished state.
Test: atest CtsAutoFillServiceTestCases:LoginActivityTest#testAutofillAutomaticallyAfterServiceReturnedNoDatasets
Test: atest CtsAutoFillServiceTestCases:LoginActivityTest#testAutofillAutomaticallyAndSaveAfterServiceReturnedNoDatasets
Test: atest CtsAutoFillServiceTestCases:LoginActivityTest
Fixes: 70046972
For optimization purposes, AutofillManager was ignoring all request
Changed AutofillManager to start a new session after service returns a null
Change-Id: Iaae9ed7f8b12ebc9da13e990ef468d9019d5c6ca
The anchors are, in practice, always Views, but they may end up
being virtual views in the future, so we should have this done
right.
Also cleaning up picture in picture mode. I don't know why I made
it a separate boolean when I already had the boolean properties.
Bug: 70730136
Test: A11y unit tests and CTS
Change-Id: I916ec066dff12fab8b586371452b728af6be1271
We need to make sure to dispatch every focus change, even if
the focus itself doesn't actually change.
Bug: 70722141
Test: bit CtsViewTestCases:WindowTest\#testSetLocalFocus
Change-Id: I12f4b18b93516f3bf03fb0d4a897a968cda65f41
This CL is a generalized version of my previous CL [1], which addresed
Bug 31056744 where InputMethodManager (IMM) fails to recover from
failure mode when IMMS#startInputOrWindowGainedFocus() failes because
the app's window is no longer eligible to be the IME target.
This CL finally addressed one TODO in that CL. InputBindResult now has
the error code, which allows us to force restart input upon the next
window-focus-in event. This should make IMM much more robust for
that kind of failure modes. For instance, Bug 70629102 is fixed as
demonstrated in a newly added CTS test case [2]. Hopefully this may
also fix Bug 31056744, which we still do not know how to reproduce.
[1]: I60adb38013b063918b074c7b947649eada77b2c8
8e9214b4bd
[2]: I4ea24c87cbbd05e4e68ad7dfafb774c8520188e2
Bug: 31056744
Fixes: 70629102
Test: Added a test case for Bug 70629102
atest CtsInputMethodTestCases
Test: Manually made sure that Bug 28281870 is still fixed:
1. Open app that has EditText.
2. Start Input.
3. Long press the task switch button to start multi-window mode.
4. Tap the EditText that is used in step 2.
5. Make sure that the IME still works as expected
Test: atest CtsViewTestCates
Change-Id: I7572d4b9d678f3669ca54d55718877b145015777
Things can be flaky, because window focus changes are
dispatched to the window on a separate path from input events,
and the window will drop events if it gets them before it sees
the focus change. I am trying to mitigate this some by noting
ASAP what the next upcoming focus state will be, so we can check
that and dispatch it before dispatching a key event if needed.
This definitely makes things better, but not perfect. ctate
suggested that maybe we should be dispatching window focus events
through the input system, which at a glance sounds like a really
really good idea to me... so maybe we can look at that later.
Also changed the wm command to just be a shell wrapper around
all of the implementation that is now in WindowManagerShellCommand.
And fixed a few places where we write debug info to streams that
would trigger strict mode violations that we really don't care
about.
Test: manual
Change-Id: I5235653bcec5522ab84c7f2e1de96d86f2f59326
