Adding View.setTooltip/getTooltip and 'tooltip' layout attribute.
Following Material Design spec for styles and behavior.
Bug: 31515376
Test: cts-tradefed run singleCommand cts -m CtsViewTestCases
--test android.view.cts.TooltipTest
Change-Id: I2d2527f642cd7446ffc88d4beffc7b81d7a2f6d6
Currently there is a single instance of WindowManagerPolicy
used in Window Manager and it is configured according to
primary display settings. Because of that it reports display
size with navigation bar insets even for secondary displays.
This CL adds displayId param, so it can adjust reported metrics
correctly when requested.
Bug: 32910901
Test: android.display.cts.DisplayTest
Change-Id: I14967fc13907c4fde17aed6a769d03cbde3ec1be
So far AutoFillService only received the assist data from framework; in
this CL, it also offers a method where the auto-fill provider can send
the auto-fill data back to framework.
The workflow is:
- AFMSI calls a new AM method (requestAutoFillData(), instead
of requestAssistContextExtras()).
- The assist receiver is located in the app, not on system service.
- AM uses a new request type (ASSIST_CONTEXT_AUTOFILL) to request the
assist data to the activity.
- ViewStructure has a new setAutoFillId() method which is used to set an
unique id for the view.
- View uses the accessibility id to implement the auto-fill id.
- When the activity fullfills the request, it creates an IAutoFillCallback
remote object - that will be used to set the auto-fill fields - and
returns it in the assist bundle (using the
VoiceInteractionSession.KEY_AUTO_FILL_CALLBACK key).
- The app-visible AutoFillService class offers an onFillRequest() method,
which contains the assist data and a FillCallback used to handle it.
BUG: 31001899
Test: manually built and ran it
Change-Id: I3d208c14e81022dc96dd03f38bbe25a778b24a67
In some situations it would be useful if the application can give a
hint that the user is not likely to want the IME to update
personalized data such as typing history and personalized language
model based on what the user typed the input area.
Typical use cases are:
* When the application is in a special mode, where user's activities
are expected to be not recorded in the application's history.
Some web browsers and chat applications may have this kind of
modes.
* When storing typing history does not make much sense. Specifying
this flag in typing games may help to avoid typing history from
being filled up with words that the user is less likely to type
in their daily life. Another example is that when the application
already knows that the expected input is not a valid word (e.g.
a promotion code that is not a valid word in any natural language).
Applications need to be aware that the flag is not a guarantee, and
some IMEs may not respect it.
Since this is basically about the general behavior that can be
combined with any of type of input types, this CL uses
EditorInfo.imeOptions instead of EditorInfo.inputType.
Also so far it look OK to do nothing in EditorInfo#makeCompatible()
regarding this flag because 1) this bit (0x1000000) has never been
used and 2) it is less likely that just passing that bit to an IME
that do not know about this bit causes any issue.
Bug: 28157942
Test: compile only as this is just a hint and OS does nothing
Change-Id: Ibf5ac3d2b8f39542baf2635c0cadbe242b059f81
With this CL, one can specify a content URI with an embedded user ID to
InputContentInfo, like such a URI is supported in
Context#grantUriPermission().
Note that such a scenario is actually possible when 1) an application
running as User X sets a content URI to the system clipboard then 2) the
IME runing as User Y who share the clipboard with User X obtains the
content URI from the system and tries to create a new instance of
InputContentInfo.
Bug: 32427307
Bug: 32778718
Test: 'adb shell dumpsys activity permissions' with a custom IME that
instantiates InputContentInfo from the content URI obtained from
the clipboard.
Change-Id: I7918c0a379b8f3e7e64b106447b42447876f9057
Currently Commit Content API work only when the content URI provided by
the IME is accessible to the target application. This is non-trivial if
the target application is running as a different user (profile) and it
is actually a possible scenario when managed profile is enabled.
This CL takes care of such a situation, by fixing up the content URI
when and only when InputContentInfo#getContentUri() is called from a
different user than the owner of the content URI.
This CL also makes it clear that we currently do not support content
URIs that already have embedded user IDs. Since
IActivityManager#grantUriPermissionFromOwner() does not support such
URIs, we should have had a special handling for such a case, which will
be addressed in a subsequent CL.
Bug: 32427307
Bug: 32778718
Test: Made sure that Commit Content API works as expected on a managed
profile created by
https://github.com/googlesamples/android-testdpc
Change-Id: I19d87fc19beea248f49b59ec5a5711b95bcbb466
- Also refactoring the PIP touch handling to be independent gestures
Test: Enable the setting in SystemUI tuner, then drag the PIP slightly
offscreen. This is only experimental behaviour, and
android.server.cts.ActivityManagerPinnedStackTests will be updated
accordingly if we keep this behavior.
Change-Id: I5834971fcbbb127526339e764e7d76b5d22d4707
As a preparation to add a new flag into EditorInfo, this CL aims to make
it clear what bits in EditorInfo are already used and what bits are
still available for new features.
There should be no behavior change because there is no code change.
Bug: 28157942
Test: compile, as there is no actual code change
Change-Id: Ie4b216dbb0978d8dc1c5e91762b87d065c7a1cac
Don't force mKeyguardGoingAway, as this never recovers. Make sure
to only show the dismissing Keyguard activtiy and recover the
state when trusted state changes.
Test: Make sure Keyguard is in a trusted state, start an activity
with FLAG_DISMISS_KEYGUARD from FLAG_SHOW_WHEN_LOCKED activity
and make sure there is no flicker.
Bug: 32057734
Change-Id: I5d212f6f9d5430250b22c8370f45dc95756432d2
> Fixing isRootNamespace check
> Updating ViewTree when ViewStub is inflated
> Applying ViewGroupAction on previously found views instead of finding it again
as the viewTree might have changed.
Test: am instrument -w -e class android.widget.RemoteViewsTest com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 32639592
Change-Id: I0815fb3a981efbc04fb0d080b81949985c2d9bc3
Forcing the layout params to be sent to
WindowManagerService, and from there to accessibility
to generate the event.
Bug: 27857482
Test: Adding corresponding CTS.
Change-Id: I24fc97e16b95799259e4c472b6f1052a1dd00a56
Saves about 300us for each AccessibilityEvent sent, which
translates to 1 ms in gfx-avg-frame-time in the
QuickSettingsPull.
Test: Ran a11y cts and unit tests. Ran systrace and the
QuickSettingsPull to measure jank improvement.
Change-Id: I6d219b0e82c21047e50d402d930d8a5cc93fa6ad
Not needed anymore \o/. Also fixes a flicker when transitioning
between two activities that both set FLAG_LIGHT_STATUS that was
somehow introduced recently.
Test:
- Start an light status bar activity from another activity that
already has light status bar, ensure there is no flicker.
- Open IME and make sure the content gets resized like before.
Change-Id: Ie9c9e1cd40f909c449d36ae436250063af20539e
Test: Enable in SysUI tuner, drag PIP. This is only experimental to help
figure out what UX we want to keep.
Change-Id: I0d6f2f0c5909d6a76aae4a8fb84c5076f6996fdd
Also speed up RenderNode creation:
Use finalizer() instead of NativeAllocationRegistry, this
shaves ~3us off of creation currently
Avoid instanceof, instead have SurfaceView explicitly ask
for updates.
Remove unused method call.
Test: ran benchmarks
Change-Id: I3117fdf72313a4e6a9965baca9f2a8b855c19b34
Switched presentation feature to use new window TYPE_PRESENTATION
and also add its own window token to the display the presentation
is running on. This is needed as window manager no longer allows
tokens to have windows on multiple displays.
Bug: 32566372
Test: Presentation mode works.
Change-Id: I9c2998311b65640743b8e23ec4f10bf1ffbfd785
Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
* changes:
The big keyguard transition refactor (6/n)
The big keyguard transition refactor (5/n)
The big keyguard transition refactor (4/n)
The big keyguard transition refactor (3/n)
The big keyguard transition refactor (2/n)
The big keyguard transition refactor (1/n)
Nuke KeyguardScrim
Test: Kill SystemUI while lockscreen is showing, make sure nothing
is visible when being killed.
Bug: 32057734
Change-Id: I9f8d1e5a0e0f968460d8170627a849623c6a7245
Notify activity manager when dreaming showing state changed so
KeyguardController can update the occluded state when the device
is dreaming.
Test: Set dreaming while charging, wait until screen times out,
make sure that dream is occluding Keyguard.
Bug: 32057734
Change-Id: Ied6f485d9b4a1526cb4cd5f0701f86b1ea05830a
Test: Manual, ensure that the accessibility focus is still visible on
a moved window (enable talkback, focus a view, then move the
window).
Change-Id: Ifd67afe355cac2f1df01ddd16f960282f4d36132
The heart of this change are two things:
1) Instead of using the force hide mechanism to hide windows behind
Keyguard, we actually make the activities invisible in activity manager.
2) When Keyguard is going away, we change the visibilities in activity
manager and run an app transition.
At the very core we move the responsibility of hiding activities to
ActivityStack, which checks whether Keyguard is showing, and then
hides all non-show-when-locked activities. For that, we need to check
whether any window of an activity has SHOW_WHEN_LOCKED set. We
introduce a callback from WM -> AM in case these Keyguard flags have
changed.
Furthermore, we decide whether to occlude Keyguard in KeyguardController,
which just checks whether the top activity has SHOW_WHEN_LOCKED set. When
this state changes, we prepare an occlude/unocclude app transition, and
in PWM we just inform the Keyguard about the animation so SysUI can play
along this animations in a mostly synchronized manner.
Since we now use an app transition when unlocking the phone, we get
lockscreen launch animations for free - window manager automatically
waits until the activity is drawn, or directly executes the transition
if there is nothing to animate. Thus, we can remove all the infrastructure
around "waitingForActivityDrawn".
The logic to show/hide non-app windows is moved to policy, and we add the
ability to run animations on non-app windows when executing an app
transition.
Test:
1) runtest frameworks-services -c com.android.server.wm.AppTransitionTests
2) Manually test unlocking Keyguard:
2a) Without security
2b) With security
2c) With security but trusted
2d) Portrait while activity behind is in landscape
3) Test launching things from Keyguard
3a) Without security
3b) With security
3c) Launch camera without security
3d) Launch camera with security
3e) Launch camera with securtiy and trusted
3f) Launch voice affordance
4) Set no notifications on lockscreen, drag down, make sure you get
the correct animation
5) Test clicking "emergency" on bouncer
5b) Test "Emergency info" on emergency dialer
5c) Test clicking edit button on emergency info, should show pattern on
Keyguard
Bug: 32057734
Change-Id: Icada03cca74d6a612c1f988845f4d4f601087558
- Creating a PinnedStackController to keep track of the state of the PIP
to prevent changes in the system (ie. IME showing) and user interaction
from clobbering each other.
- Refactoring calls in AM into WM/controller
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ie59dfd45d5c54764ba69a589b3b8148845e92cc3
Signed-off-by: Winson Chung <winsonc@google.com>
Test: docs only, no test apart from verifying that it builds
Bug: #32158219 clean up InputConnection.commitContent() javadocs
Change-Id: I94ca33a34dfaece8db912367d2290db67a4a038a
- Ensure we use the right display size when calculating PIP bounds.
- Also update interface to take the display id.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackDefaultBounds
Test: #testPinnedStackMovementBounds
Change-Id: I01fd8ba6dee212c29a9a092673ee8f7843e41af6
Now display-specific settings, such as dimensions and orientation,
are stored in display override config. For default display it is
mirroring the global config. Each time when global config is updated,
override of the default display should be updated too and vice versa.
Test: Existing and manual tests still pass.
Change-Id: Ic6c2190092d328820f314a05bed43c875db18170
For N the Camera used ROTATION_ANIMATION_JUMPCUT
which was reinterpreted as seamless rotation if possible.
However this ended up being non ideal in app transition
scenarios where the rotation animation replaces the app
transition. Here we also can't seamlessly rotate, so the
window just suddenly appears with jumpcut. In fact we want
crossfade as a fallback animation and this is what distinguishes
ROTATION_ANIMATION_JUMPCUT and SEAMLESS. The problem was patched
over in N by having double-tap gestures fire camera intents
with a SEAMLESS ActivityOptions.rotationAnimationHint,
but it was too late to un-hide for consumption by apps. While here,
clean up some documentation that doesn't really parse.
Test: Manual, try the RotationAnimation activity in ApiDemos sample.
Bug: 28838855
Bug: 28823590
Change-Id: I17b5e9fa967df8ade0943337cd7b6c3956d3a499
on a per RenderNode basis. With Skia renderer we
see 30% speed improvement in Invalidate Tree UI Jank test,
when SkiaDisplayList objects are reused.
Test: manually built and run on angler-eng.
Change-Id: Ie4ec50ddb2015150e3ec678dde7ebed0c8d90067
